idnits 2.17.1 draft-ietf-ccamp-rwa-info-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 22. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 694. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 671. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 678. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 684. 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 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 3, 2008) is 5646 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'G.7715' is mentioned on line 234, but not defined == Missing Reference: 'G.sup39' is mentioned on line 349, but not defined == Unused Reference: 'G.Sup39' is defined on line 584, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-farrel-rtg-common-bnf-07 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group G. Bernstein 2 Internet Draft Grotto Networking 3 Intended status: Informational Y. Lee 4 Expires: May 2009 D. Li 5 Huawei 6 W. Imajuku 7 NTT 9 November 3, 2008 11 Routing and Wavelength Assignment Information Model for Wavelength 12 Switched Optical Networks 14 draft-ietf-ccamp-rwa-info-01.txt 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that 19 any applicable patent or other IPR claims of which he or she is 20 aware have been or will be disclosed, and any of which he or she 21 becomes aware will be disclosed, in accordance with Section 6 of 22 BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html 40 This Internet-Draft will expire on May 3, 2007. 42 Copyright Notice 44 Copyright (C) The IETF Trust (2008). 46 Abstract 48 This document provides a model of information needed by the routing 49 and wavelength assignment (RWA) process in wavelength switched 50 optical networks (WSONs). The purpose of the information described 51 in this model is to facilitate constrained lightpath computation in 52 WSONs, particularly in cases where there are no or a limited number 53 of wavelength converters available. This model currently does not 54 include optical impairments. 56 Table of Contents 58 1. Introduction...................................................3 59 2. Terminology....................................................3 60 3. Routing and Wavelength Assignment Information Model............4 61 3.1. Dynamic and Relatively Static Information.................4 62 3.2. Node Information..........................................4 63 3.2.1. Switched Connectivity Matrix.........................5 64 3.2.2. Fixed Connectivity Matrix............................5 65 3.2.3. Shared Risk Node Group...............................6 66 3.2.4. Wavelength Converter Pool............................6 67 3.2.4.1. OEO Wavelength Converter Info...................9 68 3.3. Link Information..........................................9 69 3.3.1. Link ID.............................................10 70 3.3.2. Administrative Group................................10 71 3.3.3. Interface Switching Capability Descriptor...........10 72 3.3.4. Link Protection Type (for this link)................10 73 3.3.5. Shared Risk Link Group Information..................10 74 3.3.6. Traffic Engineering Metric..........................11 75 3.3.7. Maximum Bandwidth Per Channel.......................11 76 3.3.8. Switched and Fixed Port Wavelength Restrictions.....11 77 3.4. Dynamic Link Information.................................12 78 3.5. Dynamic Node Information.................................12 79 4. Security Considerations.......................................13 80 5. IANA Considerations...........................................13 81 6. Acknowledgments...............................................13 82 7. References....................................................14 83 7.1. Normative References.....................................14 84 7.2. Informative References...................................14 85 8. Contributors..................................................15 86 Author's Addresses...............................................16 87 Intellectual Property Statement..................................16 88 Disclaimer of Validity...........................................17 90 1. Introduction 92 The purpose of the following information model for WSONs is to 93 facilitate constrained lightpath computation and as such is not a 94 general purpose network management information model. In particular 95 this model has particular value in the cases where there are no or a 96 limited number of wavelength converters available in the WSON. This 97 constraint is frequently referred to as the "wavelength continuity" 98 constraint, and the corresponding constrained lightpath computation 99 is known as the routing and wavelength assignment (RWA) problem. 100 Hence the information model must provide sufficient topology and 101 wavelength restriction and availability information to support this 102 computation. More details on the RWA process and WSON subsystems and 103 their properties can be found in [WSON-Frame]. The model defined here 104 does not currently include impairments however optical impairments 105 can be accommodated by the general framework presented here. 107 2. Terminology 109 CWDM: Coarse Wavelength Division Multiplexing. 111 DWDM: Dense Wavelength Division Multiplexing. 113 FOADM: Fixed Optical Add/Drop Multiplexer. 115 ROADM: Reconfigurable Optical Add/Drop Multiplexer. A reduced port 116 count wavelength selective switching element featuring ingress and 117 egress line side ports as well as add/drop side ports. 119 RWA: Routing and Wavelength Assignment. 121 Wavelength Conversion. The process of converting an information 122 bearing optical signal centered at a given wavelength to one with 123 "equivalent" content centered at a different wavelength. Wavelength 124 conversion can be implemented via an optical-electronic-optical (OEO) 125 process or via a strictly optical process. 127 WDM: Wavelength Division Multiplexing. 129 Wavelength Switched Optical Network (WSON): A WDM based optical 130 network in which switching is performed selectively based on the 131 center wavelength of an optical signal. 133 3. Routing and Wavelength Assignment Information Model 135 We group the following WSON RWA information model into four 136 categories regardless of whether they stem from a switching subsystem 137 or from a line subsystem: 139 o Node Information 141 o Link Information 143 o Dynamic Node Information 145 o Dynamic Link Information 147 Note that this is roughly the categorization used in [G.7715] section 148 7. 150 In the following we use where applicable the reduced Backus-Naur form 151 (RBNF) syntax of [RBNF] to aid in defining the RWA information model. 153 3.1. Dynamic and Relatively Static Information 155 All the RWA information of concern in a WSON network is subject to 156 change over time. Equipment can be upgraded; links may be placed in 157 or out of service and the like. However, from the point of view of 158 RWA computations there is a difference between information that can 159 change with each successive connection establishment in the network 160 and that information that is relatively static on the time scales of 161 connection establishment. A key example of the former is link 162 wavelength usage since this can change with connection setup/teardown 163 and this information is a key input to the RWA process. Examples of 164 relatively static information are the potential port connectivity of 165 a WDM ROADM, and the channel spacing on a WDM link. 167 In this document we will separate, where possible, dynamic and static 168 information so that these can be kept separate in possible encodings 169 and hence allowing for separate updates of these two types of 170 information thereby reducing processing and traffic load caused by 171 the timely distribution of the more dynamic RWA WSON information. 173 3.2. Node Information 175 The node information described here contains the relatively static 176 information related to a WSON node. This includes connectivity 177 constraints amongst ports and wavelengths since WSON switches can 178 exhibit asymmetric switching properties. Additional information could 179 include properties of wavelength converters in the node if any are 180 present. In [Switch] it was shown that the wavelength connectivity 181 constraints for a large class of practical WSON devices can be 182 modeled via switched and fixed connectivity matrices along with 183 corresponding switched and fixed port constraints. We include these 184 connectivity matrices with our node information the switched and 185 fixed port wavelength constraints with the link information. 187 Formally, 189 ::= [] 190 [], [] [] 192 Where the Node_ID would be an appropriate identifier for the node 193 within the WSON RWA context. 195 3.2.1. Switched Connectivity Matrix 197 The switched connectivity matrix (SwitchConnectivityMatrix) 198 represents the potential connectivity matrix for asymmetric switches 199 (e.g. ROADMs and such). Note that this matrix does not represent any 200 particular internal blocking behavior but indicates which ingress 201 ports and wavelengths could possibly be connected to a particular 202 output port. Representing internal state dependent blocking for a 203 switch or ROADM is beyond the scope of this document and due to its 204 highly implementation dependent nature would not be subject to 205 standardization. This is a conceptual M by N matrix representing the 206 potential switched connectivity, where M represents the number of 207 ingress ports and N the number of egress ports. We say this is a 208 "conceptual" since this matrix tends to exhibit structure that allows 209 for very compact representations that are useful for both 210 transmission and path computation [Encode]. 212 SwitchedConnectivityMatrix(i, j) = 0 or 1 depending on whether 213 ingress port i can connect to egress port j for one or more 214 wavelengths. 216 3.2.2. Fixed Connectivity Matrix 218 The fixed connectivity matrix (FixedConnectivityMatrix) represents 219 the connectivity for asymmetric fixed devices or the fixed part of a 220 "hybrid" device [Switch]. This is a conceptual M by N matrix, where M 221 represents the number of ingress ports and N the number of egress 222 ports. We say this is a "conceptual" since this matrix tends to 223 exhibit structure that allows for very compact representations. 225 FixedConnectivityMatrix(i, j) = 0 or 1 depending on whether ingress 226 port i is connected to egress port j for one or more wavelengths. 228 3.2.3. Shared Risk Node Group 230 SRNG: Shared risk group for nodes. The concept of a shared risk link 231 group was defined in [RFC4202]. This can be used to achieve a desired 232 "amount" of link diversity. It is also desirable to have a similar 233 capability to achieve various degrees of node diversity. This is 234 explained in [G.7715]. Typical risk groupings for nodes can include 235 those nodes in the same building, within the same city, or geographic 236 region. 238 3.2.4. Wavelength Converter Pool 240 A WSON node may include wavelength converters. These are usually 241 arranged into some type of pool to promote resource sharing. There 242 are a number of different approaches used in the design of switches 243 with converter pools. However, from the point of view of path 244 computation we need to know the following: 246 1. The nodes that support wavelength conversion. 248 2. The accessibility and availability of a wavelength converter to 249 convert from a given ingress wavelength on a particular ingress 250 port to a desired egress wavelength on a particular egress port. 252 3. Limitations on the types of signals that can be converted and the 253 conversions that can be performed. 255 To model point 2 above we can use a similar technique as used to 256 model ROADMs and optical switches this technique was generally 257 discussed in [WSON-Frame] and consisted of a matrix to indicate 258 possible connectivity along with wavelength constraints for 259 links/ports. Since wavelength converters are considered a scarce 260 resource we will also want to our model to include as a minimum the 261 usage state of individual wavelength converters in the pool. Models 262 that incorporate more state to further reveal blocking conditions on 263 ingress or egress to particular converters are for further study. 265 We utilize a three stage model as shown schematically in Figure 1. In 266 this model we assume N ingress ports (fibers), P wavelength 267 converters, and M egress ports (fibers). Since not all ingress ports 268 can necessarily reach the converter pool, the model starts with a 269 wavelength pool ingress matrix WI(i,p) = {0,1} whether ingress port i 270 can reach potentially reach wavelength converter p. 272 Since not all wavelength can necessarily reach all the converters or 273 the converters may have limited input wavelength range we have a set 274 of ingress port constraints for each wavelength converter. Currently 275 we assume that a wavelength converter can only take a single 276 wavelength on input. We can model each wavelength converter ingress 277 port constraint via a wavelength set mechanism. 279 Next we have a state vector WC(j) = {0,1} dependent upon whether 280 wavelength converter j in the pool is in use. This is the only state 281 kept in the converter pool model. This state is not necessary for 282 modeling "fixed" transponder system, i.e., systems where there is no 283 sharing. In addition, this state information may be encoded in a 284 much more compact form depending on the overall connectivity 285 structure [WC-Pool]. 287 After that, we have a set of wavelength converter egress wavelength 288 constraints. These constraints indicate what wavelengths a particular 289 wavelength converter can generate or are restricted to generating due 290 to internal switch structure. 292 Finally, we have a wavelength pool egress matrix WE(p,k) = {0,1} 293 depending on whether the output from wavelength converter p can reach 294 egress port k. Examples of this method being used to model wavelength 295 converter pools for several switch architectures from the literature 296 are given in reference [WC-Pool]. 298 I1 +-------------+ +-------------+ E1 299 ----->| | +--------+ | |-----> 300 I2 | +------+ WC #1 +-------+ | E2 301 ----->| | +--------+ | |-----> 302 | Wavelength | | Wavelength | 303 | Converter | +--------+ | Converter | 304 | Pool +------+ WC #2 +-------+ Pool | 305 | | +--------+ | | 306 | Ingress | | Egress | 307 | Connection | . | Connection | 308 | Matrix | . | Matrix | 309 | | . | | 310 | | | | 311 IN | | +--------+ | | EM 312 ----->| +------+ WC #P +-------+ |-----> 313 | | +--------+ | | 314 +-------------+ ^ ^ +-------------+ 315 | | 316 | | 317 | | 318 | | 320 Ingress wavelength Egress wavelength 321 constraints for constraints for 322 each converter each converter 324 Figure 1 Schematic diagram of wavelength converter pool model. 326 Formally we can specify the model as: 328 ::= 329 [] 330 331 Note that except for all the other components of 332 are relatively static. In addition 333 is a relatively small structure compared potentially to 334 the others and hence in a future revision of this document maybe 335 moved to a new section on dynamic node information. 337 3.2.4.1. OEO Wavelength Converter Info 339 An OEO based wavelength converter can be characterized by an input 340 wavelength set and an output wavelength set. In addition any 341 constraints on the signal formats and rates accommodated by the 342 converter must be described. Such a wavelength converter can be 343 modeled by: 345 ::= [] 346 [] 348 Where the RegeneratorType is used to model an OEO regenerator. 349 Regenerators are usually classified into three types [G.sup39]. Level 350 1 provides signal amplification, level 2 amplification and pulse 351 shaping, and level 3 amplification, pulse shaping and timing 352 regeneration. Level 2 regenerators can have a restricted bit rate 353 range, while level 3 regenerators can also be specialized to a 354 particular signal type. 356 BitRateRange: indicates the range of bit rates that can be 357 accommodated by the wavelength converter. 359 AcceptableSignals: is a list of signals that the wavelength converter 360 can handle. This could be fairly general for Level 1 and Level 2 361 regenerators, e.g., characterized by general signal properties such 362 as modulation type and related parameters, or fairly specific signal 363 types for Level 3 based regenerators. 365 3.3. Link Information 367 MPLS-TE routing protocol extensions for OSPF and IS-IS [RFC3630], 368 [RFC5305] along with GMPLS routing protocol extensions for OSPF and 369 IS-IS [RFC4203, RFC5307] provide the bulk of the relatively static 370 link information needed by the RWA process. WSON networks bring in 371 additional link related constraints. These stem from WDM line system 372 characterization, laser transmitter tuning restrictions, and 373 switching subsystem port wavelength constraints, e.g., colored ROADM 374 drop ports. 376 In the following summarize both information from existing route 377 protocols and new information that maybe needed by the RWA process. 379 ::= [] [] 380 [] []... [] 381 [] <[SwitchedPortWavelengthRestriction>] 382 [] 384 3.3.1. Link ID 386 ::= 387 389 Here we can generally identify a link via a combination of local and 390 remote node identifiers along with the corresponding local and remote 391 link identifiers per [RFC4202, RFC4203, RFC5307]. Note that reference 392 [RFC3630] provides other ways to identify local and remote link ends 393 in the case of numbered links. 395 3.3.2. Administrative Group 397 AdministrativeGroup: Defined in [RFC3630]. Each set bit corresponds 398 to one administrative group assigned to the interface. A link may 399 belong to multiple groups. This is a configured quantity and can be 400 used to influence routing decisions. 402 3.3.3. Interface Switching Capability Descriptor 404 InterfaceSwCapDesc: Defined in [RFC4202], lets us know the different 405 switching capabilities on this GMPLS interface. In both [RFC4203] and 406 [RFC5307] this information gets combined with the maximum LSP 407 bandwidth that can be used on this link at eight different priority 408 levels. 410 3.3.4. Link Protection Type (for this link) 412 Protection: Defined in [RFC4202] and implemented in [RFC4203, 413 RFC5307]. Used to indicate what protection, if any, is guarding this 414 link. 416 3.3.5. Shared Risk Link Group Information 418 SRLG: Defined in [RFC4202] and implemented in [RFC4203, RFC5307]. 419 This allows for the grouping of links into shared risk groups, i.e., 420 those links that are likely, for some reason, to fail at the same 421 time. 423 3.3.6. Traffic Engineering Metric 425 TrafficEngineeringMetric: Defined in [RFC3630]. This allows for the 426 definition of one additional link metric value for traffic 427 engineering separate from the IP link state routing protocols link 428 metric. Note that multiple "link metric values" could find use in 429 optical networks, however it would be more useful to the RWA process 430 to assign these specific meanings such as link mile metric, or 431 probability of failure metric, etc... 433 3.3.7. Maximum Bandwidth Per Channel 435 TBD: Need to check if we still want this. 437 3.3.8. Switched and Fixed Port Wavelength Restrictions 439 Switch and fixed port wavelength restrictions 440 (SwitchedPortWavelengthRestriction, FixedPortWavelengthRestriction) 441 model the wavelength restrictions that various optical devices such 442 as OXCs, ROADMs, and waveband mulitplexers may impose on a port. This 443 plays an important role in fully characterizing a WSON switching 444 device [Switch]. The SwitchedPortWavelengthRestriction is used with 445 ports specified in the SwitchedConnectivityMatrix while the 446 FixedPortWavelengthRestriction is used with ports specified in the 447 FixedConnectivityMatrix. Reference [Switch] gives an example where 448 both switch and fixed connectivity matrices are used and both types 449 of constraints occur on the same port. 451 ::= 453 ::= 455 ::= 456 458 ::= []... 460 Where WavelengthSet is a conceptual set of wavelengths, 461 MaxNumChannels is the number of channels permitted on the port, and 462 RestrictionKind can take the following values and meanings: 464 SIMPLE: Simple wavelength selective restriction. Max number of 465 channels indicates the number of wavelengths permitted on the port 466 and the accompanying wavelength set indicates the permitted values. 468 WAVEBAND1: Waveband device with a tunable center frequency and 469 passband. In this case the maximum number of channels indicates the 470 maximum width of the waveband in terms of the channels spacing given 471 in the wavelength set. The corresponding wavelength set is used to 472 indicate the overall tuning range. Specific center frequency tuning 473 information can be obtained from dynamic channel in use information. 474 It is assumed that both center frequency and bandwidth (Q) tuning can 475 be done without causing faults in existing signals. 477 For example, if the port is a "colored" drop port of a ROADM then the 478 value of RestrictionKind = SIMPLE for a simple wavelength selective 479 restriction, the MaxNumberOfChannels = 1, and the wavelength 480 restriction is just a wavelength set consisting of a single member 481 corresponding to the frequency of the permitted wavelength. See 482 [Switch] for a complete waveband example. 484 3.4. Dynamic Link Information 486 By dynamic information we mean information that is subject to change 487 on a link with subsequent connection establishment or teardown. 488 Currently for WSON the only information we currently envision is 489 wavelength availability and wavelength in use for shared backup 490 purposes. 492 ::= 493 [] 495 Where 497 ::= 498 500 AvailableWavelengths is a set of wavelengths available on the link. 502 SharedBackupWavelengths is a set of wavelengths currently used for 503 shared backup protection on the link. An example usage of this 504 information in a WSON setting is given in [Shared]. 506 3.5. Dynamic Node Information 508 Dynamic node information is used to hold information for a node that 509 can change frequently. Currently only wavelength converter pool 510 information is included as a possible (but not required) information 511 sub-element. 513 ::= [] 514 Where NodeID is a node identifier and the exact form of the 515 wavelength converter pool status information is TBD. 517 4. Security Considerations 519 This document discussed an information model for RWA computation in 520 WSONs. Such a model is very similar from a security standpoint of the 521 information that can be currently conveyed via GMPLS routing 522 protocols. Such information includes network topology, link state 523 and current utilization, and well as the capabilities of switches and 524 routers within the network. As such this information should be 525 protected from disclosure to unintended recipients. In addition, the 526 intentional modification of this information can significantly affect 527 network operations, particularly due to the large capacity of the 528 optical infrastructure to be controlled. 530 5. IANA Considerations 532 This informational document does not make any requests for IANA 533 action. 535 6. Acknowledgments 537 This document was prepared using 2-Word-v2.0.template.dot. 539 7. References 541 7.1. Normative References 543 [Encode] Reference the encoding draft here. 545 [RBNF] A. Farrel, "Reduced Backus-Naur Form (RBNF) A Syntax Used in 546 Various Protocol Specifications", work in progress: draft- 547 farrel-rtg-common-bnf-07.txt, October 2008. 549 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 550 (TE) Extensions to OSPF Version 2", RFC 3630, September 551 2003. 553 [RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing Extensions 554 in Support of Generalized Multi-Protocol Label Switching 555 (GMPLS)", RFC 4202, October 2005 557 [RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions in 558 Support of Generalized Multi-Protocol Label Switching 559 (GMPLS)", RFC 4203, October 2005. 561 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 562 Engineering", RFC 5305, October 2008. 564 [RFC5307] Kompella, K., Ed., and Y. Rekhter, Ed., "IS-IS Extensions 565 in Support of Generalized Multi-Protocol Label Switching 566 (GMPLS)", RFC 5307, October 2008. 568 [WSON-Frame] G. Bernstein, Y. Lee, W. Imajuku, "Framework for GMPLS 569 and PCE Control of Wavelength Switched Optical Networks", 570 work in progress: draft-ietf-ccamp-wavelength-switched- 571 framework-01.txt, October 2008. 573 7.2. Informative References 575 [Shared] G. Bernstein, Y. Lee, "Shared Backup Mesh Protection in PCE- 576 based WSON Networks", iPOP 2008, http://www.grotto- 577 networking.com/wson/iPOP2008_WSON-shared-mesh-poster.pdf . 579 [Switch] G. Bernstein, Y. Lee, A. Gavler, J. Martensson, " Modeling 580 WDM Wavelength Switching Systems for use in Automated Path 581 Computation", http://www.grotto- 582 networking.com/wson/ModelingWSONswitchesV2a.pdf , June, 2008 584 [G.Sup39] ITU-T Series G Supplement 39, Optical system design and 585 engineering considerations, February 2006. 587 [WC-Pool] G. Bernstein, Y. Lee, "Modeling WDM Switching Systems 588 including Wavelength Converters" to appear www.grotto- 589 networking.com, 2008. 591 8. Contributors 593 Diego Caviglia 594 Ericsson 595 Via A. Negrone 1/A 16153 596 Genoa Italy 598 Phone: +39 010 600 3736 599 Email: diego.caviglia@(marconi.com, ericsson.com) 601 Anders Gavler 602 Acreo AB 603 Electrum 236 604 SE - 164 40 Kista Sweden 606 Email: Anders.Gavler@acreo.se 608 Jonas Martensson 609 Acreo AB 610 Electrum 236 611 SE - 164 40 Kista, Sweden 613 Email: Jonas.Martensson@acreo.se 615 Itaru Nishioka 616 NEC Corp. 617 1753 Simonumabe, Nakahara-ku, Kawasaki, Kanagawa 211-8666 618 Japan 620 Phone: +81 44 396 3287 621 Email: i-nishioka@cb.jp.nec.com 623 Lyndon Ong 624 Ciena 625 Email: lyong@ciena.com 627 Author's Addresses 629 Greg M. Bernstein (ed.) 630 Grotto Networking 631 Fremont California, USA 633 Phone: (510) 573-2237 634 Email: gregb@grotto-networking.com 636 Young Lee (ed.) 637 Huawei Technologies 638 1700 Alma Drive, Suite 100 639 Plano, TX 75075 640 USA 642 Phone: (972) 509-5599 (x2240) 643 Email: ylee@huawei.com 645 Dan Li 646 Huawei Technologies Co., Ltd. 647 F3-5-B R&D Center, Huawei Base, 648 Bantian, Longgang District 649 Shenzhen 518129 P.R.China 651 Phone: +86-755-28973237 652 Email: danli@huawei.com 654 Wataru Imajuku 655 NTT Network Innovation Labs 656 1-1 Hikari-no-oka, Yokosuka, Kanagawa 657 Japan 659 Phone: +81-(46) 859-4315 660 Email: imajuku.wataru@lab.ntt.co.jp 662 Intellectual Property Statement 664 The IETF takes no position regarding the validity or scope of any 665 Intellectual Property Rights or other rights that might be claimed to 666 pertain to the implementation or use of the technology described in 667 this document or the extent to which any license under such rights 668 might or might not be available; nor does it represent that it has 669 made any independent effort to identify any such rights. Information 670 on the procedures with respect to rights in RFC documents can be 671 found in BCP 78 and BCP 79. 673 Copies of IPR disclosures made to the IETF Secretariat and any 674 assurances of licenses to be made available, or the result of an 675 attempt made to obtain a general license or permission for the use of 676 such proprietary rights by implementers or users of this 677 specification can be obtained from the IETF on-line IPR repository at 678 http://www.ietf.org/ipr. 680 The IETF invites any interested party to bring to its attention any 681 copyrights, patents or patent applications, or other proprietary 682 rights that may cover technology that may be required to implement 683 this standard. Please address the information to the IETF at 684 ietf-ipr@ietf.org. 686 Disclaimer of Validity 688 This document and the information contained herein are provided on an 689 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 690 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 691 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 692 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 693 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 694 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 696 Copyright Statement 698 Copyright (C) The IETF Trust (2008). 700 This document is subject to the rights, licenses and restrictions 701 contained in BCP 78, and except as set forth therein, the authors 702 retain all their rights. 704 Acknowledgment 706 Funding for the RFC Editor function is currently provided by the 707 Internet Society.