idnits 2.17.1 draft-chen-ospf-tts-02.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 20, 2017) is 2471 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: 'T0' is mentioned on line 183, but not defined == Missing Reference: 'B0' is mentioned on line 206, but not defined == Missing Reference: 'T1' is mentioned on line 152, but not defined == Missing Reference: 'B1' is mentioned on line 206, but not defined == Missing Reference: 'T2' is mentioned on line 184, but not defined == Missing Reference: 'B2' is mentioned on line 206, but not defined == Missing Reference: 'T3' is mentioned on line 184, but not defined == Missing Reference: 'B3' is mentioned on line 196, but not defined == Missing Reference: 'P0' is mentioned on line 206, but not defined == Missing Reference: 'P1' is mentioned on line 206, but not defined == Missing Reference: 'P2' is mentioned on line 206, but not defined == Missing Reference: 'P3' is mentioned on line 196, but not defined -- Looks like a reference, but probably isn't: '8' on line 392 == Unused Reference: 'RFC2119' is defined on line 413, but no explicit reference was found in the text == Unused Reference: 'RFC2328' is defined on line 418, but no explicit reference was found in the text == Unused Reference: 'RFC5250' is defined on line 422, but no explicit reference was found in the text == Unused Reference: 'RFC3630' is defined on line 426, but no explicit reference was found in the text == Unused Reference: 'RFC3209' is defined on line 433, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 18 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force H. Chen 3 Internet-Draft Huawei Technologies 4 Intended status: Standards Track M. Toy 5 Expires: January 21, 2018 Verizon 6 V. Liu 7 China Mobile 8 L. Liu 9 Fijitsu 10 July 20, 2017 12 Extensions to OSPF for Temporal LSP 13 draft-chen-ospf-tts-02.txt 15 Abstract 17 This document specifies extensions to OSPF for distributing Traffic 18 Engineering (TE) information on a link in a sequence of time 19 intervals. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on January 21, 2018. 38 Copyright Notice 40 Copyright (c) 2017 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Conventions Used in This Document . . . . . . . . . . . . . . 3 58 4. Representation of TE Information . . . . . . . . . . . . . . . 4 59 4.1. TE Information in Absolute Time . . . . . . . . . . . . . 4 60 4.2. TE Information in Relative Time . . . . . . . . . . . . . 5 61 5. Extensions to OSPF . . . . . . . . . . . . . . . . . . . . . . 6 62 5.1. TE LSA . . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 5.2. TTS Link TLV . . . . . . . . . . . . . . . . . . . . . . . 7 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 65 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 66 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 10 67 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 68 9.1. Normative References . . . . . . . . . . . . . . . . . . . 10 69 9.2. Informative References . . . . . . . . . . . . . . . . . . 10 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 72 1. Introduction 74 Once an existing multiprotocol label switching (MPLS) traffic 75 engineering (TE) label switched path (LSP) is set up, it is assumed 76 to carry traffic forever until it is down. When an MPLS TE LSP 77 tunnel is up, it is assumed that the LSP consumes its reserved 78 network resources forever even though the LSP may only use network 79 resources during some period of time. As a result, the network 80 resources are not used efficiently. Moreover, a tunnel service can 81 not be reserved or booked in advance for a period of time. 83 This document specifies extensions to OSPF for supporting the setup 84 of an MPLS TE LSP in a period of time called a time interval or a 85 sequence of time intervals. It is assumed that the LSP carries 86 traffic during this time interval or each of these time intervals. 87 Thus the network resources are efficiently used. More importantly, 88 some new services can be provided. For example, a consumer can book 89 a tunnel service in advance for a time interval or a sequence of time 90 intervals. Tunnel services may be scheduled. 92 2. Terminology 94 A Time Interval: a time period from time Ta to time Tb. 96 LSP: Label Switched Path. An LSP is a P2P (point-to-point) LSP or a 97 P2MP (point-to-multipoiint) LSP. 99 LSP in a time interval: LSP that carries traffic in the time 100 interval. 102 LSP in a sequence of time intervals: LSP that carries traffic in each 103 of the time intervals. 105 Temporal LSP: LSP in a time interval or LSP in a sequence of time 106 intervals. 108 TEDB: Traffic Engineering Database. 110 This document uses terminologies defined in RFC2328 and RFC3630. 112 3. Conventions Used in This Document 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in RFC2119. 118 4. Representation of TE Information 120 The existing Open Shortest Path First (OSPF) Traffic Engineering (TE) 121 distributes an unreserved bandwidth Bi at each of eight priority 122 levels for a link at one point of time, for example, at the current 123 time. 125 Bandwidth 126 ^ 127 | 128 Bi|______________________________________________________ 129 | 130 | 131 -+------------------------------------------------------> Time 132 | 134 This means that the link has bandwidth Bi at a priority level from 135 now to forever until there is a change to it. This TE information on 136 the link is stored in TEDB. 138 Thus, a temporal LSP (i.e., an LSP in a time interval) cannot be set 139 up using the information in the TEDB and the bandwidth cannot be 140 reserved in advance for the LSP in the time interval. 142 To support temporal LSPs, we should extend OSPF to distribute TE 143 information on a link in a series of time intervals. 145 4.1. TE Information in Absolute Time 147 Suppose that the amount of the unreserved bandwidth at a priority 148 level on a link is Bj in a time interval from time Tj to Tk (k = 149 j+1), where j = 0, 1, 2, .... The unreserved bandwidth on the link 150 can be represented as 152 [T0, B0], [T1, B1], [T2, B2], [T3, B3], .... 154 This is an absolute time representation of bandwidths on a link. 155 Time Tj (j = 0, 1, 2, ...) MUST be a synchronized time among all 156 network nodes. 158 Bandwidth 159 ^ 160 | B3 161 | B1 ___________ 162 | __________ 163 |B0 B4 164 |__________ B2 _________ 165 | ________________ 166 | 167 -+-------------------------------------------------------> Time 168 |T0 T1 T2 T3 T4 170 If an LSP is deleted or down at time T and uses bandwidth B, then for 171 every time interval/period (after time T) during which bandwidth B is 172 reserved for the LSP on a link attached to a network node, the 173 network node adds B to the link for that interval/period. 175 If an LSP is set up at time T and uses bandwidth B, then for every 176 time interval/period (after time T) during which bandwidth B is 177 reserved for the LSP on a link attached to a network node, the 178 network node subtracts bandwidth B from the link for that interval/ 179 period. 181 If there are significant changes to the bandwidths on a link attached 182 to a network node, the network node distributes the bandwidths on the 183 link to other network nodes. That is that a updated [T0, B0], [T1, 184 B1], [T2, B2], [T3, B3], etc., are distributed to other network nodes 185 in the network. Each of the other network nodes can construct or 186 determine the bandwidth for a series of time intervals/periods on a 187 link after receiving the information. 189 4.2. TE Information in Relative Time 191 Alternatively, a relative time representation of bandwidths on a link 192 can be used. For example, the amount of the unreserved bandwidth at 193 a priority level on a link is Bj during a series of time intervals/ 194 periods can be expressed as 196 [P0, B0], [P1, B1], [P2, B2], [P3, B3], ..., where 197 Pj = Tk - Tj, k = (j+1) and j = 0, 1, 2, 3, .... 199 In this representation, every time Tj (j = 0, 1, 2, ...) can be a 200 local time. A timer may expire after every unit of time (e.g., every 201 second) and trigger --P0, which decrements P0. When P0 = 0, P1 202 becomes P0, P2 becomes p1, and so on. 204 If there are significant changes to the bandwidths on a link attached 205 to a node, the node distributes the bandwidths on the link to other 206 nodes. That is that a updated [P0, B0], [P1, B1], [P2, B2], [P3, 207 B3], ..., are distributed to other network nodes in the network. On 208 each of the other network nodes, a timer may expire for every unit of 209 time (e.g., every second) and trigger --P0, which decrements P0. 210 When P0 = 0, P1 becomes P0, P2 becomes p1, and so on. 212 An advantage of using relative time representation is that the times 213 or clocks on all the network nodes can be different. 215 5. Extensions to OSPF 217 This section describes the extensions to OSPF for supporting the 218 setup of temporal LSPs. 220 5.1. TE LSA 222 An opaque LSA of type 10 is originated by a network node to 223 distribute TE information such as the bandwidth of a link that is 224 attached to the network node. 226 0 1 2 3 227 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 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | LS age | Options | LS Type=10 | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | 1 | Opaque ID | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | Advertising Router | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | LS sequence number | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | LS checksum | length | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | | 240 ~ TLVs ~ 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 The opaque LSA comprises a link-state (LS) age field, an options 244 field, an LS type field, an opaque identifier (ID) field, an 245 advertising router field, an LS sequence number field, an LS checksum 246 field, a length field, and one or more TLVs. 248 The LS age field indicates the time since the LSA was originated in 249 seconds. The options field indicates the optional capabilities 250 supported by the described portion of the routing domain. The LS 251 type field indicates the type of the LSA. The opaque ID field is a 252 number used to maintain multiple opaque LSAs. The advertising router 253 field indicates the Router ID of the router that originated the LSA. 254 The LS sequence number field is used to detect old or duplicate LSAs. 255 Successive instances of an LSA are given successive LS sequence 256 numbers. The LS checksum field indicates the Fletcher checksum of 257 the complete contents of the LSA, including the LSA header but 258 excluding the LS age field. The length field indicates the length of 259 the LSA in bytes. 261 5.2. TTS Link TLV 263 In addition to existing router address TLV and link TLV, TLVs fields 264 may comprise a new temporal tunnel service (TTS) link TLV. 266 0 1 2 3 267 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 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | Type (5) | Length (variable) | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | Reserved (0) | Segment-Number | 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | sub TLVs | 274 ~ ~ 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 The TTS link TLV comprises a type field, a length field, a reserved 278 field, a segment-number field, and a sub TLVs field. 280 The type field may comprise a value assigned by the Internet Assigned 281 Number Authority (IANA) to indicate that the TLV is a TTS link TLV. 282 For example, the type field may comprise a value of 5. The length 283 field may indicate the length of the values in the TTS link TLV in 284 bytes. 286 The segment-number indicates a segment of the TTS link TLV. The 287 information on a link may be too big to fit into one TTS link TLV. 288 In this case, the information may be split into a few of segments, 289 each of which is put into a TTS link TLV and identified by a segment 290 number. 292 The sub TLV field comprises a link type sub-TLV and a link ID sub- 293 TLV. It may further comprise a local address sub-TLV, a remote 294 address sub-TLV, a TE metric sub-TLV, a maximum bandwidth sub-TLV, a 295 maximum reservable bandwidth sub-TLV, an unreserved bandwidth sub- 296 TLV, an administrator group sub-TLV, a relative TTS unreserved 297 bandwidth sub-TLV, an absolute TTS unreserved bandwidth sub-TLV, and 298 any other suitable sub-TLVs. 300 The format of an absolute TTS unreserved bandwidth sub-TLV is shown 301 below. 303 0 1 2 3 304 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 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | Type (21) | Length (36+36*n) | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | T0 | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 | B0[8] | 311 ~ ~ 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | T1 | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | B1[8] | 316 ~ ~ 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | | 319 ~ ~ 320 | | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | Tn | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | Bn[8] | 325 ~ ~ 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 It comprises a type field, a length field, absolute time fields, and 329 unreserved bandwidth fields. 331 The type field may comprise a value assigned by the IANA to indicate 332 that the sub-TLV is an absolute TTS unreserved bandwidth sub-TLV. 333 For example, the type field may comprise a value of 21. 335 The length field may indicate the length of the values in the 336 absolute TTS unreserved bandwidth sub-TLV in bytes. 338 The absolute time fields and the unreserved bandwidth fields may be 339 in pairs such as 341 [ T0, B0[8] ], [ T1, B1[8] ], ..., [ Tn, Bn[8] ], 343 where T0, T1, ..., Tn are the times synchronized among all the nodes 344 and Bj[8] (j=0, 1,..., n) are the amount of unreserved bandwidth at 345 eight priority levels in the time interval/period from Tj to Tk 346 (k=j+1). 348 The format of a relative TTS unreserved bandwidth sub-TLV is 349 illustrated as follows. 351 0 1 2 3 352 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 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 | Type (22) | Length (36+36*n) | 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 | P0 | 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | B0[8] | 359 ~ ~ 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 | P1 | 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 | B1[8] | 364 ~ ~ 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | | 367 ~ ~ 368 | | 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | Pn | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 | Bn[8] | 373 ~ ~ 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 It comprises a type field, a length field, relative time fields, and 377 unreserved bandwidth fields. 379 The type field may comprise a value assigned by the IANA to indicate 380 that the sub-TLV is a relative TTS unreserved bandwidth sub-TLV. For 381 example, the type field may comprise a value of 22. 383 The length field may indicate the length of the values in the 384 relative TTS unreserved bandwidth sub-TLV in bytes. 386 The relative time fields and the unreserved bandwidth fields may be 387 in pairs such as 389 [ P0, B0[8] ], [ P1, B1[8] ], ... , [ Pn, Bn[8] ], 391 where Pj (j=0, 1,..., n) is the time period during which the 392 unreserved bandwidth is Bj[8], containing the amount of unreserved 393 bandwidth at eight priority levels. 395 6. Security Considerations 397 The mechanism described in this document does not raise any new 398 security issues for the OSPF protocols. 400 7. IANA Considerations 402 This section specifies requests for IANA allocation. 404 8. Acknowledgement 406 The author would like to thank people for their valuable comments on 407 this draft. 409 9. References 411 9.1. Normative References 413 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 414 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 415 RFC2119, March 1997, 416 . 418 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, DOI 10.17487/ 419 RFC2328, April 1998, 420 . 422 [RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The 423 OSPF Opaque LSA Option", RFC 5250, DOI 10.17487/RFC5250, 424 July 2008, . 426 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 427 (TE) Extensions to OSPF Version 2", RFC 3630, 428 DOI 10.17487/RFC3630, September 2003, 429 . 431 9.2. Informative References 433 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 434 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 435 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 436 . 438 Authors' Addresses 440 Huaimo Chen 441 Huawei Technologies 442 Boston, MA 443 US 445 Email: huaimo.chen@huawei.com 447 Mehmet Toy 448 Verizon 449 USA 451 Email: mehmet.toy@verizon.com 453 Vic Liu 454 China Mobile 455 No.32 Xuanwumen West Street, Xicheng District 456 Beijing, 100053 457 China 459 Email: liu.cmri@gmail.com 461 Lei Liu 462 Fijitsu 463 USA 465 Email: lliu@us.fujitsu.com