idnits 2.17.1
draft-ietf-tewg-diff-te-proto-07.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
Internet-Drafts being working documents.
== No 'Intended status' indicated for this document; assuming Proposed
Standard
== It seems as if not all pages are separated by form feeds - found 0 form
feeds but 34 pages
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** There is 1 instance of too long lines in the document, the longest one
being 2 characters in excess of 72.
** The abstract seems to contain references ([RFC2119], [ISIS-TE]), which
it shouldn't. Please replace those with straight textual mentions of the
documents in question.
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 (March 2004) is 7346 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)
-- Looks like a reference, but probably isn't: '0' on line 657
-- Looks like a reference, but probably isn't: '1' on line 495
-- Looks like a reference, but probably isn't: '2' on line 496
-- Looks like a reference, but probably isn't: '3' on line 497
-- Looks like a reference, but probably isn't: '7' on line 658
== Missing Reference: 'N' is mentioned on line 995, but not defined
** Downref: Normative reference to an Informational RFC: RFC 3564 (ref.
'DSTE-REQ')
** Downref: Normative reference to an Informational RFC: RFC 2475 (ref.
'DIFF-ARCH')
** Downref: Normative reference to an Informational RFC: RFC 2702 (ref.
'TE-REQ')
** Downref: Normative reference to an Informational draft:
draft-ietf-isis-traffic (ref. 'ISIS-TE')
** Obsolete normative reference: RFC 2434 (ref. 'IANA-CONS') (Obsoleted by
RFC 5226)
== Outdated reference: A later version (-07) exists of
draft-ietf-tewg-diff-te-russian-04
== Outdated reference: A later version (-04) exists of
draft-ietf-tewg-diff-te-mam-02
== Outdated reference: A later version (-06) exists of
draft-ietf-tewg-diff-te-mar-03
== Outdated reference: A later version (-06) exists of
draft-ietf-mpls-bundle-04
== Outdated reference: A later version (-07) exists of
draft-ietf-mpls-rsvp-lsp-fastreroute-03
Summary: 9 errors (**), 0 flaws (~~), 9 warnings (==), 7 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
1 TEWG
2 Internet Draft Francois Le Faucheur
3 Editor
4 Document: draft-ietf-tewg-diff-te-proto-07.txt Cisco Systems,
5 Inc.
6 Expires: September 20024 March 2004
8 Protocol extensions for support of
9 Differentiated-Service-aware MPLS Traffic Engineering
11 Status of this Memo
13 This document is an Internet-Draft and is in full conformance with
14 all provisions of Section 10 of RFC2026. Internet-Drafts are
15 Working documents of the Internet Engineering Task Force (IETF), its
16 areas, and its working groups. Note that other groups may also
17 distribute working documents as Internet-Drafts.
19 Internet-Drafts are draft documents valid for a maximum of six months
20 and may be updated, replaced, or obsoleted by other documents at any
21 time. It is inappropriate to use Internet-Drafts as reference
22 material or to cite them other than as "work in progress."
24 The list of current Internet-Drafts can be accessed at
25 http://www.ietf.org/ietf/1id-abstracts.txt.
26 The list of Internet-Draft Shadow Directories can be accessed at
27 http://www.ietf.org/shadow.html.
29 Copyright Notice
31 Copyright (C) The Internet Society (2004). All Rights Reserved.
33 Abstract
35 This document specifies the protocol extensions for support of
36 Differentiated-Service-aware MPLS Traffic Engineering (DS-TE). This
37 includes generalization of the semantic of a number of IGP extensions
38 already defined for existing MPLS Traffic Engineering in RFC3630 and
39 RFC-TBD as well as additional IGP extensions beyond those. This also
40 includes extensions to RSVP-TE signaling beyond those already
41 specified in RFC3209 for existing MPLS Traffic Engineering. These
42 extensions address the Requirements for DS-TE spelt out in RFC3564.
44 To be removed by the RFC editor at the time of
45 publication: Please replace "TBD" above by the actual RFC
46 number when
48 Protocols for Diffserv-aware TE March 2004
50 an RFC number is allocated to [ISIS-TE]
51
53 Specification of Requirements
55 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
56 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
57 document are to be interpreted as described in [RFC2119].
59 Table of Contents
61 1. Introduction...................................................3
62 2. Contributing Authors...........................................4
63 3. Definitions....................................................4
64 4. Configurable Parameters........................................5
65 4.1.1. Link Parameters 5
66 4.1.2. Bandwidth Constraints (BCs) 5
67 4.1.3. Overbooking6
68 4.2. LSR Parameters............................................6
69 4.2.1. TE-Class Mapping 6
70 4.3. LSP Parameters............................................7
71 4.3.1. Class-Type 7
72 4.3.2. Setup and Holding Preemption Priorities 8
73 4.3.3. Class-Type/Preemption Relationship 8
74 4.4. Examples of Parameters Configuration......................8
75 4.4.1. Example 1 8
76 4.4.2. Example 2 9
77 4.4.3. Example 3 9
78 4.4.4. Example 4 10
79 4.4.5. Example 5 10
80 5. IGP Extensions for DS-TE......................................11
81 5.1. Bandwidth Constraints....................................11
82 5.2. Unreserved Bandwidth.....................................13
83 6. RSVP-TE Extensions for DS-TE..................................14
84 6.1. DS-TE related RSVP Messages Format.......................15
85 6.1.1. Path Message Format 15
86 6.2. CLASSTYPE Object.........................................15
87 6.2.1. CLASSTYPE object 16
88 6.3. Handling CLASSTYPE Object................................16
89 6.4. Non-support of the CLASSTYPE Object......................19
90 6.5. Error Codes For Diff-Serv-aware TE.......................19
91 7. DS-TE support with MPLS extensions............................20
92 7.1. DS-TE support and references to preemption priority......20
93 7.2. DS-TE support and references to Maximum Reservable Bandwidth
94 ..............................................................20
95 8. Constraint Based Routing......................................21
96 9. Diff-Serv scheduling..........................................21
97 10. Existing TE as a Particular Case of DS-TE....................21
99 Protocols for Diffserv-aware TE March 2004
101 11. Computing "Unreserved TE-Class [i]" and Admission Control Rules22
102 11.1. Computing "Unreserved TE-Class [i]".....................22
103 11.2. Admission Control Rules.................................23
104 12. Security Considerations......................................23
105 13. Acknowledgments..............................................23
106 14. IANA Considerations..........................................24
107 14.1. A new name space for Bandwidth Constraints Model Identifiers
108 ..............................................................24
109 14.2. A new name space for Error Values under the "Diff-Serv-aware
110 TE Error".....................................................24
111 14.3. Assignments made in this Document.......................24
112 14.3.1. Bandwidth Constraints sub-TLV for OSPF version 2 24
113 14.3.2. Bandwidth Constraints sub-TLV for ISIS 25
114 14.3.3. CLASSTYPE object for RSVP25
115 14.3.4. "Diff-Serv-aware TE Error" Error Code26
116 14.3.5. Error Values for "Diff-Serv-aware TE Error"26
117 15. Intellectual Property Considerations.........................27
118 16. Normative References.........................................27
119 17. Informative References.......................................28
120 18. Editor's Address:............................................28
121 19. Full Copyright Statement.....................................29
122 Appendix A - Prediction for Multiple Path Computation............29
123 Appendix B - Solution Evaluation.................................30
124 Appendix C - Interoperability with non DS-TE capable LSRs........32
126 1. Introduction
128 [DSTE-REQ] presents the Service Providers requirements for support of
129 Differentiated-Service (Diff-Serv)-aware MPLS Traffic Engineering
130 (DS-TE). This includes the fundamental requirement to be able to
131 enforce different bandwidth constraints for different classes of
132 traffic.
134 This document specifies the IGP and RSVP-TE signaling extensions
135 (beyond those already specified for existing MPLS Traffic Engineering
136 [OSPF-TE][ISIS-TE][RSVP-TE]) for support of the DS-TE requirements
137 spelt out in [DSTE-REQ] including environments relying on distributed
138 Constraint Based Routing (e.g. path computation involving Head-end
139 LSRs).
141 [DSTE-REQ] provides a definition and examples of Bandwidth
142 Constraints Models. The present document does not specify nor assume
143 a particular Bandwidth Constraints model. Specific Bandwidth
144 Constraints model are outside the scope of this document. While the
145 extensions for DS-TE specified in this document may not be sufficient
146 to support all the conceivable Bandwidth Constraints models, they do
147 support the "Russian Dolls" Model specified in [DSTE-RDM], the
149 Protocols for Diffserv-aware TE March 2004
151 "Maximum Allocation" Model specified in [DSTE-MAM] and the "Maximum
152 Allocation with Reservation" Model specified in [DSTE-MAR].
154 2. Contributing Authors
156 This document was the collective work of several. The text and
157 content of this document was contributed by the editor and the co-
158 authors listed below. (The contact information for the editor appears
159 in Section 18, and is not repeated below.)
161 Jim Boyle Kireeti Kompella
162 Protocol Driven Networks, Inc. Juniper Networks, Inc.
163 1381 Kildaire Farm Road #288 1194 N. Mathilda Ave.
164 Cary, NC 27511, USA Sunnyvale, CA 94099
165 Phone: (919) 852-5160 Email: kireeti@juniper.net
166 Email: jboyle@pdnets.com
168 William Townsend Thomas D. Nadeau
169 Tenor Networks Cisco Systems, Inc.
170 100 Nagog Park 250 Apollo Drive
171 Acton, MA 01720 Chelmsford, MA 01824
172 Phone: +1-978-264-4900 Phone: +1-978-244-3051
173 Email: Email: tnadeau@cisco.com
174 btownsend@tenornetworks.com
176 Darek Skalecki
177 Nortel Networks
178 3500 Carling Ave,
179 Nepean K2H 8E9
180 Phone: +1-613-765-2252
181 Email: dareks@nortelnetworks.com
183 3. Definitions
185 For readability a number of definitions from [DSTE-REQ] are repeated
186 here:
188 Traffic Trunk: an aggregation of traffic flows of the same class
189 [i.e. which are to be treated equivalently from the DS-TE
190 perspective] which are placed inside a Label Switched Path.
192 Class-Type (CT): the set of Traffic Trunks crossing a link that is
193 governed by a specific set of Bandwidth constraints. CT is used for
194 the purposes of link bandwidth allocation, constraint based routing
195 and admission control. A given Traffic Trunk belongs to the same CT
196 on all links.
198 Protocols for Diffserv-aware TE March 2004
200 TE-Class: A pair of:
201 i. a Class-Type
202 ii. a preemption priority allowed for that Class-Type. This
203 means that an LSP transporting a Traffic Trunk from
204 that Class-Type can use that preemption priority as the
205 set-up priority, as the holding priority or both.
207 Definitions for a number of MPLS terms are not repeated here. Those
208 can be found in [MPLS-ARCH].
210 4. Configurable Parameters
212 This section only discusses the differences with the configurable
213 parameters supported for MPLS Traffic Engineering as per [TE-REQ],
214 [ISIS-TE], [OSPF-TE], and [RSVP-TE]. All other parameters are
215 unchanged.
217 4.1.1. Link Parameters
219 4.1.2. Bandwidth Constraints (BCs)
221 [DSTE-REQ] states that "Regardless of the Bandwidth Constraints
222 Model, the DS-TE solution MUST allow support for up to 8 BCs."
224 For DS-TE, the existing "Maximum Reservable link bandwidth" parameter
225 is retained but its semantic is generalized and interpreted as the
226 aggregate bandwidth constraints across all Class-Types, so that,
227 independently of the Bandwidth Constraints Model in use:
228 SUM (Reserved (CTc)) <= Max Reservable Bandwidth,
229 where the SUM is across all values of "c" in the range 0 <= c <= 7.
231 Additionally, on every link, a DS-TE implementation MUST provide for
232 configuration of up to 8 additional link parameters which are the
233 eight potential Bandwidth Constraints i.e. BC0, BC1 , ... BC7. The
234 LSR MUST interpret these Bandwidth Constraints in accordance with the
235 supported Bandwidth Constraints Model (i.e. what bandwidth constraint
236 applies to what Class-Type and how).
238 Where the Bandwidth Constraints Model imposes some relationship among
239 the values to be configured for these Bandwidth Constraints, the LSR
240 MUST enforce those at configuration time. For example, when the
241 "Russian Doll" Bandwidth Constraints Model ([DSTE-RDM]) is used, the
242 LSR must ensure that BCi is configured smaller or equal to BCj, where
243 i is greater than j, and ensure that BC0 is equal to the Maximum
244 Reservable Bandwidth. As another example, when the Maximum Allocation
245 Model ([DSTE-MAM]) is used, the LSR must ensure that all BCi are
246 configured smaller or equal to the Maximum Reservable Bandwidth.
248 Protocols for Diffserv-aware TE March 2004
250 4.1.3. Overbooking
252 DS-TE enables a network administrator to apply different overbooking
253 (or underbooking) ratios for different CTs.
255 The principal methods to achieve this are the same as historically
256 used in existing TE deployment, which are :
257 (i) To take into account the overbooking/underbooking ratio
258 appropriate for the OA/CT associated with the considered LSP
259 at the time of establishing the bandwidth size of a given
260 LSP. We refer to this method as the "LSP Size Overbooking
261 method". AND/OR
262 (ii) To take into account the overbooking/underbooking ratio at
263 the time of configuring the Maximum Reservable
264 Bandwidth/Bandwidth Constraints and use values which are
265 larger(overbooking) or smaller(underbooking) than actually
266 supported by the link. We refer to this method as the "Link
267 Size Overbooking method".
269 The "LSP Size Overbooking" method and the "Link Size Overbooking"
270 method are expected to be sufficient in many DS-TE environments and
271 require no additional configurable parameters. Other overbooking
272 methods may involve such additional configurable parameters but are
273 beyond the scope of this document.
275 4.2. LSR Parameters
277 4.2.1. TE-Class Mapping
279 In line with [DSTE-REQ], the preemption attributes defined in [TE-
280 REQ] are retained with DS-TE and applicable within, and across, all
281 Class Types. The preemption attributes of setup priority and holding
282 priority retain existing semantics, and in particular these semantics
283 are not affected by the LSP Class Type. This means that if LSP1
284 contends with LSP2 for resources, LSP1 may preempt LSP2 if LSP1 has a
285 higher set-up preemption priority (i.e. lower numerical priority
286 value) than LSP2 holding preemption priority regardless of LSP1 CT
287 and LSP2 CT.
289 DS-TE LSRs MUST allow configuration of a TE-Class mapping whereby the
290 Class-Type and preemption level are configured for each of (up to) 8
291 TE-Classes.
293 This mapping is referred to as :
295 TE-Class[i] <--> < CTc , preemption p >
297 Where 0 <= i <= 7, 0 <= c <= 7, 0 <= p <= 7
299 Protocols for Diffserv-aware TE March 2004
301 Two TE-Classes must not be identical (i.e. have both the same Class-
302 Type and the same preemption priority).
304 There are no other restrictions on how any of the 8 Class-Types can
305 be paired up with any of the 8 preemption priorities to form a TE-
306 class. In particular, one given preemption priority can be paired up
307 with two (or more) different Class-Types to form two (or more) TE-
308 classes. Similarly, one Class-Type can be paired up with two (or
309 more) different preemption priorities to form two (or more) TE-
310 Classes. Also, there is no mandatory ordering relationship between
311 the TE-Class index (i.e. "i" above) and the Class-Type (i.e. "c"
312 above) or the preemption priority (i.e. "p" above) of the TE-Class.
314 Where the network administrator uses less than 8 TE-Classes, the DS-
315 TE LSR MUST allow remaining ones to be configured as "Unused". Note
316 that "Configuring all the 8 TE-Classes as "Unused" effectively
317 results in disabling TE/DS-TE since no TE/DS-TE LSP can be
318 established (nor even configured, since as described in section 4.3.3
319 below, the CT and preemption priorities configured for an LSP must
320 form one of the configured TE-Classes)".
322 To ensure coherent DS-TE operation, the network administrator MUST
323 configure exactly the same TE-Class Mapping on all LSRs of the DS-TE
324 domain.
326 When the TE-class mapping needs to be modified in the DS-TE domain,
327 care must be exercised during the transient period of reconfiguration
328 during which some DS-TE LSRs may be configured with the new TE-class
329 mapping while others are still configured with the old TE-class
330 mapping. It is recommended that active tunnels do not use any of the
331 TE-classes which are being modified during such a transient
332 reconfiguration period.
334 4.3. LSP Parameters
336 4.3.1. Class-Type
338 With DS-TE, LSRs MUST support, for every LSP, an additional
339 configurable parameter which indicates the Class-Type of the Traffic
340 Trunk transported by the LSP.
342 There is one and only one Class-Type configured per LSP.
344 The configured Class-Type indicates, in accordance with the supported
345 Bandwidth Constraints Model, the Bandwidth Constraints that MUST be
346 enforced for that LSP.
348 Protocols for Diffserv-aware TE March 2004
350 4.3.2. Setup and Holding Preemption Priorities
352 As per existing TE, DS-TE LSRs MUST allow every DS-TE LSP to be
353 configured with a setup and holding priority, each with a value
354 between 0 and 7.
356 4.3.3. Class-Type/Preemption Relationship
358 With DS-TE, the preemption priority configured for the setup priority
359 of a given LSP and the Class-Type configured for that LSP must be
360 such that, together, they form one of the (up to) 8 TE-Classes
361 configured in the TE-Class Mapping specified in section 4.2.1 above.
363 The preemption priority configured for the holding priority of a
364 given LSP and the Class-Type configured for that LSP must also be
365 such that, together, they form one of the (up to) 8 TE-Classes
366 configured in the TE-Class Mapping specified in section 4.2.1 above.
368 The LSR MUST enforce these two rules at configuration time.
370 4.4. Examples of Parameters Configuration
372 For illustrative purposes, we now present a few examples of how these
373 configurable parameters may be used. All these examples assume that
374 different bandwidth constraints need to be enforced for different
375 sets of Traffic Trunks (e.g. for Voice and for Data) so that two, or
376 more, Class-Types need to be used.
378 4.4.1. Example 1
380 The Network Administrator of a first network using two Class Types
381 (CT1 for Voice and CT0 for Data), may elect to configure the
382 following TE-Class Mapping to ensure that Voice LSPs are never driven
383 away from their shortest path because of Data LSPs:
385 TE-Class[0] <--> < CT1 , preemption 0 >
386 TE-Class[1] <--> < CT0 , preemption 1 >
387 TE-Class[i] <--> unused, for 2 <= i <= 7
389 Voice LSPs would then be configured with:
390 - CT=CT1, set-up priority =0, holding priority=0
392 Data LSPs would then be configured with:
393 - CT=CT0, set-up priority =1, holding priority=1
395 A new Voice LSP would then be able to preempt an existing Data LSP in
396 case they contend for resources. A Data LSP would never preempt a
397 Voice LSP. A Voice LSP would never preempt another Voice LSP. A Data
398 LSP would never preempt another Data LSP.
400 Protocols for Diffserv-aware TE March 2004
402 4.4.2. Example 2
404 The Network Administrator of another network may elect to configure
405 the following TE-Class Mapping in order to optimize global network
406 resource utilization by favoring placement of large LSPs closer to
407 their shortest path:
409 TE-Class[0] <--> < CT1 , preemption 0 >
410 TE-Class[1] <--> < CT0 , preemption 1 >
411 TE-Class[2] <--> < CT1 , preemption 2 >
412 TE-Class[3] <--> < CT0 , preemption 3 >
413 TE-Class[i] <--> unused, for 4 <= i <= 7
415 Large size Voice LSPs could be configured with:
416 - CT=CT1, set-up priority =0, holding priority=0
418 Large size Data LSPs could be configured with:
419 - CT=CT0, set-up priority = 1, holding priority=1
421 Small size Voice LSPs could be configured with:
422 - CT=CT1, set-up priority = 2, holding priority=2
424 Small size Data LSPs could be configured with:
425 - CT=CT0, set-up priority = 3, holding priority=3.
427 A new large size Voice LSP would then be able to preempt a small size
428 Voice LSP or any Data LSP in case they contend for resources.
429 A new large size Data LSP would then be able to preempt a small size
430 Data LSP or a small size Voice LSP in case they contend for
431 resources, but it would not be able to preempt a large size Voice
432 LSP.
434 4.4.3. Example 3
436 The Network Administrator of another network may elect to configure
437 the following TE-Class Mapping in order to ensure that Voice LSPs are
438 never driven away from their shortest path because of Data LSPs while
439 also achieving some optimization of global network resource
440 utilization by favoring placement of large LSPs closer to their
441 shortest path:
443 TE-Class[0] <--> < CT1 , preemption 0 >
444 TE-Class[1] <--> < CT1 , preemption 1 >
445 TE-Class[2] <--> < CT0 , preemption 2 >
446 TE-Class[3] <--> < CT0 , preemption 3 >
447 TE-Class[i] <--> unused, for 4 <= i <= 7
449 Large size Voice LSPs could be configured with:
451 Protocols for Diffserv-aware TE March 2004
453 - CT=CT1, set-up priority = 0, holding priority=0.
455 Small size Voice LSPs could be configured with:
456 - CT=CT1, set-up priority = 1, holding priority=1.
458 Large size Data LSPs could be configured with:
459 - CT=CT0, set-up priority = 2, holding priority=2.
461 Small size Data LSPs could be configured with:
462 - CT=CT0, set-up priority = 3, holding priority=3.
464 A Voice LSP could preempt a Data LSP if they contend for resources. A
465 Data LSP would never preempt a Voice LSP. A Large size Voice LSP
466 could preempt a small size Voice LSP if they contend for resources. A
467 Large size Data LSP could preempt a small size Data LSP if they
468 contend for resources.
470 4.4.4. Example 4
472 The Network Administrator of another network may elect to configure
473 the following TE-Class Mapping in order to ensure that no preemption
474 occurs in the DS-TE domain:
476 TE-Class[0] <--> < CT1 , preemption 0 >
477 TE-Class[1] <--> < CT0 , preemption 0 >
478 TE-Class[i] <--> unused, for 2 <= i <= 7
480 Voice LSPs would then be configured with:
481 - CT=CT1, set-up priority =0, holding priority=0
483 Data LSPs would then be configured with:
484 - CT=CT0, set-up priority =0, holding priority=0
486 No LSP would then be able to preempt any other LSP.
488 4.4.5. Example 5
490 The Network Administrator of another network may elect to configure
491 the following TE-Class Mapping in view of increased network stability
492 through a more limited use of preemption:
494 TE-Class[0] <--> < CT1 , preemption 0 >
495 TE-Class[1] <--> < CT1 , preemption 1 >
496 TE-Class[2] <--> < CT0 , preemption 1 >
497 TE-Class[3] <--> < CT0 , preemption 2 >
498 TE-Class[i] <--> unused, for 4 <= i <= 7
500 Large size Voice LSPs could be configured with:
501 - CT=CT1, set-up priority = 0, holding priority=0.
503 Protocols for Diffserv-aware TE March 2004
505 Small size Voice LSPs could be configured with:
506 - CT=CT1, set-up priority = 1, holding priority=0.
508 Large size Data LSPs could be configured with:
509 - CT=CT0, set-up priority = 2, holding priority=1.
511 Small size Data LSPs could be configured with:
512 - CT=CT0, set-up priority = 2, holding priority=2.
514 A new large size Voice LSP would be able to preempt a Data LSP in
515 case they contend for resources, but it would not be able to preempt
516 any Voice LSP even a small size Voice LSP.
518 A new small size Voice LSP would be able to preempt a small size Data
519 LSP in case they contend for resources, but it would not be able to
520 preempt a large size Data LSP or any Voice LSP.
522 A Data LSP would not be able to preempt any other LSP.
524 5. IGP Extensions for DS-TE
526 This section only discusses the differences with the IGP
527 advertisement supported for (aggregate) MPLS Traffic Engineering as
528 per [OSPF-TE] and [ISIS-TE]. The rest of the IGP advertisement is
529 unchanged.
531 5.1. Bandwidth Constraints
533 As detailed above in section 4.1.1, up to 8 Bandwidth Constraints
534 ( BCb, 0 <= b <= 7) are configurable on any given link.
536 With DS-TE, the existing "Maximum Reservable Bandwidth" sub-TLV
537 ([OSPF-TE], [ISIS-TE]) is retained with a generalized semantic so
538 that it MUST now be interpreted as the aggregate bandwidth constraint
539 across all Class-Types [ i.e.
540 SUM (Reserved (CTc)) <= Max Reservable Bandwidth], independently of
541 the Bandwidth Constraints Model.
543 This document also defines the following new optional sub-TLV to
544 advertise the eight potential Bandwidth Constraints (BC0 to BC7):
546 "Bandwidth Constraints" sub-TLV:
547 - Bandwidth Constraints Model Id (1 octet)
548 - Reserved (3 octets)
549 - Bandwidth Constraints (Nx4 octets)
551 Where:
553 Protocols for Diffserv-aware TE March 2004
555 - With OSPF, the sub-TLV is a sub-TLV of the "Link TLV" and its
556 sub-TLV type is TBD
558 - With ISIS, the sub-TLV is a sub-TLV of the "extended IS
559 reachability TLV" and its sub-TLV type is TBD ().
561 To be removed by the RFC editor at the time of
562 publication: When the sub-TLV numbers are allocated by IANA
563 for OSPF and ISIS, replace "TBD" in the two bullet points above by
564 the respective assigned value. See IANA Considerations section for
565 allocation request.
566
567 - Bandwidth Constraints Model Id: 1 octet identifier for the
568 Bandwidth Constraints Model currently in use by the LSR
569 initiating the IGP advertisement. See the IANA Considerations
570 section below for assignment of values in this name space.
572 - Reserved: a 3-octet field. This field should be set to zero
573 by the LSR generating the sub-TLV and should be ignored by
574 the LSR receiving the sub-TLV.
576 - Bandwidth Constraints: contains BC0, BC1,... BC(N-1).
577 Each Bandwidth Constraint is encoded on 32 bits in IEEE
578 floating point format. The units are bytes (not bits!) per
579 second. Where the configured TE-class mapping and the
580 Bandwidth Constraints model in use are such that BCh+1,
581 BCh+2, ...and BC7 are not relevant to any of the Class-Types
582 associated with a configured TE-class, it is RECOMMENDED that
583 only the Bandwidth Constraints from BC0 to BCh be advertised,
584 in order to minimize the impact on IGP scalability.
586 All relevant generic TLV encoding rules (including TLV format,
587 padding and alignment, as well as IEEE floating point format
588 encoding) defined in [OSPF-TE] and [ISIS-TE] are applicable to this
589 new sub-TLV.
591 The "Bandwidth Constraints" sub-TLV format is illustrated below:
593 0 1 2 3
594 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
595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
596 | BC Model Id | Reserved |
597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
598 | BC0 value |
599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
600 // . . . //
601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
602 | BCh value |
604 Protocols for Diffserv-aware TE March 2004
606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
608 A DS-TE LSR MAY optionally advertise Bandwidth Constraints.
610 A DS-TE LSR which does advertise Bandwidth Constraints MUST use the
611 new "Bandwidth Constraints" sub-TLV (in addition to the existing
612 Maximum Reservable Bandwidth sub-TLV) to do so. For example,
613 considering the case where a Service Provider deploys DS-TE with
614 TE-classes associated with CT0 and CT1 only, and where the Bandwidth
615 Constraints Model is such that only BC0 and BC1 are relevant to CT0
616 and CT1: a DS-TE LSR which does advertise Bandwidth Constraints would
617 include in the IGP advertisement the Maximum Reservable Bandwidth
618 sub-TLV as well as the "Bandwidth Constraints" sub-TLV, where the
619 former should contain the aggregate bandwidth constraint across all
620 CTs and the latter would contain BC0 and BC1.
622 A DS-TE LSR receiving the "Bandwidth Constraints" sub-TLV with a
623 Bandwidth Constraints Model Id which does not match the Bandwidth
624 Constraints Model it currently uses, SHOULD generate a warning to the
625 operator/management-system reporting the inconsistency between
626 Bandwidth Constraints Models used on different links. Also, in that
627 case, if the DS-TE LSR does not support the Bandwidth Constraints
628 Model designated by the Bandwidth Constraints Model Id, or if the DS-
629 TE LSR does not support operations with multiple simultaneous
630 Bandwidth Constraints Models, the DS-TE LSR MAY discard the
631 corresponding TLV. If the DS-TE LSR does support the Bandwidth
632 Constraints Model designated by the Bandwidth Constraints Model Id
633 and if the DS-TE LSR does support operations with multiple
634 simultaneous Bandwidth Constraints Models, the DS-TE LSR MAY accept
635 the corresponding TLV and allow operations with different Bandwidth
636 Constraints Models used in different parts of the DS-TE domain.
638 5.2. Unreserved Bandwidth
640 With DS-TE, the existing "Unreserved Bandwidth" sub-TLV is retained
641 as the only vehicle to advertise dynamic bandwidth information
642 necessary for Constraint Based Routing on Head-ends, except that it
643 is used with a generalized semantic. The Unreserved Bandwidth sub-TLV
644 still carries eight bandwidth values but they now correspond to the
645 unreserved bandwidth for each of the TE-Class (instead of for each
646 preemption priority as per existing TE).
648 More precisely, a DS-TE LSR MUST support the Unreserved Bandwidth
649 sub-TLV with a definition which is generalized into the following:
651 The Unreserved Bandwidth sub-TLV specifies the amount of bandwidth
652 not yet reserved for each of the eight TE-classes, in IEEE floating
653 point format arranged in increasing order of TE-Class index, with
655 Protocols for Diffserv-aware TE March 2004
657 unreserved bandwidth for TE-Class [0] occurring at the start of the
658 sub-TLV, and unreserved bandwidth for TE-Class [7] at the end of the
659 sub-TLV. The unreserved bandwidth value for TE-Class [i] ( 0 <= i <=
660 7) is referred to as "Unreserved TE-Class [i]". It indicates the
661 bandwidth that is available, for reservation, to an LSP which :
662 - transports a Traffic Trunk from the Class-Type of TE-
663 Class[i], and
664 - has a setup priority corresponding to the preemption priority
665 of TE-Class[i].
667 The units are bytes per second.
669 Since the bandwidth values are now ordered by TE-class index and thus
670 can relate to different CTs with different bandwidth constraints and
671 can relate to any arbitrary preemption priority, a DS-TE LSR MUST NOT
672 assume any ordered relationship among these bandwidth values.
674 With existing TE, since all preemption priorities reflect the same
675 (and only) bandwidth constraints and since bandwidth values are
676 advertised in preemption priority order, the following relationship
677 is always true, and is often assumed by TE implementations:
679 If i < j , then "Unreserved Bw [i]" >= "Unreserved Bw [j]"
681 With DS-TE, no relationship is to be assumed so that:
682 If i < j , then any of the following relationship may be true
683 "Unreserved TE-Class [i]" = "Unreserved TE-Class [j]"
684 OR
685 "Unreserved TE-Class [i]" > "Unreserved TE-Class [j]"
686 OR
687 "Unreserved TE-Class [i]" < "Unreserved TE-Class [j]".
689 Rules for computing "Unreserved TE-Class [i]" are specified in
690 section 11.
692 If TE-Class[i] is unused, the value advertised by the IGP in
693 "Unreserved TE-Class [i]" MUST be set to zero by the LSR generating
694 the IGP advertisement, and MUST be ignored by the LSR receiving the
695 IGP advertisement.
697 6. RSVP-TE Extensions for DS-TE
699 In this section we describe extensions to RSVP-TE for support of
700 Diff-Serv-aware MPLS Traffic Engineering. These extensions are in
701 addition to the extensions to RSVP defined in [RSVP-TE] for support
702 of (aggregate) MPLS Traffic Engineering and to the extensions to RSVP
703 defined in [DIFF-MPLS] for support of Diff-Serv over MPLS.
705 Protocols for Diffserv-aware TE March 2004
707 6.1. DS-TE related RSVP Messages Format
709 One new RSVP Object is defined in this document: the CLASSTYPE
710 Object. Detailed description of this Object is provided below. This
711 new Object is applicable to Path messages. This specification only
712 defines the use of the CLASSTYPE Object in Path messages used to
713 establish LSP Tunnels in accordance with [RSVP-TE] and thus
714 containing a Session Object with a C-Type equal to LSP_TUNNEL_IPv4
715 and containing a LABEL_REQUEST object.
717 Restrictions defined in [RSVP-TE] for support of establishment of LSP
718 Tunnels via RSVP-TE are also applicable to the establishment of LSP
719 Tunnels supporting DS-TE. For instance, only unicast LSPs are
720 supported and Multicast LSPs are for further study.
722 This new CLASSTYPE object is optional with respect to RSVP so that
723 general RSVP implementations not concerned with MPLS LSP set up do
724 not have to support this object.
726 An LSR supporting DS-TE MUST support the CLASSTYPE Object.
728 6.1.1. Path Message Format
730 The format of the Path message is as follows:
732 ::= [ ]
733
734
735 [ ]
736
737 [ ]
738 [ ]
739 [ ]
740 [ ... ]
741 [ ]
743 ::= [ ]
744 [ ]
745 [ ]
747 6.2. CLASSTYPE Object
749 The CLASSTYPE object Class Name is CLASSTYPE. Its Class Number is
750 TBD. Currently, there is only one defined C_Type which is C_Type 1.
751 The CLASSTYPE object format is shown below.
753 To be removed by the RFC editor at the time of
754 publication: When the RSVP Class-Num is assigned by IANA
755 replace "TBD"
757 Protocols for Diffserv-aware TE March 2004
759 above by the assigned value. See IANA Considerations section
760 for allocation request.
761
763 6.2.1. CLASSTYPE object
765 Class Number = TBD
766 Class Type = 1
768 To be removed by the RFC editor at the time of
769 publication: When the RSVP Class Number is assigned by IANA
770 replace "TBD"
771 above by the assigned value. See IANA Considerations section
772 for allocation request.
773
775 0 1 2 3
776 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
777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
778 | Reserved | CT |
779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
781 Reserved : 29 bits
782 This field is reserved. It must be set to zero on transmission
783 and must be ignored on receipt.
785 CT : 3 bits
786 Indicates the Class-Type. Values currently allowed are
787 1, 2, ... , 7. Value of 0 is Reserved.
789 6.3. Handling CLASSTYPE Object
791 To establish an LSP tunnel with RSVP, the sender LSR creates a Path
792 message with a session type of LSP_Tunnel_IPv4 and with a
793 LABEL_REQUEST object as per [RSVP-TE]. The sender LSR may also
794 include the DIFFSERV object as per [DIFF-MPLS].
796 If the LSP is associated with Class-Type 0, the sender LSR MUST NOT
797 include the CLASSTYPE object in the Path message. This allows
798 backward compatibility with non-DSTE-configured or non-DSTE-capable
799 LSRs as discussed below in section 10 and Appendix C.
801 If the LSP is associated with Class-Type N (1 <= N <=7), the sender
802 LSR MUST include the CLASSTYPE object in the Path message with the
803 Class-Type (CT) field set to N.
805 Protocols for Diffserv-aware TE March 2004
807 If a path message contains multiple CLASSTYPE objects, only the first
808 one is meaningful; subsequent CLASSTYPE object(s) MUST be ignored and
809 MUST NOT be forwarded.
811 Each LSR along the path MUST record the CLASSTYPE object, when
812 present, in its path state block.
814 If the CLASSTYPE object is not present in the Path message, the LSR
815 MUST associate the Class-Type 0 to the LSP.
817 The destination LSR responding to the Path message by sending a Resv
818 message MUST NOT include a CLASSTYPE object in the Resv message
819 (whether the Path message contained a CLASSTYPE object or not).
821 During establishment of an LSP corresponding to the Class-Type N, the
822 LSR MUST perform admission control over the bandwidth available for
823 that particular Class-Type.
825 An LSR that recognizes the CLASSTYPE object and that receives a path
826 message which:
827 - contains the CLASSTYPE object, but
828 - which does not contain a LABEL_REQUEST object or which does
829 not have a session type of LSP_Tunnel_IPv4,
830 MUST send a PathErr towards the sender with the error code "Diff-
831 Serv-aware TE Error" and an error value of "Unexpected CLASSTYPE
832 object". Those are defined below in section 6.5.
834 An LSR receiving a Path message with the CLASSTYPE object, which:
835 - recognizes the CLASSTYPE object, but
836 - does not support the particular Class-Type,
837 MUST send a PathErr towards the sender with the error code "Diff-
838 Serv-aware TE Error" and an error value of "Unsupported Class-Type".
839 Those are defined below in section 6.5.
841 An LSR receiving a Path message with the CLASSTYPE object, which:
842 - recognizes the CLASSTYPE object, but
843 - determines that the Class-Type value is not valid (i.e.
844 Class-Type value 0),
845 MUST send a PathErr towards the sender with the error code "Diff-
846 Serv-aware TE Error" and an error value of "Invalid Class-Type
847 value". Those are defined below in section 6.5.
849 An LSR receiving a Path message with the CLASSTYPE object, which:
850 - recognizes the CLASSTYPE object,
851 - supports the particular Class-Type, but
852 - determines that the tuple formed by (i) this Class-Type and
853 (ii) the set-up priority signaled in the same Path message,
854 is not one of the eight TE-classes configured in the TE-class
855 mapping,
857 Protocols for Diffserv-aware TE March 2004
859 MUST send a PathErr towards the sender with the error code "Diff-
860 Serv-aware TE Error" and an error value of "CT and setup priority do
861 not form a configured TE-Class". Those are defined below in section
862 6.5.
864 An LSR receiving a Path message with the CLASSTYPE object, which:
865 - recognizes the CLASSTYPE object,
866 - supports the particular Class-Type, but
867 - determines that the tuple formed by (i) this Class-Type and
868 (ii) the holding priority signaled in the same Path message,
869 is not one of the eight TE-classes configured in the TE-class
870 mapping,
871 MUST send a PathErr towards the sender with the error code "Diff-
872 Serv-aware TE Error" and an error value of "CT and holding priority
873 do not form a configured TE-Class". Those are defined below in
874 section 6.5.
876 An LSR receiving a Path message with the CLASSTYPE object and with
877 the DIFFSERV object for an L-LSP, which:
878 - recognizes the CLASSTYPE object,
879 - has local knowledge of the relationship between Class-Types
880 and PSC (e.g. via configuration)
881 - based on this local knowledge, determines that the PSC
882 signaled in the DIFFSERV object is inconsistent with the
883 Class-Type signaled in the CLASSTYPE object,
884 MUST send a PathErr towards the sender with the error code "Diff-
885 Serv-aware TE Error" and an error value of "Inconsistency between
886 signaled PSC and signaled CT". Those are defined below in section
887 6.5.
889 An LSR receiving a Path message with the CLASSTYPE object and with
890 the DIFFSERV object for an E-LSP, which:
891 - recognizes the CLASSTYPE object,
892 - has local knowledge of the relationship between Class-Types
893 and PHBs (e.g. via configuration)
894 - based on this local knowledge, determines that the PHBs
895 signaled in the MAP entries of the DIFFSERV object are
896 inconsistent with the Class-Type signaled in the CLASSTYPE
897 object,
898 MUST send a PathErr towards the sender with the error code "Diff-
899 Serv-aware TE Error" and an error value of "Inconsistency between
900 signaled PHBs and signaled CT". Those are defined below in section
901 6.5.
903 An LSR MUST handle the situations where the LSP can not be accepted
904 for other reasons than those already discussed in this section, in
905 accordance with [RSVP-TE] and [DIFF-MPLS] (e.g. a reservation is
906 rejected by admission control, a label can not be associated).
908 Protocols for Diffserv-aware TE March 2004
910 6.4. Non-support of the CLASSTYPE Object
912 An LSR that does not recognize the CLASSTYPE object Class-Num MUST
913 behave in accordance with the procedures specified in [RSVP] for an
914 unknown Class-Num whose format is 0bbbbbbb (i.e. it must send a
915 PathErr with the error code "Unknown object class" toward the
916 sender).
918 An LSR that recognizes the CLASSTYPE object Class-Num but does not
919 recognize the CLASSTYPE object C-Type, MUST behave in accordance with
920 the procedures specified in [RSVP] for an unknown C-type (i.e. it
921 must send a PathErr with the error code "Unknown object C-Type"
922 toward the sender).
924 In both situations, this causes the path set-up to fail. The sender
925 SHOULD notify the operator/management-system that an LSP cannot be
926 established and possibly might take action to retry reservation
927 establishment without the CLASSTYPE object.
929 6.5. Error Codes For Diff-Serv-aware TE
931 In the procedures described above, certain errors must be reported as
932 a "Diff-Serv-aware TE Error". The value of the "Diff-Serv-aware TE
933 Error" error code is (TBD)().
935 To be removed by the RFC editor at the time of
936 publication: When the "Diff-Serv-aware TE Error" Error Code is
937 assigned by
938 IANA, replace "TBD" above by the assigned value.
939 See IANA Considerations section for allocation request.
940
941 The following defines error values for the Diff-Serv-aware TE Error:
943 Value Error
945 1 Unexpected CLASSTYPE object
946 2 Unsupported Class-Type
947 3 Invalid Class-Type value
948 4 Class-Type and setup priority do not form a configured
949 TE-Class
950 5 Class-Type and holding priority do not form a
951 configured TE-Class
952 6 Inconsistency between signaled PSC and signaled
953 Class-Type
954 7 Inconsistency between signaled PHBs and signaled
955 Class-Type
957 See the IANA Considerations section for allocation of additional
958 Values.
960 Protocols for Diffserv-aware TE March 2004
962 7. DS-TE support with MPLS extensions.
964 There are a number of extensions to the initial base specification
965 for signaling [RSVP-TE] and IGP support for TE [OSPF-TE][ISIS-TE].
966 Those include enhancements for generalization [GMPLS-SIG]
967 [GMPLS-ROUTE], as well as for additional functionality such as LSP
968 hierarchy [HIERARCHY], link bundling [BUNDLE] and fast restoration
969 [REROUTE]. These specifications may reference how to encode
970 information associated with certain preemption priorities, how to
971 treat LSPs at different preemption priorities, or otherwise specify
972 encodings or behavior that have a different meaning for an DS-TE
973 router.
975 In order for an implementation to support both this specification for
976 Diff-Serv-aware TE and a given MPLS enhancement such as those listed
977 above (but not limited to those), it MUST treat references to
978 "preemption priority" and to "Maximum Reservable Bandwidth" in a
979 generalized manner, such as it is used in this specification.
981 Additionally, current and future MPLS enhancements may include more
982 precise specification for how they interact with Diff-Serv-aware TE.
984 7.1. DS-TE support and references to preemption priority
986 When a router supports both Diff-Serv-aware TE and one of the MPLS
987 protocol extensions such as those mentioned above, encoding of values
988 of preemption priority in signaling or encoding of information
989 associated with preemption priorities in IGP defined for the MPLS
990 extension, MUST be considered to be an encoding of the same
991 information for the corresponding TE-Class. For instance, if an MPLS
992 enhancement specifies advertisement in IGP of a parameter for routing
993 information at preemption priority N, in a DS-TE environment it MUST
994 actually be interpreted as specifying advertisement of the same
995 routing information but for TE-Class [N]. On receipt, DS-TE routers
996 MUST interpret it as such as well.
998 When there is discussion on how to comparatively treat LSPs of
999 different preemption priority, a DS-TE LSR MUST treat the preemption
1000 priorities in this context as the preemption priorities associated
1001 with the TE-Classes of the LSPs in question.
1003 7.2. DS-TE support and references to Maximum Reservable Bandwidth
1005 When a router supports both Diff-Serv-aware TE and MPLS protocol
1006 extensions such as those mentioned above, advertisements of Maximum
1007 Reservable Bandwidth MUST be done with the generalized interpretation
1008 defined above in section 4.1.1 as the aggregate bandwidth constraint
1010 Protocols for Diffserv-aware TE March 2004
1012 across all Class-Types and MAY also allow the optional advertisement
1013 of all Bandwidth Constraints.
1015 8. Constraint Based Routing
1017 Let us consider the case where a path needs to be computed for an LSP
1018 whose Class-Type is configured to CTc and whose set-up preemption
1019 priority is configured to p.
1021 Then the pair of CTc and p will map to one of the TE-Classes defined
1022 in the TE-Class mapping. Let us refer to this TE-Class as TE-
1023 Class[i].
1025 The Constraint Based Routing algorithm of a DS-TE LSR is still only
1026 required to perform path computation satisfying a single bandwidth
1027 constraint which is to fit in "Unreserved TE-Class [i]" as advertised
1028 by the IGP for every link. Thus, no changes are required to the
1029 existing TE Constraint Based Routing algorithm itself.
1031 The Constraint Based Routing algorithm MAY also take into account,
1032 when used, the optional additional information advertised in IGP such
1033 as the Bandwidth Constraints and the Maximum Reservable Bandwidth. As
1034 an example, the Bandwidth Constraints MIGHT be used as a tie-breaker
1035 criteria in situations where multiple paths, otherwise equally
1036 attractive, are possible.
1038 9. Diff-Serv scheduling
1040 The Class-Type signaled at LSP establishment MAY optionally be used
1041 by DS-TE LSRs to dynamically adjust the resources allocated to the
1042 Class-Type by the Diff-Serv scheduler. In addition, the Diff-Serv
1043 information (i.e. the PSC) signaled by the TE-LSP signaling protocols
1044 as specified in [DIFF-MPLS], if used, MAY optionally be used by DS-TE
1045 LSRs to dynamically adjust the resources allocated to a PSC/OA within
1046 a Class Type by the Diff-Serv scheduler.
1048 10. Existing TE as a Particular Case of DS-TE
1050 We observe that existing TE can be viewed as a particular case of
1051 DS-TE where:
1053 (i) a single Class-Type is used,
1054 (ii) all 8 preemption priorities are allowed for that Class-
1055 Type, and
1056 (iii) the following TE-Class Mapping is used:
1057 TE-Class[i] <--> < CT0 , preemption i >
1059 Protocols for Diffserv-aware TE March 2004
1061 Where 0 <= i <= 7.
1063 In that case, DS-TE behaves as existing TE.
1065 As with existing TE, the IGP advertises:
1066 - Unreserved Bandwidth for each of the 8 preemption priorities
1068 As with existing TE, the IGP may advertise:
1069 - Maximum Reservable Bandwidth containing a bandwidth
1070 constraint applying across all LSPs
1072 Since all LSPs transport traffic from CT0, RSVP-TE signaling is done
1073 without explicit signaling of the Class-Type (which is only used for
1074 other Class-Types than CT0 as explained in section 6) as with
1075 existing TE.
1077 11. Computing "Unreserved TE-Class [i]" and Admission Control Rules
1079 11.1. Computing "Unreserved TE-Class [i]"
1081 We first observe that, for existing TE, details on admission control
1082 algorithms for TE LSPs, and consequently details on formulas for
1083 computing the unreserved bandwidth, are outside the scope of the
1084 current IETF work. This is left for vendor differentiation. Note that
1085 this does not compromise interoperability across various
1086 implementations since the TE schemes rely on LSRs to advertise their
1087 local view of the world in terms of Unreserved Bw to other LSRs. This
1088 way, regardless of the actual local admission control algorithm used
1089 on one given LSR, Constraint Based Routing on other LSRs can rely on
1090 advertised information to determine whether an additional LSP will be
1091 accepted or rejected by the given LSR. The only requirement is that
1092 an LSR advertises unreserved bandwidth values which are consistent
1093 with its specific local admission control algorithm and take into
1094 account the holding preemption priority of established LSPs.
1096 In the context of DS-TE, again, details on admission control
1097 algorithms are left for vendor differentiation and formulas for
1098 computing the unreserved bandwidth for TE-Class[i] are outside the
1099 scope of this specification. However, DS-TE places the additional
1100 requirement on the LSR that the unreserved bandwidth values
1101 advertised MUST reflect all of the Bandwidth Constraints relevant to
1102 the CT associated with TE-Class[i] in accordance with the Bandwidth
1103 Constraints Model. Thus, formulas for computing "Unreserved TE-Class
1104 [i]" depend on the Bandwidth Constraints Model in use and MUST
1105 reflect how bandwidth constraints apply to CTs. Example formulas for
1106 computing "Unreserved TE-Class [i]" Model are provided for the
1108 Protocols for Diffserv-aware TE March 2004
1110 Russian Dolls Model and Maximum Allocation Model respectively in
1111 [DSTE-RDM] and [DSTE-MAM].
1113 As with existing TE, DS-TE LSRs MUST consider the holding preemption
1114 priority of established LSPs (as opposed to their set-up preemption
1115 priority) for the purpose of computing the unreserved bandwidth for
1116 TE-Class [i].
1118 11.2. Admission Control Rules
1120 A DS-TE LSR MUST support the following admission control rule:
1122 Regardless of how the admission control algorithm actually computes
1123 the unreserved bandwidth for TE-Class[i] for one of its local link,
1124 an LSP of bandwidth B, of set-up preemption priority p and of Class-
1125 Type CTc is admissible on that link if, and only if,:
1127 B <= Unreserved Bandwidth for TE-Class[i]
1129 Where
1131 - TE-Class [i] maps to < CTc , p > in the TE-Class mapping
1132 configured on the LSR.
1134 12. Security Considerations
1136 This document does not introduce additional security threats beyond
1137 those described for Diff-Serv ([DIFF-ARCH]) and MPLS Traffic
1138 Engineering ([TE-REQ], [RSVP-TE], [OSPF-TE], [ISIS-TE]) and the same
1139 security measures and procedures described in these documents apply
1140 here. For example, the approach for defense against theft- and
1141 denial-of-service attacks discussed in [DIFF-ARCH], which consists of
1142 the combination of traffic conditioning at DS boundary nodes along
1143 with security and integrity of the network infrastructure within a
1144 Diff-Serv domain, may be followed when DS-TE is in use. Also, as
1145 stated in [TE-REQ], it is specifically important that manipulation of
1146 administratively configurable parameters (such as those related to
1147 DS-TE LSPs) be executed in a secure manner by authorized entities.
1149 13. Acknowledgments
1151 We thank Martin Tatham, Angela Chiu and Pete Hicks for their earlier
1152 contribution in this work. We also thank Sanjaya Choudhury for his
1153 thorough review and suggestions.
1155 Protocols for Diffserv-aware TE March 2004
1157 14. IANA Considerations
1159 This document creates two new name spaces which are to be managed by
1160 IANA. Also, a number of assignments from existing name spaces have
1161 been made by IANA in this document. Those are discussed below.
1163 14.1. A new name space for Bandwidth Constraints Model Identifiers
1165 This document defines in section 5.1 a "Bandwidth Constraints Model
1166 Id" field (name space) within the "Bandwidth Constraints" sub-TLV,
1167 both for OSPF and ISIS. IANA is requested to create and maintain this
1168 new name space. The field for this namespace is 1 octet, and IANA
1169 guidelines for assignments for this field are as follows:
1171 o values in the range 0-127 are to be assigned according to
1172 the "Specification Required" policy defined in [IANA-CONS].
1174 o values in the range 128-239 are not to be assigned at this
1175 time. Before any assignments can be made in this range, there MUST be
1176 a Standards Track RFC that specifies IANA Considerations that cover
1177 assignment within that range.
1179 o values in the range 240-255 are for experimental use; these
1180 will not be registered with IANA, and MUST NOT be mentioned by RFCs.
1182 14.2. A new name space for Error Values under the "Diff-Serv-aware TE
1183 Error"
1185 An Error Code is an 8-bit quantity defined in [RSVP] that appears in
1186 an ERROR_SPEC object to broadly define an error condition. With each
1187 Error Code there may be a 16-bit Error Value (which depends on the
1188 Error Code) that further specifies the cause of the error.
1190 This document defines in section 6.5 a new RSVP error code, the
1191 "Diff-Serv-aware TE Error" (see section 14.3.4). The Error Values for
1192 the "Diff-Serv-aware TE Error" constitute a new name space to be
1193 managed by IANA.
1195 This document defines, in section 6.5, values 1 through 7 in that
1196 name space (see section 14.3.5).
1198 Future allocations of values in this name space are to be assigned by
1199 IANA using the "Specification Required" policy defined in [IANA-
1200 CONS].
1202 14.3. Assignments made in this Document
1204 14.3.1. Bandwidth Constraints sub-TLV for OSPF version 2
1206 Protocols for Diffserv-aware TE March 2004
1208 [OSPF-TE] creates a name space for the sub-TLV types within the "Link
1209 TLV" of the Traffic Engineering LSA and rules for management of this
1210 name space by IANA.
1212 This document defines in section 5.1 a new sub-TLV, the "Bandwidth
1213 Constraints" sub-TLV, for the OSPF "Link" TLV. In accordance with the
1214 IANA considerations provided in [OSPF-TE], a sub-TLV type in the
1215 range 10 to 32767 was requested and the value TBD has been assigned
1216 by IANA for the "Bandwidth Constraints" sub-TLV.
1218 To be removed by the RFC editor at the time of
1219 publication: When the sub-TLV Type is assigned by IANA replace
1220 "TBD" above
1221 by the assigned value.
1222
1223 14.3.2. Bandwidth Constraints sub-TLV for ISIS
1225 [ISIS-TE] creates a name space for the sub-TLV types within the ISIS
1226 "Extended IS Reachability" TLV and rules for management of this name
1227 space by IANA.
1229 This document defines in section 5.1 a new sub-TLV, the "Bandwidth
1230 Constraints" sub-TLV, for the ISIS "Extended IS Reachability" TLV. In
1231 accordance with the IANA considerations provided in [ISIS-TE], a sub-
1232 TLV type was requested and the value TBD has been assigned by IANA
1233 for the "Bandwidth Constraints" sub-TLV.
1235 To be removed by the RFC editor at the time of
1236 publication: When the sub-TLV Type is assigned by IANA replace
1237 "TBD" above
1238 by the assigned value.
1239
1240 14.3.3. CLASSTYPE object for RSVP
1242 [RSVP] defines the Class Number name space for RSVP object which is
1243 managed by IANA. Currently allocated Class Numbers are listed at
1244 "http://www.iana.org/assignments/rsvp-parameters"
1246 This document defines in section 6.2.1 a new RSVP object, the
1247 CLASSTYPE object. IANA was requested to assign a Class Number for
1248 this RSVP object from the range defined in section 3.10 of [RSVP] for
1249 those objects which, if not understood, cause the entire RSVP message
1250 to be rejected with an error code of "Unknown Object Class". Such
1251 objects are identified by a zero in the most significant bit of the
1252 class number (i.e.
1253 Class-Num = 0bbbbbbb).
1254 IANA assigned Class-Number TBD to the CLASSTYPE object. C_Type 1 is
1255 defined in this document for the CLASSTYPE object.
1257 Protocols for Diffserv-aware TE March 2004
1259 To be removed by the RFC editor at the time of
1260 publication: When the RSVP Class-Num is assigned by IANA
1261 replace "TBD"
1262 above by the assigned value.
1263
1264 14.3.4. "Diff-Serv-aware TE Error" Error Code
1266 [RSVP] defines the Error Code name space and rules for management of
1267 this name space by IANA. Currently allocated Error Codes are listed
1268 at "http://www.iana.org/assignments/rsvp-parameters"
1270 This document defines in section 6.5 a new RSVP Error Code, the
1271 "Diff-Serv-aware TE Error". In accordance with the IANA
1272 considerations provided in [RSVP], Error Code TBD was assigned by
1273 IANA to the "Diff-Serv-aware TE Error".
1275 To be removed by the RFC editor at the time of
1276 publication: When the RSVP Class-Num is assigned by IANA
1277 replace "TBD"
1278 above by the assigned value.
1279
1280 14.3.5. Error Values for "Diff-Serv-aware TE Error"
1282 An Error Code is an 8-bit quantity defined in [RSVP] that appears in
1283 an ERROR_SPEC object to broadly define an error condition. With each
1284 Error Code there may be a 16-bit Error Value (which depends on the
1285 Error Code) that further specifies the cause of the error.
1287 This document defines in section 6.5 a new RSVP error code, the
1288 "Diff-Serv-aware TE Error" (see section 14.3.4). The Error Values for
1289 the "Diff-Serv-aware TE Error" constitute a new name space to be
1290 managed by IANA.
1292 This document defines, in section 6.5, the following Error Values for
1293 the "Diff-Serv-aware TE Error":
1295 Value Error
1297 1 Unexpected CLASSTYPE object
1298 2 Unsupported Class-Type
1299 3 Invalid Class-Type value
1300 4 Class-Type and setup priority do not form a configured
1301 TE-Class
1302 5 Class-Type and holding priority do not form a
1303 configured TE-Class
1304 6 Inconsistency between signaled PSC and signaled
1305 Class-Type
1306 7 Inconsistency between signaled PHBs and signaled
1307 Class-Type
1309 Protocols for Diffserv-aware TE March 2004
1311 See section 14.2 for allocation of other values in that name space.
1313 15. Intellectual Property Considerations
1315 The IETF takes no position regarding the validity or scope of any
1316 intellectual property or other rights that might be claimed to
1317 pertain to the implementation or use of the technology described in
1318 this document or the extent to which any license under such rights
1319 might or might not be available; neither does it represent that it
1320 has made any effort to identify any such rights. Information on the
1321 IETF's procedures with respect to rights in standards-track and
1322 standards-related documentation can be found in RFC 2028. Copies of
1323 claims of rights made available for publication and any assurances of
1324 licenses to be made available, or the result of an attempt made to
1325 obtain a general license or permission for the use of such
1326 proprietary rights by implementors or users of this specification can
1327 be obtained from the IETF Secretariat.
1329 The IETF invites any interested party to bring to its attention any
1330 copyrights, patents or patent applications, or other proprietary
1331 rights which may cover technology that may be required to practice
1332 this standard. Please address the information to the IETF Executive
1333 Director.
1335 16. Normative References
1337 [DSTE-REQ] Le Faucheur et al, Requirements for support of Diff-Serv-
1338 aware MPLS Traffic Engineering, RFC3564, .
1340 [MPLS-ARCH] Rosen et al., "Multiprotocol Label Switching
1341 Architecture", RFC3031.
1343 [DIFF-ARCH] Blake et al., "An Architecture for Differentiated
1344 Services", RFC2475.
1346 [TE-REQ] Awduche et al., "Requirements for Traffic Engineering Over
1347 MPLS", RFC2702.
1349 [OSPF-TE] Katz et al., "Traffic Engineering (TE) Extensions to OSPF
1350 Version 2", RFC3630.
1352 [ISIS-TE] Smit, Li, IS-IS extensions for Traffic Engineering, draft-
1353 ietf-isis-traffic-05.txt, work in progress.
1355 Protocols for Diffserv-aware TE March 2004
1357 [RSVP-TE] Awduche et al, "RSVP-TE: Extensions to RSVP for LSP
1358 Tunnels", RFC 3209.
1360 [RSVP] Braden et al, "Resource ReSerVation Protocol (RSVP) - Version
1361 1 Functional Specification", RFC 2205.
1363 [DIFF-MPLS] Le Faucheur et al, "MPLS Support of Diff-Serv", RFC3270.
1365 [RFC2119] S. Bradner, Key words for use in RFCs to Indicate
1366 Requirement Levels, RFC2119.
1368 [IANA-CONS], T. Narten et al, "Guidelines for Writing an IANA
1369 Considerations Section in RFCs", RFC2434.
1371 17. Informative References
1373 [DSTE-RDM] Le Faucheur et al., "Russian Dolls Bandwidth Constraints
1374 Model for DS-TE", draft-ietf-tewg-diff-te-russian-04.txt, work in
1375 progress.
1377 [DSTE-MAM] Le Faucheur, Lai, "Maximum Allocation Bandwidth
1378 Constraints Model for DS-TE", draft-ietf-tewg-diff-te-mam-02.txt,
1379 work in progress .
1381 [DSTE-MAR] Ash, "Max Allocation with Reservation Bandwidth
1382 Constraints Model for MPLS/DiffServ TE & Performance Comparisons",
1383 draft-ietf-tewg-diff-te-mar-03.txt, work in progress .
1385 [GMPLS-SIG] Berger et. al., "Generalized Multi-Protocol Label
1386 Switching (GMPLS) Signaling Functional Description", RFC3471
1388 [GMPLS-ROUTE] Kompella et. al., "Routing Extensions in Support of
1389 Generalized MPLS", draft-ietf-ccamp-gmpls-routing-09.txt, work in
1390 progress.
1392 [BUNDLE] Kompella, Rekhter, Berger, "Link Bundling in MPLS Traffic
1393 Engineering", draft-ietf-mpls-bundle-04.txt, work in progress.
1395 [HIERARCHY] Kompella, Rekhter, "LSP Hierarchy with Generalized MPLS
1396 TE", draft-ietf-mpls-lsp-hierarchy-08.txt, work in progress.
1398 [REROUTE] Pan et. al., "Fast Reroute Extensions to RSVP-TE for LSP
1399 Tunnels", draft-ietf-mpls-rsvp-lsp-fastreroute-03.txt, work in
1400 progress.
1402 18. Editor's Address:
1404 Protocols for Diffserv-aware TE March 2004
1406 Francois Le Faucheur
1407 Cisco Systems, Inc.
1408 Village d'Entreprise Green Side - Batiment T3
1409 400, Avenue de Roumanille
1410 06410 Biot-Sophia Antipolis
1411 France
1412 Phone: +33 4 97 23 26 19
1413 Email: flefauch@cisco.com
1415 19. Full Copyright Statement
1417 Copyright (C) The Internet Society (2004). All Rights Reserved.
1419 This document and translations of it may be copied and furnished to
1420 others, and derivative works that comment on or otherwise explain it
1421 or assist in its implementation may be prepared, copied, published
1422 and distributed, in whole or in part, without restriction of any
1423 kind, provided that the above copyright notice and this paragraph are
1424 included on all such copies and derivative works. However, this
1425 document itself may not be modified in any way, such as by removing
1426 the copyright notice or references to the Internet Society or other
1427 Internet organizations, except as needed for the purpose of
1428 developing Internet standards in which case the procedures for
1429 copyrights defined in the Internet Standards process must be
1430 followed, or as required to translate it into languages other than
1431 English.
1433 The limited permissions granted above are perpetual and will not be
1434 revoked by the Internet Society or its successors or assigns.
1436 This document and the information contained herein is provided on an
1437 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
1438 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
1439 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
1440 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
1441 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1443 Appendix A - Prediction for Multiple Path Computation
1445 There are situations where a Head-End needs to compute paths for
1446 multiple LSPs over a short period of time. There are potential
1447 advantages for the Head-end in trying to predict the impact of the n-
1448 th LSP on the unreserved bandwidth when computing the path for the
1449 (n+1)-th LSP, before receiving updated IGP information. One example
1450 would be to perform better load-distribution of the multiple LSPs
1451 across multiple paths. Another example would be to avoid CAC
1452 rejection when the (n+1)-th LSP would no longer fit on a link after
1454 Protocols for Diffserv-aware TE March 2004
1456 establishment of the n-th LSP. While there are also a number of
1457 conceivable scenarios where doing such predictions might result in a
1458 worse situation, it is more likely to improve the situation. As a
1459 matter of fact, a number of network administrators have elected to
1460 use such predictions when deploying existing TE.
1462 Such predictions are local matters, are optional and are outside the
1463 scope of this specification.
1465 Where such predictions are not used, the optional Bandwidth
1466 Constraint sub-TLV and the optional Maximum Reservable Bandwidth sub-
1467 TLV need not be advertised in IGP for the purpose of path computation
1468 since the information contained in the Unreserved Bw sub-TLV is all
1469 that is required by Head-Ends to perform Constraint Based Routing.
1471 Where such predictions are used on Head-Ends, the optional Bandwidth
1472 Constraints sub-TLV and the optional Maximum Reservable Bandwidth
1473 sub-TLV MAY be advertised in IGP. This is in order for the Head-ends
1474 to predict as accurately as possible how an LSP affects unreserved
1475 bandwidth values for subsequent LSPs.
1477 Remembering that actual admission control algorithms are left for
1478 vendor differentiation, we observe that predictions can only be
1479 performed effectively when the Head-end LSR predictions are based on
1480 the same (or a very close) admission control algorithm as used by
1481 other LSRs.
1483 Appendix B - Solution Evaluation
1485 1. Satisfying Detailed Requirements
1487 This DS-TE Solution addresses all the scenarios presented in [DSTE-
1488 REQ].
1490 It also satisfies all the detailed requirements presented in [DSTE-
1491 REQ].
1493 The objective set out in the last paragraph of section "4.7
1494 overbooking" of [DSTE-REQ] is only partially addressed by this DS-TE
1495 solution. Through support of the "LSP Size Overbooking" and "Link
1496 Size Overbooking" methods, this DS-TE solution effectively allows CTs
1497 to have different overbooking ratios and simultaneously allows
1498 overbooking to be tweaked differently (collectively across all CTs)
1499 on different links. But, in a general sense, it does not allow the
1500 effective overbooking ratio of every CT to be tweaked differently in
1501 different parts of the network independently of other CTs, while
1502 maintaining accurate bandwidth accounting of how different CTs
1504 Protocols for Diffserv-aware TE March 2004
1506 mutually affect each other through shared Bandwidth Constraints (such
1507 as the Maximum Reservable Bandwidth).
1509 2. Flexibility
1511 This DS-TE solution supports 8 CTs. It is entirely flexible as to how
1512 Traffic Trunks are grouped together into a CT.
1514 3. Extendibility
1516 A maximum of 8 CTs is considered by the authors of this document as
1517 more than comfortable. A maximum of 8 TE-classes is considered by the
1518 authors of this document as sufficient. However, this solution could
1519 be extended to support more CTs or more TE-classes if deemed
1520 necessary in the future; This would necessitate additional IGP
1521 extensions beyond those specified in this document.
1523 Although the prime objective of this solution is support of Diff-
1524 Serv-aware Traffic Engineering, its mechanisms are not tightly
1525 coupled with Diff-Serv. This makes the solution amenable, or more
1526 easily extendable, for support of potential other future Traffic
1527 Engineering applications.
1529 4. Scalability
1531 This DS-TE solution is expected to have a very small scalability
1532 impact compared to existing TE.
1534 From an IGP viewpoint, the amount of mandatory information to be
1535 advertised is identical to existing TE. One additional sub-TLV has
1536 been specified, but its use is optional and it only contains a
1537 limited amount of static information (at most 8 Bandwidth
1538 Constraints).
1540 We expect no noticeable impact on LSP Path computation since, as with
1541 existing TE, this solution only requires CSPF to consider a single
1542 unreserved bandwidth value for any given LSP.
1544 From a signaling viewpoint we expect no significant impact due to
1545 this solution since it only requires processing of one additional
1546 information (the Class-Type) and does not significantly increase the
1547 likelihood of CAC rejection. Note that DS-TE has some inherent impact
1548 on LSP signaling in the sense that it assumes that different classes
1549 of traffic are split over different LSPs so that more LSPs need to be
1550 signaled; but this is due to the DS-TE concept itself and not to the
1551 actual DS-TE solution discussed here.
1553 5. Backward Compatibility/Migration
1555 Protocols for Diffserv-aware TE March 2004
1557 This solution is expected to allow smooth migration from existing TE
1558 to DS-TE. This is because existing TE can be supported as a
1559 particular configuration of DS-TE. This means that an "upgraded" LSR
1560 with a DS-TE implementation can directly interwork with an "old" LSR
1561 supporting existing TE only.
1563 This solution is expected to allow smooth migration when increasing
1564 the number of CTs actually deployed since it only requires
1565 configuration changes. however, these changes must be performed in a
1566 coordinated manner across the DS-TE domain.
1568 Appendix C - Interoperability with non DS-TE capable LSRs
1570 This DSTE solution allows operations in a hybrid network where some
1571 LSRs are DS-TE capable while some LSRs are not DS-TE capable, which
1572 may occur during migration phases. This Appendix discusses the
1573 constraints and operations in such hybrid networks.
1575 We refer to the set of DS-TE capable LSRs as the DS-TE domain. We
1576 refer to the set of non DS-TE capable (but TE capable) LSRs as the
1577 TE-domain.
1579 Hybrid operations requires that the TE-class mapping in the DS-TE
1580 domain is configured so that:
1581 - a TE-class exist for CT0 for every preemption priority
1582 actually used in the TE domain
1583 - the index in the TE-class mapping for each of these TE-
1584 classes is equal to the preemption priority.
1586 For example, imagine the TE domain uses preemption 2 and 3. Then, DS-
1587 TE can be deployed in the same network by including the following TE-
1588 classes in the TE-class mapping:
1589 i <---> CT preemption
1590 ====================================
1591 2 CT0 2
1592 3 CT0 3
1594 Another way to look at this is to say that, the whole TE-class
1595 mapping does not have to be consistent with the TE domain, but the
1596 subset of this TE-Class mapping applicable to CT0 must effectively be
1597 consistent with the TE domain.
1599 Hybrid operations also requires that:
1600 - non DS-TE capable LSRs be configured to advertise the Maximum
1601 Reservable Bandwidth
1602 - DS-TE capable LSRs be configured to advertise Bandwidth
1603 Constraints (using the Max Reservable Bandwidth sub-TLV as
1605 Protocols for Diffserv-aware TE March 2004
1607 well as the Bandwidth Constraints sub-TLV, as specified in
1608 section 5.1 above).
1609 This allows DS-TE capable LSRs to unambiguously identify non DS-TE
1610 capable LSRs.
1612 Finally hybrid operations require that non DS-TE capable LSRs be able
1613 to accept Unreserved Bw sub-TLVs containing non decreasing bandwidth
1614 values (ie with Unreserved [p] < Unreserved [q] with p CT preemption
1639 ====================================
1640 0 CT1 0
1641 1 CT1 1
1642 2 CT0 2
1643 3 CT0 3
1644 rest unused
1646 LSR0 is configured with a Max Reservable bandwidth=m01 for Link01.
1647 LSR1 is configured with a BC0=x0 a BC1=x1(possibly=0), and a Max
1648 Reservable Bandwidth=m10(possibly=m01) for Link01.
1650 LSR0 will advertise in IGP for Link01:
1651 - Max Reservable Bw sub-TLV =
1652 - Unreserved Bw sub-TLV =
1653
1655 Protocols for Diffserv-aware TE March 2004
1657 On receipt of such advertisement, LSR1 will:
1658 - understand that LSR0 is not DS-TE capable because it
1659 advertised a Max Reservable Bw sub-TLV and no Bandwidth
1660 Constraints sub-TLV
1661 - conclude that only CT0 LSPs can transit via LSR0 and that
1662 only the values CT0/2 and CT0/3 are meaningful in the
1663 Unreserved Bw sub-TLV. LSR1 may effectively behave as if the
1664 six other values contained in the Unreserved Bw sub-TLV were
1665 set to zero.
1667 LSR1 will advertise in IGP for Link01:
1668 - Max Reservable Bw sub-TLV =
1669 - Bandwidth Constraints sub-TLV =
1670 - Unreserved Bw sub-TLV =
1672 On receipt of such advertisement, LSR0 will:
1673 - Ignore the Bandwidth Constraints sub-TLV (unrecognized)
1674 - Correctly process CT0/2 and CT0/3 in the Unreserved Bw sub-
1675 TLV and use these values for CTO LSP establishment
1676 - Incorrectly believe that the other values contained in the
1677 Unreserved Bw sub-TLV relates to other preemption priorities
1678 for CT0, but will actually never use those since we assume
1679 that only preemption 2 and 3 are used in the TE domain.