idnits 2.17.1 draft-zhang-ccamp-rwa-wson-routing-ospf-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. 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 : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 5 instances of too long lines in the document, the longest one being 18 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 528 has weird spacing: '... Type sub-...' == Line 537 has weird spacing: '... Type sub-...' -- The document date (March 02, 2009) is 5533 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: 'Lambda-Label' is mentioned on line 446, but not defined == Missing Reference: 'RFC 3630' is mentioned on line 512, but not defined == Missing Reference: 'RFC 4203' is mentioned on line 512, but not defined == Unused Reference: 'RFC3471' is defined on line 548, but no explicit reference was found in the text == Unused Reference: 'WSON-IGP-Eval' is defined on line 596, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 4655 == Outdated reference: A later version (-11) exists of draft-ietf-ccamp-gmpls-g-694-lambda-labels-03 -- No information found for draft-ietf-ccamp-rwa-WSON-Framework - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'WSON-Frame' == Outdated reference: A later version (-24) exists of draft-ietf-ccamp-rwa-info-01 ** Downref: Normative reference to an Informational draft: draft-ietf-ccamp-rwa-info (ref. 'WSON-Info') == Outdated reference: A later version (-28) exists of draft-ietf-ccamp-rwa-wson-encode-00 ** Downref: Normative reference to an Informational draft: draft-li-ccamp-wson-igp-eval (ref. 'WSON-IGP-Eval') -- Possible downref: Non-RFC (?) normative reference: ref. 'Switch' Summary: 6 errors (**), 0 flaws (~~), 11 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network work group Fatai Zhang 2 Internet Draft Huawei 3 Intended status: Standards Track G. Bernstein 4 Expires: September 2009 Grotto Networking 5 Young Lee 6 Dan Li 7 Jianrui Han 8 Huawei 9 March 02, 2009 11 OSPF Extensions in Support of Routing and Wavelength 12 Assignment (RWA) in Wavelength Switched Optical Networks (WSONs) 14 draft-zhang-ccamp-rwa-wson-routing-ospf-00.txt 16 Status of this Memo 18 This Internet-Draft is submitted to IETF in full conformance with 19 the provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on September 02, 2009. 39 Abstract 41 Wavelength switched optical networks (WSONs) are based on Wavelength 42 Division Multiplexing (WDM) in which user traffic is carried by data 43 channels of different optical wavelengths. In traditional WDM 44 Networks, each wavelength path is statically configured. With the 45 deployment of Reconfigurable Optical Add-Drop Multiplexers (ROADMs), 46 photonic cross-connects (PXCs), and tunable laser, WSONs have become 47 more dynamic, and operators can flexibly set up wavelength paths to 48 carry user traffic. 50 In WSONs where there are no or a limited number of switches capable 51 of wavelength conversion paths must be set up subject to the 52 "wavelength continuity" constraint. This leads to a path computation 53 problem known as routing and wavelength assignment (RWA). In order to 54 perform such computations, it is necessary to collect information 55 about the available wavelengths within the network. 57 This document describes OSPF routing protocols extensions to support 58 Wavelength Switched Optical Networks (WSON) under the control of 59 Generalized MPLS (GMPLS). 61 Conventions used in this document 63 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 64 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 65 document are to be interpreted as described in RFC-2119 [RFC2119]. 67 Table of Contents 69 1. Introduction.................................................3 70 2. Node Information.............................................3 71 2.1. Connectivity Matrix.....................................4 72 2.1.1. Link Set...........................................5 73 2.2. Wavelength Converter Pool Information...................7 74 3. Link Information.............................................7 75 3.1. WSON Port Wavelength Restrictions.......................8 76 3.2. Wavelength Availability Information.....................9 77 3.3. Shared Backup Wavelengths..............................11 78 4. Procedures for Routing Flooding.............................11 79 5. Security Considerations.....................................12 80 6. IANA Considerations.........................................12 81 6.1. Node Information.......................................12 82 6.2. Link Information.......................................12 83 7. References..................................................12 84 8. Authors' Addresses..........................................15 85 Acknowledgment.................................................16 87 1. Introduction 89 Wavelength switched optical networks (WSONs) are based on Wavelength 90 Division Multiplexing (WDM) in which user traffic is carried by data 91 channels of different optical wavelengths. In traditional WDM 92 Networks, each wavelength path is statically configured. With the 93 deployment of Reconfigurable Optical Add-Drop Multiplexers (ROADMs), 94 photonic cross-connects (PXCs), and tunable laser, WSONs have become 95 more dynamic, and operators can flexibly set up wavelength paths to 96 carry user traffic. 98 In WSONs where there are no or a limited number of switches capable 99 of wavelength conversion paths must be set up subject to the 100 "wavelength continuity" constraint. This leads to a path computation 101 problem known as routing and wavelength assignment (RWA). In order to 102 perform such computations, it is necessary to collect information 103 about the available wavelengths within the network. 105 [WSON-Frame] provides a framework for applying GMPLS [RFC3945] and 106 the Path Computation Element (PCE) architecture [RFC4655] to the 107 control of WSONs to address the RWA problem. [WSON-Info] describes an 108 information model that specifies the information needed at various 109 points in a WSON in order to compute paths and establish Label 110 Switched Paths (LSPs). Based on the information model of [WSON-Info], 111 [WSON-Encode] provides efficient protocol-independent encodings of 112 the information needed by the RWA process in a WSON. Such encodings 113 can be used to extend GMPLS signaling and routing protocols. 115 Therefore, in order to enable GMPLS to control WSON networks, this 116 document follows on from [WSON-Info], [WSON-Encode], and [WSON-IGP- 117 Eval] to define extensions to the OSPF routing protocol to enhance 118 the Traffic Engineering (TE) properties of GMPLS TE which are defined 119 in [RFC3630], [RFC4202], and [RFC4203]. 121 No consideration of optical impairment routing related information is 122 included in this document. 124 2. Node Information 126 According to [WSON-Info] and [WSON-Encode], the node information 127 about WSON nodes includes Node ID, connectivity matrix, wavelength 128 converter pool information. Except for the Node ID which should 129 comply with Routing Address described in [RFC3630], the other pieces 130 of information are defined in this document. 132 [OSPF-Node] defines a new top TLV named the Node Attribute TLV which 133 carries attributes related to a router/node. Connectivity matrix, 134 wavelength converter pool information are attributes associated with 135 a WSON node, so this document defines the following sub-TLVs of Node 136 Attribute TLV: 138 (1)Connectivity matrix sub-TLV 140 (2)Wavelength converter pool information sub-TLV 142 2.1. Connectivity Matrix 144 Unlike the packet and TDM networks whose switching devices are 145 symmetric, the switching devices in a WSON are highly asymmetric. 146 Therefore, it is necessary to identify which ingress ports and 147 wavelengths can be connected to (the same wavelength on) a specific 148 egress port. Detailed descriptions of the Connectivity Matrix can be 149 found in the corresponding sections of [WSON-Info] and [WSON-Encode]. 151 The Connectivity Matrix TLV is a sub-TLV (the type is TBD by IANA) of 152 the Node Attribute TLV. The format of this sub-TLV is defined as 153 follows: 155 0 1 2 3 156 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 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | Connectivity | Reserved | 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 | Link Set A #1 | 161 : : : 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | Link Set B #1 | 164 : : : 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | Additional Link set pairs as needed | 167 : to specify connectivity : 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 Type = TBD 172 Connectivity : 8 bits 174 The following values are currently defined. All other values are 175 reserved and SHOULD be transmitted as zero and ignored on receipt. 177 0x01: Fixed Connectivity Matrix 178 Indicates that the switching element is a kind of fixed switching 179 device, so the connectivity matrix represents the potential 180 connectivity matrix. This applies to asymmetric fixed devices or to 181 the fixed part of a "hybrid" device [Switch]. 183 0x02: Switched Connectivity Matrix 185 Indicates that the switching element is a kind of switched device 186 (e.g., ROADM or OXC). The connectivity matrix represents the 187 potential connectivity matrix for an asymmetric switch. 189 Reserved: 24 bits 191 This field is reserved. It SHOULD be set to zero on transmission 192 and MUST be ignored on receipt. 194 Link Set: At least one Link Set MUST be present. Multiple Link Sets 195 MAY be present. Each one has variable length. The Link set is defined 196 in Section 2.2.1.. 198 2.1.1. Link Set 200 Link Set identifies a link group and is defined as follows: 202 0 1 2 3 203 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 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | Action |Dir| Format | Num Links | Reserved | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | Link Identifier 1 | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 : : : 210 : : : 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 | Link Identifier N | 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 The Link Set is not a kind of sub-TLV and it is just a part of the 216 Connectivity Matrix TLV. (Note that this construct may be reused in 217 the Wavelength Converter Pool information in Section 2.3 in a future 218 version of this document.) 220 Action: 8 bits 222 The following values are currently defined. All other values are 223 reserved. 225 0x01: Inclusive List 227 Indicates that one or more link identifiers are included in the 228 Link Set. Each identifies a separate link that is part of the set. 230 0x02: Inclusive Range 232 Indicates that the Link Set defines a range of links. It 233 contains two link identifiers. The first identifier indicates the 234 start of the range (inclusive). The second identifier indicates the 235 end of the range (inclusive). All links with numeric values between 236 the bounds are considered to be part of the set. A value of zero in 237 either position indicates that there is no bound on the corresponding 238 portion of the range. Note that the Action field could be set to 239 0x02(Inclusive Range) only when unnumbered link identifier is used. 241 Directionality of the Link Set (Dir): 2 bits 243 The following values are currently defined. All other values are 244 reserved. 246 0x01: Bidirectional 248 Indicates that the links in the Link Set are bidirectional. 250 0x02: Incoming 252 Indicates that the links in the Link Set are from the incoming 253 direction with respect to the node advertising the information. 255 0x03: Outgoing 257 Indicates that the links in the Link Set are to the outgoing 258 direction with respect to the node advertising the information. 260 Format: 6 bits 262 This field identifies the format of the link identifier. The 263 following values are currently defined. All other values are reserved. 265 0x01: Link Local Identifier with IPv4 address 267 Indicates that the links in the Link Set are identified by link 268 local identifiers which are IPv4 numbered. All link local identifiers 269 are supplied in the context of the advertising node. 271 0x02: Link Local Identifier with unnumbered interface 272 Indicates that the links in the Link Set are identified by link 273 local identifiers which are unnumbered interface IDs. All link local 274 identifiers are supplied in the context of the advertising node. 276 Num Links: 8 bits 278 This field indicates the total number of the links in the Link Set. 280 Reserved: 8 bits 282 This field is reserved. It MUST be set to zero on transmission 283 and MUST be ignored on receipt. 285 Link Identifier: 32 bits for each link 287 If the Format field is set to 0x01 (Link Local Identifier with 288 IPv4 address), the link identifier is the interface IP address used 289 to identify the incoming or outgoing port corresponding to the link. 290 The format of the Link Identifier should comply with the format of 291 the Local/Remote Interface IP Address described in [RFC3630]. 293 If the Format field is set to 0x02 (Link Local Identifier with 294 unnumbered interface), the link identifier is unnumbered. 296 An example about Connectivity Matrix representation could be referred 297 to the Section 3.2 of [WSON-Encode]. 299 2.2. Wavelength Converter Pool Information 301 TBD. 303 3. Link Information 305 The most common link sub-TLVs are already defined in [RFC3630], 306 [RFC4203]. For example, Link ID, Administrative Group, Interface 307 Switching Capability Descriptor (ISCD), Link Protection Type, Shared 308 Risk Link Group Information (SRLG), and Traffic Engineering Metric. 310 For WSONs, per [WSON-Info] and [WSON-Encode], the following 311 additional link sub-TLVs are defined in this document. 313 (1) WSON Port Wavelength Restrictions sub-TLV 315 (2) Wavelength Availability sub-TLV 317 (3) Shared Backup Wavelengths sub-TLV 319 3.1. WSON Port Wavelength Restrictions 321 In WSONs, there may be wavelength restrictions on a link or port. For 322 example, a WSON link might only be able to support switching some 323 specific wavelengths. These restrictions are distributed by OSPF to 324 be convenient for wavelength path computation. 326 The WSON Port Wavelength Restrictions TLV is a sub-TLV (the type is 327 TBD by IANA) of the Link TLV. The format of this sub-TLV is defined 328 as follows: 330 0 1 2 3 331 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 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 |RestrictionKind|T| Reserved | MaxNumChannels | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | Wavelength Set | 336 | (variable) | 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 Type = TBD 341 RestrictionKind: 8 bits 343 The following values are currently defined. All other values are 344 reserved. 346 0x01: Simple wavelength selective restriction 348 In this case, MaxNumChannels indicates the maximum number of 349 wavelengths permitted on the port, and the accompanying Wavelength 350 Set indicates the specific permitted wavelengths. 352 0x02: Waveband device with a tunable center frequency and 353 passband. 355 In this case, MaxNumChannels indicates the maximum width of the 356 waveband in terms of the channels spacing given in the Wavelength Set. 357 The corresponding wavelength set is used to indicate the overall 358 tuning range. Specific center frequency tuning information can be 359 obtained from dynamic channel in use information. 361 MaxNumChannels indicates the maximum number of channels supported on 362 the port/waveband dependent on the setting of the RestrictionKind 363 field. 365 Wavelength Set information is carried as defined in Section 3.4 of 366 [WSON-Encode]. 368 3.2. Wavelength Availability Information 370 The requirements for a global semantic for wavelength labels and the 371 corresponding standardized wavelength label can be found in [Lambda- 372 Labels]. 374 Because the wavelength continuity along the wavelength Label Switched 375 Path (LSP) should be ensured without wavelength conversion or with 376 wavelength conversion at some switches along the path, the 377 information about wavelength availability and wavelength connectivity 378 is very important when computing a wavelength LSP. For example, if 379 the wavelength label range [lambda 1, lambda 5] of fiber 1 can be 380 connected to the same wavelength label range of fiber 2, but only 381 lambda 3 is available on fiber 2 because other wavelength labels are 382 occupied, lambda 3 must be selected on fiber 1. 384 If the wavelength availability information is not known by the node 385 performing the path computation, then the computation can only be 386 performed at the level of TE links, and wavelength assignment must be 387 resolved locally by the switches on a hop-by-hop basis enhanced by 388 signaling protocol mechanisms used to negotiate label selection. 389 However, this case may be very inefficient in the signaling protocol, 390 and can easily lead to blocking problems where a path is selected for 391 which there is no suitable wavelength availability, unless some or 392 all of the switches along the path are capable of full wavelength 393 conversion. In the general case of limited or no wavelength 394 conversion, information on wavelength availability is essential to 395 perform efficient and accurate path computation. 397 It is possible to consider reporting the statuses of each wavelength 398 on a link using implicit wavelength identification based on the link- 399 local knowledge of wavelengths supported and a well-known sequence. 400 However, this information would be of no use in a wider context (i.e., 401 away from the link ends). On the other hand, if the standardized 402 label format described in [Lambda-Labels] is used to identify every 403 wavelength when its status is reported, the wavelength information 404 will be a little larger (or the order of one wavelength label per 405 status advertised). This may have a significant affect on the total 406 information advertised in a network because a WSON link often 407 supports many wavelengths (e.g., 80 or 160 wavelength systems). 409 To minimize the size of information, a bitmap wavelength set is 410 defined in [WSON-Encode] to indicate the wavelength availability 411 information for a fiber, i.e., only one bit is used to indicate the 412 status of a certain wavelength (the wavelength is either available or 413 not available). 415 Note that there are five approaches for Wavelength Set which is used 416 to represent the wavelength availability information described in 417 Section 3.4 of [WSON-Encode]. Considering that the continuity of the 418 available or unavailable wavelength set can be scattered for the 419 dynamic wavelength availability, so it may burden the routing to 420 reorganize the wavelength set information when the Inclusive 421 (/Exclusive) List (/Range) approaches are used to represent 422 wavelength availability information. Therefore, it is RECOMMENDED 423 that only the Bitmap Set be used for representation wavelength 424 availability information as follows. 426 The Wavelength Availability TLV is a sub-TLV (the type is TBD by 427 IANA) of the Link TLV. The format of this sub-TLV is defined as 428 follows: 430 0 1 2 3 431 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 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 | Num Wavelengths | Reserved | 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 |Grid | C.S. | Reserved | n for lowest frequency | 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 | Bit Map Double-word #1 (Lowest frequency channels) | 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 : : 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 |Bit Map Double-word #N (Highest frequency channels)|Padded bits| 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 Type = TBD 446 The three fields (Grid, C.S. and n) are defined in [Lambda-Label]. 448 Num Wavelengths: 8 bits 450 Indicates the number of the wavelengths represented by the bit 451 map. 453 Each bit in the bit map represents a particular frequency with a 454 value of 1/0 indicating whether the frequency is available or not. 455 Bit position zero represents the lowest frequency, while each 456 succeeding bit position represents the next frequency a channel 457 spacing (C.S.) above the previous. The values of the bit map are 458 defined as follows: 460 1 = Available 462 0 = Assigned (in use, or failed, or administratively down, or 463 under testing) 465 The valid length of the bit map is clearly Num Wavelengths bits, but 466 the bit map should be padded to make the whole number of the bits in 467 bitmap be the time of 32 bits so that the TLV is a multiple of four 468 bytes. Padded bit SHOULD be set to 0 and MUST be ignored. 470 Bits that do not represent wavelengths (i.e., those in positions (Num 471 Wavelengths - 1) and beyond) SHOULD be set to zero and MUST be 472 ignored. 474 3.3. Shared Backup Wavelengths 476 TBD. 478 4. Procedures for Routing Flooding 480 The advertisement for the node attributes SHOULD comply with the 481 procedures described in [OSPF-Node]. 483 In the WSON networks, the node information can be classified as two 484 kinds: one is static information comparatively such as Node ID, 485 Connectivity Matrix information; the other is dynamic information 486 such as Wavelength Converter Pool Status information. For the static 487 node information, the router announces the static node information in 488 the node attribute TLV which could be advertised during the node 489 starts or periodically for some configurable time (e.g., per hour or 490 several hours). For the dynamic node information, the router 491 announces this information in the separate node attribute TLV which 492 SHOULD be advertised during node starts or when the corresponding 493 node information is changed. 495 For the WSON link information, the procedures for the routing 496 flooding SHOULD comply with [RFC3630], [RFC4203] and the other 497 existing family standards, and there is no extended process for the 498 link attributes advertisement, except that some link sub-TLVs are 499 defined in this document. 501 Note that as with other TE information, an implementation SHOULD take 502 measures to avoid rapid and frequent updates of routing information 503 that could cause the routing network to become swamped. A threshold 504 mechanism MAY be applied such that updates are only flooded when a 505 number of changes have been made to the wavelength availability 506 information within a specific time. Such mechanisms MUST be 507 configurable if they are implemented. 509 5. Security Considerations 511 This document does not introduce any further security issues other 512 than those discussed in [RFC 3630], [RFC 4203]. 514 6. IANA Considerations 516 [RFC3630] says that the top level Types in a TE LSA and Types for 517 sub-TLVs for each top level Types must be assigned by Expert Review, 518 and must be registered with IANA. 520 IANA is requested to allocate new Types for the sub-TLVs as defined 521 in Sections 2.1, 3.1, and 3.2 as follows: 523 6.1. Node Information 525 This document introduces the following sub-TLV of Node Attribute TLV 526 (Value TBD, see [OSPF-Node]) 528 Type sub-TLV 530 TBD Connectivity matrix 532 6.2. Link Information 534 This document introduces the following sub-TLV of TE Link TLV (Value 535 2) 537 Type sub-TLV 539 TBD WSON Port Wavelength Restrictions 541 TBD Wavelength Availability 543 7. References 545 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 546 Requirement Levels", BCP 14, RFC 2119, March 1997. 548 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 549 (GMPLS) Signaling Functional Description", RFC 3471, 550 January 2003. 552 [RFC3630] Katz, D., Kompella, K., and Yeung, D., "Traffic 553 Engineering (TE) Extensions to OSPF Version 2", RFC 554 3630, September 2003. 556 [RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing Extensions 557 in Support of Generalized Multi-Protocol Label Switching 558 (GMPLS)", RFC 4202, October 2005 560 [RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions in 561 Support of Generalized Multi-Protocol Label Switching 562 (GMPLS)", RFC 4203, October 2005. 564 [RFC3945] E. Mannie, Ed., "OGeneralized Multi-Protocol Label Switching (GMPLS) 565 Architecture", RFC 3945, October 2004. 567 [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path 568 Computation Element (PCE)-Based Architecture ", RFC 4655, 569 August 2006. 571 [OSPF-Node] R. Aggarwal and K. Kompella, "Advertising a Router's 572 Local Addresses in OSPF TE Extensions", draft-ietf-ospf- 573 te-node-addr, work in progress. 575 [Lambda-Labels] T. Otani, H. Guo, K. Miyazaki, D. Caviglia, 576 "Generalized Labels for G.694 Lambda-Switching 577 Capable Label Switching Routers", work in progress: 578 draft-ietf-ccamp-gmpls-g-694-lambda-labels-03.txt, 579 January 2009. 581 [WSON-Frame] G. Bernstein, Y. Lee, W. Imajuku, "Framework for GMPLS 582 and PCE Control of Wavelength Switched Optical 583 Networks", work in progress: draft-ietf-ccamp-rwa-WSON- 584 Framework-00.txt, December 2008. 586 [WSON-Info] Y. Lee, G. Bernstein, D. Li, W. Imajuku, "Routing and 587 Wavelength Assignment Information Model for Wavelength 588 Switched Optical Networks", work in progress: draft-ietf- 589 ccamp-rwa-info-01.txt, October 2008. 591 [WSON-Encode] G. Bernstein, Y. Lee, D. Li, W. Imajuku, "Routing and 592 Wavelength Assignment Information Encoding for 593 Wavelength Switched Optical Networks", work in progress: 594 draft-ietf-ccamp-rwa-wson-encode-00.txt, December 2008. 596 [WSON-IGP-Eval] Dan Li, J. Gao, Y. Lee, "Evaluation of Possible 597 Interior Gateway Protocol Extensions for Wavelength 598 Switching Optical Networks", work in progress: 599 draft-li-ccamp-wson-igp-eval-01.txt, July 2008. 601 [Switch] G. Bernstein, Y. Lee, A. Gavler, J. Martensson, " Modeling 602 WDM Wavelength Switching Systems for use in Automated Path 603 Computation", http://www.grotto- 604 networking.com/wson/ModelingWSONswitchesV2a.pdf , June, 605 2008 607 8. Authors' Addresses 609 Fatai Zhang 610 Huawei Technologies 611 F3-5-B R&D Center, Huawei Base 612 Bantian, Longgang District 613 Shenzhen 518129 P.R.China 615 Phone: +86-755-28972912 616 Email: zhangfatai@huawei.com 618 Greg Bernstein 619 Grotto Networking 620 Fremont CA, USA 622 Phone: (510) 573-2237 623 Email: gregb@grotto-networking.com 625 Young Lee 626 Huawei Technologies 627 1700 Alma Drive, Suite 100 628 Plano, TX 75075 629 USA 631 Phone: (972) 509-5599 (x2240) 632 Email: ylee@huawei.com 634 Dan Li 635 Huawei Technologies Co., Ltd. 636 F3-5-B R&D Center, Huawei Base, 637 Bantian, Longgang District 638 Shenzhen 518129 P.R.China 640 Phone: +86-755-28973237 641 Email: danli@huawei.com 643 Jianrui Han 644 Huawei Technologies Co., Ltd. 645 F3-5-B R&D Center, Huawei Base, 646 Bantian, Longgang District 647 Shenzhen 518129 P.R.China 648 Phone: +86-755-28972913 649 Email: hanjianrui@huawei.com 651 Acknowledgment 653 TBD. 655 Intellectual Property 657 The IETF Trust takes no position regarding the validity or scope of 658 any Intellectual Property Rights or other rights that might be 659 claimed to pertain to the implementation or use of the technology 660 described in any IETF Document or the extent to which any license 661 under such rights might or might not be available; nor does it 662 represent that it has made any independent effort to identify any 663 such rights. 665 Copies of Intellectual Property disclosures made to the IETF 666 Secretariat and any assurances of licenses to be made available, or 667 the result of an attempt made to obtain a general license or 668 permission for the use of such proprietary rights by implementers or 669 users of this specification can be obtained from the IETF on-line IPR 670 repository at http://www.ietf.org/ipr 672 The IETF invites any interested party to bring to its attention any 673 copyrights, patents or patent applications, or other proprietary 674 rights that may cover technology that may be required to implement 675 any standard or specification contained in an IETF Document. Please 676 address the information to the IETF at ietf-ipr@ietf.org. 678 The definitive version of an IETF Document is that published by, or 679 under the auspices of, the IETF. Versions of IETF Documents that are 680 published by third parties, including those that are translated into 681 other languages, should not be considered to be definitive versions 682 of IETF Documents. The definitive version of these Legal Provisions 683 is that published by, or under the auspices of, the IETF. Versions of 684 these Legal Provisions that are published by third parties, including 685 those that are translated into other languages, should not be 686 considered to be definitive versions of these Legal Provisions. 688 For the avoidance of doubt, each Contributor to the IETF Standards 689 Process licenses each Contribution that he or she makes as part of 690 the IETF Standards Process to the IETF Trust pursuant to the 691 provisions of RFC 5378. No language to the contrary, or terms, 692 conditions or rights that differ from or are inconsistent with the 693 rights and licenses granted under RFC 5378, shall have any effect and 694 shall be null and void, whether published or posted by such 695 Contributor, or included with or in such Contribution. 697 Disclaimer of Validity 699 All IETF Documents and the information contained therein are provided 700 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 701 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 702 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 703 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 704 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 705 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 706 FOR A PARTICULAR PURPOSE. 708 Full Copyright Statement 710 Copyright (c) 2009 IETF Trust and the persons identified as the 711 document authors. All rights reserved. 713 This document is subject to BCP 78 and the IETF Trust's Legal 714 Provisions Relating to IETF Documents in effect on the date of 715 publication of this document (http://trustee.ietf.org/license-info). 716 Please review these documents carefully, as they describe your rights 717 and restrictions with respect to this document.