idnits 2.17.1 draft-ietf-rtgwg-igp-shortcut-01.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 293 has weird spacing: '...for the purpo...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 2004) is 7248 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3567 (ref. '5') (Obsoleted by RFC 5304) ** Obsolete normative reference: RFC 3272 (ref. '6') (Obsoleted by RFC 9522) Summary: 7 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Naiming Shen 3 INTERNET DRAFT Redback Networks 4 Category: Informational Henk Smit 5 Expiration Date: November 2004 6 May 2004 8 Calculating IGP Routes Over Traffic Engineering Tunnels 10 draft-ietf-rtgwg-igp-shortcut-01.txt 12 1. Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as ``work in progress.'' 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 2. Abstract 35 This document describes how conventional hop-by-hop link-state 36 routing protocols interact with new Traffic Engineering capabilities 37 to create IGP shortcuts. In particular this document describes how 38 Dijkstra's SPF algorithm can be adapted so that link-state IGPs 39 will calculate IP routes to forward traffic over tunnels that are 40 set up by Traffic Engineering. 42 3. Introduction 44 Link-state protocols like integrated IS-IS [1] and OSPF [2] use 45 Dijkstra's SPF algorithm to compute a shortest path tree to all nodes 46 in the network. Routing tables are derived from this shortest path 47 tree. The routing tables contain tuples of destination and first-hop 48 information. If a router does normal hop-by-hop routing, the first- 49 hop will be a physical interface attached to the router. 50 New traffic engineering algorithms calculate explicit routes to one 51 or more nodes in the network. At the router that originates explicit 52 routes, such routes can be viewed as logical interfaces which supply 53 Label Switched Paths through the network. In the context of this 54 document we refer to these Label Switched Paths as Traffic 55 Engineering tunnels (TE-tunnels). Such capabilities are specified 56 in [3] and [4]. 58 The existence of TE-tunnels in the network and how the traffic 59 in the network is switched over those tunnels are orthogonal 60 issues. A node may define static routes pointing to the TE-tunnels; 61 it may match the recursive route next-hop with the TE-tunnel 62 end-point address; or it may define local policy such as affinity 63 based tunnel selection for switching certain traffic. This document 64 describes a mechanism utilizing link-state IGPs to dynamically 65 install IGP routes over those TE-tunnels. 67 The tunnels under consideration are tunnels created explicitly by 68 the node performing the calculation, and with an end-point address 69 known to this node. For use in algorithms such as the one described 70 in this document, it does not matter whether the tunnel itself is 71 strictly or loosely routed. A simple constraint can ensure that the 72 mechanism being loop free. When a router chooses to inject a packet 73 addressed to a destination D, the router may inject the packet into 74 a tunnel where the end-point is closer, according to link-state 75 IGP topology, to the destination D than the injecting router is. 76 In other words, the tail-end of the tunnel has to be a downstream 77 IGP node for the destination D. The algorithms that follow are one 78 way that a router may obey this rule and dynamically make 79 intelligent choices about when to use TE-tunnels for traffic. 80 This algorithm may be used in conjunction with other mechanisms 81 such as statically defined routes over TE-tunnels or traffic flow 82 and QoS based TE-tunnel selection. 84 This IGP shortcut mechanism assumes the TE-tunnels have already 85 been setup. The TE-tunnels in the network may be used for 86 QoS, bandwidth, redundancy or fastreroute reasons. When IGP 87 shortcut mechanism is applied on those tunnels, or other 88 mechanisms are used in conjunction with IGP shortcut, the 89 physical traffic switching through those tunnels may not 90 match the initial traffic engineering setup goal. Also the 91 traffic pattern in network may change with time. Some forwarding 92 plane measurement and feedback into the adjustment of TE-tunnel 93 attributes need to be there to ensure the network being 94 traffic engineered efficiently [6]. 96 4. Enhancement to the Shortest Path First computation 98 During each step of the SPF computation, a router discovers the path 99 to one node in the network. If that node is directly connected to the 100 calculating router, the first-hop information is derived from the 101 adjacency database. If a node is not directly connected to the 102 calculating router, it inherits the first-hop information from the 103 parent(s) of that node. Each node has one or more parents. Each node 104 is the parent of zero or more down-stream nodes. 106 For traffic engineering purposes each router maintains a list of all 107 TE-tunnels that originate at this router. For each of those TE- 108 tunnel, the router at the tail-end is known. 110 During SPF, when a router finds the path to a new node (in other 111 words, this new node is moved from the TENTative list to the PATHS 112 list), the router must determine the first-hop information. There 113 are three possible ways to do this: 115 - Examine the list of tail-end routers directly reachable via a 116 TE-tunnel. If there is a TE-tunnel to this node, we use the 117 TE-tunnel as the first-hop. 119 - If there is no TE-tunnel, and the node is directly connected, we 120 will use the first-hop information from the adjacency database. 122 - If the node is not directly connected, and is not directly 123 reachable via a TE-tunnel, we will copy the first-hop 124 information from the parent node(s) to the new node. 126 The result of this algorithm is that traffic to nodes that are the 127 tail-end of TE-tunnels, will flow over those TE-tunnels. Traffic to 128 nodes that are downstream of the tail-end nodes will also flow over 129 those TE-tunnels. If there are multiple TE-tunnels to different 130 intermediate nodes on the path to destination node X, traffic will 131 flow over the TE-tunnel whose tail-end node is closest to node X. 132 In certain applications, there is a need to carry both the native 133 adjacency and the TE-tunnel next-hop information for the TE-tunnel 134 tail-end and its downstream nodes. The head-end node may 135 conditionally switch the data traffic onto TE-tunnels based on 136 user defined criteria or events; The head-end node may also split 137 flow of traffic towards either types of the next-hops; The head-end 138 node may install the routes with two different types of next-hops 139 into two separate RIBs. Multicast protocols running over physical 140 links may have to perform RPF checks using the native adjacency 141 next-hops rather than the TE-tunnel next-hops. 143 5. Special cases and exceptions 145 The Shortest Path First algorithm will find equal-cost parallel paths 146 to destinations. The enhancement described in this document does not 147 change this. Traffic can be forwarded over one or more native IP 148 paths, over one or more TE-tunnels, or over a combination of native 149 IP paths and TE-tunnels. 151 A special situation occurs in the following topology: 153 rtrA -- rtrB -- rtrC 154 | | 155 rtrD -- rtrE 157 Assume all links have the same cost. Assume a TE-tunnel is set up 158 from rtrA to rtrD. When the SPF calculation puts rtrC on the 159 TENTative list, it will realize that rtrC is not directly connected, 160 and thus it will use the first-hop information from the parent. Which 161 is rtrB. When the SPF calculation on rtrA moves rtrD from the 162 TENTative list to the PATHS list, it realizes that rtrD is the 163 tail-end of a TE-tunnel. Thus rtrA will install a route to rtrD via 164 the TE-tunnel, and not via rtrB. 166 When rtrA puts rtrE on the TENTative list, it realizes that rtrE is 167 not directly connected, and that rtrE is not the tail-end of a TE- 168 tunnel. Therefor rtrA will copy the first-hop information from the 169 parents (rtrC and rtrD) to the first-hop information of rtrE. 170 Traffic to rtrE will now load-balance over the native IP path via 171 rtrA->rtrB->rtrC, and the TE-tunnel rtrA->rtrD. 173 In the case where both parallel native IP paths and paths over TE- 174 tunnels are available, implementations can allow the network 175 administrator to force traffic to flow over only TE-tunnels (or only 176 over native IP paths) or both to be used for load sharing. 178 6. Metric adjustment of IP routes over TE-tunnels 180 When an IGP route is installed in the routing table with a TE-tunnel 181 as next hop, an interesting question is what should be the cost or 182 metric of this route ? The most obvious answer is to assign a metric 183 that is the same as the IGP metric of the native IP path as if the 184 TE-tunnels did not exist. For example, rtrA can reach rtrC over a 185 path with a cost of 20. X is an IP prefix advertised by rtrC. We 186 install the route to X in rtrA's routing table with a cost of 20. 187 When a TE-tunnel from rtrA to rtrC comes up, by default the route is 188 still installed with metric of 20, only the next-hop information for 189 X is changed. 191 While this scheme works well, in some networks it might be useful to 192 change the cost of the path over a TE-tunnel, to make the route over 193 the TE-tunnel less or more preferred than other routes. 195 For instance when equal cost paths exist over a TE-tunnel and over a 196 native IP path, by adjusting the cost of the path over the TE-tunnel, 197 we can force traffic to prefer the path via the TE-tunnel, to prefer 198 the native IP path, or to load-balance among them. Another example is 199 when multiple TE-tunnels go to the same or different destinations. 200 Adjusting TE-tunnel metrics can force the traffic to prefer some 201 TE-tunnels over others regardless of underlining IGP cost to those 202 destinations. 204 Setting a manual metric on a TE-tunnel does not impact the SPF 205 algorithm itself. It only affects comparison of the new route with 206 existing routes in the routing table. Existing routes can be either 207 IP routes to another router that advertises the same IP prefix, or it 208 can be a path to the same router, but via a different outgoing 209 interface or different TE-tunnel. All routes to IP prefixes 210 advertised by the tail-end router will be affected by the TE-tunnel 211 metric. Also the metrics of paths to routers that are downstream of 212 the tail-end router will be influenced by the manual TE-tunnel 213 metric. 215 This mechanism is loop free since the TE-tunnels are source-routed 216 and the tunnel egress is a downstream node to reach the computed 217 destinations. The end result of TE-tunnel metric adjustment is 218 more control over traffic loadsharing. If there is only one way 219 to reach a particular IP prefix through a single TE-tunnel, then no 220 matter what metric is assigned, the traffic has only one path to go. 222 The routing table described in this section can be viewed as the 223 private RIB for the IGP. The metric is an important attribute to 224 the routes in the routing table. A path or paths with lower metric 225 will be selected over other paths for the same route in the 226 routing table. 228 6.1. Absolute and relative metrics 230 It is possible to represent the TE-tunnel metric in two different 231 ways: an absolute (or fixed) metric or a relative metric, which is 232 merely an adjustment of the dynamic IGP metric as calculate by the 233 SPF computation. When using an absolute metric on a TE-tunnel, the 234 cost of the IP routes in the routing table does not depend on the 235 topology of the network. Note that this fixed metric is not only used 236 to compute the cost of IP routes advertised by the router that is the 237 tail-end of the TE-tunnel, but also for all the routes that are 238 downstream of this tail-end router. For example, if we have TE- 239 tunnels to two core routers in a remote POP, and one of them is 240 assigned with absolute metric of 1, then all the traffic going to 241 that POP will traverse this low-metric TE-tunnel. 243 By setting a relative metric, the cost of IP routes in the routing 244 table is based on the IGP metric as calculated by the SPF 245 computation. This relative metric can be a positive or a negative 246 number. Not configuring a metric on a TE-tunnel is a special case of 247 the relative metric scheme. No metric is the same as a relative 248 metric of 0. The relative metric is bounded by minimum and maximum 249 allowed metric values while the positive metric disables the 250 TE-tunnel in the SPF calculation. 252 6.2. Examples of metric adjustment 254 Assume the following topology. X, Y and Z are IP prefixes advertised 255 by rtrC, rtrD and rtrE respectively. T1 is a TE-tunnel from rtrA to 256 rtrC. Each link in the network has an IGP metric of 10. 258 ===== T1 =====> 259 rtrA -- rtrB -- rtrC -- rtrD -- rtrE 260 10 10 | 10 | 10 | 261 X Y Z 263 Without TE-tunnel T1, rtrA will install IP routes X, Y and Z in the 264 routing table with metrics 20, 30 and 40 respectively. When rtrA has 265 brought up TE-tunnel T1 to rtrC, and if rtrA is configured with the 266 relative metric of -5 on tunnel T1, then the routes X, Y, and Z will 267 be installed in the routing table with metrics 15, 25, and 35. If an 268 absolute metric of 5 is configured on tunnel T1, then rtrA will 269 install routes X, Y and Z all with metrics 5, 15 and 25 respectively. 271 7. Security Considerations 273 This document does not change the security aspects of IS-IS or OSPF. 274 Security considerations specific to each protocol still apply. For 275 more information see [5] and [2]. 277 8. Acknowledgments 279 The authors would like to thank Joel Halpern and Christian Hopps for 280 their comments to this document. 282 9. Full Copyright Statement 284 Copyright (C) The Internet Society (2002). All Rights Reserved. 285 This document and translations of it may be copied and furnished to 286 others, and derivative works that comment on or otherwise explain it 287 or assist in its implementation may be prepared, copied, published 288 and distributed, in whole or in part, without restriction of any 289 kind, provided that the above copyright notice and this paragraph are 290 included on all such copies and derivative works. However, this 291 document itself may not be modified in any way, such as by removing 292 the copyright notice or references to the Internet Society or other 293 Internet organizations, except as needed for the purpose of 294 developing Internet standards in which case the procedures for 295 copyrights defined in the Internet Standards process must be 296 followed, or as required to translate it into languages other than 297 English. 299 The limited permissions granted above are perpetual and will not be 300 revoked by the Internet Society or its successors or assigns. 302 This document and the information contained herein is provided on an 303 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 304 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 305 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 306 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 307 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 309 10. References 311 [1] ISO. Information Technology - Telecommunications and 312 Information Exchange between Systems - Intermediate System 313 to Intermediate System Routing Exchange Protocol for 314 Use in Conjunction with the Protocol for Providing the 315 Connectionless-Mode Network Service. ISO, 1990. 317 [2] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 319 [3] D. Awduche, J. Malcolm, J. Agogbua, M. O'Dell, J. McManus, 320 "Requirements for Traffic Engineering Over MPLS", RFC 2702, 321 September 1999. 323 [4] D. Awduche, et al, "RSVP-TE: Extensions to RSVP for LSP 324 tunnels", RFC 3209, December 2001. 326 [5] T. Li, R. Atkinson, "Intermediate System to Intermediate System 327 (IS-IS) Cryptographic Authentication", RFC 3567, July 2003. 329 [6] D. Awduche, A. Chiu, A. Elwalid, I. Widjaja, X. Xiao, 330 "Overview and Principles of Internet Traffic Engineering," 331 RFC-3272, May 2002. 333 11. Authors' Addresses 335 Naiming Shen 336 Redback Networks, Inc. 337 300 Holger Way 338 San Jose, CA 95134 339 Email: naiming@redback.com 341 Henk Smit 342 Email: hhwsmit@xs4all.nl