idnits 2.17.00 (12 Aug 2021) /tmp/idnits57890/draft-bccdg-ccamp-gmpls-ospf-agnostic-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 16 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 15 has weird spacing: '...ensions for G...' -- The document date (October 15, 2010) is 4229 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) == Missing Reference: 'RFC 3630' is mentioned on line 285, but not defined == Missing Reference: 'RFC 4203' is mentioned on line 288, but not defined == Missing Reference: 'RFC3471' is mentioned on line 182, but not defined == Missing Reference: 'RFC4328' is mentioned on line 182, but not defined == Missing Reference: 'EDITOR NOTE' is mentioned on line 217, but not defined == Unused Reference: 'RFC2370' is defined on line 646, but no explicit reference was found in the text == Unused Reference: 'RFC4201' is defined on line 653, but no explicit reference was found in the text == Unused Reference: 'RFC5339' is defined on line 667, but no explicit reference was found in the text ** Downref: Normative reference to an Experimental RFC: RFC 2154 ** Obsolete normative reference: RFC 2370 (Obsoleted by RFC 5250) ** Downref: Normative reference to an Informational RFC: RFC 5339 Summary: 4 errors (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CCAMP Working Group D. Ceccarelli 3 Internet-Draft D. Caviglia 4 Intended status: Standards Track Ericsson 5 Expires: April 18, 2011 S. Belotti 6 P. Grandi 7 Alcatel-Lucent 8 F. Zhang 9 D. Li 10 Huawei Technologies 11 J. Drake 12 Juniper 13 October 15, 2010 15 Technology Agnostic OSPF Traffic Engineering Extensions for Generalized 16 MPLS (GMPLS) 17 draft-bccdg-ccamp-gmpls-ospf-agnostic-00 19 Abstract 21 This document defines a new approach to Generalized Multiprotocol 22 Label Switching (GMPLS) bandwidth advertisement aiming at providing 23 the Network Elements (NEs) and Path Computation Elements (PCEs) with 24 all the data required for crank-backs minimization and scalability 25 optimization. 27 A new Open Shortest Path First - Traffic Engineering (OSPF-TE) 28 routing protocol sub-tlv is defined for bandwidth advertisement per 29 service type. 31 Status of this Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on April 18, 2011. 48 Copyright Notice 49 Copyright (c) 2010 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 66 2. OSPF Extensions . . . . . . . . . . . . . . . . . . . . . . . 3 67 2.1. Bandwidth Accounting sub-TLV . . . . . . . . . . . . . . . 4 68 3. LSA composition . . . . . . . . . . . . . . . . . . . . . . . 8 69 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 5. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 12 71 6. Compatibility Considerations . . . . . . . . . . . . . . . . . 16 72 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 73 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 74 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 16 75 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 76 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 77 11.1. Normative References . . . . . . . . . . . . . . . . . . . 17 78 11.2. Informative References . . . . . . . . . . . . . . . . . . 17 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 81 1. Introduction 83 An Opaque OSPF (Open Shortest Path First) LSA (Link State 84 Advertisements) carrying application-specific information can be 85 generated and advertised to other nodes following the flooding 86 procedures defined in [RFC5250]. Three types of opaque LSA are 87 defined, i.e. type 9 - link-local flooding scope, type 10 - area- 88 local flooding scope, type 11 - AS flooding scope. 90 Traffic Engineering (TE) LSA using type 10 opaque LSA is defined in 91 [RFC3630] for TE purposes. This type of LSA is composed of a 92 standard LSA header and a payload including one top-level TLV (Type/ 93 Length/Value triplet) and possible several nested sub-TLVs. 94 [RFC3630] defines two top-level TLVs: Router Address TLV and Link 95 TLV; and nine possible sub-TLVs for the Link TLV, used to carry link 96 related TE information. 98 The Link type sub-TLVs are enhanced by [RFC4203] in order to support 99 GMPLS networks and related specific link information. 101 In GMPLS networks each node generates TE LSAs to advertise its TE 102 information and capabilities (link-specific or node-specific), 103 through the network. The TE information carried in the LSAs are 104 collected by the other nodes of the network and stored into their 105 local Traffic Engineering Databases (TED). 107 In GMPLS networks, routing serves as the foundation for automatically 108 establishing Label Switched Paths (LSPs) through GMPLS RSVP-TE 109 signaling. 111 This document describes technology agnostic OSPF LSA extensions to 112 support connection oriented tranport networks under the control of 113 GMPLS (e.g. OTN, SDH, MPLS-TP). In particular a new OSPF-TE LSP is 114 defined for bandwidth advertisement per service type tanking into 115 account priorities and technology specific capabilities. 117 1.1. Conventions Used in This Document 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in [RFC2119]. 123 2. OSPF Extensions 125 Each TE LSA can carry a top-level link TLV with several nested sub- 126 TLVs to describe different attributes of a TE link. Two top-level 127 TLVs are defined in [RFC 3630]. (1) The Router Address TLV (referred 128 to as the Node TLV) and (2) the TE link TLV. One or more sub-TLVs 129 can be nested into the two top-level TLVs. The sub-TLV set for the 130 two top-level TLVs are also defined in [RFC 3630] and [RFC 4203]. 132 This document defines a new link sub-TLV, called Bandwidth Accounting 133 (BA) sub-TLV (Sub-tlv value TBA by IANA, suggested 26). 135 One or more component links can be bundled as a TE link. In case of 136 link bundling a single BA sub-TLV will be used to describe several 137 component links. 139 2.1. Bandwidth Accounting sub-TLV 141 The BA sub-TLV has a so generic format that it can be used for the 142 advertisement of any type of transport technology, from SDH/SONET to 143 OTN, from L2SC to PSC etc. The main difference from the ISCD defined 144 in [RFC4202] is the fact that unreserved bandwidth is advertised per 145 service type per priority. The format of the BA sub-TLV is based on 146 "8 bytes" data blocks repeated for each service type/priority/ 147 technology specific capability combination as is illustrated in 148 Figure 1. 150 0 1 2 3 151 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 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 | Switching Cap | Encoding | Reserved | 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 | Service Type | M | T.S. Flags | Reserved |Prior| 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 | Bandwidth | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 | Service Type | M | T.S. Flags | Reserved |Prior| 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | Bandwidth | 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | Service Type | M | T.S. Flags | Reserved |Prior| 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 | Bandwidth | 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 ~ ... ~ 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 | Service Type | M | T.S. Flags | Reserved |Prior| 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 | Bandwidth | 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 Figure 1: Bandwidth Accounting sub-TLV format 176 Where: 178 o Switching Capability (8 bits): the values for this field are 179 defined in [RFC4203] section 1.4. 181 o Encoding (8 bits): the values for this field are defined in 182 [RFC3471] section 3.1.1 and [RFC4328] section 3.1.1 184 - Data Blocks: Data blocks are composed by 64 bits and contain 185 Service Type, M field, Technology Specific Flags, Priority and 186 Bandwidth. For the definition of each field refer below. The number 187 of data blocks depends on the number of service types, priority and 188 technology specific features supported. Blocks declared in the LSA 189 MUST contain a supported service type. Blocks declaring bandwidth at 190 priority Pi, MUST NOT be declared in case priority Pi is not 191 supported by the network element. Data blocks SHOULD be ordered from 192 the highest to the lowest priority. If no priority is supported, 193 just the 0 priority MUST be advertised. Please see the Example 194 section for further details. 196 o Service Type (8 bits): Indicates the type of service supported by 197 TE link (e.g. STMx in an SDH network, ODUx in an OTN network). Each 198 Service Type in a TE-link can be advertised only once for each 199 supported priority. 201 o M field (2 bits): This field defines the meaning of the Bandwidth 202 field. It states that the Bandwidth field is indicating Unreserved 203 Bandwidth, Max LSP Bandwidth or Available Bandwidth. Possible values 204 are: 206 0 - Unreserved bandwidth at priority Pi 208 1 - Max LSP bandwidth at priority Pi 210 For the service types where the advertisement of more than one of the 211 previous values needs to be advertised (e.g. OTN ODUflex, MPLS-TP 212 interface), a data block for each value MUST be advertised. For 213 example, when advertising an ODUflex service type in an OTN network, 214 both Unreserved bandwidth and MAX LSDP bandwidth are advertised as 215 illustrated in Figure 2 (assuming supported priorities: P1 and P5). 217 [EDITOR NOTE]: Under Discussion - M=2 - Available bandwdith at 218 priorioty Pi, Where Available bandwidth is defined as the unused link 219 bandwidth available for additional non-traffic engineered IP/LDP 220 forwarding and can be used as input to a node equal cost multipath 221 load balancing function 222 0 1 2 3 223 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 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | Switching Cap | Encoding | Reserved | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | ODUflex |M=0| T.S. Flags | Reserved | P1 | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | Unreserved Bandwidth @ P1 | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | ODUflex |M=1| T.S. Flags | Reserved | P1 | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | Max LSP Bandwidth @ P1 | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | ODUflex |M=0| T.S. Flags | Reserved | P5 | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | Unreserved Bandwidth @ P1 | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | ODUflex |M=1| T.S. Flags | Reserved | P5 | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | Max LSP Bandwidth @ P1 | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 Figure 2: M field utilization example 246 o Technology Specific Flags (8 bits): These bits are used for the 247 advertisement of technology specific interface capabilities and are 248 defined in companion technology specific IDs. Depending on the 249 technology it could be possible to have different data block 250 advertised for different cabability flags. 252 o Reserved (11 bits): Reserved bits MUST be set to zero. 254 o Priority (3 bits): Indicates the priority related to the advertised 255 service type. Only supported priorities MUST be advertised. 257 o Bandwidth (32 bits): Independently on the type of bandwidth being 258 advertised (see M field), this field is expressed in Bytes/sec in 259 IEEE floating point format unless differently stated in technology 260 specific documents. 262 The maximum bandwidth that an LSP can occupy in a TE link is 263 determined by the component link with the maximum unreserved 264 bandwidth in such TE link. For example, if two OTN OTU3 component 265 links are bundled in a TE link, the unreserved bandwidth of the first 266 component link is 20*1.25 Gbps, and the unreserved bandwidth of the 267 second component link is 24*1.25Gbps, then the unreserved bandwidth 268 of this TE link is 44*1.25Gbps, but the maximum bandwidth an LSP can 269 occupy in this TE link is 24*1,25Gbps, not 44*1,25Gbps. 271 All the reserved fields MUST be set to zero and SHOULD be ignored 272 when received. 274 3. LSA composition 276 Each NE generates an LSA to describe the attributes of each TE link. 277 If we suppose to have unnumbered link IDs, the LSA should carry a 278 link TLV with the following nested minimal sub-TLVs: 280 < Link > ::= < Link Type > < Link ID > < Link 281 Local/Remote Identifiers > < Generalized-ISCD > 283 o Link Type sub-TLV: Defined in [RFC 3630]. 285 o Link ID sub-TLV: Defined in [RFC 3630], for point-to-point link, 286 indicates the remote router ID. 288 o Link Local/Remote Identifiers sub-TLV: Defined in [RFC 4203], 289 indicates the local link ID and the remote link ID. 291 o Bandwidth Accounting sub-TLV: Defined in this document, carries the 292 Bandwidth related information of the advertised TE-link. 294 4. Examples 296 The examples in the following pages are not normative and are not 297 intended to infer or mandate any specific implementation. Moreover 298 they aim at giving a general idea of the utilization of the BA sub- 299 TLV in a technology agnostic scenario. 301 Figure 3 shows the case of a TE-link composed of two component links. 303 +------+ component link 1 +------+ 304 | +------------------+ | 305 | N1 +------------------+ N2 | 306 | | component link 2 | | 307 +------+ +------+ 308 Figure 3: Example 310 The nominal bandwidth of the two component links is 10Gbps and 40Gbps 311 respectively. The former has the capability of carrying service 312 types A and B, while the latter, service types B and C, where A and C 313 are fixed bandwidth service types (just unreserved bandwidth is 314 advertised) and B variable bandwidth service types (unreserved 315 bandwidth and Max LSP bandwidth advertised). The supported 316 priorities are:0 and 3. 318 In this example the two component links are bundled as a TE link but 319 it could also be possible to consider each of them as separate TE 320 links. 322 If the two component links are bundled together, N1 and N2 should 323 assign a link local ID to the TE link and then N1 can get the link 324 remote ID automatically or manually. 326 Just after the creation of the TE Link comprising the two component 327 links, the BA sub-TLV would be advertised as follows: 329 0 1 2 3 330 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 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | Switching Cap | Encoding | Reserved | 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | S.Type(A) |M=0| T.S. Flags | Reserved | P0 | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 | Unreserved Bandwidth = 10 Gbps | 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 | S.Type(A) |M=0| T.S. Flags | Reserved | P3 | 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 | Unreserved Bandwidth = 10 Gbps | 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 | S.Type(B) |M=0| T.S. Flags | Reserved | P0 | 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 | Unreserved Bandwidth = 50 Gbps | 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | S.Type(B) |M=1| T.S. Flags | Reserved | P0 | 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 | Max LSP Bandwidth = 40 Gbps | 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 | S.Type(B) |M=0| T.S. Flags | Reserved | P3 | 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 | Unreserved Bandwidth = 50 Gbps | 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 | S.Type(B) |M=1| T.S. Flags | Reserved | P3 | 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 | Max LSP Bandwidth = 40 Gbps | 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | S.Type(C) |M=0| T.S. Flags | Reserved | P0 | 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | Unreserved Bandwidth = 40 Gbps | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 | S.Type(C) |M=0| T.S. Flags | Reserved | P3 | 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 | Unreserved Bandwidth = 40 Gbps | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 Figure 4: Example - BA sub-TLV(to) 369 Suppose that at time t1 an service type B LSP is created allocating 370 35 Gbps at priority 3. The BA sub-TLV will be modified as follows: 372 0 1 2 3 373 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 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 | Switching Cap | Encoding | Reserved | 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | S.Type(A) |M=0| T.S. Flags | Reserved | P0 | 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 | Unreserved Bandwidth = 10 Gbps | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 | S.Type(A) |M=0| T.S. Flags | Reserved | P3 | 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 | Unreserved Bandwidth = 10 Gbps | 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 | S.Type(B) |M=0| T.S. Flags | Reserved | P0 | 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 | Unreserved Bandwidth = 50 Gbps | 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 | S.Type(B) |M=1| T.S. Flags | Reserved | P0 | 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | Max LSP Bandwidth = 40 Gbps | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | S.Type(B) |M=0| T.S. Flags | Reserved | P3 | 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 | Unreserved Bandwidth = 15 Gbps | 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 | S.Type(B) |M=1| T.S. Flags | Reserved | P3 | 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 | Max LSP Bandwidth = 10 Gbps | 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 | S.Type(C) |M=0| T.S. Flags | Reserved | P0 | 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 | Unreserved Bandwidth = 40 Gbps | 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 | S.Type(C) |M=0| T.S. Flags | Reserved | P3 | 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 | Unreserved Bandwidth = 5 Gbps | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 Figure 5: Example - BA sub-TLV(t1) 412 The last example shows how the prehemption is managed. In 413 particular, if at time t2 a new 15 GBps service type B LSP with 414 priority 0 is created, the LSP with priority 3 is pre-empted and its 415 resources (or part of them) are allocated to the LSP with higher 416 priority. The BA sub-TLV is updated accordingly to Figure 6: 418 0 1 2 3 419 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 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | Switching Cap | Encoding | Reserved | 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 | S.Type(A) |M=0| T.S. Flags | Reserved | P0 | 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 | Unreserved Bandwidth = 10 Gbps | 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 | S.Type(A) |M=0| T.S. Flags | Reserved | P3 | 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 | Unreserved Bandwidth = 10 Gbps | 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 | S.Type(B) |M=0| T.S. Flags | Reserved | P0 | 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 | Unreserved Bandwidth = 35 Gbps | 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 | S.Type(B) |M=1| T.S. Flags | Reserved | P0 | 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 | Max LSP Bandwidth = 25 Gbps | 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 | S.Type(B) |M=0| T.S. Flags | Reserved | P3 | 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 | Unreserved Bandwidth = 35 Gbps | 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 | S.Type(B) |M=1| T.S. Flags | Reserved | P3 | 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 | Max LSP Bandwidth = 25 Gbps | 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 | S.Type(C) |M=0| T.S. Flags | Reserved | P0 | 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 | Unreserved Bandwidth = 15 Gbps | 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 | S.Type(C) |M=0| T.S. Flags | Reserved | P3 | 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 | Unreserved Bandwidth = 15 Gbps | 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 Figure 6: Example - BA sub-TLV (t2) 458 5. Applicability 460 The goal of this section is providing a comparison in term of 461 bandwidth utilization between the BA sub-TLV based advertisement and 462 the [RFC4203] based one. In order to provide a meaningful comparison 463 between the two solutions (i.e. with same type and quantity of 464 information carried) it is necessary to assume [RFC4203] tools 465 properly extended. 467 In other words it is assumed that both unreserved bandwidth and max 468 LSP bandwidth are advertised per signal type. The unreserved 469 bandwidth per signal type could be advertised by means of an 470 unreserved bandwidth sub-tlv per signal type (1 header word + 8 body 471 words) or using the technology specific part of the ISCD (8 words). 472 In this example the utilization of the technology specific part of 473 the ISCD is considered in order to take into account the most 474 optimized option. 476 The following example is based on the advertisement of a simple link 477 supporting six different types of fixed bandwidth service types 478 (A,B,C,D,E,F) and a variable length service type (G). 480 +------+ +------+ 481 | | TE-link | | 482 | N1 +------------------+ N2 | 483 | | | | 484 +------+ +------+ 486 Figure 7: Example 488 Three different cases are analyzed: 490 - 8 priorities supported 492 - 5 priorities supported 494 - 1 priorities supported 496 In the first case, [RFC4203] approach would use 1 ISCD per signal 497 type. The ISCD would need to be extended as follows: 499 0 1 2 3 500 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 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 | Type | Length | 503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 504 | Switching Cap | Encoding | Reserved | 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 | Max LSP Bandwidth at priority 0 | 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 | Max LSP Bandwidth at priority 1 | 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 | Max LSP Bandwidth at priority 2 | 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 | Max LSP Bandwidth at priority 3 | 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 | Max LSP Bandwidth at priority 4 | 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 | Max LSP Bandwidth at priority 5 | 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 | Max LSP Bandwidth at priority 6 | 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 | Max LSP Bandwidth at priority 7 | 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 522 | Technology Specific Part | | 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | S 524 | Technology Specific Part | | W 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | I 526 | Unreserved Bandwidth at priority 0 | | T 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | C 528 | Unreserved Bandwidth at priority 1 | | H. 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 530 | Unreserved Bandwidth at priority 2 | | C 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | A 532 | Unreserved Bandwidth at priority 3 | | P. 533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 534 | Unreserved Bandwidth at priority 4 | | S 535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | P 536 | Unreserved Bandwidth at priority 5 | | E 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | C. 538 | Unreserved Bandwidth at priority 6 | | 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | I 540 | Unreserved Bandwidth at priority 7 | | N 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + F. 543 Figure 8: Example 545 The amount of words used per ISCD is 20 for a total amount of 140 546 words. On the other side, using the BA sub-TLV these words would be 547 used: 549 - 1 word for type/length declaration 551 - 1 word for sub-tlv header 553 - 2 words per (fixed) service type per priority = 2*6*8 = 96 555 - 4 words per (variable) service type per priority = 4*1*8 = 32 557 Total words used with 8 priorities: 140 (RFC4203) vs 130 (BA sub- 558 TLV). 560 Performing the same computation in a scenario where 5 priorities are 561 supported, the number of words used in the [RFC4203] approach would 562 be the same (140), while in the BA sub-TLV would be: 564 - 1 word for type/length declaration 566 - 1 word for sub-tlv header 568 - 2 words per (fixed) service type per priority = 2*6*5 = 60 570 - 4 words per (variable) service type per priority = 4*1*5 = 20 572 Total words used with 5 priorities: 140 (RFC4203) vs 82 (BA sub-TLV). 574 The difference is significantly higher as the number of supported 575 priorities decreases. Considering the case of single priority, the 576 number of words used by the BA sub-TLV approach would be: 578 - 1 word for type/length declaration 580 - 1 word for sub-tlv header 582 - 2 words per (fixed) service type per priority = 2*6*1 = 12 584 - 4 words per (variable) service type per priority = 4*1*1 = 4 586 Total words used with 1 priority: 140 (RFC4203) vs 18 (BA sub-TLV). 588 It is worth considering that using the Unreserved bandwdith sub-TLV 589 for unreserved bandwidth advertisement would increase the difference 590 between the two solutions due to the fact that a higher number of 591 headers is needed and at least a new word per sub-TLV would be 592 required for the identification of the service type. 594 6. Compatibility Considerations 596 Backward compatibility issues are addressed in technology specific 597 documents. 599 7. Security Considerations 601 This document specifies the contents of Opaque LSAs in OSPFv2. As 602 Opaque LSAs are not used for SPF computation or normal routing, the 603 extensions specified here have no direct effect on IP routing. 604 Tampering with GMPLS TE LSAs may have an effect on the underlying 605 transport (optical and/or SONET-SDH) network. [RFC3630] suggests 606 mechanisms such as [RFC2154] to protect the transmission of this 607 information, and those or other mechanisms should be used to secure 608 and/or authenticate the information carried in the Opaque LSAs. 610 8. IANA Considerations 612 TBD 614 9. Contributors 616 Francesco Fondelli, Ericsson 618 Email: francesco.fondelli@ericsson.com 620 Eve Varma, Alcatel-Lucent 622 EMail: eve.varma@alcatel-lucent.com 624 Jonathan Sadler, Tellabs 626 EMail: Jonathan.Sadler@tellabs.com 628 Lyndon Ong, Ciena 630 EMail: Lyong@Ciena.com 632 10. Acknowledgements 634 TBD 636 11. References 638 11.1. Normative References 640 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 641 Requirement Levels", BCP 14, RFC 2119, March 1997. 643 [RFC2154] Murphy, S., Badger, M., and B. Wellington, "OSPF with 644 Digital Signatures", RFC 2154, June 1997. 646 [RFC2370] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, 647 July 1998. 649 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 650 (TE) Extensions to OSPF Version 2", RFC 3630, 651 September 2003. 653 [RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling 654 in MPLS Traffic Engineering (TE)", RFC 4201, October 2005. 656 [RFC4202] Kompella, K. and Y. Rekhter, "Routing Extensions in 657 Support of Generalized Multi-Protocol Label Switching 658 (GMPLS)", RFC 4202, October 2005. 660 [RFC4203] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support 661 of Generalized Multi-Protocol Label Switching (GMPLS)", 662 RFC 4203, October 2005. 664 [RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The 665 OSPF Opaque LSA Option", RFC 5250, July 2008. 667 [RFC5339] Le Roux, JL. and D. Papadimitriou, "Evaluation of Existing 668 GMPLS Protocols against Multi-Layer and Multi-Region 669 Networks (MLN/MRN)", RFC 5339, September 2008. 671 11.2. Informative References 672 Authors' Addresses 674 Daniele Ceccarelli 675 Ericsson 676 Via A. Negrone 1/A 677 Genova - Sestri Ponente 678 Italy 680 Email: daniele.ceccarelli@ericsson.com 682 Diego Caviglia 683 Ericsson 684 Via A. Negrone 1/A 685 Genova - Sestri Ponente 686 Italy 688 Email: diego.caviglia@ericsson.com 690 Sergio Belotti 691 Alcatel-Lucent 692 Via Trento, 30 693 Vimercate 694 Italy 696 Email: sergio.belotti@alcatel-lucent.com 698 Pietro Vittorio Grandi 699 Alcatel-Lucent 700 Via Trento, 30 701 Vimercate 702 Italy 704 Email: pietro_vittorio.grandi@alcatel-lucent.com 706 Fatai Zhang 707 Huawei Technologies 708 F3-5-B R&D Center, Huawei Base 709 Shenzhen 518129 P.R.China Bantian, Longgang District 710 Phone: +86-755-28972912 712 Email: zhangfatai@huawei.com 713 Dan Li 714 Huawei Technologies 715 F3-5-B R&D Center, Huawei Base 716 Shenzhen 518129 P.R.China Bantian, Longgang District 717 Phone: +86-755-28973237 719 Email: danli@huawei.com 721 John E Drake 722 Juniper 724 Email: jdrake@juniper.net