idnits 2.17.00 (12 Aug 2021) /tmp/idnits40238/draft-ong-gmpls-ason-routing-exper-01.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: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 12 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([OSPFASON]), 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 date (February 26, 2010) is 4467 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: 'G.8080' is mentioned on line 91, but not defined == Missing Reference: 'G.7715' is mentioned on line 95, but not defined == Missing Reference: 'G.7715.1' is mentioned on line 95, but not defined == Outdated reference: draft-ietf-ccamp-gmpls-ason-routing-ospf has been published as RFC 5787 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Ong, Ciena 3 Internet-Draft A. Malis, Verizon 4 Intended status: Standards Track R. Theillaud, Marben Products 5 Expires: October 26, 2010 6 February 26, 2010 8 OSPFv2 Extensions for ASON Routing based on Implementation Experience 9 draft-ong-gmpls-ason-routing-exper-01 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 This Internet-Draft will expire on October 26, 2010. 34 Abstract 36 IETF CCAMP WG has defined a set of extensions to OSPFv2 to support 37 ASON routing requirements. These extensions have been given EXP 38 status rather than Standards Track and according to guidelines for 39 OSPFv2 have not been allocated standard codepoints by IANA. This 40 work has continued in [OSPFASON]. 42 This draft defines a set of proposed updates for a subset of the 43 the ASON routing extensions for OSPFv2 defined in [OSPFASON]. 44 These proposed updates have already benefited from running code 45 tested in multiple interoperability testing events, with at least 46 eight independent implementations. The differences from [OSPFASON] 47 are the result of field and interoperability testing experience. 49 These formats are proposed to either be folded in to [OSPFASON], 50 or be a separate Standards Track RFC covering 51 a subset of the ASON extensions to OSPFv2, as preferred by the 52 working group. We believe that adopting these formats will help 53 move those parts of [OSPFASON] towards Standards Track, while 54 preserving the functionality defined in [OSPFASON]. 56 Requirements Language 58 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 59 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 60 document are to be interpreted as described in RFC 2119 [RFC2119]. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Comparison with [OSPFASON]. . . . . . . . . . . . . . . . . . 3 66 3. Reachability . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 3.1. ASON Routing Requirements . . . . . . . . . . . . . . . . 4 68 3.2. Local TE Router_ID sub-TLV . . . . . . . . . . . . . . . . 5 69 3.3. IPv4 Reachable Address Prefix sub-TLV . . . . . . . . . . 5 70 3.4. IPv6 Reachable Address Prefix sub-TLV . . . . . . . . . . 5 71 4. Routing Information Scope . . . . . . . . . . . . . . . . . . 6 72 4.1. ASON Routing Requirements . . . . . . . . . . . . . . . . 6 73 4.2. Local and Remote TE Router_ID sub-TLVs . . . . . . . . . . 6 74 5. Link Attributes . . . . . . . . . . . . . . . . . . . . . . . 7 75 5.1. ASON Requirements . . . . . . . . . . . . . . . . . . . . 7 76 5.2. Link Component Availability Sub-TLV. . . . . . . . . . . . 7 77 6. Implementation and Testing Results . . . . . . . . . . . . . . 9 78 6.1. Standardization . . . . . . . . . . . . . . . . . . . . . 9 79 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 80 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 81 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 82 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 83 10.1. Normative References . . . . . . . . . . . . . . . . . . . 11 84 10.2. Informative References . . . . . . . . . . . . . . . . . . 11 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 86 Intellectual Property and Copyright Statements . . . . . . . . . . 12 88 1. Introduction 90 The ITU-T defines the architecture of the Automatically Switched 91 Optical Network (ASON) in [G.8080]. 93 [RFC4258] details the routing requirements for the GMPLS suite of 94 routing protocols to support the capabilities and functionality of 95 ASON control planes identified in [G.7715] and in [G.7715.1]. 97 [RFC4652] evaluates the IETF Link State Routing Protocols against the 98 requirements identified in [RFC4258]. Section 7.1 of [RFC4652] 99 summarizes the capabilities to be provided by OSPFv2 [RFC2328] in 100 support of ASON routing. This document details a set of OSPFv2 101 extensions supporting a subset of the capabilities identified in 102 [RFC4652] which have already been implemented and tested for 103 interoperability across at least 8 independent implementations. 105 Note that these extensions have been tested in a transport-only 106 instance of OSPF, i.e. routing implementations supported only optical 107 routing and did not participate in any IP routing use of OSPF. 109 This draft also compares the implemented extensions to those 110 defined in [OSPFASON], which defines experimental OSPFv2 111 extensions in support of [RFC4652] capabilities. The changes from 112 [OSPFASON] are the result of field and interoperability testing 113 experience, and are either minor format changes or supplementary 114 information found useful in field testing. We believe that adop- 115 ting the extensions in this draft will further progress [OSPFASON]. 117 2. Comparison with [OSPFASON] 119 This draft defines formats similar to some defined in [OSPFASON]. 120 This section gives a high level comparison of the two formats. 122 2.1. Reachable Address Prefix Advertisement 124 Uses a single TLV to carry multiple values of TE Router_ID and 125 associated IPv4 or IPv6 address prefixes, rather than separate 126 TLVs as in [OSPFASON]. 128 In the IPv4 prefix format, uses Prefix Length to indicate the 129 prefix length rather than a Network Mask as in [OSPFASON] (Note 130 [OSPFASON] uses Prefix Length for the IPv6 prefix format). 132 2.2. Router Information Scoping 134 Uses separate Sub-TLVs to carry Local and Remote TE Router_ID 135 instead of a single Sub-TLV for both, as in [OSPFASON]. 137 2.3. Link Attributes 139 Advertises Link Component Availability at multiple TDM layers 140 as opposed to or in addition to advertisement of ISCD for an 141 individual TDM layer. 143 3. Reachability 145 3.1. ASON Routing Requirements 147 [RFC4652] identifies the need for additional capabilities to 148 advertise blocks of reachable address prefixes using a summarization 149 mechanism either taking the form of a prefix length (which indicates 150 the number of significant bits in the prefix) or a network mask. 152 An OSPF Reachable Address Prefix TLV was implemented and tested 153 to support this capability. This TLV is advertised as the payload 154 of a Type 1 Traffic Engineering LSA [RFC3630]. It has the following 155 format:" 157 0 1 2 3 158 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 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 | Type | Length (variable) | 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | Local TE_Router_Id sub-TLV | 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 | IPv4 or IPv6 Reachable Address sub-TLV | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | | 167 // . . . // 168 | | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | IPv4 or IPv6 Reachable Address sub-TLV | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | | 173 // . . . // 174 | | 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 | Local TE_Router_Id sub-TLV | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 | IPv4 or IPv6 Reachable Address sub-TLV | 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 // . . . // 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 | IPv4 or IPv6 Reachable Address sub-TLV | 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 This format allows the Reachable Address Prefix TLV to advertise 185 multiple TE Router_IDs associated with the advertising entity, as 186 well as multiple Reachable Address Prefixes associated with these 187 TE Router_IDs. 189 Each IPv4 or IPv6 Reachable Address Prefix sub-TLV is associated 190 specifically with the TE Router_ID preceding it in the TLV. 192 3.2. Local TE_Router_ID Sub-TLV 194 The Local TE_Router_ID sub-TLV used the following format: 196 0 1 2 3 197 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 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 | Type (tbd) | Length | 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | Local TE Router_ID | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 The Local TE Router_ID field advertises a Local TE Router_IDentifier 205 being advertised associated with the advertising entity. 207 3.3 IPv4 Reachable Address Prefix Sub-TLV 209 The IPv4 Reachable Address Prefix sub-TLV takes the following form: 211 0 1 2 3 212 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 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | Type (tbd) | Length (variable) | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 | Pref_length | Reserved | 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | IPv4 Reachable Address Prefix | 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 The following fields are defined: 223 Pref_length: length in bits of the Prefix 225 IPv4 Reachable Address Prefix: Each prefix is encoded as a 226 32-bit word with trailing zero bit padding as necessary. 228 3.4 IPv6 Reachable Address Prefix Sub-TLV 230 IPv6 prefixes were not implemented or tested. 232 4. Routing Information Scope 234 4.1. ASON Routing Requirements 236 [RFC4652] identifies the need for an extension to routing protocols 237 to support non-1:1 relationships between the Router_ID and TE 238 Router_ID, and as a result the need for the capability to advertise 239 the remote Lj value where Lj is a logical control plane entity that 240 is associated to a single data plane (abstract) node. 242 4.2. Local and Remote TE Router_ID Sub-TLVs 244 In order to support this capability, two sub-TLVs of the TE LSA Link 245 TLV [RFC3630] are defined for advertising the Local TE Router_ID 246 and Remote TE Router_ID. These use the following formats: 248 0 1 2 3 249 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 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | Type | Length | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 | Local TE Router_ID | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 0 1 2 3 257 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 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 | Type | Length | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | Remote TE Router_ID | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 These sub-TLVs allow the routing protocol to scope the advertised 265 link attributes advertised in an OSPFv2 TE Link LSA for ASON 266 routing. 268 5. Link Attributes 270 5.1 ASON Requirements 272 [RFC4652] notes that in the ASON context, bandwidth accounting 273 representations are possible, taking the form of a set of tuples 274 , and that this 275 representation may also require definition of additional signal 276 types (from those defined in [RFC4606]) to represent support of 277 contiguously concatenated signals, 278 i.e., STS-(3xN)c SPE / VC-4-Nc, N = 4, 16, 64, 256. 280 It notes that the ISCD defined in [RFC4202] is the most 281 straightforward without requiring any bandwidth accounting 282 change from an LSR perspective. However, the ISCD defined 283 in [RFC4202} must be advertised once per signal type 284 (identified by the Minimum Reservable Bandwidth value) in 285 order to provide an accurate advertisement of bandwidth 286 for each signal. For SONET/SDH links, it is common to support 287 4-5 signal types (e.g., STS-1, 3c, 12c, 48c and 192c) at once, 288 and advertisement of 4-5 ISCD sub-TLVs would consume about 289 200 bytes as compared to 20-30 bytes for a tuple format. 291 Most of the ISCD bytes are required to advertise 8 levels of 292 priority. We believe this overhead can be reduced as (a) ASON 293 specifications do not identify priority as an ASON service; and 294 (b) TDM networks generally to not support preemption priority 295 at all, not to mention 8 levels. 297 5.2. Link Component Availability Sub-TLV 299 The Link Component Availability Sub-TLV carries an indication 300 of SONET/SDH bandwidth at multiple link component signal types as 301 supplementary information to the ISCD sub-TLV. 303 When multiple priorities are used, the Link Component Availability 304 Sub-TLV can be interpreted as the availability for Priority 7. 306 The following format is defined: 308 0 1 2 3 309 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 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | Type (tbd) | Length = 4 + n*4 | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | Switching Cap | Encoding | Reserved | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | Signal Type | Number of Unallocated Timeslots | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | Signal Type | Number of Unallocated Timeslots | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | | 320 // . . . // 321 | | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | Signal Type | Number of Unallocated Timeslots | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 Note: n defines the number of signal types supported on this link, 327 and thus has a value greater than or equal to 1. Inherited from 328 [RFC4202], the Switching Capability field and the Encoding field MUST 329 take the following values for Sonet/SDH interfaces: Switching 330 Capability (8 bits): value 100 (TDM). Encoding (8 bits): value 5 for 331 Sonet/SDH. Reserved (16 bits): must be set to zero when sent and 332 ignored when received. 334 Signal Type (8 bits): 336 STS-1 SPE / VC-3 [RFC4606] 337 STS-3c SPE / VC-4 [RFC4606] 338 STS-12c SPE/VC-4-4c 339 STS-48c SPE/VC-4-16c 340 STS-192c SPE/VC-4-64c 342 Number of Unallocated Timeslots (24 bits): 344 Specifies the number of identical unallocated timeslots per Signal 345 Type and per TE Link. As such, the initial value(s) of this TLV 346 indicates the total capacity in terms of number of timeslots per TE 347 link. The signal type included in the BW announcement is specific to 348 the layer link being reported and is not derived from some other 349 signal type (e.g. STS-48c is not announced as 16 x STS-3c). 351 For instance on an OC-192/STM-64 interface either the number of 352 STS-3c SPE/VC-4 unallocated timeslots is initially equal to 64, or 353 the number of STS-48c SPE/VC-4-16c unallocated timeslots is equal to 354 4 or even a combination of both type of signals depending on the 355 interface capabilities. Once one of these timeslots is occupied 356 either by being allocated for a connection at the same or a larger 357 signal type or by being blocked due to the allocation of part of 358 the timeslot for a connection at a smaller signal type, the number 359 of unallocated timeslots is decreased by the number of timeslots 360 this connection implies. 362 6. Implementation and Testing Results 364 Initial implementation of ASON routing extensions began in 2003. 365 Testing of these protocol extensions was carried out at a number of 366 testing events from 2003-2009, most recently occurring over a period 367 of months during July-September 2007 and April-June 2009. There were 368 7 independent implementations tested at each event as listed below: 370 2007 interop test implementations: 372 o Alcatel-Lucent 373 o Ciena Corporation 374 o Ericsson 375 o Huawei Technologies 376 o Sycamore Networks 377 o Tellabs 378 o ZTE 380 2009 interop test implementations: 382 o Alcatel-Lucent 383 o Ciena Corporation 384 o Ericsson 385 o Huawei Technologies 386 o Nokia Siemens Networks 387 o Sycamore Networks 388 o Tellabs 389 o ZTE 391 Further information about the testing conducted can be found at 392 http://www.oiforum.com/public/OIF_demos.html 393 All implementations utilized the ASON routing extensions described in 394 this draft. 396 Results were: 398 o prototype implementations were interoperable 399 o aligned TE database was achieved by participating implementations 400 o path computation was successfully achieved for connections 401 o connections were successfully set up at different SONET/SDH rates 402 using the TE database 404 6.1. Standardization 406 The extensions defined in this draft satisfy a subset of the 407 functionality identified in [RFC4258] and [RFC4652] for ASON 408 routing. The results of implementation and interoperability testing 409 show that these functions are useful and implementable, and that ASON 410 routing extensions to OSPF may be made Standards Track rather than 411 Experimental, using the formats implemented and tested. 413 Standardization of these extensions by IETF for ASON routing support 414 would allow fast adoption in the industry due to the presence of 415 several existing implementations, i.e., running code. 417 7. IANA Considerations 419 Propose IANA allocate codepoints for new TLV/sub-TLVs for ASON 420 Routing from the standard range. 422 8. Security Considerations 424 This document describes implementation and testing experience with 425 ASON routing extensions similar to those defined in [OSPFASON]. No 426 additional security issues are identified. 428 9. Acknowledgements 430 The authors would like to thank the following OIF members for their 431 comments and support for this document: 433 Richard Graveman (Department of Defense) 434 Hans-Martin Foisel (Deutsche Telekom) 435 Thierry Marcot (France Telecom) 436 Evelyne Roch (Nortel Networks) 437 Jonathan Sadler (Tellabs) 438 Yoshiaki Sone (NTT Corporation) 439 Takehiro Tsuritani (KDDI R&D Laboratories) 441 10. References 443 10.1. Normative References 445 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 446 Requirement Levels", BCP 14, RFC 2119, March 1997. 447 [RFC2328] Moy, J., "OSPF Version 2", RFC 2328,April 1998. 448 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 449 (TE) Extensions to OSPF Version 2", RFC 3630, 450 September 2003. 451 [RFC4202] Kompella, K. and Y. Rekhter, "Routing Extensions in 452 Support of Generalized Multi-Protocol Label Switching 453 (GMPLS)", RFC 4202,February 2005. 454 [RFC4606] Mannie, E. and D. Papadimitriou, "Generalized Multi- 455 Protocol Label Switching (GMPLS) Extensions for 456 Synchronous Optical Network (SONET) and Synchronous 457 Digital Hierarchy (SDH) Control", RFC 4606, August 2006. 459 10.2. Informative References 461 [OSPFASON] Papadimitriou, D., "OSPFv2 Routing Protocols Extensions 462 for ASON Routing, 463 draft-ietf-ccamp-gmpls-ason-routing-ospf-09.txt, work in 464 progress", August 2010. 465 [RFC4258] Brungard, D., "Requirements for Generalized Multi-Protocol 466 Label Switching (GMPLS) Routing for the Automatically 467 Switched Optical Network (ASON)", RFC 4258, November 2005. 468 [RFC4652] Papadimitriou, D., L.Ong, Sadler, J., Shew, S., and D. 469 Ward, "Evaluation of Existing Routing Protocols against 470 Automatic Switched Optical Network (ASON) Routing 471 Requirements", RFC 4652,February 2006. 473 Authors' Addresses 475 Lyndon Ong 476 Ciena 477 P.O.Box 308 478 Cupertino CA 95015 479 USA 481 Phone: +1 408 962 4929 482 Email: lyong@ciena.com 484 Andrew Malis 485 Verizon 486 117 West St. 487 Waltham, MA 02451 488 USA 490 Email: andrew.g.malis@verizon.com 491 Phone: +1 781 466 2362 493 Remi Theillaud 494 Marben Products 495 176 rue Jean Jaures 496 Puteaux 92800 497 France 499 Email: remi.theillaud@marben-products.com 501 Copyright Notice 503 Copyright (c) 2010 IETF Trust and the persons identified as the 504 document authors. All rights reserved. 506 This document is subject to BCP 78 and the IETF Trust's Legal 507 Provisions Relating to IETF Documents 508 (http://trustee.ietf.org/license-info) in effect on the date of 509 publication of this document. Please review these documents 510 carefully, as they describe your rights and restrictions with 511 respect to this document.