idnits 2.17.00 (12 Aug 2021) /tmp/idnits6008/draft-fedyk-isis-ospf-te-metrics-01.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 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. ** The abstract seems to contain references ([ISIS], [OSPF], [GMPLSR]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (November 2000) is 7850 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) == Unused Reference: 'CRLDP' is defined on line 296, but no explicit reference was found in the text == Unused Reference: 'RSVP-TE' is defined on line 299, but no explicit reference was found in the text ** 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 ** Downref: Normative reference to an Informational RFC: RFC 2386 (ref. 'QOSR') == Outdated reference: draft-ietf-isis-gmpls-extensions has been published as RFC 4205 ** Downref: Normative reference to an Informational draft: draft-ietf-isis-gmpls-extensions (ref. 'GMPLSR') Summary: 9 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Don Fedyk 2 Internet Draft (Nortel Networks) 3 Expiration Date: May 2001 4 Anoop Ghanwani 5 Rajesh Balay 6 (Cosine Communications) 8 Jerry Ash 9 (AT&T) 11 Alain Vedrenne 12 (SITA Equant) 14 November 2000 16 Multiple Metrics for Traffic Engineering with IS-IS and OSPF 18 draft-fedyk-isis-ospf-te-metrics-01.txt 20 Status of this Memo 22 This document is an Internet-Draft and is in full conformance with all 23 provisions of Section 10 of RFC2026. 25 Internet-Drafts are working documents of the Internet Engineering Task 26 Force (IETF), its areas, and its working groups. Note that other groups 27 may also distribute working documents as Internet-Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsolete by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference material 32 or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 Abstract 42 This draft describes optional sub-TLVs that can be used to extend IGPs 43 to support multiple metrics for use with traffic engineering. These 44 optional extensions are an addendum to the existing work on traffic 45 engineering extensions to OSPF and ISIS. While the current 46 specifications allow advertising only one metric, the ability to 48 Fedyk, et. al. 1 49 advertise multiple metrics has proven to be very useful in similar 50 systems. The encoding for the proposed optional sub-TLVs is also 51 specified. This draft is intended to complement and extend the existing 52 work in [OSPF], [ISIS] and [GMPLSR]. 54 1. Introduction 56 Present-day IP networks do not have many of the features required for 57 supporting traffic engineering. To address this issue, several IETF 58 Working Groups are working together to define the methodologies that 59 are required for providing traffic engineering features [TEREQ]. 60 Basically, there has been activity in the following areas: 62 - Extensions to IGP routing protocols (OSPF and IS-IS) for carrying 63 an additional metric, and bandwidth and resource class information 64 about links [OSPF,ISIS]; and 66 - Signaling support for traffic engineering via MPLS [CRLDP, RSVP- 67 TE]. 69 The extensions for traffic engineering currently allow for only one 70 routing metric. However, it is advantageous to allow the advertisement 71 of multiple metrics because they can be used very effectively in a 72 network running MPLS. In IP networks in the past, multiple routing 73 metrics, even if defined, were not widely used. This is because 74 traditional IP networks are based on a connectionless routing paradigm. 75 For such networks, it has proven difficult to provide a scalable 76 solution that uses multiple metrics. Since the routes must be computed 77 in advance before any data arrives at the router, it places a 78 significant burden on the router if it needs to compute separate 79 routing tables for each metric. Furthermore, there is the issue of how 80 to select which route a particular packet should use. See [QOSR] for a 81 comprehensive study of the QoS routing problem and issues with multiple 82 metrics and how these can be used. 84 The scalability issue described above is not a concern for networks 85 running MPLS, because the routes for traffic engineering label switched 86 paths (LSPs) may be computed on demand, and therefore a different 87 routing metric may be used for each LSP. Existing connection-oriented 88 systems that are non-IP based already have multiple metrics. For 89 example, it may be desirable to minimize the economic cost of the path 90 for one LSP, while for another LSP the goal may be minimizing the end- 91 to-end delay. In other words, we are not recommending that the 92 multiple advertised metrics be used simultaneously during path 93 selection; that problem is known to be NP-complete. Instead, we would 94 like to be able to use a different metric for path selection depending 95 on the requirements of the LSP. Of course, clever approximation 96 algorithms may be able to make use of more than one metric for path 97 selection for a given LSP. 99 Fedyk, et. al. Expires September 2000 2 100 Therefore in this draft, a set of new sub-TLVs is proposed that will 101 allow OSPF and ISIS to advertise multiple metrics for traffic 102 engineering. These sub-TLVs are optional; a particular implementation 103 may optionally choose to support one or more of them. 105 The remainder of this draft is organized as follows. Section 2 106 discusses the extensions to IS-IS and OSPF for advertising multiple 107 metrics. Section 3 discusses reasons for different routing metrics. 109 2. Optional traffic engineering metrics for IS-IS and OSPF 111 As a part of the recent IGP extensions for traffic engineering, a new 112 routing metric called the Traffic Engineering Default Metric was 113 introduced. The introduction of only a single metric is limiting. For 114 example, it may be desirable to minimize hops, minimize delay or 115 distance, minimize cost, or minimize resource usage, in the same 116 network for different LSPs. 118 Three optional metrics are defined by this document for use in traffic 119 engineering. These are in addition to the Default TE Metric [ISIS, 120 OSPF]. The most pressing need is for a delay-based metric, but 121 defining additional metrics has added advantages. 123 For example, having multiple metrics allows easy migration from one 124 metric to another. A network operator may start out by using the first 125 metric for delay expressed as milliseconds, and then later migrate to 126 using delays expressed as hundreds of microseconds by using one of the 127 _free_ metrics in the network. Also, it makes the introduction of new 128 metrics easier eliminating the need for vendor proprietary extensions, 129 even if the metric is only for experimental use. 131 The actual metric type that is being advertised is specific to a 132 service provider and does not need to be standardized. Consistency of 133 the metric type is only required within the domain on which the path 134 selection algorithm is being run. 136 2.2 New sub-TLVs for IS-IS 138 The optional metrics are sub-TLVs carried within the Extended IS 139 Reachability TLV, whose TLV type is 22. The new sub-TLVs are: 141 - Traffic Engineering Optional Metric 1 (sub-TLV type TBD, length 142 3 octets); 143 - Traffic Engineering Optional Metric 2 (sub-TLV type TBD, length 144 3 octets); 145 - Traffic Engineering Optional Metric 3 (sub-TLV type TBD, length 146 3 octets). 148 Fedyk, et. al. Expires September 2000 3 149 2.3 New sub-TLVs for OSPF 151 The optional metrics are sub-TLVs carried within the Link TLV, whose 152 TLV type is 2. The new sub-TLVs are: 154 - Traffic Engineering Optional Metric 1 (sub-TLV type TBD, length 155 4 octets); 156 - Traffic Engineering Optional Metric 2 (sub-TLV type TBD, length 157 4 octets); 158 - Traffic Engineering Optional Metric 3 (sub-TLV type TBD, length 159 4 octets). 161 3. Routing metrics background 163 This section is provided for background only. It is not intended to be 164 an exhaustive list of routing metrics. Some attributes may be more 165 appropriately represented as Resource Class constraints or colors. This 166 is are highlighted out where applicable. 168 A metric is a weight that is assigned to links in the network to 169 indicate the relative preference of a link during path computation. 170 Usually, metrics are selected so that they allow the computation of 171 paths that meet or minimize or maximize (e.g., available link bandwidth 172 on a per hop basis) certain constraints. Metrics for path selection 173 can be classified using the following two criteria: 175 - Additive/non-additive: This refers to whether or not the path 176 metric is obtaining by adding the metric value for all links in 177 the path. Examples of additive constraints include delay and 178 hop count. 180 - Static/dynamic: A static metric doesn't change with time. This 181 includes metrics such as hop count and propagation delay of a 182 link. A dynamic metric changes with traffic conditions in the 183 network. An example is the available bandwidth and queuing 184 delays on a link. 186 Parameters such as bandwidth, delay, delay-jitter, and loss or error 187 probability are used for driving path selection when setting up 188 connections with QoS guarantees. Other metrics that can be considered 189 include hop count, administrative cost, and economic cost. 191 A brief description of each of these metric types follows. 193 3.1 Bandwidth 195 For a connection-oriented networks the unreserved bandwidth or 196 bandwidth available allows path selection to be constrained to links 197 that can support a request. The bandwidth available at each of the 198 eight holding priorities is now advertised as a part of the IGP 200 Fedyk, et. al. Expires September 2000 4 201 extensions for traffic engineering [OSPF, ISIS, GMPLSR]. LSPs that 202 specify traffic parameters with bandwidth allocations can use this 203 usage-based metric instead of the bandwidth metric to ensure sufficient 204 bandwidth allocation. 206 3.2 Delay 208 Static delay-based metrics may be used for representing the propagation 209 and the transmission delay of a link. This metric is used to minimize 210 the end-to-end delay experienced by a packet. The propagation delay is 211 a fixed quantity that is related to the transmission medium and the 212 physical distance over which the signal travels. The transmission 213 delay is the time that it takes to transmit a packet of a given size at 214 a given link speed, and is thus a function of the bandwidth of the 215 link. The combination of transmission delay for a given packet size 216 and the propagation delay yields a value that represents the minimum 217 delay that a packet would experience when transmitted over a given 218 link. 220 The delay metric may represent the real value of the delay in 221 milliseconds or microseconds. It may or may not include the 222 transmission delay, especially since with higher link speeds, the 223 transmission delay becomes negligible and propagation delay dominates. 225 3.3 Delay-jitter 227 Delay-jitter is caused due to queuing delays at various points in a 228 network (usually the links). The exact value depends on the 229 instantaneous traffic load. One option for advertising delay-jitter 230 could be to advertise a static value that represents the average delay- 231 jitter for a given link. With the advent of multi-queue schedulers 232 such as static priority and fair queuing, delay-jitter can vary for 233 different traffic types on the same link. A resource class bit could be 234 used to indicate links that support such a queuing discipline, negating 235 the need for a delay-jitter metric. 237 3.4 Loss Probability 239 The loss probability depends on the type of link used (optical fiber, 240 satellite, etc.). Another way to express this would be bit error rate. 241 This can be advertised as a static value. Alternatively, some bits in 242 the resource class vector can be used to indicate the loss 243 characteristics of the link again removing the requirement for a loss 244 probability metric. 246 3.5 Hop Count 248 A Hop count metric is used to minimize the number of intermediate 249 switches traversed, thereby minimizing the resources used in the 250 network. Typically, minimizing the hop count does not require an 251 explicit advertisement since it can be deduced while doing path 253 Fedyk, et. al. Expires September 2000 5 254 computation. In some cases however, advertising the hop count may be 255 desirable. For instance, when tunnels are advertised by the IGP, it 256 may be useful to know the number of hops that the tunnel traverses. 258 3.6 Administrative weight 260 This metric is assigned based on a combination of factors. Sometimes, 261 the administrative weight attempts to meld together several of the 262 other metric attributes into a single metric. It is important to 263 realize that doing this is a significant compromise for traffic 264 engineering since melding the various metrics together reduces the 265 flexibility for path selection. 267 3.7 Economic cost or expense-based metric types 269 Cost-based metrics are assigned based on the economic cost for using a 270 given link. These may be different from the administrative cost or 271 weight of a link. With the advent of usage-based billing for services 272 such as Frame Relay and ATM, and the use of tunnels over these 273 technologies, the true cost of sending a certain amount and type of 274 traffic can be calculated. 276 4. Security Considerations 278 This document raises no new security issues for IS-IS or OSPF. 280 5. Acknowledgements 282 The authors would like to thank Bilel Jamoussi, Peter Ashwood-Smith and 283 Darek Skalecki for their helpful comments on the document. 285 6. References 287 [TEREQ] D. Awduche et al., "Requirements for Traffic Engineering Over 288 MPLS,_ RFC 2702, September 1999 290 [ISIS] H. Smit, T. Li, "IS-IS extensions for Traffic Engineering," 291 Internet Draft, draft-ietf-isis-traffic-02.txt, September 2000. 293 [OSPF] D. Katz, D. Yeung, "Traffic Engineering Extensions to OSPF,_ 294 Internet Draft, draft-katz-yeung-ospf-traffic-03.txt, September 2000. 296 [CRLDP] B. Jamoussi et al., "Constraint-Based LSP Setup using LDP,_ 297 Internet Draft, draft-ietf-mpls-cr-ldp-04.txt, July 2000. 299 [RSVP-TE] D. Awduche et al., "Extensions to RSVP for LSP Tunnels,_ 300 Internet Draft, draft-ietf-mpls-rsvp-lsp-tunnel-07.txt, August 2000. 302 Fedyk, et. al. Expires September 2000 6 303 [QOSR] E. Crawley et al., "A Framework for QoS-based routing in the 304 Internet," Request for Comments 2386, August 1998. 306 [GMPLSR] K. Kompella et al., "IS-IS Extensions in Support of 307 Generalized MPLS," Internet Draft, draft-ietf-isis-gmpls-extensions- 308 00.txt, September 2000. 310 7. Authors' Addresses 312 Don Fedyk Anoop Ghanwani 313 Nortel Networks Corp. Cosine Communications 314 600 Technology Park Drive 1200 Bridge Parkway 315 Billerica, MA 01821 Redwood City, CA 94065 316 USA USA 317 Phone: +1-978-288-4506 Phone: +1-650-628-4225 318 Email: dwfedyk@nortelnetworks.com Email: anoop@cosinecom.com 320 Rajesh Balay Gerald R. (Jerry) Ash 321 Cosine Communications AT&T Labs 322 1200 Bridge Parkway Room MT E3-3C37 323 Redwood City, CA 94065 200 Laurel Avenue 324 Phone: +1-650-628-4893 Middletown, NJ 07748 325 Email: rbalay@cosinecom.com USA 326 Email: gash@att.com 328 Alain Vedrenne 329 SITA EQUANT 330 Strategic Technology Planning 331 400 Galleria Parkway, 332 Atlanta, Georgia 30339 333 USA 334 Phone: +1 (678) 346-3466 335 Email:Alain.Vedrenne@sita.int 337 Full Copyright Statement 339 "Copyright (C) The Internet Society (March 2000). All Rights Reserved. 340 This document and translations of it may be copied and furnished to 341 others, and derivative works that comment on or otherwise explain it or 342 assist in its implementation may be prepared, copied, published and 343 distributed, in whole or in part, without restriction of any kind, 344 provided that the above copyright notice and this paragraph are 345 included on all such copies and derivative works. However, this 346 document itself may not be modified in any way, such as by removing the 347 copyright notice or references to the Internet Society or other 349 Fedyk, et. al. Expires September 2000 7 350 Internet organizations, except as needed for the purpose of developing 351 Internet standards in which case the procedures for copyrights defined 352 in the Internet Standards process must be followed, or as required to 353 translate it into languages other than English. 355 The limited permissions granted above are perpetual and will not be 356 revoked by the Internet Society or its successors or assigns. 358 Fedyk, et. al. Expires September 2000 8