draft-ietf-rtgwg-igp-shortcut-00.txt   draft-ietf-rtgwg-igp-shortcut-01.txt 
Network Working Group Naiming Shen Network Working Group Naiming Shen
INTERNET DRAFT Redback Networks INTERNET DRAFT Redback Networks
Category: Informational Henk Smit Category: Informational Henk Smit
Expiration Date: October 2004 Expiration Date: November 2004
April 2004 May 2004
Calculating IGP Routes Over Traffic Engineering Tunnels Calculating IGP Routes Over Traffic Engineering Tunnels
draft-ietf-rtgwg-igp-shortcut-00.txt draft-ietf-rtgwg-igp-shortcut-01.txt
1. Status of this Memo 1. Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 38 skipping to change at page 1, line 39
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
2. Abstract 2. Abstract
This document describes how conventional hop-by-hop link-state This document describes how conventional hop-by-hop link-state
routing protocols interact with new Traffic Engineering capabilities routing protocols interact with new Traffic Engineering capabilities
to create IGP shortcuts. In particular this document describes how to create IGP shortcuts. In particular this document describes how
Dijkstra's SPF algorithm should be adapted so that link-state IGPs Dijkstra's SPF algorithm can be adapted so that link-state IGPs
will calculate IP routes to forward traffic over tunnels that are will calculate IP routes to forward traffic over tunnels that are
set up by Traffic Engineering. set up by Traffic Engineering.
3. Introduction 3. Introduction
Link-state protocols like integrated IS-IS [1] and OSPF [2] use Link-state protocols like integrated IS-IS [1] and OSPF [2] use
Dijkstra's SPF algorithm to compute a shortest path tree to all nodes Dijkstra's SPF algorithm to compute a shortest path tree to all nodes
in the network. Routing tables are derived from this shortest path in the network. Routing tables are derived from this shortest path
tree. The routing tables contain tuples of destination and first-hop tree. The routing tables contain tuples of destination and first-hop
information. If a router does normal hop-by-hop routing, the first- information. If a router does normal hop-by-hop routing, the first-
hop will be a physical interface attached to the router. hop will be a physical interface attached to the router.
New traffic engineering algorithms calculate explicit routes to one New traffic engineering algorithms calculate explicit routes to one
or more nodes in the network. At the router that originates explicit or more nodes in the network. At the router that originates explicit
routes, such routes can be viewed as logical interfaces which supply routes, such routes can be viewed as logical interfaces which supply
Label Switched Paths through the network. In the context of this Label Switched Paths through the network. In the context of this
document we refer to these Label Switched Paths as Traffic document we refer to these Label Switched Paths as Traffic
Engineering tunnels (TE-tunnels). Such capabilities are specified Engineering tunnels (TE-tunnels). Such capabilities are specified
in [3] and [4]. in [3] and [4].
This document describes how Link-state IGPs can make use of these The existence of TE-tunnels in the network and how the traffic
shortcuts, and how they can install routes in the routing table that in the network is switched over those tunnels are orthogonal
point out over these TE-tunnels. Because these tunnels use explicit issues. A node may define static routes pointing to the TE-tunnels;
routes, the path taken by a TE-tunnel is controlled by the router it may match the recursive route next-hop with the TE-tunnel
that is the head-end of the tunnel. In the absence of errors, TE- end-point address; or it may define local policy such as affinity
tunnels are guaranteed not to loop. But routers must agree on how to based tunnel selection for switching certain traffic. This document
use TE-tunnels. Otherwise traffic might loop via two or more tunnels. describes a mechanism utilizing link-state IGPs to dynamically
install IGP routes over those TE-tunnels.
The tunnels under consideration are tunnels created explicitly by
the node performing the calculation, and with an end-point address
known to this node. For use in algorithms such as the one described
in this document, it does not matter whether the tunnel itself is
strictly or loosely routed. A simple constraint can ensure that the
mechanism being loop free. When a router chooses to inject a packet
addressed to a destination D, the router may inject the packet into
a tunnel where the end-point is closer, according to link-state
IGP topology, to the destination D than the injecting router is.
In other words, the tail-end of the tunnel has to be a downstream
IGP node for the destination D. The algorithms that follow are one
way that a router may obey this rule and dynamically make
intelligent choices about when to use TE-tunnels for traffic.
This algorithm may be used in conjunction with other mechanisms
such as statically defined routes over TE-tunnels or traffic flow
and QoS based TE-tunnel selection.
This IGP shortcut mechanism assumes the TE-tunnels have already
been setup. The TE-tunnels in the network may be used for
QoS, bandwidth, redundancy or fastreroute reasons. When IGP
shortcut mechanism is applied on those tunnels, or other
mechanisms are used in conjunction with IGP shortcut, the
physical traffic switching through those tunnels may not
match the initial traffic engineering setup goal. Also the
traffic pattern in network may change with time. Some forwarding
plane measurement and feedback into the adjustment of TE-tunnel
attributes need to be there to ensure the network being
traffic engineered efficiently [6].
4. Enhancement to the Shortest Path First computation 4. Enhancement to the Shortest Path First computation
During each step of the SPF computation, a router discovers the path During each step of the SPF computation, a router discovers the path
to one node in the network. If that node is directly connected to the to one node in the network. If that node is directly connected to the
calculating router, the first-hop information is derived from the calculating router, the first-hop information is derived from the
adjacency database. If a node is not directly connected to the adjacency database. If a node is not directly connected to the
calculating router, it inherits the first-hop information from the calculating router, it inherits the first-hop information from the
parent(s) of that node. Each node has one or more parents. Each node parent(s) of that node. Each node has one or more parents. Each node
is the parent of zero or more down-stream nodes. is the parent of zero or more down-stream nodes.
skipping to change at page 4, line 23 skipping to change at page 4, line 54
While this scheme works well, in some networks it might be useful to While this scheme works well, in some networks it might be useful to
change the cost of the path over a TE-tunnel, to make the route over change the cost of the path over a TE-tunnel, to make the route over
the TE-tunnel less or more preferred than other routes. the TE-tunnel less or more preferred than other routes.
For instance when equal cost paths exist over a TE-tunnel and over a For instance when equal cost paths exist over a TE-tunnel and over a
native IP path, by adjusting the cost of the path over the TE-tunnel, native IP path, by adjusting the cost of the path over the TE-tunnel,
we can force traffic to prefer the path via the TE-tunnel, to prefer we can force traffic to prefer the path via the TE-tunnel, to prefer
the native IP path, or to load-balance among them. Another example is the native IP path, or to load-balance among them. Another example is
when multiple TE-tunnels go to the same or different destinations. when multiple TE-tunnels go to the same or different destinations.
Adjusting TE-tunnel metrics can force the traffic to prefer some TE- Adjusting TE-tunnel metrics can force the traffic to prefer some
tunnels over others regardless of underlining IGP cost to those TE-tunnels over others regardless of underlining IGP cost to those
destinations. destinations.
Setting a manual metric on a TE-tunnel does not impact the SPF Setting a manual metric on a TE-tunnel does not impact the SPF
algorithm itself. It only affects comparison of the new route with algorithm itself. It only affects comparison of the new route with
existing routes in the routing table. Existing routes can be either existing routes in the routing table. Existing routes can be either
IP routes to another router that advertises the same IP prefix, or it IP routes to another router that advertises the same IP prefix, or it
can be a path to the same router, but via a different outgoing can be a path to the same router, but via a different outgoing
interface or different TE-tunnel. All routes to IP prefixes interface or different TE-tunnel. All routes to IP prefixes
advertised by the tail-end router will be affected by the TE-tunnel advertised by the tail-end router will be affected by the TE-tunnel
metric. Also the metrics of paths to routers that are downstream of metric. Also the metrics of paths to routers that are downstream of
the tail-end router will be influenced by the manual TE-tunnel the tail-end router will be influenced by the manual TE-tunnel
metric. metric.
This mechanism is loop free since the TE-tunnels are source-routed This mechanism is loop free since the TE-tunnels are source-routed
and the tunnel egress is a downstream node to reach the computed and the tunnel egress is a downstream node to reach the computed
destinations. The end result of TE-tunnel metric adjustment is destinations. The end result of TE-tunnel metric adjustment is
more control over traffic loadsharing. If there is only one way more control over traffic loadsharing. If there is only one way
to reach a particular IP prefix through a single TE-tunnel, then no to reach a particular IP prefix through a single TE-tunnel, then no
matter what metric is assigned, the traffic has only one path to go. matter what metric is assigned, the traffic has only one path to go.
The routing table described in this section can be viewed as the
private RIB for the IGP. The metric is an important attribute to
the routes in the routing table. A path or paths with lower metric
will be selected over other paths for the same route in the
routing table.
6.1. Absolute and relative metrics 6.1. Absolute and relative metrics
It is possible to represent the TE-tunnel metric in two different It is possible to represent the TE-tunnel metric in two different
ways: an absolute (or fixed) metric or a relative metric, which is ways: an absolute (or fixed) metric or a relative metric, which is
merely an adjustment of the dynamic IGP metric as calculate by the merely an adjustment of the dynamic IGP metric as calculate by the
SPF computation. When using an absolute metric on a TE-tunnel, the SPF computation. When using an absolute metric on a TE-tunnel, the
cost of the IP routes in the routing table does not depend on the cost of the IP routes in the routing table does not depend on the
topology of the network. Note that this fixed metric is not only used topology of the network. Note that this fixed metric is not only used
to compute the cost of IP routes advertised by the router that is the to compute the cost of IP routes advertised by the router that is the
tail-end of the TE-tunnel, but also for all the routes that are tail-end of the TE-tunnel, but also for all the routes that are
skipping to change at page 5, line 39 skipping to change at page 6, line 26
Without TE-tunnel T1, rtrA will install IP routes X, Y and Z in the Without TE-tunnel T1, rtrA will install IP routes X, Y and Z in the
routing table with metrics 20, 30 and 40 respectively. When rtrA has routing table with metrics 20, 30 and 40 respectively. When rtrA has
brought up TE-tunnel T1 to rtrC, and if rtrA is configured with the brought up TE-tunnel T1 to rtrC, and if rtrA is configured with the
relative metric of -5 on tunnel T1, then the routes X, Y, and Z will relative metric of -5 on tunnel T1, then the routes X, Y, and Z will
be installed in the routing table with metrics 15, 25, and 35. If an be installed in the routing table with metrics 15, 25, and 35. If an
absolute metric of 5 is configured on tunnel T1, then rtrA will absolute metric of 5 is configured on tunnel T1, then rtrA will
install routes X, Y and Z all with metrics 5, 15 and 25 respectively. install routes X, Y and Z all with metrics 5, 15 and 25 respectively.
7. Security Considerations 7. Security Considerations
This document raises no new security issues. This document does not change the security aspects of IS-IS or OSPF.
Security considerations specific to each protocol still apply. For
more information see [5] and [2].
8. Acknowledgments 8. Acknowledgments
The authors would like to thank Christian Hopps for his comments The authors would like to thank Joel Halpern and Christian Hopps for
to this document. their comments to this document.
9. Full Copyright Statement 9. Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved. Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
skipping to change at page 6, line 33 skipping to change at page 7, line 21
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
10. References 10. References
[1] ISO. Information Technology - Telecommunications and [1] ISO. Information Technology - Telecommunications and
Information Exchange between Systems - Intermediate System Information Exchange between Systems - Intermediate System
to Intermediate System Routing Exchange Protocol for to Intermediate System Routing Exchange Protocol for
Use in Conjunction with the Protocol for Providing the Use in Conjunction with the Protocol for Providing the
Connectionless-Mode Network Service. ISO, 1990. Connectionless-Mode Network Service. ISO, 1990.
[2] J. Moy. OSPF Version 2. Technical Report RFC2328 Internet [2] Moy, J., "OSPF Version 2", RFC 2328, April 1998.
Engineering Task Force, 1998.
[3] D. Awduche, J. Malcolm, J. Agogbua, M. O'Dell, J. McManus, [3] D. Awduche, J. Malcolm, J. Agogbua, M. O'Dell, J. McManus,
"Requirements for Traffic Engineering Over MPLS", RFC 2702, "Requirements for Traffic Engineering Over MPLS", RFC 2702,
September 1999. September 1999.
[4] D. Awduche, et al, "RSVP-TE: Extensions to RSVP for LSP [4] D. Awduche, et al, "RSVP-TE: Extensions to RSVP for LSP
tunnels", RFC3029, December 2001. tunnels", RFC 3209, December 2001.
[5] T. Li, R. Atkinson, "Intermediate System to Intermediate System
(IS-IS) Cryptographic Authentication", RFC 3567, July 2003.
[6] D. Awduche, A. Chiu, A. Elwalid, I. Widjaja, X. Xiao,
"Overview and Principles of Internet Traffic Engineering,"
RFC-3272, May 2002.
11. Authors' Addresses 11. Authors' Addresses
Naiming Shen Naiming Shen
Redback Networks, Inc. Redback Networks, Inc.
300 Holger Way 300 Holger Way
San Jose, CA 95134 San Jose, CA 95134
Email: naiming@redback.com Email: naiming@redback.com
Henk Smit Henk Smit
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/