idnits 2.17.1 draft-otani-ccamp-gmpls-lambda-labels-00.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 533. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 444. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 451. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 457. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page == There are 2 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([RFC3471]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document updates RFC3471, but the abstract doesn't seem to directly say this. It does mention RFC3471 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year (Using the creation date from RFC3471, updated by this document, for RFC5378 checks: 2000-10-23) -- 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 (June 2007) is 6159 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) == Outdated reference: A later version (-07) exists of draft-otani-ccamp-gmpls-cspf-constraints-05 Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IETF Internet Draft T. Otani 3 Updates: RFC 3471 H. Guo 4 Proposed status: standard track KDDI R&D Labs 5 Expires:Dec. 2007 K. Miyazaki 6 Fujitsu Lab. 7 Diego Caviglia 8 Ericsson 9 June 2007 11 Generalized Labels of Lambda-Switching Capable Label Switching 12 Routers (LSR) 14 Document: draft-otani-ccamp-gmpls-lambda-labels-00.txt 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of 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-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 Abstract 39 Technology in the optical domain is constantly evolving and as a 40 consequence new equipment providing lambda switching capability has 41 been developed and is currently being deployed. However, RFC 3471 42 [RFC3471] has defined that a wavelength label (section 3.2.1.1) "only 43 has significance between two neighbors" and global wavelength 44 continuity is not considered and getting significant. In order to 45 achieve interoperability in a network composed of new generation 46 lambda switch-capable equipment, this document proposes a standard 47 lambda label format. Moreover some consideration on how to ensure 48 lambda continuity with RSVP-TE is provided. 50 This document is a companion to the Generalized Multi-Protocol Label 51 Switching (GMPLS) signaling. It defines the label format when Lambda 52 Switching is requested in an all optical network. 54 Table of Contents 56 Status of this Memo................................................1 57 Abstract...........................................................1 58 1. Introduction....................................................3 59 2. Conventions used in this document...............................3 60 4. Requirements on Label Identification............................5 61 7. Security consideration..........................................9 62 8. Acknowledgement................................................10 63 9. Intellectual property considerations...........................10 64 Author's Addresses................................................11 65 Document expiration...............................................11 66 Copyright statement...............................................11 67 1. Introduction 69 As described in [RFC3945], Generalized MPLS (GMPLS) extends MPLS from 70 supporting only packet (Packet Switching Capable - PSC) interfaces 71 and switching to also include support for four new classes of 72 interfaces and switching: 73 - Layer-2 Switch Capable (L2SC) 74 - Time-Division Multiplex (TDM) 75 - Lambda Switch Capable (LSC) 76 - Fiber-Switch Capable (FSC). 77 A functional description of the extensions to MPLS signaling needed 78 to support new classes of interfaces and switching is provided in 79 [RFC3471]. 81 This document presents details that are specific to the use of GMPLS 82 with a new generation of Lambda Switch Capable (LSC) equipment. 83 Technologies such as Reconfigurable Optical Add/Drop Multiplex 84 (ROADM) and Wavelength Cross-Connect (WXC) operate at the wavelength 85 switching level. As such, the wavelength is important information 86 that is necessary to set up a wavelength-based LSP appropriately. 88 2. Conventions used in this document 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 92 document are to be interpreted as described in RFC-2119 [RFC2119]. 94 3. Assumed network model and related problem statement 96 Figure 1 depicts an all-optically switched network consisting of 97 different vendor's optical network domains. Vendor A's network is a 98 ring topology that consists of ROADM or WXC, and vendor B's network 99 is a mesh topology consisting of PXCs and DWDMs, otherwise both 100 vendors� network is based on the same technology. 102 In this case, the use of standardized wavelength label information is 103 quite significant to establish a wavelength-based LSP. It is also an 104 important constraint when conducting CSPF calculation for RSVP-TE 105 signaling. The way the CSPF is performed is outside the scope of this 106 document, but defined in [GMPLS-CSPF]. 108 It is needless to say, a LSP must be appropriately provisioned 109 between a selected pair of ports within Domain A, considering 110 wavelength information. Even over multiple domains, a LSP must be 111 accordingly established satisfying wavelength constraints. 113 Figure 2 illustrates in detail the interconnection between Domain A 114 and Domain B. 116 | 117 Domain A (or Vendor A) | Domain B (or Vendor B) 118 | 119 Node-1 Node-2 | Node-6 Node-7 120 +--------+ +--------+ | +-------+ +-+ +-+ +-------+ 121 | ROADM | | ROADM +---|---+ PXC +-+D| |D+-+ PXC | 122 | or WXC +========+ or WXC +---|---+ +-+W+=====+W+-+ | 123 | (LSC) | | (LSC) +---|---+ (LSC) +-+D| |D+-+ (LSC) | 124 +---+----+ +--------+ | | +-|M| |M+-+ | 125 || || | +++++++++ +-+ +-+ +++++++++ 126 || Node-3 || | ||||||| ||||||| 127 || +--------+ || | +++++++++ +++++++++ 128 ||===| WXC +===|| | | DWDM | | DWDM | 129 | (LSC) | | +--++---+ +--++---+ 130 ||===+ +===|| | || || 131 || +--------+ || | +--++---+ +--++---+ 132 || || | | DWDM | | DWDM | 133 +--------+ +--------+ | +++++++++ +++++++++ 134 | ROADM | | ROADM | | ||||||| ||||||| 135 | or WXC +========+ or WXC | | +++++++++ +-+ +-+ +++++++++ 136 | (LSC) | | (LSC) | | | PXC +-+D| |D+-+ PXC | 137 +--------+ +--------+ | | +-+W+=====+W+-+ | 138 Node-4 Node-5 | | (LSC) +-+D| |D+-+ (LSC) | 139 | | +-+M| |M+-+ | 140 | +-------+ +-+ +-+ +-------+ 141 | Node-8 Node-9 143 Figure 1 Wavelength-based network model 145 +---------------------------------------------------------------+ 146 | Domain A | Domain B | 147 | | | 148 | +---+ +---+ lambda 1 | +---+ +---+ | 149 | | | |L S|---------------|---------|L S| |L S|-- | 150 | --| | |A W| lambda 2 | |A W| |A W|-- | 151 | --| | WDM |M I|---------------|---------|M I| |M I|-- | 152 | --|L S|=====|B T| . | |B T| WDM |B T|-- | 153 | --|A W| |D C| . | |D C|=====|D C|-- | 154 | --|M I| |A H| lambda n | |A H| |A H|-- | 155 | --|B T| | 2|---------------|---------| 3| | 4|-- | 156 | --|D C| +---+ | +---+ +---+ | 157 | --|A H| | | 158 | --| 1| +---+ | +---+ +---+ | 159 | --| | |L S| | |L S| |L S|-- | 160 | --| | |A W| | |A W| |A W|-- | 161 | --| | WDM |M I| WDM | |M I| WDM |M I|-- | 162 | --| |=====|B T|=========================|B T|=====|B T|-- | 163 | --| | |D C| | |D C| |D C|-- | 164 | --| | |A H| | |A H| |A H|-- | 165 | | | | 5| | | 6| | 7|-- | 166 | +---+ +---+ | +---+ +---+ | 167 +---------------------------------------------------------------+ 169 Figure 2 Interconnecting details between two domains 170 In the scenario of Figure 2, consider the setting up of a 171 bidirectional LSP from ingress switch 1 to egress switch 4. A fixed 172 wavelength (lambda 1) will be used in domain A throughout domain B 173 satisfying wavelength continuity. A Path message will be used for the 174 signaling, the PATH message must contain the upstream label and a 175 label set object; both this two objects have to contain the same 176 lambda, that is, the label set object is made by only one sub channel 177 that must be the same as the upstream label. The path setup will 178 continue downstream to switch 4 by configuring each lambda switch 179 based on the wavelength label. This label allows the correct 180 switching of lambda switches and the label contents needs to be used 181 over the inter-domain. As same above, the path setup will continue 182 downstream to switch 7 by configuring lambda switch based on multiple 183 wavelength labels. If the node has a tunable wavelength transponder, 184 the tuning wavelength is considered as a part of wavelength switching 185 operation. 187 Not using a standardized label would add undue burden on the operator 188 to enforce policy as each manufacturer may decide on a different 189 representation and therefore each domain may have its own label 190 formats. Moreover, manual provisioning may lead to misconfiguration 191 if domain-specific labels are used. 193 4. Requirements on Label Identification 195 Here, some signaling-related requirements are listed considering 196 actual operation of above wavelength switched optical networks. 198 1. A wavelength label SHOULD be standardized in order to allow 199 interoperability between multiple domains; otherwise appropriate 200 existing labels are identified in support of wavelength 201 availability. 202 2. The ITU-T frequency grid specified in [G.694.1] for Dense WDM 203 (DWDM) and wavelength information in [G.694.2] for Coarse WDM 204 (CWDM) SHOULD be used by LSC LSRs when setting up LSPs. 205 3. Labels SHOULD be stable and not allow for rounding errors. 206 4. Existing labels should be still utilized appropriately even if 207 wavelength availability is advertised. 209 Moreover, some routing-related requirements are indicated, but not 210 covered in this document. 212 5. An operator MAY want to advertise wavelength availability in the 213 network. 214 6. Care SHOULD be taken if advertising the wavelength availability in 215 order to reduce impact on the existing OSPF-TE. 216 7. To decrease the probability of operators' error or difficulties, 217 it is RECOMMENDED that advertising using OSPF-TE/ISIS-TE be 218 standardized to simplify management. 220 5. Label Related Formats 221 To deal with the widening scope of MPLS into the optical and time 222 domains, several new forms of "label" have been defined in [RFC3471]. 223 This section contains clarifications for the Wavelength label and 224 Label Set definition specific for LSC LSRs. 226 5.1 Wavelength Labels 228 In section 3.2.1.1 of [RFC3471], a Wavelength label is defined to 229 have significance between two neighbors, and the receiver may need to 230 convert the received value into a value that has local significance. 232 LSC equipment uses multiple wavelengths controlled by a single 233 control channel. In such case, the label indicates the wavelength to 234 be used for the LSP. This document proposes to standardize the 235 wavelength label. As an example of wavelength values, the reader is 236 referred to [G.694.1] which lists the frequencies from the ITU-T DWDM 237 frequency grid. The same can be done for CWDM technology by using 238 the wavelength defined in [G.694.2]. 240 Since the ITU-T DWDM grid is based on nominal central frequencies, we 241 will indicate the appropriate table, the channel spacing in the grid 242 and a value n that allows the calculation of the frequency. That 243 value can be positive or negative. 245 The frequency is calculated as such in [G.694.1]: 247 Frequency (THz) = 193.0 THz + n * channel spacing (THz) 249 , Where n is an integer (positive, negative or 0) and channel 250 spacing is defined to be 0.0125, 0.025, 0.05, 0.1, or 0.2 THz. 252 For the other example of the case of the ITU-T CWDM grid, the spacing 253 between different channels was defined to be 20nm, so we need to pass 254 the wavelength value in nm in this case. Examples of CWDM 255 wavelengths are 1470, 1490, etc. nm. 257 The tables listed in [G.694.1] and [G.694.2] are not numbered and 258 change with the changing frequency spacing as technology advances, so 259 an index is not appropriate in this case. 261 5.2 DWDM Wavelength Label 263 For the case of DWDM, the information carried in a Wavelength label 264 is: 266 0 1 2 3 267 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 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 |Grid | C.S.|S| n | Reserved | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 (1) Grid: 3 bits 273 The value for grid is set to 1 for ITU-T DWDM Grid as defined in 274 [G.694.1]. 276 +----------+---------+ 277 | Grid | Value | 278 +----------+---------+ 279 |ITU-T DWDM| 1 | 280 +----------+---------+ 281 |ITU-T CWDM| 2 | 282 +----------+---------+ 283 |Future use| 3 - 7 | 284 +----------+---------+ 286 (2) C.S.(channel spacing): 3 bits 288 DWDM channel spacing is defined as follows. 290 +----------+---------+ 291 | C.S(GHz) | Value | 292 +----------+---------+ 293 | 12.5 | 1 | 294 +----------+---------+ 295 | 25 | 2 | 296 +----------+---------+ 297 | 50 | 3 | 298 +----------+---------+ 299 | 100 | 4 | 300 +----------+---------+ 301 | 200 | 5 | 302 +----------+---------+ 303 |Future use| 6 � 7 | 304 +----------+---------+ 306 (3) S: 1 bit 308 Sign for the value of n, set to 1 for (-) and 0 for (+) 310 (4) n: 9 bits 312 The value used to compute the frequency as shown above. 314 5.3 CWDM Wavelength Label 316 For the case of CWDM, the information carried in a Wavelength label 317 is: 319 0 1 2 3 320 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 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 |Grid | Lambda | Reserved | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 (1) Grid: 3 bits 326 The value for grid is set to 2 for ITU-T CWDM Grid as defined in 327 [G.694.2]. 329 +----------+---------+ 330 | Grid | Value | 331 +----------+---------+ 332 |ITU-T DWDM| 1 | 333 +----------+---------+ 334 |ITU-T CWDM| 2 | 335 +----------+---------+ 336 |Future use| 3 - 7 | 337 +----------+---------+ 339 (2) Lambda: 11 bits 341 Integer value of lambda in nm is defined as below. 343 +-------------+ 344 | Lambda (nm) | 345 +-------------+ 346 | 1470 | 347 +-------------+ 348 | 1490 | 349 +-------------+ 350 | 1510 | 351 +-------------+ 352 | 1530 | 353 +-------------+ 354 | 1550 | 355 +-------------+ 356 | 1590 | 357 +-------------+ 358 | 1610 | 359 +-------------+ 361 We do not need to define a new type as the information stored is 362 either a port label or a wavelength label. Only the wavelength label 363 as above needs to be defined. 365 6. Lambda constraint in all-optical networks 367 6.1 Wavelength continuity 369 An all-optical network imposes the Lambda continuity constraint, that 370 is, a label cannot be changed hop by hop, but must have an end to end 371 scope. 373 The above is not supported by RFC3471 that states that a label has 374 significance only between two neighbors. 376 This memo changes the way an all optical node process and manage a 377 Path message with Lambda label. 379 Two possible scenarios are taken into consideration: 380 1. The node is able via OEO operation to change the Lambda 381 2. The node is a pure optical device and is not able to change the 382 Lambda 384 The first scenario can be supported either by nodes with a double 385 switching matrix (eclectic and optic) but also by nodes that have 386 only an optic matrix and a G.709 tunable transponder on the outgoing 387 interface. 389 This scenario is covered by 3471 procedures and then will not be 390 taken into consideration in the following. 392 Scenario 2 imposes in case of bidirectional LSPs some constraints: 393 . on the same hop Upstream and Downstream must be the same; 394 . on an end to end basis the LSP must use the same Label 396 The first constraint do not need any modification to the already 397 defined RSVP-TE protocols and behaviors, and can be satisfied just 398 setting the Upstream Label value equal to the Label Set subchannel 399 value. The action must be inclusive and there must be only one 400 subchannel in the object. 402 The second constraint cannot be satisfied with the way RSVP-TE works 403 today. The solution proposed here is: if a node is not able to 404 perform OEO conversion then it must use on its outgoing interface the 405 same Lambda it received on the incoming interface. 407 The above applies in the case the ERO does not contain information up 408 to the label level. 410 6.2 Advertising wavelength availability 412 Wavelength availability may be thought of as a constraint in an all- 413 optical network. Although it may be collected through an EMS/NMS 414 system, operators may want to have it advertised using GMPLS routing. 415 It may be needed to standardize the information advertised using 416 OSPF-TE and ISIS-TE if an operator wishes to have it advertised. This 417 allows the operator to parse LSA information without regard to the 418 applied policy in different manufacturer domains. However, more 419 investigation to extend the existing routing protocol is required 420 from the point of routing scalability and this consideration is out 421 of scope in this document. 423 7. Security consideration 425 This document introduces no new security considerations to [RFC3473]. 426 GMPLS security is described in section 11 of [RFC3471] and refers to 427 [RFC3209] for RSVP-TE. 429 8. Acknowledgement 431 The authors would like to express their thanks to Sidney Shiba, 432 Richard Rabbat for originally initiating this work. They also thank 433 Adrian Farrel and Lawrence Mao for the discussion. 435 9. Intellectual property considerations 437 The IETF takes no position regarding the validity or scope of any 438 Intellectual Property Rights or other rights that might be claimed to 439 pertain to the implementation or use of the technology described in 440 this document or the extent to which any license under such rights 441 might or might not be available; nor does it represent that it has 442 made any independent effort to identify any such rights. Information 443 on the procedures with respect to rights in RFC documents can be 444 found in BCP 78 and BCP 79. 446 Copies of IPR disclosures made to the IETF Secretariat and any 447 assurances of licenses to be made available, or the result of an 448 attempt made to obtain a general license or permission for the use of 449 such proprietary rights by implementers or users of this 450 specification can be obtained from the IETF on-line IPR repository at 451 http://www.ietf.org/ipr. 453 The IETF invites any interested party to bring to its attention any 454 copyrights, patents or patent applications, or other proprietary 455 rights that may cover technology that may be required to implement 456 this standard. Please address the information to the IETF at ietf- 457 ipr@ietf.org. 459 10. References 461 10.1. Normative References 463 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 464 Requirement Levels", BCP 14, RFC 2119, March 1997. 466 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 467 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 468 3209, December 2001. 470 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 471 (MPLS) Signaling Functional Description", RFC 3471, January 2003. 473 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 474 (MPLS} Signaling - Resource ReserVation Protocol Traffic Engineering 475 (RSVP-TE) Extensions", RFC 3473, January 2003. 477 [RFC3945] Mannie, E., Ed., "Generalized Multiprotocol Label Switching 478 (GMPLS) Architecture", RFC 3945, October 2004. 480 10.2. Informative References 482 [G.694.1] ITU-T Recommendation G.694.1, "Spectral grids for WDM 483 applications: DWDM frequency grid", June 2002. 485 [G.694.2] ITU-T Recommendation G.694.2, "Spectral grids for WDM 486 applications: CWDM wavelength grid", December 2003. 488 [GMPLS-CSPF] Otani, T., et al, "Considering Generalized Multiprotocol 489 Label Switching Traffic Engineering Attributes During Path 490 Computation", draft-otani-ccamp-gmpls-cspf-constraints-05.txt, March 491 2007. 493 Author's Addresses 495 Tomohiro Otani 496 KDDI R&D Laboratories, Inc. 497 2-1-15 Ohara Fujimino Phone: +81-49-278-7357 498 Saitama, 356-8502. Japan Email: otani@kddilabs.jp 500 Hongxiang Guo 501 KDDI R&D Laboratories, Inc. 502 2-1-15 Ohara Fujimino Phone: +81-49-278-7864 503 Saitama, 356-8502. Japan Email: ho-guo@kddilabs.jp 505 Keiji Miyazaki 506 Fujitsu Laboratories Ltd 507 4-1-1 Kotanaka Nakahara-ku, Kawasaki Phone: +81-44-754-2765 508 Kanagawa, 211-8588. Japan Email: miyazaki.keiji@jp.fujitsu.com 510 Diego Caviglia 511 Ericsson 512 16153 Genova Cornigliano Phone: +390106003736 513 ITALY Email: diego.caviglia@ericsson.com 515 Document expiration 517 This document will be expired in Dec. 30, 2007, unless it is updated. 519 Copyright statement 521 Copyright (C) The IETF Trust (2007). 523 This document is subject to the rights, licenses and restrictions 524 contained in BCP 78, and except as set forth therein, the authors 525 retain all their rights. 527 This document and the information contained herein are provided on an 528 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 529 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 530 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 531 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 532 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 533 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.