idnits 2.17.00 (12 Aug 2021) /tmp/idnits62525/draft-fedyk-mpls-te-metrics-00.txt: 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? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 487 lines 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 -- 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 (October 1999) is 8247 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 2702 (ref. 'TEREQ') == Outdated reference: draft-ietf-isis-traffic has been published as RFC 3784 ** Downref: Normative reference to an Informational draft: draft-ietf-isis-traffic (ref. 'ISIS') == Outdated reference: draft-katz-yeung-ospf-traffic has been published as RFC 3630 == Outdated reference: draft-ietf-mpls-cr-ldp has been published as RFC 3212 == Outdated reference: draft-ietf-mpls-rsvp-lsp-tunnel has been published as RFC 3209 Summary: 6 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Traffic Engineering Working Group Don Fedyk 2 Internet Draft Anoop Ghanwani 3 Expiration Date: April 2000 5 Nortel Networks Corp. 7 October 1999 9 Metrics and Resource Classes for Traffic Engineering 11 draft-fedyk-mpls-te-metrics-00.txt 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsolete by other documents 25 at any time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Abstract 36 There has recently been a lot of activity in defining the components 37 for MPLS-based traffic engineering. This includes the recent 38 extensions of the Interior Gateway Protocols (IGPs) to carry metrics 39 and resource class information about links. This memo explores 40 additional metrics that are useful for traffic engineering. We also 41 describe some of the subtleties associated with the use of the 42 resource class (or color) vector that has been defined in the IGP 43 extensions. 45 Fedyk, et. al. 1 46 1. Introduction 48 Present-day IP networks do not have much support for traffic 49 engineering features. To address this issue, many of the working 50 groups are working together to define the methodologies that are 51 required for providing traffic engineering features [TEREQ]. 52 Basically, there has been activity in the following areas: 54 - Extension of the IGP routing protocols (OSPF and IS-IS) for 55 carrying additional metrics and resource class information about 56 links [OSPF,ISIS]; and 58 - Providing signaling support for traffic engineering via MPLS 59 [RSVP,CRLDP]. 61 This draft provides a brief overview of different metrics that are 62 useful for traffic engineering. We argue that it is better to allow 63 the advertisement of multiple metrics because they can in fact be 64 used when performing connection-oriented routing as would be the 65 case in a network running MPLS. In the past, there have been 66 attempts to define multiple metric types. However, IP is based on a 67 connectionless routing paradigm and therefore it is difficult to 68 provide a scalable solution that is able to use multiple metrics. 69 One of the reasons for this is that every router in the network 70 would need to maintain separate shortest-path spanning trees, one 71 for each metric type. This is not an issue with a network running 72 MPLS-based traffic engineering. The routes for traffic engineering 73 label switched paths (LSPs) can be computed on demand, and therefore 74 different metrics may be used for each LSP. For example, it may be 75 desirable to minimize the economic cost of the path for one LSP, 76 while for another LSP the goal may be minimizing the end-to-end 77 delay. Note that we are not recommending that the multiple 78 advertised metrics be used simultaneously; the multiple constraint 79 problem is known to be NP-complete. It is simply desirable to use a 80 different metric for path selection depending on the requirements of 81 the LSP. 83 The remainder of this draft is organized as follows. Section 2 84 discusses different routing metrics. Section 3 discusses the use of 85 metrics in traffic engineering and provides a recommendation for the 86 metrics that should be advertised by routing protocols. Section 4 87 discusses the use of the resource class vector, a new field that is 88 being advertised by the IGP routing protocols, but about which 89 little has been said so far. 91 2. Routing Metrics 93 A metric is a weight that is assigned to links in the network to 94 indicate the relative preference of a link during path computation. 95 Usually, metrics are selected so that they allow the computation of 96 paths that meet certain constraints. Metrics for path selection can 97 be classified using the following two criteria: 99 Fedyk, et. al. April 2000 2 100 - Additive/non-additive: This refers to whether or not the path 101 metric is obtained by adding the metric value for all links in the 102 path. Examples of additive constraints include delay and hop 103 count. Bandwidth is an example of a non-additive constraint. On 104 the other hand, it is also possible to look at bandwidth as an 105 additive metric by using link costs that are in inverse proportion 106 to available bandwidth; in such cases, the shortest path 107 corresponds to the path with the most bandwidth. 109 - Static/dynamic: A static metric doesn't change with time. This 110 includes metrics such as hop count and propagation delay of a 111 link. A dynamic metric changes with traffic conditions in the 112 network. An example is bandwidth and queuing delays on a link. 114 Metrics are typically assigned positive numbers. Additive metrics 115 can have a fairly large range of values starting from a small 116 positive number and going all the way up to infinity, which in 117 reality means there is no connection. As long as the additive 118 metric is a positive number the routing systems can converge on loop 119 free paths. In all metric schemes, there is a maximum metric, that 120 means no connection, but there may be other limits due to the 121 dynamic range. It is often challenging to find good ways to 122 efficiently represent the complete dynamic range of metric values. 123 One result of this is that many of the standards-based metrics are 124 simple small integer values with a limited dynamic range. 126 The four factors of bandwidth, delay, delay-jitter and loss or error 127 probability are often driving forces in the determination of 128 metrics. The commonly used metrics include but are not limited to: 130 - Hop count 131 - Bandwidth 132 - Delay 133 - Administrative cost 134 - Economic cost 136 A brief description of each of these metric types follows. 138 2.1 Hop-based metrics 140 A Hop based metric is used to minimize the number of intermediate 141 switches traversed, thereby minimizing the resources used in the 142 network. It also, therefore maximizes the number of equal cost 143 paths in a network. The hop-based metric is also the degenerative 144 form of many other metric types when the link attributes are 145 considered equal. This type can be used to maximize the number of 146 equal cost paths to a destination for load sharing schemes. 148 2.2 Bandwidth-based metrics 150 Fedyk, et. al. April 2000 3 151 A Bandwidth based metric is used to find the fewest large pipes to 152 the destination. This metric can be assigned in a relative fashion 153 or it can be algorithmically determined. Algorithmic determination 154 has proven to be a challenge since the dynamic range of links has 155 changed from 10^2 to 10^12 over the years, and is expected to go 156 beyond this in future. This complete range is not usually used at a 157 single time in a domain a range of 10^5 between the highest and 158 lowest link speeds are not uncommon. The formula for determination 159 is usually in the form of the reciprocal of bandwidth. A 16 to 32 160 bit number is usually required to represent this effectively in an 161 integer format. 163 Bandwidth metrics that are not algorithmically determined use a 164 coarse representation of bandwidth rather than a true value. A 165 bandwidth-based metric is a true minimizing metric since traffic 166 that uses the higher speed links is more likely to get through. 168 2.2.1 Bandwidth Usage 170 An absolute bandwidth available at holding priority has been added 171 for Traffic Engineering [OSPF,ISIS]. LSPs that specify traffic 172 parameters with bandwidth allocations can use this usage-based 173 metric instead of the bandwidth metric to ensure sufficient 174 bandwidth allocation. In a sense, this is a dynamic metric. 176 2.3 Delay-based metrics 178 Static delay based metrics have been used for representing the 179 propagation and the emission delay of a link. This metric is used 180 to minimize the end-to-end delay experienced by a packet. The 181 propagation delay is a fixed quantity that is related to the medium 182 and the physical distance that the signal travels. The emission 183 delay is related to the time that it takes to transmit a packet from 184 the fist bit sent to the last bit sent. This is a function of the 185 bandwidth of the link. The combination of emission and propagation 186 delay for a given packet size yields a value that represents the 187 minimum delay that a packet would experience when sent from one node 188 to the other. This is a fixed number. 190 The delay metric represents a number of milliseconds or 191 microseconds. Again the dynamic range of links has some bearing on 192 the emission delay but the propagation delay tends to be stable in 193 the millisecond range. The link speed is a gauge of how reliable 194 the delay metric is since, as link speed increases the emission 195 component becomes negligible. 197 2.4 Economic cost or expense-based metrics 199 Cost based metrics are assigned based on attributes of links that 200 represent a usage cost for a link. These are not to be confused with 201 administrative weight. With the advent of usage charging for 202 services such as Frame Relay and ATM, and the use of tunnels over 204 Fedyk, et. al. April 2000 4 205 these technologies, a true cost per traffic sent can be calculated. 206 The value of this type of metric is that traffic that does not want 207 to incur charges for using a link or set of links. 209 2.5 Administrative weight 211 This metric is assigned based on a combination of factors. The 212 administrated weight attempts to meld several of the other metric 213 attributes into a single metric. The weight can be adjusted. This 214 type of metric is commonly used to differentiate links that differ 215 from one another by some characteristic. It is important to realize 216 that this is a significant compromise for traffic engineering since 217 the melding of metric types reduces the ability to differentiate 218 routes. 220 3. Traffic engineering trends 222 Recently, in the MPLS traffic engineering space, the addition of 223 bandwidth reservation and allocation statistics represents dynamic 224 information that can be used to engineer LSPs that have traffic 225 parameters. 227 3.1 Multiple traffic engineering (TE) metrics 229 Included with the recent work is the introduction of a new single 230 metric for traffic engineering. 232 However, the introduction of a single metric is limiting since 233 traffic engineering can have the goal of maximizing throughput, 234 minimizing hops, minimizing delay or distance, minimizing cost or 235 minimizing resource usage. 237 In such systems the metric type chosen is a guide to generating 238 paths and will attempt to minimize the metric subject to the other 239 constraints. There is little overhead for advertising multiple 240 metrics for traffic engineering since only the static metrics need 241 to be propagated. 243 3.2 Bandwidth allocation for MPLS TE 245 Bandwidth allocation of MPLS TE LSPs with traffic parameters 246 represents a usage-based constraint that is dynamic. As bandwidth is 247 consumed on a link, new LSPs must look for other links to satisfy 248 their bandwidth requirements. 250 Interestingly enough, the value of maximizing throughput is not 251 required for paths that specify minimum traffic profiles and 252 allocate bandwidth. 254 3.3 Metric recommendation 256 Fedyk, et. al. April 2000 5 257 It is recommended that at least four additional metrics be defined 258 for traffic engineering, in addition to the single metric that is 259 used for connectionless IP routing. This would yield the following 260 5 metrics: 262 - Connectionless Metric (for use with connectionless routing) 263 - Traffic Engineering Metric 1 (32 bits) 264 - Traffic Engineering Metric 2 (32 bits) 265 - Traffic Engineering Metric 3 (32 bits) 266 - Reserved (32 bits) 268 The connectionless metric may be used to route LSPs along routes 269 that would be selected by the IGP for connectionless routing. 271 It is network administrative decision on whether a metric is 272 supported. The dynamic range of 32 is more than sufficient for the 273 metrics. 275 A possible definition of the TE metrics could be: 277 - TE Metric 1: Delay Based Metric (Minimize delay) 278 - TE Metric 2: Cost/Administrative Based Metric (Minimize cost) 279 - TE Metric 3: Hop based Metric (Minimize resource usage) 281 4. Resource classes 283 The IGPs have recently been extended to carry a resource class or 284 color vector for every link. This vector is 32 bits long and 285 represents certain characteristics that the link satisfies. Little 286 has been said about the expected use of this field. This section 287 describes some of the ways it may be used and the subtleties 288 associated with it. 290 4.1 Using the resource class or color vector 292 The resource class vector is one of the attributes flooded by the 293 IGP, and is used by routers for computing a constraint-based path 294 that uses only those links that satisfy the required criteria. The 295 flooding scope of this information is a single area in OSPF and 296 level-1 in IS-IS. When computing a constraint-based route that 297 traverses links in a single area, the router computing the path uses 298 this information to determine which links satisfy the requested 299 criteria. In this case, it is not necessary to carry the color 300 vector of the request in the setup message. However, when setting 301 up a hierarchical constraint-based route (i.e. one that traverses 302 multiple areas), it becomes necessary to carry the resource class 303 vector that is desired for the label switched path (LSP). When a 304 router receives a request message during path setup, it would be 305 expected to perform the following logical operation: 307 Fedyk, et. al. April 2000 6 308 ((color vector of request) & (color vector of link)) == 309 (color vector of request) 311 The request gets forwarded only if the above expression evaluates to 312 TRUE. If a suitable link cannot be found, the request is rejected. 314 Using the above operation, there are two basic definitions of bits 315 in the color vector that can be supported: 317 The link attribute is taken from a set of attributes. A given link 318 may match one or more of these attributes requiring a bit to be set 319 in that position. 321 A link satisfies a certain attribute up to a numeric value (e.g. a 322 link has a security level of 5). In that case, all of the bits that 323 correspond to that numeric value or lower must be set high at the 324 time of configuration. Note that in the second case, there is some 325 interdependence between the bits that must be taken into account 326 while creating the color vector for the link. For example, in a 327 system where links are rated with one of 8 levels of a certain 328 attribute, the links at each level would have the following colors: 330 Level 0: 10000000 331 Level 1: 11000000 332 Level 2: 11100000 333 .. 334 Level 8: 11111111 336 There are two drawbacks to using the simple operation defined above: 338 First, the usage of bits is sub-optimal; n levels of a particular 339 characteristic require n bits in the color vector. While n levels 340 of a certain characteristic can be represented with just lg(n) bits, 341 it would require the capability to perform operations such as _less 342 than_ and _greater than_. 344 Second, the above operation cannot support the case where there are 345 three or more attributes in a set, of which some unordered subset of 346 those is acceptable. For instance, if we have _link type_ as a 347 characteristic and we classify links as terrestrial, low-orbit 348 satellite and high-orbit satellite links, and if we wish to request 349 either terrestrial or low-orbit satellite links, there is no way to 350 do that. However, if the same set was ordered by lower delay, (e.g. 351 terrestrial, low-orbit satellite, high orbit satellite) then as an 352 ordered subset this would still work. 354 4.2 Link characteristics 356 A few examples of link characteristics that might be desirable to 357 have in the color vector include: 359 Fedyk, et. al. April 2000 7 360 Satellite/terrestrial: A link can be either a satellite link or a 361 terrestrial link. When making a request, the user can specify the 362 use of only terrestrial links, or satellite links, or either. 364 Security level: A link can be rated as being at one of eight 365 security levels ranging from completely insecure to highest security 366 with levels in between. A typical request would be to use only 367 links with a security of 5 or higher for the connection. 369 Link reliability: A link can be rated as being very reliable 370 (possibly a link with automatic protection switching at the link 371 layer) to one which is highly unreliable (i.e. loss characteristics 372 of the link may be subject to weather or solar activity). This 373 factor really is a function of loss rate and availability of a link. 374 Some forms of transmission such as radio-based wireless and 375 microwave are susceptible to weather conditions. These mediums are 376 suitable for certain types of traffic. 378 4.3 Standardizing resource classes 380 It is worthwhile to explore the demand for standardized resource 381 masks. This will allow requests to propagate seamlessly across 382 areas since the semantics of the bits will have a universal value. 383 One way to do this could be to have global and local subsets of the 384 color mask. The bit semantics of the global portion would be 385 standardized, while the bit semantics for the local portion would be 386 left for definition by the developers/users of the router. The 387 present color vector can be split equally into global and local 388 portions as follows: 390 0 1 2 3 391 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 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | Globally significant | Local use | 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 Bits 0-15: Global use 398 Bit 0: satellite 399 Bit 1: terrestrial 400 Bit 2: highest reliability 401 Bit 3: high reliability 402 Bit 4: medium reliability 403 Bit 5: low reliability 404 Bits 6-15: reserved 406 Bits 16-32: Local use 408 6. Security considerations 410 This document raises no new security issues. 412 Fedyk, et. al. April 2000 8 413 5. Acknowledgements 415 The authors are grateful to Bilel Jamoussi, Peter Ashwood-Smith and 416 Darek Skalecki for their helpful comments on the document. 418 6. References 420 [TEREQ] D. Awduche et al., "Requirements for traffic engineering 421 over MPLS," RFC 2702, September 1999. 423 [ISIS] H. Smit, T. Lee, "IS-IS extensions for traffic engineering," 424 Internet Draft, draft-ietf-isis-traffic-01.txt, May 1999. 426 [OSPF] D. Katz, D. Yeung, "Traffic engineering extensions to OSPF," 427 Internet Draft, draft-katz-yeung-ospf-traffic-00.txt, April 1999. 429 [CRLDP] B. Jamoussi et al., "Constraint-based LSP setup using LDP," 430 Internet Draft, draft-ietf-mpls-cr-ldp-03.txt, September 1999. 432 [RSVP] D. Awduche et al., "Extensions to RSVP for LSP tunnels," 433 Internet Draft, draft-ietf-mpls-rsvp-lsp-tunnel-04.txt, September 434 1999. 436 7. Authors' Addresses 438 Don Fedyk Anoop Ghanwani 439 Nortel Networks Corp. Nortel Networks Corp. 440 600 Technology Park Drive 600 Technology Park Drive 441 Billerica, MA 01821 Billerica, MA 01821 442 USA USA 443 Phone: +1-978-288-4506 Phone: +1-978-288-4514 444 dwfedyk@nortelnetworks.com aghanwan@nortelnetworks.com 446 Full Copyright Statement 448 "Copyright (C) The Internet Society (1999). All Rights Reserved. 449 This document and translations of it may be copied and furnished to 450 others, and derivative works that comment on or otherwise explain it 451 or assist in its implementation may be prepared, copied, published 452 and distributed, in whole or in part, without restriction of any 453 kind, provided that the above copyright notice and this paragraph 454 are included on all such copies and derivative works. However, this 455 document itself may not be modified in any way, such as by removing 456 the copyright notice or references to the Internet Society or other 457 Internet organizations, except as needed for the purpose of 459 Fedyk, et. al. April 2000 9 460 developing Internet standards in which case the procedures for 461 copyrights defined in the Internet Standards process must be 462 followed, or as required to translate it into languages other than 463 English. 465 The limited permissions granted above are perpetual and will not be 466 revoked by the Internet Society or its successors or assigns. 468 Fedyk, et. al. April 2000 10