idnits 2.17.1 draft-ietf-ospf-diff-te-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 ([TEWG-FW], [DIFF-TE-ISIS], [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) == Unused Reference: 'ISIS-TE' is defined on line 277, but no explicit reference was found in the text ** 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') == Outdated reference: A later version (-07) exists of draft-ietf-tewg-diff-te-reqts-00 ** Downref: Normative reference to an Informational draft: draft-ietf-tewg-diff-te-reqts (ref. 'DIFF-TE-REQTS') -- Possible downref: Normative reference to a draft: ref. 'DIFF-TE-EXT' -- No information found for draft-ietf-isis-diff-te00 - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'DIFF-TE-ISIS' == Outdated reference: A later version (-10) exists of draft-katz-yeung-ospf-traffic-03 == 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: 10 errors (**), 0 flaws (~~), 6 warnings (==), 5 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 Celion Networks 8 William Townsend 9 Tenor Networks 11 Darek Skalecki 12 Nortel Networks 14 IETF Internet Draft 15 Expires: August, 2001 16 Document: draft-ietf-ospf-diff-te-00.txt February, 2001 18 Extensions to OSPF 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 OSPF 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-ISIS] propose 51 corresponding extensions to RSVP and CR-LDP and to ISIS 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 in networks 59 where fine optimisation of resources is sought in order to further 60 enhance performance and efficiency. By mapping a traffic trunk in a 61 given class on a separate LSP, it allows the traffic trunk to 62 utilize resources available on both shortest path(s) and non- 63 shortest paths and follow paths that meet constraints which are 64 specific to the given class. It also allows each class to select the 65 proper protection/restoration mechanism(s) that satisfy its 66 survivability requirements in a cost effective manner. 68 Besides the set of parameters defined for the general aggregate TE 69 [TE-REQ], a new set of per-class parameters needs to be provided at 70 each LSR interface and propagated via extensions to the IGP 71 (ISIS/OSPF) [TEWG-FW]. Furthermore, the per-class parameters can be 72 aggregated into per-Class-Type parameters. The main motivation for 73 grouping a set of classes into a Class-Type is to improve the 74 scalability of the IGP link state advertisements by propagating 75 information on a per-Class-Type basis instead of on a per-class 76 basis. This approach also has the benefit of allowing better 77 bandwidth sharing between classes in the same Class-Type. 79 A Class-Type [TEWG-FW] is defined as a set of classes that satisfy 80 the following two conditions: 82 1) Classes in the same Class-Type possess common aggregate maximum 83 and minimum bandwidth requirements to guarantee the required 84 performance level. 86 2) There is no maximum or minimum bandwidth requirement to be 87 enforced at the level of an individual class within the Class- 88 Type. One can still implement some "priority" policies for 89 classes within the same Class-Type in terms of accessing the 90 Class-Type bandwidth (e.g. via the use of preemption 91 priorities). 93 An example of Class-Type comprising multiple Diff-Serv classes is a 94 low-loss Class-Type that includes both AF1-based and AF2-based 95 Ordering Aggregates. 97 Note that with per Class-Type TE, Constraint-Based Routing is 98 performed with bandwidth constraints on a per Class-Type basis but 99 LSPs may carry a single Diff-Serv class (Ordered Aggregate) with 100 Diff-Serv scheduling (i.e. PHB) performed separately for each class. 102 Le Faucheur et. al 2 103 In this document, we will only discuss "per Class-Type TE" because 104 "per Class TE" can be viewed as a special case of per Class-Type TE 105 (where each Class-Type is degenerated into a single Diff-Serv 106 class). 108 This document focuses on intra-domain operations. Inter-domain 109 operations is for further study. 111 A companion document [DIFF-TE-REQTS] defines the requirements for 112 support of MPLS Traffic Engineering on a per-Class-Type basis. The 113 following sections propose detailed extensions to OSPF that meet 114 those requirements. 116 Two companion documents [DIFF-TE-EXT] [DIFF-TE-ISIS] propose 117 corresponding extensions to RSVP and CR-LDP and to ISIS for support 118 of Traffic Engineering on a per-Class-Type basis. 120 2. OSPF Extensions 122 In this section we propose extensions to OSPF for support of Diff- 123 Serv Traffic Engineering on a per-Class-Type basis which meet the 124 requirements defined in [DIFF-TE-REQTS]. These extensions are in 125 addition to the extensions already defined for support of 126 (aggregate) MPLS Traffic Engineering in [OSPF-TE]. 128 2.1. Existing TE Sub-TLVs 130 [OSPF-TE] defines a new LSA for support of (aggregate) Traffic 131 Engineering, which is referred to as the Traffic Engineering LSA. 132 This LSA contains a Link TLV (Type 2) comprising a number of sub- 133 TLVs. 135 In this document we refer to the sub-TLV 7 (maximum reservable 136 bandwidth) of the Link TLV (as defined in [OSPF-TE]) as the "Maximum 137 Reservable Aggregate Bandwidth". 139 We also refer to the sub-TLV 8 (unreserved bandwidth) of the Link 140 TLV (as defined in [OSPF-TE]) as the "Unreserved Bandwidth for 141 Class-Type 0". 143 2.2. New Sub-TLVs 145 The following additional sub-TLVs are defined for the Link TLV of 146 the Traffic Engineering LSA (sub-TLV numbers to be allocated) 148 TBD1 - Unreserved Bandwidth for Class-Type 1 (32 octets) 149 TBD2 - Unreserved Bandwidth for Class-Type 2 (32 octets) 150 TBD3 - Unreserved Bandwidth for Class-Type 3 (32 octets) 152 Each sub-TLV may occur only once. Unrecognized types are ignored. 154 Le Faucheur et. al 3 155 Unlike the sub-TLVs defined for the Link TLV in [OSPF-TE], the 156 additional sub-TLVs defined above are optional. 158 The Link TLV may include the sub-TLVs for any subset of the three 159 additional Class-Types. In other words, the Link TLV may contain 160 none of the three sub-TLVs defined above, any one of those, any two 161 of those, or the three sub-TLVs. 163 As discussed in [DIFF-TE-REQTS], where a Class-Type is not 164 effectively used in a network, it is recommended that the 165 corresponding sub-TLV is not included in the Link TLV. Therefore, 166 the Class-Types to be advertised in OSPF should be configurable. For 167 instance, a Network Administrator may elect to use Diff-Serv Traffic 168 Engineering in order to compute separate routes for data traffic and 169 voice traffic (and apply different bandwidth constraints to the 170 route computation for those). In that case, the IGP would only 171 advertise the sub-TLV for one additional Class-Type (i.e. the Link 172 TLV would contain sub-TLV 7 for the Maximum Reservable Aggregate 173 Bandwidth, sub-TLV 8 for the Unreserved Bandwidth for Class-Type 0 174 and sub-TLV TBD1 for Unreserved Bandwidth for Class-Type 1). 176 An LSR which supports Class-Type N and which receives a Link TLV 177 without the sub-TLV corresponding to Class-Type N, interprets this 178 as meaning that the corresponding link does not support Class-Type 179 N. For Constraint Based Routing purposes, the LSR may consider this 180 equivalent to the case where the Link TLV contains an Unreserved 181 Bandwidth for Class-Type N sub-TLV set to zero. 183 An LSR which does not support Class-Type N and which receives a Link 184 TLV containing the sub-TLV corresponding to Class-Type N, must 185 ignore this sub-TLV. However, the Link TLV must be flooded 186 transparently, so that the sub-TLV for Class-Type N is kept in the 187 Link TLV when reflooded by this LSR. 189 2.3. Sub-TLV Details 191 The Unreserved Bandwidth for Class-Type N (N= 1,2,3) sub-TLV 192 specifies the amount of bandwidth not yet reserved at each of the 193 eight preemption priority levels for Class-Type N. Each value will 194 be less than or equal to the Maximum Reservable Bandwidth for Class- 195 Type N. 197 When the bandwidth value for preemption Z (Z > 0) is identical to 198 the bandwidth value for preemption Z-1, the bandwidth value for 199 preemption Z is not explicitly repeated in the sub-TLV. Rather, the 200 fact that it is identical to the value of preemption Z-1, is encoded 201 in a "repetition octet". 203 Thus, the sub-TLV comprises: 205 Le Faucheur et. al 4 206 - P (1<=P<=8) bandwidth values. These values correspond to the 207 bandwidth that can be reserved with a holding priority of 0 through 208 7, arranged in increasing order with priority 0 occurring at the 209 start of the sub-TLV, and priority 7 towards the end of the sub-TLV, 210 but omitting all repeated values. The units are bytes per second and 211 the values are encoded in IEEE floating point format. 213 - a "repetition octet" where each bit is referred to as bitZ , 214 0 <= Z < 8, and is defined to have the following meaning: 215 * if bitZ = 0 then "Unreserved Bandwidth" for preemption 216 level Z is explicitely included in the sub-TLV, 217 * if bitZ = 1 then "Unreserved Bandwidth" for preemption 218 level Z is not explicitely included in the sub-TLV but is 219 defined to be equal to "Unreserved Bandwidth" for preemption 220 level Z-1. 222 Note that the highest preemption level (level 0) is always 223 advertised and the first bit (Bit0) in the "repetition octet" is 224 always set to 0. 226 [Editor's note: should the "repetition octet" be moved before the 227 bandwidth values?] 229 The Unreserved Bandwidth for Class-Type N sub-TLV is TLV type 230 (TBDN). Its length is (P*4 +1), where 1<=P<=8 and where P is the 231 number of non-equal bandwidth values across all preemption levels 232 for that Class-Type. 234 For example, when a link supports LSPs of preemption levels 2 and 4 235 only (for a particular Class-Type) with "Unreserved Bandwidth" (for 236 the particular Class-Type) on that link for preemption levels 0, 2, 237 and 4 currently of 10Mb/s, 5Mb/s and 3Mb/s, respectively, then 238 "Unreserved Bandwidth" (for the particular Class-Type) for 239 preemption levels 0, 2, and 4 of 10Mb/s, 5Mb/s and 3Mb/s, 240 respectively, are explicitly advertised for that link as well as 241 "repetition octet" of 01010111 in binary form. The sub-TLV length is 242 13. 244 3. Security Considerations 246 This document raises no new security issues for OSPF. The security 247 mechanisms already proposed for OSPF may be used. 249 4. Acknowledgments 251 This document has benefited from discussions with Carol Iturralde. 253 Le Faucheur et. al 5 254 References 256 [TE-REQ] Awduche et al, Requirements for Traffic Engineering over 257 MPLS, RFC2702, September 1999. 259 [TEWG-FW] Awduche et al, A Framework for Internet Traffic 260 Engineering, draft-ietf-tewg-framework-02.txt, July 2000. 262 [DIFF-TE-REQTS] Le Faucheur et al, Requirements for support of 263 Diff-Serv-aware MPLS Traffic Engineering, draft-ietf-tewg-diff-te- 264 reqts-00.txt, February 2001. 266 [DIFF-TE-EXT] Le Faucheur et al, Extension to RSVP and CR-LDP for 267 support of Diff-Serv-aware MPLS Traffic Engineering, draft-ietf- 268 mpls-diff-te-ext-01.txt, February 2001. 270 [DIFF-TE-ISIS] Le Faucheur et al, Extension to ISIS for support of 271 Diff-Serv-aware MPLS Traffic Engineering, draft-ietf-isis-diff- 272 te00.txt, February 2001. 274 [OSPF-TE] Katz, Yeung, Traffic Engineering Extensions to OSPF, 275 draft-katz-yeung-ospf-traffic-03.txt, September 2000. 277 [ISIS-TE] Smit, Li, IS-IS extensions for Traffic Engineering, draft- 278 ietf-isis-traffic-02.txt, September 2000. 280 Authors' Address: 282 Francois Le Faucheur 283 Cisco Systems, Inc. 284 Petra B - Les Lucioles - 291, rue Albert Caquot - 06560 Valbonne - 285 France 286 Phone: +33 4 92 96 75 64 287 Email: flefauch@cisco.com 289 Angela Chiu 290 Celion Networks 291 1 Sheila Drive, Suite 2 292 Tinton Falls, NJ 07724 293 Phone: +1-732 747 9987 294 Email: angela.chiu@celion.com 296 William Townsend 297 Tenor Networks 298 100 Nagog Park 299 Acton, MA 01720 300 Phone: +1-978-264-4900 301 Email: btownsend@tenornetworks.com 303 Thomas D. Nadeau 305 Le Faucheur et. al 6 306 Cisco Systems, Inc. 307 250 Apollo Drive 308 Chelmsford, MA 01824 309 Phone: +1-978-244-3051 310 Email: tnadeau@cisco.com 312 Darek Skalecki 313 Nortel Networks 314 3500 Carling Ave, 315 Nepean K2H 8E9 316 Phone: +1-613-765-2252 317 Email: dareks@nortelnetworks.com 319 Le Faucheur et. al 7