idnits 2.17.1 draft-lefaucheur-diff-te-isis-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: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == 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 ([DIFF-TE-OSPF], [TEWG-FW], [DIFF-TE-EXT], [DIFF-TE-REQTS]), 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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. 'TE-REQ') == Outdated reference: A later version (-05) exists of draft-ietf-tewg-framework-02 ** Downref: Normative reference to an Informational draft: draft-ietf-tewg-framework (ref. 'TEWG-FW') -- Possible downref: Normative reference to a draft: ref. 'DIFF-TE-REQTS' -- Unexpected draft version: The latest known version of draft-lefaucheur-diff-te-ospf is -00, but you're referring to -01. -- Possible downref: Normative reference to a draft: ref. 'DIFF-TE-OSPF' == Outdated reference: A later version (-01) exists of draft-ietf-mpls-diff-te-ext-00 -- Possible downref: Normative reference to a draft: ref. 'DIFF-TE-EXT' == Outdated reference: A later version (-05) exists of draft-ietf-isis-traffic-02 ** Downref: Normative reference to an Informational draft: draft-ietf-isis-traffic (ref. 'ISIS-TE') Summary: 9 errors (**), 0 flaws (~~), 4 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Francois Le Faucheur 2 Thomas D. Nadeau 3 Cisco Systems, Inc. 5 Angela Chiu 6 AT&T 8 William Townsend 9 Tenor Networks 11 Darek Skalecki 12 Nortel Networks 14 IETF Internet Draft 15 Expires: May, 2001 16 Document: draft-lefaucheur-diff-te-isis-00.txt November, 2000 18 Extensions to ISIS 19 for support of Diff-Serv-aware MPLS Traffic Engineering 21 Status of this Memo 23 This document is an Internet-Draft and is in full conformance with 24 all provisions of Section 10 of RFC2026. Internet-Drafts are 25 Working documents of the Internet Engineering Task Force (IETF), its 26 areas, and its working groups. Note that other groups may also 27 distribute working documents as Internet-Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six 30 months and may be updated, replaced, or obsoleted by other documents 31 at any time. It is inappropriate to use Internet-Drafts as reference 32 material 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. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 Abstract 41 A companion document [DIFF-TE-REQTS] defines the requirements for 42 support of Diff-Serv-aware MPLS Traffic Engineering on a per-Class- 43 Type basis, as discussed in the Traffic Engineering Working Group 44 Framework document [TEWG-FW]. 46 This document proposes corresponding extensions to ISIS for support 47 of Traffic Engineering on a per-Class-Type basis. 49 Le Faucheur, et. al 1 50 Two companion documents [DIFF-TE-EXT] [DIFF-TE-OSPF] propose 51 corresponding extensions to RSVP and CR-LDP and to OSPF for support 52 of Traffic Engineering on a per-Class-Type basis. 54 1. Introduction 56 As Diffserv becomes prominent in providing scalable multi-class of 57 services in IP networks, performing traffic engineering at a per- 58 class level instead of an aggregated level is needed to further 59 enhance networks in performance and efficiency. By mapping a traffic 60 trunk in a given class on a separate LSP, it allows the traffic 61 trunk to utilize resources available on both shortest path(s) and 62 non-shortest paths and follow paths that meet constraints which are 63 specific to the given class. It also allows each class to select the 64 proper protection/restoration mechanism(s) that satisfy its 65 survivability requirements in a cost effective manner. 67 Besides the set of parameters defined for the general aggregate TE 68 [TE-REQ], a new set of per-class parameters needs to be provided at 69 each LSR interface and propagated via extensions to the IGP 70 (ISIS/OSPF) [TEWG-FW]. Furthermore, the per-class parameters can be 71 aggregated into per-Class-Type parameters. The main motivation for 72 grouping a set of classes into a Class-Type is to improve the 73 scalability of the IGP link state advertisements by propagating 74 information on a per-Class-Type basis instead of on a per-class 75 basis. This approach also has the benefit of allowing better 76 bandwidth sharing between classes in the same Class-Type. 78 A Class-Type [TEWG-FW] is defined as a set of classes that satisfy 79 the following two conditions: 81 1) Classes in the same Class-Type possess common aggregate maximum 82 and minimum bandwidth requirements to guarantee the required 83 performance level. 85 2) There is no maximum or minimum bandwidth requirement to be 86 enforced at the level of an individual class within the Class- 87 Type. One can still implement some "priority" policies for 88 classes within the same Class-Type in terms of accessing the 89 Class-Type bandwidth (e.g. via the use of preemption 90 priorities). 92 An example of Class-Type comprising multiple Diff-Serv classes is a 93 low-loss Class-Type that includes both AF1-based and AF2-based 94 Ordering Aggregates. 96 Note that with per Class-Type TE, Constraint-Based Routing is 97 performed with bandwidth constraints on a per Class-Type basis but 98 LSPs may carry a single Diff-Serv class (Ordered Aggregate) with 99 Diff-Serv scheduling (i.e. PHB) performed separately for each class. 101 Le Faucheur et. al 2 102 In this document, we will only discuss "per Class-Type TE" because 103 "per Class TE" can be viewed as a special case of per Class-Type TE 104 (where each Class-Type is degenerated into a single Diff-Serv 105 class). 107 This document focuses on intra-domain operations. Inter-domain 108 operations is for further study. 110 A companion document [DIFF-TE-REQTS] defines the requirements for 111 support of MPLS Traffic Engineering on a per-Class-Type basis. The 112 following sections propose detailed extensions to ISIS that meet 113 those requirements. 115 Two companion documents [DIFF-TE-EXT] [DIFF-TE-OSPF] propose 116 corresponding extensions to RSVP and CR-LDP and to OSPF for support 117 of Traffic Engineering on a per-Class-Type basis. 119 2. ISIS Extensions 121 In this section we describe extensions to IS-IS for support of Diff- 122 Serv Traffic Engineering on a per-Class-Type basis which meet the 123 requirements defined in [DIFF-TE-REQTS]. These extensions are in 124 addition to the extensions required to support (aggregate) MPLS 125 Traffic Engineering defined in [ISIS-TE]. 127 2.1. Existing TE sub-TLVs 129 [ISIS-TE] defines new extended TLVs for support of (aggregate) 130 Traffic Engineering. One of these extended TLV is referred to as the 131 extended IS reachability TLV (TLV type 22). This TLV contains a 132 number of new sub-TLVs. 134 In this document we refer to the sub-TLV 10 (Maximum reservable link 135 bandwidth) of the extended IS reachability TLV (as defined in [ISIS- 136 TE]) as the "Maximum Reservable Aggregate Bandwidth". 138 We also refer to the sub-TLV 11 (unreserved bandwidth) of the 139 extended IS reachability TLV (as defined in [ISIS-TE]) as the 140 "Unreserved Bandwidth for Class-Type 0". 142 2.2. New Sub-TLVs 144 The following additional sub-TLVs are defined for the extended IS 145 reachability TLV (sub-TLV numbers to be allocated): 147 TBD1 - Unreserved bandwidth for Class-Type 1 148 TBD2 - Unreserved bandwidth for Class-Type 2 149 TBD3 - Unreserved bandwidth for Class-Type 3 151 Each sub-TLV may occur only once. Unrecognized types are ignored. 153 Le Faucheur et. al 3 154 The additional sub-TLVs defined above are optional so that they may 155 or may not be included in the extended IS reachability TLV. 157 The extended IS reachability TLV may include the sub-TLVs for any 158 subset of the three additional Class-Types. In other words, the IS 159 reachability TLV may contain none of the three sub-TLVs defined 160 above, any one of those, any two of those, or the three sub-TLVs. 162 As discussed in [DIFF-TE-REQTS], where a Class-Type is not 163 effectively used in a network, it is recommended that the 164 corresponding sub-TLV is not included in the IS reachability TLV. 165 Therefore, the Class-Types to be advertised in ISIS should be 166 configurable. For instance, a Network Administrator may elect to use 167 Diff-Serv Traffic Engineering in order to compute separate routes 168 for data traffic and voice traffic (and apply different bandwidth 169 constraints to the route computation for those). In that case, the 170 IGP would be configured to only advertise the sub-TLV for one 171 additional Class-Type (i.e. the extended IS reachability TLV would 172 contain sub-TLV 10 for the Maximum Reservable Aggregate Bandwidth, 173 sub-TLV 11 for the Unreserved Bandwidth for Class-Type 0 and sub-TLV 174 TBD1 for Unreserved Bandwidth for Class-Type 1). 176 An LSR which supports Class-Type N and receiving an extended IS 177 reachability TLV without the sub-TLV corresponding to Class-Type N, 178 must interpret this as meaning that the corresponding link does not 179 support Class-Type N. For Constraint Based Routing purposes, the LSR 180 may consider this equivalent to the case where the extended IS 181 reachability TLV contains an Unreserved Bandwidth Class-Type N sub- 182 TLV with bandwidth values set to zero. 184 An LSR which does not support Class-Type N and which receives an 185 extended IS reachability TLV containing the sub-TLV corresponding to 186 Class-Type N, must ignore this sub-TLV. However, the IS reachability 187 TLV must be flooded transparently, so that the sub-TLV for Class- 188 Type N is kept in the IS reachability TLV when reflooded by this 189 LSR. 191 2.3. Sub-TLV Details 193 The Unreserved Bandwidth for Class-Type N (N= 1,2,3) sub-TLVs 194 specifies the amount of bandwidth not yet reserved for Class-Type N 195 at each of the eight preemption priority levels. Each value will be 196 less than, or equal to, the Maximum Reservable Bandwidth for Class- 197 Type N. 199 When the bandwidth value for preemption Z (Z > 0) is identical to 200 the bandwidth value for preemption Z-1, the bandwidth value for 201 preemption Z is not explicitly repeated in the sub-TLV. Rather, the 202 fact that it is identical to the value of preemption Z-1, is encoded 203 in a "repetition octet". 205 Le Faucheur et. al 4 206 Thus, the sub-TLV comprises: 208 - P (1<=P<=8) bandwidth values. These values correspond to the 209 bandwidth that can be reserved with a holding priority of 0 through 210 7, arranged in increasing order with priority 0 occurring at the 211 start of the sub-TLV, and priority 7 towards the end of the sub-TLV, 212 but omitting all repeated values. The units are bytes per second and 213 the values are encoded in IEEE floating point format. 215 - a "repetition octet" where each bit is referred to as bitZ , 216 0 <= Z < 8, and is defined to have the following meaning: 217 * if bitZ = 0 then "Unreserved Bandwidth" for preemption 218 level Z is explicitely included in the sub-TLV, 219 * if bitZ = 1 then "Unreserved Bandwidth" for preemption 220 level Z is not explicitely included in the sub-TLV but is 221 defined to be equal to "Unreserved Bandwidth" for preemption 222 level Z-1. 224 Note that the highest preemption level (level 0) is always 225 advertised and the first bit (Bit0) in the "repetition octet" is 226 always set to 0. 228 [Editor's note: should the "repetition octet" be moved before the 229 bandwidth values?] 231 The Unreserved Bandwidth for Class-Type N sub-TLV is TLV type 232 (TBDN). Its length is (P*4 +1), where 1<=P<=8 and where P is the 233 number of non-equal bandwidth values across all preemption levels 234 for that Class-Type. 236 For example, when a link supports LSPs of preemption levels 2 and 4 237 only (for a particular Class-Type) with "Unreserved Bandwidth" (for 238 the particular Class-Type) on that link for preemption levels 0, 2, 239 and 4 currently of 10Mb/s, 5Mb/s and 3Mb/s, respectively, then 240 "Unreserved Bandwidth" (for the particular Class-Type) for 241 preemption levels 0, 2, and 4 of 10Mb/s, 5Mb/s and 3Mb/s, 242 respectively, are explicitly advertised for that link as well as 243 "repetition octet" of 01010111 in binary form. The sub-TLV length is 244 13. 246 3. Security Considerations 248 This document raises no new security issues for IS-IS. The security 249 mechanisms already proposed for ISIS may be used. 251 4. Acknowledgments 253 This document has benefited from discussions with Carol Iturralde . 255 Le Faucheur et. al 5 256 References 258 [TE-REQ] Awduche et al, Requirements for Traffic Engineering over 259 MPLS, RFC2702, September 1999. 261 [TEWG-FW] Awduche et al, A Framework for Internet Traffic 262 Engineering, draft-ietf-tewg-framework-02.txt, July 2000. 264 [DIFF-TE-REQTS] Le Faucheur et al, Requirements for support of 265 Diff-Serv-aware MPLS Traffic Engineering, draft-ietf-mpls-diff-te- 266 reqts-00.txt, November 2000. 268 [DIFF-TE-OSPF] Le Faucheur et al, Extension to OSPF for support of 269 Diff-Serv-aware MPLS Traffic Engineering, draft-lefaucheur-diff-te- 270 ospf-01.txt, November 2000. 272 [DIFF-TE-EXT] Le Faucheur et al, Extension to RSVP and CR-LDP for 273 support of Diff-Serv-aware MPLS Traffic Engineering, draft-ietf- 274 mpls-diff-te-ext-00.txt, November 2000. 276 [ISIS-TE] Smit, Li, IS-IS extensions for Traffic Engineering, draft- 277 ietf-isis-traffic-02.txt, September 2000. 279 Authors' Address: 281 Francois Le Faucheur 282 Cisco Systems, Inc. 283 Petra B - Les Lucioles - 291, rue Albert Caquot - 06560 Valbonne - 284 France 285 Phone: +33 4 92 96 75 64 286 Email: flefauch@cisco.com 288 Angela Chiu 289 AT&T Labs 290 200 Laurel Ave. Rm A5-1F06 291 Middletown, NJ 07748, USA 292 Tel: 1-(732) 420-9057 293 Email: alchiu@att.com 295 William Townsend 296 Tenor Networks 297 100 Nagog Park 298 Acton, MA 01720 299 Phone: +1-978-264-4900 300 Email: btownsend@tenornetworks.com 302 Thomas D. Nadeau 303 Cisco Systems, Inc. 304 250 Apollo Drive 305 Chelmsford, MA 01824 306 Phone: +1-978-244-3051 308 Le Faucheur et. al 6 309 Email: tnadeau@cisco.com 311 Darek Skalecki 312 Nortel Networks 313 3500 Carling Ave, 314 Nepean K2H 8E9 315 Phone: +1-613-765-2252 316 Email: dareks@nortelnetworks.com 318 Le Faucheur et. al 7