idnits 2.17.1 draft-bernstein-ccamp-wson-info-02.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 21. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1009. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 986. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 993. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 999. 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 (February 20, 2008) is 5909 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) == Unused Reference: 'G.694.1' is defined on line 895, but no explicit reference was found in the text == Unused Reference: 'G.694.2' is defined on line 898, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'G.694.1' == Outdated reference: A later version (-02) exists of draft-otani-ccamp-gmpls-lambda-labels-01 -- Obsolete informational reference (is this intentional?): RFC 4205 (Obsoleted by RFC 5307) == Outdated reference: A later version (-03) exists of draft-bernstein-ccamp-wavelength-switched-02 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Greg Bernstein 2 Internet Draft Grotto Networking 3 Intended status: Standards Track Young Lee 4 Expires: August 2008 Dan Li 5 Huawei 6 Wataru Imajuku 7 NTT 9 February 20, 2008 11 Routing and Wavelength Assignment Information for Wavelength 12 Switched Optical Networks 13 draft-bernstein-ccamp-wson-info-02.txt 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that 18 any applicable patent or other IPR claims of which he or she is 19 aware have been or will be disclosed, and any of which he or she 20 becomes aware will be disclosed, in accordance with Section 6 of 21 BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html 39 This Internet-Draft will expire on August 20, 2008. 41 Copyright Notice 43 Copyright (C) The IETF Trust (2008). 45 Abstract 46 This memo provides and information model and compact encodings for 47 information needed for path computation and wavelength assignment in 48 wavelength switched optical networks. Such encodings can be used in 49 extensions to Generalized Multi-Protocol Label Switching (GMPLS) 50 routing for control of wavelength switched optical networks (WSON) or 51 for other mechanisms, e.g. XML based, for conveying this information 52 to a path computation element. 54 Conventions used in this document 56 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 57 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 58 document are to be interpreted as described in RFC-2119 [RFC2119]. 60 Table of Contents 62 1. Introduction...................................................3 63 2. Terminology....................................................3 64 3. High Level Information Model...................................4 65 3.1. Information Model.........................................4 66 3.2. Node Information..........................................5 67 3.2.1. ConnectivityMatrix...................................5 68 3.2.2. OEOWavelengthConverterInfo...........................6 69 3.3. Link Information..........................................6 70 3.3.1. Port Wavelength Restrictions.........................7 71 3.4. Dynamic Link Information..................................7 72 3.5. Dynamic Node Information..................................8 73 3.6. End System Information....................................8 74 4. Application to OSPF GMPLS extensions...........................8 75 4.1. Node Top Level TLV........................................8 76 4.2. Link Sub-TLVs.............................................9 77 4.3. Dealing with Dynamic Information..........................9 78 5. Type Length Value (TLV) Encoding of WSON Information...........9 79 5.1. Wavelength Information Encoding..........................10 80 5.2. Link Set Sub-TLV.........................................10 81 5.3. Wavelength Set Sub-TLV...................................12 82 5.3.1. Inclusive/Exclusive Wavelength Lists................13 83 5.3.2. Inclusive/Exclusive Wavelength Ranges...............14 84 5.3.3. Bitmap Wavelength Set...............................14 85 5.4. Connectivity Matrix Sub-TLV..............................15 86 5.5. Port Wavelength Restriction sub-TLV......................19 87 6. Security Considerations.......................................20 88 7. IANA Considerations...........................................20 89 8. Acknowledgments...............................................20 90 9. References....................................................21 91 9.1. Normative References.....................................21 92 9.2. Informative References...................................21 93 10. Contributors.................................................22 94 Author's Addresses...............................................22 95 Intellectual Property Statement..................................23 96 Disclaimer of Validity...........................................24 98 1. Introduction 100 This document provides an information model and efficient encodings 101 of information needed by the routing and wavelength assignment (RWA) 102 process in wavelength switched optical networks (WSONs). Such 103 encodings can be to extend GMPLS IGPs. In addition these encodings or 104 information could be used by other mechanisms to convey this same 105 information to a path computation element (PCE). Note since these 106 encodings are relatively efficient they can provide more accurate 107 analysis of the control plane communications/processing load for 108 WSONs looking to utilize a GMPLS control plane. 110 2. Terminology 112 CWDM: Coarse Wavelength Division Multiplexing. 114 DWDM: Dense Wavelength Division Multiplexing. 116 FOADM: Fixed Optical Add/Drop Multiplexer. 118 ROADM: Reconfigurable Optical Add/Drop Multiplexer. A reduced port 119 count wavelength selective switching element featuring ingress and 120 egress line side ports as well as add/drop side ports. 122 RWA: Routing and Wavelength Assignment. 124 Wavelength Conversion/Converters: The process of converting an 125 information bearing optical signal centered at a given wavelength to 126 one with "equivalent" content centered at a different wavelength. 127 Wavelength conversion can be implemented via an optical-electronic- 128 optical (OEO) process or via a strictly optical process. 130 WDM: Wavelength Division Multiplexing. 132 Wavelength Switched Optical Networks (WSON): WDM based optical 133 networks in which switching is performed selectively based on the 134 center wavelength of an optical signal. 136 3. High Level Information Model 138 The purpose of the following information model and encodings for 139 WSONs is to facilitate constrained lightpath computation. In 140 particular, the cases of no or a limited number of wavelength 141 converters available in the WSON. This constraint is frequently 142 referred to as the "wavelength continuity" constraint, and the 143 corresponding constrained lightpath computation is known as the 144 routing and wavelength assignment (RWA) problem. Hence the 145 information model must provide sufficient topology and wavelength 146 restriction and availability information to support this computation. 147 More details on the RWA process and WSON subsystems and their 148 properties can be found in [WSON-Frame]. 150 3.1. Information Model 152 From [WSON-Frame] the following WSON information needs to be conveyed 153 via GMPLS routing or some other mechanism. 155 Information Static/Dynamic 156 --------------------------------------------------------- 157 Connectivity matrix Static 158 Per port wavelength restrictions Static(2) 159 WDM link (fiber) lambda ranges Static(2) 160 WDM link channel spacing Static(2) 161 Laser Transmitter range Static(2) 162 Wavelength conversion capabilities Static(2) 163 Wavelength Availability Dynamic(2) 164 Wavelength Converter availability Dynamic(1,2) 166 Notes: 168 1. This could be dynamic in the case of a limited pool of converters 169 where the number available can change with connection 170 establishment. Note we may want to include regeneration 171 capabilities here since OEO converters are also regenerators. 173 2. Not necessarily needed in the case of distributed wavelength 174 assignment via signaling. 176 See [WSON-Frame] for more details on these types of WSON information 177 and their use. 179 For the purposes of conveying the information we can group the 180 information model into four categories regardless of whether they 181 stem from a switching subsystem or a line subsystem: 183 o Node Information 184 o Link Information 186 o Dynamic Node Information 188 o Dynamic Link Information 190 o End System Information 192 In the following we use a BNF/Regular expression like syntax where 193 the symbol "|" indicates a choice between two or more elements; the 194 symbol "*" indicates zero or more occurrences of an element; the 195 symbol "?" indicates zero or one occurrences; and the symbol "+" 196 indicates one or more occurrences. 198 3.2. Node Information 200 Node information contains relatively static information related to a 201 WSON node. This includes internal information such as a connectivity 202 matrix and port wavelength constraints. Additional information could 203 include properties of wavelength converters in the node if any are 204 present. 206 Formally, 208 Node Information := Node_ID (ConnectivityMatrix?, 209 OEOWavelengthConverterInfo? ) 211 Where the Node_ID would be a "Router ID" in OSPFv2. 213 3.2.1. ConnectivityMatrix 215 The ConnectivityMatrix represents the potential connectivity matrix 216 for asymmetric switches (e.g. ROADMs and such) and the connectivity 217 matrix for asymmetric fixed devices. The following provides a compact 218 representation of the connectivity via a list of pairs of link sets 219 that have connectivity to each other. 221 ConnectivityMatrix := ConnectivityFixed (LinkSetA, LinkSetB)+ 223 Where ConnectivityFixed is a Boolean that takes the value true if the 224 device has fixed connectivity and false if the device is a switch or 225 ROADM. LinkSets are defined in Section 5.2. Only two valid 226 combinations of link sets A and B are permitted. In the first case 227 LinkSetA is a set of ingress links and LinkSetB is a set of egress 228 links. In the second case LinkSetA and LinkSetB are both bi- 229 directional link sets. 231 3.2.2. OEOWavelengthConverterInfo 233 An OEO based wavelength converter can be characterized by an input 234 wavelength set and an output wavelength set. In addition any 235 constraints on the signal formats and rates accommodated by the 236 converter must be described. Such a wavelength converter can be 237 modeled by: 239 OEOWavelengthConverterInfo := RegeneratorLevel 240 (IngressWavelengthRange, EgressWavelengthRange, BitRateRange?, 241 AcceptableSignals? ) 243 Where the RegeneratorLevel is used to model an OEO regenerator. 244 Regenerators are usually classified into three levels. Level 1 245 provides signal amplification, level 2 amplification and pulse 246 shaping, and level 3 amplification, pulse shaping and timing 247 regeneration. Level 2 regenerators can have a restricted bit rate 248 range, while level 3 regenerators can also be specialized to a 249 particular signal type. For ingress and egress wavelength ranges see 250 the WavelengthSet definition in section 5.3. 252 3.3. Link Information 254 WSONs contribute information in addition to that in RFC3630 (OSPF-TE) 255 and RFC4203 (OSPF for GMPLS) via additional link constraints. These 256 stem from (a) WDM line system characterization, laser transmitter 257 tuning restrictions, and switching subsystem port wavelength 258 constraints, e.g., colored ROADM drop ports. 260 As described below we add two new sub-elements to the link 261 information model derived from [RFC3630, RFC4203]: (a) the maximum 262 number of channels, and (b) link wavelength restrictions. Note that 263 network topology information is implicit in the link information 264 element. 266 LinkInfo := LocalLinkID LocalNodeID RemoteLinkID RemoteNodeID 267 (AdministrativeGroup?, InterfaceCapDesc?, 268 MaximumBandwidthPerChannel?, Protection?, SRLG*, 269 TrafficEngineeringMetric?, PortWavelengthRestriction?) 271 Note that RFC3630 provides other ways to identify local and remote 272 link ends in the case of numbered links. In the above we have 273 reinterpreted the Maximum Bandwidth of RFC3630 as the maximum 274 bandwidth per WDM channel and have omitted the Maximum Reservable 275 Bandwidth of RFC3630 since overbooking is not typically used in 276 circuit switching for obvious reasons. In addition we propose an 277 alternative to the Unreserved Bandwidth of RFC3630 in the next 278 section. 280 3.3.1. Port Wavelength Restrictions 282 Models the wavelength restrictions that various optical devices such 283 as OXC, ROADMs, and waveband mulitplers may impose on a port. 285 PortWavelengthRestriction := (RestrictionKind, MaxNumChannels, 286 WavelengthSet ) 288 Where RestrictionKind can take the following values and meanings: 290 0 Simple wavelength selective restriction. Max number of channels 291 indicates the number of wavelength permitted on the port and the 292 accompanying wavelength set indicates the permitted values. 294 1 Waveband device with a tunable center frequency and passband. In 295 this case the maximum number of channels indicates the maximum width 296 of the waveband in terms of the channels spacing given in the 297 wavelength set. The corresponding wavelength set is used to indicate 298 the overall tuning range. Specific center frequency tuning 299 information can be obtained from dynamic channel in use information. 300 It is assumed that both center frequency and bandwidth (Q) tuning can 301 be done without causing faults in existing signals. 303 A 16 bit non-negative integer would suffice for the maximum number of 304 channels. For example if the port is a "colored" drop port of a ROADM 305 then the value of RestrictionKind = 0 for a simple wavelength 306 selective restriction, the MaxNumberOfChannels = 1, and the 307 wavelength restriction is just a wavelength set consisting of a 308 single member corresponding to the frequency of the permitted 309 wavelength. 311 3.4. Dynamic Link Information 313 By dynamic information we mean information that is subject to change 314 on a link with subsequent connection establishment or teardown. 315 Currently for WSON the only information we currently envision is 316 wavelength availability. 318 DynamicLinkInfo := LocalLinkID LocalNodeID RemoteLinkID 319 RemoteNodeID AvailableWavelengths 321 Where, once again, the local and remote link and node IDs are used to 322 specify the particular link in the unnumbered case and 323 AvailableWavelengths is a WavelengthSet as defined in Section 5.3. 325 3.5. Dynamic Node Information 327 Dynamic node information is used to hold information for a node that 328 can change frequently. Currently only wavelength converter 329 availability information is included as a possible (but not required) 330 information sub-element. 332 DynamicNodeInfo := NodeID AvailableWavelengthConverters? 334 Where NodeID is a node identifier such as the router ID in OSPFv2 and 335 the number of currently available wavelength converters is given by 336 AvailableWavelengthConverters. 338 3.6. End System Information 340 Current end system information of interest includes the tuning range 341 of laser transmitters, support or single or multiple wavelengths on a 342 port, etc... 344 4. Application to OSPF GMPLS extensions 346 RFC2370 defined the opaque link state advertisement (LSA) and its 347 various flavors based on flooding scope. RFC3630 defines the Traffic 348 Engineering (TE) LSA which is an opaque LSA of area flooding scope 349 with an LSA ID defined by: 351 0 1 2 3 352 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 | 1 | Instance | 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 "The Instance field is an arbitrary value used to maintain multiple 358 Traffic Engineering LSAs. A maximum of 16777216 Traffic Engineering 359 LSAs may be sourced by a single system. The LSA ID has no 360 topological significance." [RFC3630] 362 From RFC3630 the TE LSA can contain only one top level TLV and 363 RFC3630 defines two top level TLVs: (a) router address, and (b) link. 364 RFC4203 adds new sub-TLVs to the top level link TLV to support GMPLS, 365 but does not add any new top level TLVs. 367 4.1. Node Top Level TLV 369 As we saw in section 3.2. for WSON networks there can be a 370 significant amount of information specific to nodes in WSON networks 371 hence we recommend the addition of a new top level TE TLV (e.g. type 372 5) for holding node related information. Currently we have defined 373 two sub-TLVs for the Node TLV: (a) Connectivity Matrix sub-TLV, (b) 374 OEO Wavelength converter information sub-TLV. 376 4.2. Link Sub-TLVs 378 As discussed in section 3.3. two new sub-TLVs are needed to 379 characterize WSON links: (a) Maximum number of channels sub-TLV and, 380 (b) wavelength constraints sub-TLV. 382 4.3. Dealing with Dynamic Information 384 In our information model we differentiated between relatively static 385 and dynamic information; defining dynamic information as that 386 information that is subject to change due to connection setup or 387 teardown. There are three ways that we could differentiate dynamic 388 from static information in flooding and processing, if desired. 390 A. Use a separate TE LSA instance for static and dynamic information 391 for the same modeled entity. For example, one could group all the 392 relatively static information concerning a specific link into one 393 instance and the wavelength availability information (subTLV of 394 the link TLV) into another TE LSA instance. 396 B. Use separate top level TLVs to differentiate static and dynamic 397 information. For example define a top level "dynamic link" TLV. 399 C. Define a new "dynamic TE LSA" type (e.g. opaque type 5) 400 specifically for conveying dynamic information 402 These three different options are ordered in reverse of the amount of 403 processing required to tell whether the information is dynamic or 404 not. For example in case (A) one must look all the way into the sub- 405 TLV type to understand that this is dynamic information, while in 406 case (C) this can easily be inferred from the LSA ID. Note that for 407 high level LSA processing the LSA ID is the finest granularity field 408 that would be looked at. 410 5. Type Length Value (TLV) Encoding of WSON Information 412 A TLV encoding of the high level WSON information model is given in 413 the following sections. This encoding is designed to be suitable for 414 use in routing protocols such as OSPFv2 via the extension mechanisms 415 of RFC2370 (opaque LSA), RFC3630 (OSPF-TE) and RFC4203 (OSPF-GMPLS), 416 and in PCE protocols such as PCEP. Note that the information in 417 RFC3630 and RFC4203 is arranged via the nesting of sub-TLVs within 418 TLVs and we will make use of such constructs. 420 The following encodings have multiple uses in specifying WSON 421 information. 423 5.1. Wavelength Information Encoding 425 This document makes frequent use of the lambda label format defined 426 in [Otani] shown below: 428 0 1 2 3 429 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 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 |Grid | C.S. |S| Reserved | n | 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 Where 435 Grid is used to indicate which ITU-T grid specification is being 436 used. 438 C.S. = Channel spacing used in a DWDM system, i.e., with a ITU-T 439 G.694.1 grid. 441 S = sign of the offset from the center frequency of 193.1THz for the 442 ITU-T 6.694.1 grid. 444 n = Used to specify the frequency as 193.1THz +/- n*(channel spacing) 445 where the + or - is chosen based on the sign (S) bit. 447 5.2. Link Set Sub-TLV 449 We will frequently want to describe properties of links. To do so 450 efficiently we can make use of a link set concept similar to the 451 label set concept of [RFC3471]. All links will be denoted by their 452 local link identifier as defined an used in[RFC4202, RFC4203, 453 RFC4205]. 455 The information carried in a Link Set is defined by: 457 0 1 2 3 458 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 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 | Action |Dir| Format | Reserved | 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 | Link Identifier 1 | 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 : : : 465 : : : 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 | Link Identifier N | 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 Action: 8 bits 472 0 - Inclusive List 474 Indicates that the object/TLV contains one or more link elements 475 that are included in the Link Set. 477 1 - Exclusive List 479 Indicates that the object/TLV contains one or more link elements that 480 are excluded from the Link Set. 482 2 - Inclusive Range 484 Indicates that the object/TLV contains a range of links. The 485 object/TLV contains two link elements. The first element indicates 486 the start of the range. The second element indicates the end of the 487 range. A value of zero indicates that there is no bound on the 488 corresponding portion of the range. 490 3 - Exclusive Range 492 Indicates that the object/TLV contains a range of links that are 493 excluded from the Link Set. The object/TLV contains two link 494 elements. The first element indicates the start of the range. The 495 second element indicates the end of the range. A value of zero 496 indicates that there is no bound on the corresponding portion of the 497 range. 499 Dir: Directionality of the Link Set (2 bits) 501 0 -- bidirectional 503 1 -- ingress 504 2 -- egress 506 In optical networks we think in terms of unidirectional as well as 507 bidirectional links. For example wavelength restrictions or 508 connectivity may be much different for an ingress port, than for its 509 "companion" egress port if it has one. Note that "interfaces" such as 510 discussed in the Interfaces MIB are assumed bidirectional, as well as 511 the links of various link state IGPs. 513 Format: The format of the link identifier (6 bits) 515 0 -- Link Local Identifier 517 Others TBD. 519 Reserved: 16 bits 521 This field is reserved. It MUST be set to zero on transmission and 522 MUST be ignored on receipt. 524 Link Identifier: 526 The link identifier represents the port which is being described 527 either for connectivity or wavelength restrictions. This can be the 528 link local identifier of [RFC4202], GMPLS routing, [RFC4203] GMPLS 529 OSPF routing, and [RFC4205] IS-IS GMPLS routing. The use of the link 530 local identifier format can result in more compact WSON encodings 531 when the assignments are done in a reasonable fashion. 533 5.3. Wavelength Set Sub-TLV 535 Wavelength sets come up frequently in WSONs to describe the range of 536 a laser transmitter, the wavelength restrictions on ROADM ports, or 537 the availability of wavelengths on a DWDM link. The general format 538 for a wavelength set is given below. This format uses the Action 539 concept from [RFC3471] with an additional Action to define a "bit 540 map" type of label set. Note that the second 32 bit field is a lambda 541 label in the previously defined format. This provides important 542 information on the WDM grid type and channel spacing that will be 543 used in the compact encodings listed. 545 0 1 2 3 546 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 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 | Action | Reserved | Num Wavelengths | 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 |Grid | C.S. |S| Reserved | n for lowest frequency | 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 | Additional fields as necessary per action | 553 | 555 Action: 557 0 - Inclusive List 559 1 - Exclusive List 561 2 - Inclusive Range 563 3 - Exclusive Range 565 4 - Bitmap Set 567 5.3.1. Inclusive/Exclusive Wavelength Lists 569 In the case of the inclusive/exclusive lists the wavelength set 570 format is given by: 572 0 1 2 3 573 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 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 |Action=0 or 1 | Reserved | Num Wavelengths | 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 |Grid | C.S. |S| Reserved | n for lowest frequency | 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 | n2 | n3 | 580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 581 | ... | 582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 583 | nm | | 584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 585 Where Num Wavelengths tells us the number of wavelength in this 586 inclusive or exclusive list this does not include the initial 587 wavelength in the list hence if the number of wavelengths is odd then 588 zero padding of the last half word is required. 590 5.3.2. Inclusive/Exclusive Wavelength Ranges 592 In the case of inclusive/exclusive ranges the wavelength set format 593 is given by: 595 0 1 2 3 596 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 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 |Action=2 or 3 | Reserved | Num Wavelengths | 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 |Grid | C.S. |S| Reserved | n for lowest frequency | 601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 In this case Num Wavelengths specifies the number of wavelengths in 604 the range starting at the given wavelength and incrementing the Num 605 Wavelengths number of channel spacing up in frequency (regardless of 606 the value of the sign bit). 608 5.3.3. Bitmap Wavelength Set 610 In the case of Action = the bitmap the wavelength set format is given 611 by: 613 0 1 2 3 614 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 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 616 | Action = 4 | Reserved | Num Wavelengths | 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 |Grid | C.S. |S| Reserved | n for lowest frequency | 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 | Bit Map Word #1 (Lowest frequency channels) | 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 622 | ... | 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 624 | Bit Map Word #N (Highest frequency channels) | 625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 627 Where Num Wavelengths in this case tells us the number of wavelengths 628 represented by the bit map which is required to be ceiling[(Num 629 Wavelengths)/32]. Each bit in the bit map represents a particular 630 frequency with a value of 1/0 indicating whether the frequency is in 631 the set or not. Bit position zero represents the lowest frequency, 632 while each succeeding bit position represents the next frequency a 633 channel spacing (C.S.) above the previous. 635 Example: 637 A 40 channel C-Band DWDM system with 100GHz spacing with lowest 638 frequency 192.0THz (1561.4nm) and highest frequency 195.9THz 639 (1530.3nm). These frequencies correspond to n = -11, and n = 28 640 respectively. Now suppose the following channels are available: 642 Frequency(THz) n Value bit map position 643 -------------------------------------------------- 644 192.0 -11 0 645 192.5 -6 5 646 193.1 0 11 647 193.9 8 19 648 194.0 9 20 649 195.2 21 32 650 195.8 27 38 652 With the Grid value set to indicate an ITU-T G.694.1 DWDM grid, C.S. 653 set to indicate 100GHz, and with S (sign) set to indicate negative 654 this lambda bit map set would then be encoded as follows: 656 0 1 2 3 657 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 658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 | Action = 4 | Reserved | Num Wavelengths = 40 | 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 661 |Grid | C.S. |S| Reserved | n for lowest frequency = -11 | 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 |1 0 0 0 0 1 0 0 0 0 0 1 0 0 0 0 0 0 0 1 1 0 0 0 0 0 0 0 0 0 0 0| 664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 665 |1 0 0 0 0 0 1 0| Not used in 40 Channel system (all zeros) | 666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 668 5.4. Connectivity Matrix Sub-TLV 670 The potential connectivity matrix for asymmetric switches (e.g. 671 ROADMs and such) and the connectivity matrix for asymmetric fixed 672 devices can be represented by a matrix A where Amn = 0 or 1, 673 depending upon whether a wavelength on ingress port m can be 674 connected to egress port n. 676 This can be compactly represented link sets as follows: 678 0 1 2 3 679 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 680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 681 |Connectivity | Reserved | 682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 683 | Link Set A #1 | 684 : : : 685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 686 | Link Set B #1 687 : : : 688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 689 | Additional Link set pairs as needed | 690 : to specify connectivity : 691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 693 Where Connectivity = 0 if the device is fixed 695 1 if the device is reconfigurable (ROADM/OXC) 697 Issue for further study: 699 It may be useful to have a bit from the reserved field to indicate 700 whether "local" switching can take place or not, i.e., whether the 701 diagonal of Amn should be assumed to be 0 or 1 in cases where the 702 same port # appears in both ingress set list and egress set list. For 703 a typical ROADM Amm = 0. 705 Example: 707 Suppose we have a typical 2-degree 40 channel ROADM. In addition to 708 its two line side ports it has 80 add and 80 drop ports. The picture 709 below illustrates how a typical 2-degree ROADM system that works with 710 bi-directional fiber pairs is a highly asymmetrical system composed 711 of two unidirectional ROADM subsystems. 713 (Tributary) Ports #3-#42 714 Ingress added to Egress dropped from 715 West Line Egress East Line Ingress 716 vvvv ^^^^ 717 | |...| | |...| 718 +-----| |...|--------| |...|------+ 719 | +----------------------+ | 720 | | | | 721 Egress | | Unidirectional ROADM | | 722 -----------------+ | | +-------------- 723 <=====================| |===================< 724 -----------------+ +----------------------+ +-------------- 725 | | 726 Port #1 | | Port #2 727 (West Line Side) | |(East Line Side) 728 -----------------+ +----------------------+ +-------------- 729 >=====================| |===================> 730 -----------------+ | Unidirectional ROADM | +-------------- 731 | | | | 732 | | _ | | 733 | +----------------------+ | 734 +-----| |...|--------| |...|------+ 735 | |...| | |...| 736 vvvv ^^^^ 737 (Tributary) Ports #43-#82 738 Egress dropped from Ingress added to 739 West Line ingress East Line egress 741 Referring to the figure we see that the ingress direction of ports 742 #3-#42 (add ports) can only potentially egress on port #1. While in 743 ingress side of port #2 (line side) can egress only on ports #3-#42 744 (drop) and #1 (pass through). Similarly, the ingress direction of 745 ports #43-#82 can only potentially egress on port #2 (line). While 746 the ingress direction of port #1 can only potentially egress on ports 747 #43-#82 (drop) or port #2 (pass through). We can now represent this 748 potential connectivity matrix as follows. This representation uses 749 only 30 32-bit words. 751 0 1 2 3 752 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 753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 754 | Conn = 1 | Reserved |1 755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 756 Note: adds to line 757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 758 | Action=2 |0 1|0 0 0 0 0 0|Reserved(Note:inclusive range) |2 759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 760 | Link Local Identifier = #3 |3 761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 762 | Link Local Identifier = #42 |4 763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 764 | Action=0 |1 0|0 0 0 0 0 0|Reserved (Note:inclusive list) |5 765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 766 | Link Local Identifier = #1 |6 767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 768 Note: line to drops 769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 770 | Action=0 |0 1|0 0 0 0 0 0|Reserved (Note:inclusive list) |7 771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 772 | Link Local Identifier = #2 |8 773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 774 | Action=2 |1 0|0 0 0 0 0 0|Reserved(Note: inclusive range)|9 775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 776 | Link Local Identifier = #3 |10 777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 778 | Link Local Identifier = #42 |11 779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 780 Note: line to line 781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 782 | Action=0 |0 1|0 0 0 0 0 0|Reserved (Note:inclusive list) |12 783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 784 | Link Local Identifier = #2 |13 785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 786 | Action=0 |1 0|0 0 0 0 0 0|Reserved(Note: inclusive range)|14 787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 788 | Link Local Identifier = #1 |15 789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 790 Note: adds to line 791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 792 | Action=2 |0 1|0 0 0 0 0 0|Reserved(Note:inclusive range) |16 793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 794 | Link Local Identifier = #42 |17 795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 796 | Link Local Identifier = #82 |18 797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 798 | Action=0 |1 0|0 0 0 0 0 0|Reserved (Note:inclusive list) |19 799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 800 | Link Local Identifier = #2 |20 801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 802 Note: line to drops 803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 804 | Action=0 |0 1|0 0 0 0 0 0|Reserved (Note:inclusive list) |21 805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 806 | Link Local Identifier = #1 |22 807 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 808 | Action=2 |1 0|0 0 0 0 0 0|Reserved(Note: inclusive range)|23 809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 810 | Link Local Identifier = #43 |24 811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 812 | Link Local Identifier = #82 |25 813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 814 Note: line to line 815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 816 | Action=0 |0 1|0 0 0 0 0 0|Reserved (Note:inclusive list) |26 817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 818 | Link Local Identifier = #1 |27 819 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 820 | Action=0 |1 0|0 0 0 0 0 0|Reserved(Note: inclusive range)|28 821 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 822 | Link Local Identifier = #2 |30 823 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 825 5.5. Port Wavelength Restriction sub-TLV 827 The port wavelength restriction of section 3.3.1. can be encoded as a 828 sub-TLV as follows. 830 0 1 2 3 831 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 832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 833 |RestrictionKind| Reserved | MaxNumChannels | 834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 835 --Wavelength Set-- 836 | Action | Reserved | Num Wavelengths | 837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 838 |Grid | C.S. |S| Reserved | n for lowest frequency | 839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 840 | Additional fields as necessary per action | 841 | | 843 Where the meanings of RestrictionKind, MaxNumChannels and the 844 Wavelength Set were defined in section 3.3.1. 846 6. Security Considerations 848 This document has no requirement for a change to the security models 849 within GMPLS and associated protocols. That is the OSPF-TE, RSVP-TE, 850 and PCEP security models could be operated unchanged. 852 7. IANA Considerations 854 TBD. Once finalized in our approach we will need identifiers for such 855 things and modulation types, modulation parameters, wavelength 856 assignment methods, etc... 858 8. Acknowledgments 860 This document was prepared using 2-Word-v2.0.template.dot. 862 9. References 864 9.1. Normative References 866 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 867 Requirement Levels", BCP 14, RFC 2119, March 1997. 869 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 870 (GMPLS) Signaling Functional Description", RFC 3471, 871 January 2003. 873 [G.694.1] ITU-T Recommendation G.694.1, "Spectral grids for WDM 874 applications: DWDM frequency grid", June, 2002. 876 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 877 (TE) Extensions to OSPF Version 2", RFC 3630, September 878 2003. 880 [RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing Extensions 881 in Support of Generalized Multi-Protocol Label Switching 882 (GMPLS)", RFC 4202, October 2005 884 [RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions in 885 Support of Generalized Multi-Protocol Label Switching 886 (GMPLS)", RFC 4203, October 2005. 888 9.2. Informative References 890 [Otani] T. Otani, H. Guo, K. Miyazaki, D. Caviglia, "Generalized 891 Labels of Lambda-Switching Capable Label Switching Routers 892 (LSR)", work in progress: draft-otani-ccamp-gmpls-lambda- 893 labels-01.txt, November 2007. 895 [G.694.1] ITU-T Recommendation G.694.1, Spectral grids for WDM 896 applications: DWDM frequency grid, June 2002. 898 [G.694.2] ITU-T Recommendation G.694.2, Spectral grids for WDM 899 applications: CWDM wavelength grid, December 2003. 901 [RFC4205] Kompella, K., Ed., and Y. Rekhter, Ed., "Intermediate 902 System to Intermediate System (IS-IS) Extensions in Support 903 of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 904 4205, October 2005. 906 [WSON-Frame] G. Bernstein, Y. Lee, W. Imajuku, "Framework for GMPLS 907 and PCE Control of Wavelength Switched Optical Networks", 908 work in progress: draft-bernstein-ccamp-wavelength- 909 switched-02.txt, February 2008. 911 10. Contributors 913 Diego Caviglia 914 Ericsson 915 Via A. Negrone 1/A 16153 916 Genoa Italy 918 Phone: +39 010 600 3736 919 Email: diego.caviglia@(marconi.com, ericsson.com) 921 Anders Gavler 922 Acreo AB 923 Electrum 236 924 SE - 164 40 Kista Sweden 926 Email: Anders.Gavler@acreo.se 928 Jonas Martensson 929 Acreo AB 930 Electrum 236 931 SE - 164 40 Kista, Sweden 933 Email: Jonas.Martensson@acreo.se 935 Itaru Nishioka 936 NEC Corp. 937 1753 Simonumabe, Nakahara-ku, Kawasaki, Kanagawa 211-8666 938 Japan 940 Phone: +81 44 396 3287 941 Email: i-nishioka@cb.jp.nec.com 943 Author's Addresses 945 Greg Bernstein (ed.) 946 Grotto Networking 947 Fremont, CA, USA 949 Phone: (510) 573-2237 950 Email: gregb@grotto-networking.com 951 Young Lee (ed.) 952 Huawei Technologies 953 1700 Alma Drive, Suite 100 954 Plano, TX 75075 955 USA 957 Phone: (972) 509-5599 (x2240) 958 Email: ylee@huawei.com 960 Dan Li 961 Huawei Technologies Co., Ltd. 962 F3-5-B R&D Center, Huawei Base, 963 Bantian, Longgang District 964 Shenzhen 518129 P.R.China 966 Phone: +86-755-28973237 967 Email: danli@huawei.com 969 Wataru Imajuku 970 NTT Network Innovation Labs 971 1-1 Hikari-no-oka, Yokosuka, Kanagawa 972 Japan 974 Phone: +81-(46) 859-4315 975 Email: imajuku.wataru@lab.ntt.co.jp 977 Intellectual Property Statement 979 The IETF takes no position regarding the validity or scope of any 980 Intellectual Property Rights or other rights that might be claimed to 981 pertain to the implementation or use of the technology described in 982 this document or the extent to which any license under such rights 983 might or might not be available; nor does it represent that it has 984 made any independent effort to identify any such rights. Information 985 on the procedures with respect to rights in RFC documents can be 986 found in BCP 78 and BCP 79. 988 Copies of IPR disclosures made to the IETF Secretariat and any 989 assurances of licenses to be made available, or the result of an 990 attempt made to obtain a general license or permission for the use of 991 such proprietary rights by implementers or users of this 992 specification can be obtained from the IETF on-line IPR repository at 993 http://www.ietf.org/ipr. 995 The IETF invites any interested party to bring to its attention any 996 copyrights, patents or patent applications, or other proprietary 997 rights that may cover technology that may be required to implement 998 this standard. Please address the information to the IETF at 999 ietf-ipr@ietf.org. 1001 Disclaimer of Validity 1003 This document and the information contained herein are provided on an 1004 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1005 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1006 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1007 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1008 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1009 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1011 Copyright Statement 1013 Copyright (C) The IETF Trust (2008). 1015 This document is subject to the rights, licenses and restrictions 1016 contained in BCP 78, and except as set forth therein, the authors 1017 retain all their rights. 1019 Acknowledgment 1021 Funding for the RFC Editor function is currently provided by the 1022 Internet Society.