idnits 2.17.1 draft-ceccarelli-ccamp-gmpls-ospf-g709-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 is 1 instance of too long lines in the document, the longest one being 7 characters in excess of 72. ** There are 4 instances of lines with control characters in the document. ** The abstract seems to contain references ([G709-V3], [Gsup43]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (March 8, 2010) is 5153 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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: 'G709-V3' is mentioned on line 291, but not defined == Missing Reference: 'WSON-Frame' is mentioned on line 129, but not defined -- Looks like a reference, but probably isn't: '2009' on line 133 == Missing Reference: 'G709' is mentioned on line 176, but not defined == Missing Reference: 'WSON-OSPF' is mentioned on line 250, but not defined == Missing Reference: 'RFC 3630' is mentioned on line 517, but not defined == Missing Reference: 'RFC 4203' is mentioned on line 520, but not defined == Unused Reference: 'RFC2119' is defined on line 702, but no explicit reference was found in the text == Unused Reference: 'RFC2370' is defined on line 708, but no explicit reference was found in the text == Unused Reference: 'RFC4201' is defined on line 715, but no explicit reference was found in the text == Unused Reference: 'G.709' is defined on line 727, but no explicit reference was found in the text == Unused Reference: 'G.709-v3' is defined on line 731, 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) Summary: 6 errors (**), 0 flaws (~~), 13 warnings (==), 3 comments (--). 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: September 9, 2010 F. Zhang 6 D. Li 7 Huawei Technologies 8 Y. Xu 9 CATR 10 March 8, 2010 12 Traffic Engineering Extensions to OSPF for Generalized MPLS (GMPLS) 13 Control of Evolutive G.709 OTN Networks 14 draft-ceccarelli-ccamp-gmpls-ospf-g709-01 16 Abstract 18 Recent revisions of ITU-T Recommendation G.709 have introduced new 19 features for OTNs:ODU0, ODU4, ODU2e, ODU3e1, ODU3e2 and ODUflex. The 20 new features for the evolutive OTNs are described in separate ITU-T 21 documents. ODU0, ODU2e and ODU4 ODUflex are described in [G709-V3]. 22 ODU3e1 and ODU3e2 are described in [Gsup43]. This document describes 23 OSPF routing protocol extensions to support the evolutive Optical 24 Transport Networks (OTN) under the control of Generalized MPLS 25 (GMPLS). 27 Status of this Memo 29 This Internet-Draft is submitted to IETF in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF), its areas, and its working groups. Note that 34 other groups may also distribute working documents as Internet- 35 Drafts. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/ietf/1id-abstracts.txt. 45 The list of Internet-Draft Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html. 48 This Internet-Draft will expire on September 9, 2010. 50 Copyright Notice 52 Copyright (c) 2010 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. OSPF Requirements . . . . . . . . . . . . . . . . . . . . . . 3 69 3. Overview of the Evolutive G.709 . . . . . . . . . . . . . . . 4 70 4. G.709 Digital Layer TE Information . . . . . . . . . . . . . . 6 71 4.1. Tributary Slot type . . . . . . . . . . . . . . . . . . . 6 72 4.2. TE link type . . . . . . . . . . . . . . . . . . . . . . . 7 73 4.3. LO ODU signal type . . . . . . . . . . . . . . . . . . . . 7 74 4.4. TE link Unreserved Bandwidth . . . . . . . . . . . . . . . 8 75 4.5. Maximum LSP Bandwidth . . . . . . . . . . . . . . . . . . 8 76 5. OSPF Extensions . . . . . . . . . . . . . . . . . . . . . . . 8 77 5.1. OTN Interface Switching Capability Descriptor . . . . . . 9 78 6. Compatibility Considerations . . . . . . . . . . . . . . . . . 11 79 7. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 80 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 81 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 82 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 16 83 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 84 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 85 12.1. Normative References . . . . . . . . . . . . . . . . . . . 18 86 12.2. Informative References . . . . . . . . . . . . . . . . . . 18 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 89 1. Introduction 91 An Opaque OSPF (Open Shortest Path First) LSA (Link State 92 Advertisements) carrying application-specific information can be 93 generated and advertised to other nodes following the flooding 94 procedures defined in [RFC5250]. Three types of opaque LSA are 95 defined, i.e. type 9 - link-local flooding scope, type 10 - area- 96 local flooding scope, type 11 - AS flooding scope. 98 Traffic Engineering (TE) LSA using type 10 opaque LSA is defined in 99 [RFC3630] for TE purpose. This type of LSA is composed of a standard 100 LSA header and a payload including one top-level TLV (Type/Length/ 101 Value triplet) and possible several nested sub-TLVs. [RFC3630] 102 defines two top-level TLVs: Router Address TLV and Link TLV; and nine 103 possible sub-TLVs for the Link TLV, used to carry link related TE 104 information. 106 The Link type sub-TLVs are enhanced by [RFC4203] in order to support 107 GMPLS networks and related specific link information. 109 In GMPLS networks each node generates TE LSAs to advertise its TE 110 information and capabilities (link-specific or node-specific), 111 through the network. The TE information carried in the LSAs are 112 collected by the other nodes of the network and stored into their 113 local Traffic Engineering Databases (TED). 115 In the GMPLS based G.709 Optical Transport Networks (OTNs), in order 116 to automatically establish ODUk connections through GMPLS RSVP-TE 117 signaling, routing is the foundation. 119 OTN networks provide flexible and various multiplexing relationships 120 (e.g., ODUj multiplexed into ODUk (j j) signal can be depicted as follows: 213 - ODU0 into ODU1 multiplexing (with 1,25Gbps TS granularity) 215 - ODU0, ODU1, ODUflex into ODU2 multiplexing (with 1.25Gbps TS 216 granularity) 218 - ODU1 into ODU2 multiplexing (with 2.5Gbps TS granularity) 220 - ODU0, ODU1, ODU2, ODU2e and ODUflex into ODU3 multiplexing (with 221 1.25Gbps TS granularity) 223 - ODU1, ODU2 into ODU3 multiplexing (with 2.5Gbps TS granularity) 225 - ODU0, ODU1, ODU2, ODU2e, ODU3 and ODUflex into ODU4 multiplexing 226 (with 1.25Gbps TS granularity) 228 - ODU2e into ODU3e1 multiplexing (with 2.5Gbps TS granularity) 230 - ODU2e into ODU3e2 multiplexing (with 1.25Gbps TS granularity) 231 In order to be backward compatible with the 2.5Gbps TS defined in 232 [G709-V3], both the 2.5Gbps TS and the 1.25Gbps TS can be used in the 233 two cases listed below: 235 o ODU1 into ODU2 multiplexing 237 o ODU1 and ODU2 into ODU3 multiplexing 239 From the link perspective, it can only work under one TS type. For 240 example, if the both ends (or interfaces) of the link can support 241 2.5Gbps TS and 1.25Gbps TS, then it can work under 2.5Gbps TS or 242 1.25Gbps TS. If one end can support 1.25Gbps TS, and another end can 243 support 2.5Gbps TS, the end with 1.25Gbps TS MUST adopt a 2.5Gbps 244 TS). 246 4. G.709 Digital Layer TE Information 248 This document only considers the TE information needed for LO ODU 249 path computation. WSON TE information is out of scope. Please refer 250 to [WSON-OSPF] for more information about WSON routing information. 252 From the perspective of [G709-V3], there are two different cases for 253 LO ODU: 255 (1) A LO ODUk mapped into an OTUk. In this case, the server layer of 256 this LO ODU is an OTUk. For example, if a STM-16 signal is 257 encapsulated into an ODU1 and then mapped into OTU1, the ODU1 is a LO 258 ODU. 260 (2) A LO ODUj multiplexed into a HO (Higher Order) ODUk (j < k) 261 occupying several TSs. In this case, the server layer of this LO ODU 262 is a HO ODUk. For example, if an ODU1 is multiplexed into ODU2 and 263 then mapped into an OTU2, the ODU1 is a LO ODU and the ODU2 is a HO 264 ODU. 266 In order to compute a suitable path the PCE (centralized or 267 distributed) needs a set of data that should be advertised by the 268 routing protocol. In the following sections each type of data is 269 listed and analyzed, while the possible values are shown in section 270 5. 272 4.1. Tributary Slot type 274 ITU-T recommendations define two types of TS but, from the link 275 perspective, it can only work under one of them. For example, if the 276 both ends (or interfaces) of a link can support 2.5Gbps TS or 277 1.25Gbps TS, then the link will work under 2.5Gbps TS or 1.25Gbps TS. 279 If one end can support the 1.25Gbps TS, and another end the 2.5Gbps 280 TS, the former end SHOULD adopt the 2.5Gbps TS. 282 In addition, the bandwidth accounting depends on the type of TS. 283 Therefore, the type of the TS should be known during LO ODU path 284 computation. 286 4.2. TE link type 288 The link type indicates the OTUk/HO ODUk type of the TE link. 290 The TS bandwidth of different types of OTUk is different; it 291 increases along with the increasing of k (see [G709-V3]). The 292 bandwidth of a TS in a TE link can be deduced from the TS type and 293 link type of the TE link. For example, the bandwidth of a 1.25G TS 294 without NJO (Negative Justification Opportunity) in an OTU2 is about 295 1.249409620 Gbps, while the bandwidth of a 1.25G TS without NJO in an 296 OTU3 is about 1.254703729 Gbps. 298 The actual TS bandwidth of a TE link is useful to determine the 299 number of TSs needed by an ODUflex service. And the actual TS 300 bandwidth of a TE link can be deduced by the TE link type and TS 301 type. 303 4.3. LO ODU signal type 305 It is possible that some equipments can not support all the LO ODU 306 signal types. When a path computation procedure for a LO ODU is 307 performed, it needs to check whether a link has the capability to 308 carry a specific type of LO ODU or not. If a link can not carry this 309 type of LO ODU, it should be excluded during the path computation. 310 Only the links with the capability of carrying this type of LO ODU 311 can be the candidates. 313 For example, in the following figure, the interfaces IF1, IF2, IF8, 314 IF7, IF5 and IF6 can support ODUflex signals, while the interfaces 315 IF3 and IF4 cannot. In this case, if one ODUflex connection from A 316 to C is requested, link #1 and #2 are excluded and link #3 and link 317 #4 are the candidates (the possible path could be A-D-C through link 318 #3 and link #4). 320 +-----+ 321 link #3 | | link #4 322 +-----------------+ D +-----------------+ 323 | IF8| |IF7 | 324 | +-----+ | 325 | | 326 |IF1 IF6| 327 +--+--+ +-----+ +--+--+ 328 | | link #1 | | link #2 | | 329 | A +--------------+ B +--------------+ C | 330 | |IF2 IF3| |IF4 IF5| | 331 +-----+ +-----+ +-----+ 333 Figure 1: LO ODU signal type 335 Therefore, it is necessary to advertise the LO ODU types that the OTU 336 or HO ODU TE link can support. 338 4.4. TE link Unreserved Bandwidth 340 In the GMPLS based OTN networks, the Unreserved Bandwidth of a TE 341 link is the sum of the unreserved bandwidths of all the component 342 links associated with the bundled link. 344 The unreserved bandwidth can be accounted through the unallocated 345 Tributary Slots of the TE link. 347 4.5. Maximum LSP Bandwidth 349 The Maximum Bandwidth that an LSP can occupy in a TE link is 350 determined by the component link with the maximum unreserved 351 bandwidth in such TE link. 353 For example, if two OTU3 component links are bundled to a TE link, 354 the unreserved bandwidth of the first component link is 20*1.25G TSs, 355 and the unreserved bandwidth of the second component link is 24*1.25G 356 TSs. Then the unreserved bandwidth of this TE link is 44*1.25G TSs, 357 but the maximum TSs that a LSP can occupy in this TE link is 24, not 358 44. 360 5. OSPF Extensions 362 In terms of GMPLS based OTN networks, each OTUk/HO ODUk can be viewed 363 as a component link, and each component link can carry one or more 364 types of LO ODU. 366 Each TE LSA can carry a top-level TLV with several nested sub-TLVs to 367 describe different attributes of a TE link. Two top-level TLVs are 368 defined in [RFC 3630]. (1) The Router Address TLV (referred to as the 369 Node TLV) and (2) the TE link TLV. One or more sub-TLVs can be 370 nested into the two top-level TLVs. The sub-TLV set for the two top- 371 level TLVs are also defined in [RFC 3630] and [RFC 4203]. 373 A general Interface Switching Capability Descriptor (ISCD) sub-TLV is 374 defined In [RFC 4203]. The bandwidth accounting is encoded in a 4 375 octets field in the IEEE floating point format. Max LSP Bandwidth is 376 accounted at each priority X (0~7). 378 This document defines a new sub-TLV of the Link TLV, called OTN 379 Interface Switching Capability Descriptor (OTN-ISCD) with value TBD 380 by IANA. The OTN-ISCD format is described in Section 5.1. 382 One or more component links can be bundled as a TE link. In case of 383 link bundling an OTN-ISCD will be used for each component link. 385 5.1. OTN Interface Switching Capability Descriptor 387 The format of the new OTN-Interface Switching Capability Descriptor 388 is defined in Figure 2. 390 0 1 2 3 391 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 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | Type | Length | 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 |Res| T |OD(T)Uk| Reserved | Signal Flags |G|F|E|D|C|B|A| 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 | Max lsp TS at P0 | Unreserved TS at p0 | 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 | Max lsp TS at P1 | Unreserved TS at p1 | 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 | Max lsp TS at P2 | Unreserved TS at p2 | 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 | Max lsp TS at P3 | Unreserved TS at p3 | 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 | Max lsp TS at P4 | Unreserved TS at p4 | 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 | Max lsp TS at P5 | Unreserved TS at p5 | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 | Max lsp TS at P6 | Unreserved TS at p6 | 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | Max lsp TS at P7 | Unreserved TS at p7 | 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 Figure 2: OTN-Interface Switching Capability Descriptor 416 Where: 418 o T (2 bits): Indicates the type of the Tributary Slot of this TE 419 link, value 0 means the TS type is 1.25Gbps, value 1 means the TS 420 type is 2.5Gbps. 422 o OD(T)Uk (4 bits): Indicates the type of the TE link, i.e. the 423 server layer signal that the LO ODUs can be mapped or multiplexed 424 into. The following values are defined: 426 0: Reserved (for future use) 428 1: OTU1/HO ODU1 430 2: OTU2/HO ODU2 432 3: OTU3/HO ODU3 434 4: OTU4/HO ODU4 435 5: OTU2e/HO ODU2e 437 6-15: Reserved (for future use) 439 The bandwidth of a TS in this TE link can be deduced from T bit and 440 OD(T)Uk field. 442 o Signal Flags (16 bits): This field indicates the LO ODU type 443 supported by the TE link. A flag set to 1 indicates that the TE link 444 supports the corresponding LO ODU signal. Currently the following 445 flags are defined: 447 Flag A: indicates whether LO ODU0 is supported. 449 Flag B: indicates whether LO ODU1 is supported. 451 Flag C: indicates whether LO ODU2 is supported. 453 Flag D: indicates whether LO ODU3 is supported. 455 Flag E: indicates whether LO ODU4 is supported. 457 Flag F: indicates whether LO ODU2e is supported. 459 Flag G: indicates whether LO ODUflex is supported. 461 Other bits are reserved and must be set to zero when sent and should 462 be ignored when received. 464 o Max lsp TS at Pi (16 bits): Indicates the maximum number of 465 unreserved TS at priority Pi of all of the component links of the TE 466 link. 468 o Unreserved TS at Pi (12 bits): Indicates the number of unreserved 469 TSs at priority Pi inside all the component links of the TE link. 471 All the reserved fields must be set to zero and should be ignored 472 when received. 474 6. Compatibility Considerations 476 The legacy nodes that do not implement the extensions defined in this 477 document are able to ignore the LSA containing an OTN-ISCD sub-TLV. 478 They will continue to flood the LSA to other neighbors, but will not 479 use the information carried in this LSA. 481 7. Example 483 Based on the sub-TLVs defined in [RFC 3630], [RFC 4203] and this 484 document, a G.709 digital TE link can be described as follows. 486 +------+ component link 1 +------+ 487 | +------------------+ | 488 | N1 +------------------+ N2 | 489 | | component link 2 | | 490 +--+---+ +---+--+ 492 Figure 3: Example 494 This picture shows a simple example of an OTN network. The link type 495 of the two component links are OTU2 and OTU3 respectively. The 496 former have the capability of carrying ODU0, ODU1 and ODUflex client 497 signals, while the latter, ODU1, ODU2, ODU3 and ODUflex. The TS type 498 is 1.25Gbps and all the possible priorities are supported (0~7). 500 The two component links can be bundled as a TE link but it is also 501 possible to consider each of them as a separate TE link. 503 If the two component links are bundled together, N1 and N2 should 504 assign a link local ID to the TE link and then N1 get the link remote 505 ID automatically or manually. 507 N1 can generate an LSA to describe the above attributes of the TE 508 link. Suppose the link IDs are unnumbered, the LSA should carry a 509 link TLV with the following nested minimal sub-TLVs: 511 < G.709 Digital Link > ::= < Link Type > < Link ID > < Link 512 Local/Remote Identifiers > < OTN Interface Switching Capability Descriptor > 514 o Link Type sub-TLV: Defined in [RFC 3630], G.709 digital links are 515 always type 1 - Point-to-point link. 517 o Link ID sub-TLV: Defined in [RFC 3630], for point-to-point link, 518 indicates the remote router ID. 520 o Link Local/Remote Identifiers sub-TLV: Defined in [RFC 4203], 521 indicates the local link ID and the remote link ID. 523 o OTN Interface Switching Capability Descriptor sub-TLV: Defined in 524 this document, carries the characteristic of this G.709 digital TE 525 link. 527 Just after the creation of the TE Link comprising the two component 528 links, the two ISCDs would be as follows: 530 0 1 2 3 531 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 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 | Type | Length | 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 |Res|T=0|OTk =2 | Reserved | Signal Flags |1|0|0|0|0|1|1| 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 | Max lsp TS at P0 =8 | Unreserved TS at p0 =8 | 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 | Max lsp TS at P1 =8 | Unreserved TS at p1 =8 | 540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 541 | Max lsp TS at P2 =8 | Unreserved TS at p2 =8 | 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 | Max lsp TS at P3 =8 | Unreserved TS at p3 =8 | 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 | Max lsp TS at P4 =8 | Unreserved TS at p4 =8 | 546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 547 | Max lsp TS at P5 =8 | Unreserved TS at p5 =8 | 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 549 | Max lsp TS at P6 =8 | Unreserved TS at p6 =8 | 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 | Max lsp TS at P7 =8 | Unreserved TS at p7 =8 | 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 Figure 4: Example - OTN-ISCD OTU2 LC (to) 556 0 1 2 3 557 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 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 | Type | Length | 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 |Res|T=0|OTk =3 | Reserved | Signal Flags |1|0|0|1|1|1|0| 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 | Max lsp TS at P0 =32 | Unreserved TS at p0 =32 | 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 | Max lsp TS at P1 =32 | Unreserved TS at p1 =32 | 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 | Max lsp TS at P2 =32 | Unreserved TS at p2 =32 | 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 | Max lsp TS at P3 =32 | Unreserved TS at p3 =32 | 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 | Max lsp TS at P4 =32 | Unreserved TS at p4 =32 | 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 | Max lsp TS at P5 =32 | Unreserved TS at p5 =32 | 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 | Max lsp TS at P6 =32 | Unreserved TS at p6 =32 | 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 | Max lsp TS at P7 =32 | Unreserved TS at p7 =32 | 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 Figure 5: Example - OTN-ISCD OTU3 LC (to) 582 Suppose that at time t1 an LSP is created allocating 35 Gbps at 583 priority 3. The OTN-ISCD referring to the OTU2 component link is 584 unmodified (Figure 4 and the OTN-ISCD referring to the OTU3 component 585 link is modified as illustrated in Figure 6): 587 0 1 2 3 588 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 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 590 | Type | Length | 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 |Res|T=0|OTk =3 | Reserved | Signal Flags |1|0|0|1|1|1|0| 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 594 | Max lsp TS at P0 =32 | Unreserved TS at p0 =32 | 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 | Max lsp TS at P1 =32 | Unreserved TS at p1 =32 | 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 | Max lsp TS at P2 =32 | Unreserved TS at p2 =32 | 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 | Max lsp TS at P3 =4 | Unreserved TS at p3 =4 | 601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 | Max lsp TS at P4 =4 | Unreserved TS at p4 =4 | 603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 604 | Max lsp TS at P5 =4 | Unreserved TS at p5 =4 | 605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 606 | Max lsp TS at P6 =4 | Unreserved TS at p6 =4 | 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 | Max lsp TS at P7 =4 | Unreserved TS at p7 =4 | 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 Figure 6: Example - OTN-ISCD OTU3 LC (t1) 613 The last example shows how the prehemption is managed. In 614 particular, if a time t2 a new 15 GBps LSP with priority 1 is 615 created, the LSP with priority 3 is prehempted and its resouces (or 616 part of them) are allocated to the LSP with higher priority. The 617 OTN-ISCD sub-TLV related to component link 2 is updated accordingly 618 to Figure 7: 620 0 1 2 3 621 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 622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 623 | Type | Length | 624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 |Res|T=0|OTk =3 | Reserved | Signal Flags |1|0|0|1|1|1|0| 626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 627 | Max lsp TS at P0 =32 | Unreserved TS at p0 =32 | 628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 629 | Max lsp TS at P1 =20 | Unreserved TS at p1 =20 | 630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 631 | Max lsp TS at P2 =20 | Unreserved TS at p2 =20 | 632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 633 | Max lsp TS at P3 =20 | Unreserved TS at p3 =20 | 634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 635 | Max lsp TS at P4 =20 | Unreserved TS at p4 =20 | 636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 637 | Max lsp TS at P5 =20 | Unreserved TS at p5 =20 | 638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 639 | Max lsp TS at P6 =20 | Unreserved TS at p6 =20 | 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 641 | Max lsp TS at P7 =20 | Unreserved TS at p7 =20 | 642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 644 Figure 7: Example - OTN-ISCD OTU3 LC (t2) 646 8. Security Considerations 648 This document specifies the contents of Opaque LSAs in OSPFv2. As 649 Opaque LSAs are not used for SPF computation or normal routing, the 650 extensions specified here have no direct effect on IP routing. 651 Tampering with GMPLS TE LSAs may have an effect on the underlying 652 transport (optical and/or SONET-SDH) network. [RFC3630] suggests 653 mechanisms such as [RFC2154] to protect the transmission of this 654 information, and those or other mechanisms should be used to secure 655 and/or authenticate the information carried in the Opaque LSAs. 657 9. IANA Considerations 659 TBD 661 10. Contributors 662 Xiaobing Zi 664 Huawei Technologies 666 F3-5-B R&D Center, Huawei Base 668 Bantian, Longgang District 670 Shenzhen 518129 P.R.China 672 Email: zixiaobing@huawei.com 674 Francesco Fondelli 676 Ericsson 678 Via Negrone 1/A 680 Genova - 16145 682 Email: francesco.fondelli@ericsson.com 684 Marco Corsi 686 Altran Italia 688 Via Negrone 1/A 690 Genova - 16145 692 EMail: marco.corsi@altran.it 694 11. Acknowledgements 696 The authors would like to thank Eric Gray for his precious comments 697 and advices. 699 12. References 700 12.1. Normative References 702 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 703 Requirement Levels", BCP 14, RFC 2119, March 1997. 705 [RFC2154] Murphy, S., Badger, M., and B. Wellington, "OSPF with 706 Digital Signatures", RFC 2154, June 1997. 708 [RFC2370] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, 709 July 1998. 711 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 712 (TE) Extensions to OSPF Version 2", RFC 3630, 713 September 2003. 715 [RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling 716 in MPLS Traffic Engineering (TE)", RFC 4201, October 2005. 718 [RFC4203] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support 719 of Generalized Multi-Protocol Label Switching (GMPLS)", 720 RFC 4203, October 2005. 722 [RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The 723 OSPF Opaque LSA Option", RFC 5250, July 2008. 725 12.2. Informative References 727 [G.709] ITU-T, "Interface for the Optical Transport Network 728 (OTN)", G.709 Recommendation (and Amendment 1), 729 February 2001. 731 [G.709-v3] 732 ITU-T, "Draft revised G.709, version 3", consented 733 by ITU-T on Oct 2009. 735 [Gsup43] ITU-T, "Proposed revision of G.sup43 (for agreement)", 736 December 2008. 738 Authors' Addresses 740 Daniele Ceccarelli 741 Ericsson 742 Via A. Negrone 1/A 743 Genova - Sestri Ponente 744 Italy 746 Email: daniele.ceccarelli@ericsson.com 748 Diego Caviglia 749 Ericsson 750 Via A. Negrone 1/A 751 Genova - Sestri Ponente 752 Italy 754 Email: diego.caviglia@ericsson.com 756 Fatai Zhang 757 Huawei Technologies 758 F3-5-B R&D Center, Huawei Base 759 Shenzhen 518129 P.R.China Bantian, Longgang District 760 Phone: +86-755-28972912 762 Email: zhangfatai@huawei.com 764 Dan Li 765 Huawei Technologies 766 F3-5-B R&D Center, Huawei Base 767 Shenzhen 518129 P.R.China Bantian, Longgang District 768 Phone: +86-755-28973237 770 Email: danli@huawei.com 772 Yunbin Xu 773 CATR 774 11 Yue Tan Nan Jie 775 Beijing 776 P.R.China 778 Email: xuyunbin@mail.ritt.com.cn