idnits 2.17.1 draft-ietf-pppext-sonet-ds-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == 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.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. ** The abstract seems to contain references ([RFC-1661]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (August 1998) is 9385 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) == Missing Reference: 'DayDreamer' is mentioned on line 2, but not defined == Missing Reference: 'RFC-1973bis' is mentioned on line 232, but not defined -- Looks like a reference, but probably isn't: '256' on line 300 == Missing Reference: 'FC97' is mentioned on line 375, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'RFC-yyyy' -- Possible downref: Non-RFC (?) normative reference: ref. 'RFC-zzzz' -- Possible downref: Non-RFC (?) normative reference: ref. 'SONET' -- Possible downref: Non-RFC (?) normative reference: ref. 'G.707' Summary: 11 errors (**), 0 flaws (~~), 5 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group W A Simpson [DayDreamer] 3 Internet Draft 4 expires in six months August 1998 6 PPP over SONET/SDH 7 draft-ietf-pppext-sonet-ds-01.txt 9 Status of this Memo 11 This document is an Internet-Draft. Internet Drafts are working doc- 12 uments of the Internet Engineering Task Force (IETF), its Areas, and 13 its Working Groups. Note that other groups may also distribute work- 14 ing documents as Internet Drafts. 16 Internet Drafts are draft documents valid for a maximum of six 17 months, and may be updated, replaced, or obsoleted by other documents 18 at any time. It is not appropriate to use Internet Drafts as refer- 19 ence material, or to cite them other than as a ``working draft'' or 20 ``work in progress.'' 22 To learn the current status of any Internet-Draft, please check the 23 ``1id-abstracts.txt'' listing contained in the internet-drafts Shadow 24 Directories on: 26 ftp.is.co.za (Africa) 27 nic.nordu.net (Northern Europe) 28 ftp.nis.garr.it (Southern Europe) 29 ftp.ietf.org (Eastern USA) 30 ftp.isi.edu (Western USA) 31 munnari.oz.au (Pacific Rim) 33 Distribution of this memo is unlimited. 35 Copyright Notice 37 Copyright (C) William Allen Simpson (1993-1994, 1997-1998). All 38 Rights Reserved. 40 Abstract 42 The Point-to-Point Protocol (PPP) [RFC-1661] provides a standard 43 method for transporting multi-protocol datagrams over point-to-point 44 links. This document describes the use of PPP over Synchronous Opti- 45 cal Network (SONET) and Synchronous Digital Hierarchy (SDH) circuits. 47 1. Introduction 49 PPP was designed as a standard method of communicating over point-to- 50 point links. Initial deployment has been over short local lines, 51 leased lines, and plain-old-telephone-service (POTS) using modems. 52 As new packet services and higher speed lines are introduced, PPP is 53 easily deployed in these environments as well. 55 The Synchronous Optical Network [SONET] is a time division multiplex- 56 ing scheme that defines a family of standard rates and formats. 57 Despite the name, it is not limited to optical links. The ITU-T Syn- 58 chronous Digital Hierarchy (SDH) attempts to internationalize SONET 59 to provide interworking beteen networks based on different ple- 60 siochronous digital hierarchies and speech encoding regimes. 62 The SONET and SDH efforts specify an entire infrastructure, from 63 physical-layer through network-layer to application-layer. The upper 64 layers rely on ISO CLNP, TP4/CLNS, ASN.1, ASCE, CMISE, and an exten- 65 sive list of ITU-T X.committee specifications. 67 Where SONET/SDH is configured as a point-to-point circuit, PPP is 68 well suited to use over these links. PPP provides link-layer packet 69 encapsulation with framing, and treats SONET/SDH in its entirety 70 merely as an overly complicated physical-layer, ignoring its other 71 features. 73 Because the PPP encapsulation has relatively low overhead, it is 74 anticipated that substantially higher throughput can be attained com- 75 pared to other SONET/SDH payload mappings, at a significantly lower 76 cost for line termination equipment. 78 1.1. Terminology 80 The various committees changing the SONET/SDH specifications have 81 been inconsistent in their terminology. This specification uses a 82 few simplified terms: 84 block A fixed-size time-based multiplexing unit, carried 85 from interface to interface; also known as the SONET 86 Synchronous Transport Signal (STS-N) Frame, or the 87 SDH Synchronous Transport Module (STM-N) Frame 88 Structure. This use of "frame" conflicts with link- 89 layer use of the same term. The format has more in 90 common with fixed-length unit record equipment, such 91 as a magnetic tape, than with a variable-length 92 packet. 94 byte An 8-bit quantity; also known as "octet" in stan- 95 dardese. 97 envelope A fixed-size time-based multiplexing unit, carried 98 within successive blocks along a path; also known as 99 the SONET Synchronous Payload Envelope (SPE), or the 100 SDH Administrative Unit Group (AUG). 102 frame A variable-length unit of transmission, which is 103 passed across the interface between the link-layer 104 and the physical-layer. A single packet is usually 105 wrapped in a frame, unless link-layer packet frag- 106 mentation is performed, or multiple packets are 107 aggregated into a single frame. 109 packet The basic unit of link encapsulation, which is 110 passed across the interface between the network- 111 layer and the link-layer. The packet information is 112 variable-length. 114 In this document, the key words "MAY", "MUST, "MUST NOT", "optional", 115 "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as 116 described in [RFC-2119]. 118 To remain consistent with standard Internet practice, and avoid con- 119 fusion for people used to reading RFCs, all binary numbers in the 120 following descriptions are in Most Significant Bit to Least Signifi- 121 cant Bit order, from Most Significant Byte to Least Significant Byte, 122 reading from left to right, unless otherwise indicated. Note that 123 this is contrary to ISO and ITU practice, which orders bits as trans- 124 mitted (network bit order). Keep this in mind when comparing this 125 document with the other documents. 127 2. Physical Layer Requirements 129 PPP treats SONET/SDH transport as an octet-oriented synchronous link. 130 SONET/SDH links are bi-directional and full-duplex by definition. 132 Interface Format 134 PPP presents an octet interface to the physical layer. There is 135 no provision for sub-octets to be supplied or accepted. 137 The octet stream is mapped into the SONET/SDH envelope payload, 138 with the octet boundaries aligned with the payload byte bound- 139 aries. 141 PPP Authentication is preferable to the use of Path Trace (J1) for 142 confirming connection between the correct peers. 144 The Path Signal Label (C2) is intended to indicate the contents of 145 the envelope. 147 16 (10 hex) has been assigned to indicate PPP in octet-synchronous 148 HDLC-like framing [RFC-1662] with ATM-style payload scrambling. 149 This scrambling MUST be configurable at both terminals, and 150 SHOULD NOT be enabled by default. This technique is only used 151 at STS-3c/STM-1. 153 17 (11 hex) has been assigned to indicate PPP in ether-like fram- 154 ing [RFC-yyyy] with LSFR payload scrambling. 156 207 157 (cf hex) SHOULD be used to indicate PPP in octet-synchronous 158 HDLC-like framing [RFC-1662]. Byte sequences that might other- 159 wise need scrambling (for under-performing circuits) are 160 escaped using optional prophylactic octet-stuffing. This tech- 161 nique is only used at STS-3c/STM-1 and STS-12c/STM-4. 163 An implementation MUST also allow configuration of the C2 field to 164 0 (Unequipped) or 1 (Non-Specific Payload). 166 The Multipurpose Position Indicator (H4) is currently unused, and 167 MUST be zero. 169 Transmission Rate 171 The SONET transmission rates are integral multiples of 51.840 172 Mbps, which may be used to carry T3/E3 signals. The allowed mul- 173 tiples are currently specified (in Mbps) as 175 STS-1 51.840 STS-18 933.120 176 STS-3 155.520 STS-24 1,244.160 177 STS-9 466.560 STS-36 1,866.240 178 STS-12 622.080 STS-48 2,488.320 180 STS-192 9,953.280 182 SDH defines a subset of SONET transmission rates beginning at 183 155.520 Mbps [G.707] 184 SONET SDH equivalent 185 STS-3c STM-1 186 STS-12c STM-4 187 STS-48c STM-16 188 STS-192c STM-48 190 The basic rate chosen for this specification is that of 191 STS-3c/STM-1 at 155.520 Mbps. The available information bandwidth 192 is 149.760 Mbps, which is the STS-3c/STM-1 envelope payload with 193 overhead removed. This is the same super-rate mapping that is 194 used for ATM and FDDI. 196 Lower signal rates MUST use the SONET Virtual Tributary (VT) mech- 197 anism, also known as SDH Tributary Units (TU) and Virtual Contain- 198 ers (VC). This maps existing signals up to T3/E3 rates asyn- 199 chronously into the envelope, or uses available clocks for bit- 200 synchronous and byte-synchronous mapping. 202 Higher signal rates SHOULD conform to the SDH STM series, rather 203 than the SONET STS series, as equipment becomes available. The 204 STM series progresses in powers of 4 (instead of 3), and employs 205 fewer steps, which is likely to simplify multiplexing and integra- 206 tion, thereby promoting interoperability. 208 Control Signals 210 PPP does not require the use of control signals. When available, 211 using such signals can allow greater functionality and perfor- 212 mance. Implications are discussed in [RFC-1662]. 214 For more information on the specification of the SONET/SDH interface, 215 see [RFC-zzzz]. 217 3. The Data Link Layer 219 The framed PPP packet MUST be mapped directly into the envelope pay- 220 load by row, skipping a single column for Path Overhead (POH), and 221 filling any fixed-stuff columns. Because packets are variable in 222 length, the frames are allowed to carry over envelope boundaries. 224 Interleaving and separating VT/TU PPP packet streams over multiple 225 circuit paths are beyond the scope of this specification. 227 3.1. STS-3c/STM-1 and STS-12c/STM-4 229 By default, octet-synchronous HDLC-like framing [RFC-1662] MUST be 230 implemented. 232 As an option, octet-synchronous Frame Relay [RFC-1973bis] MAY be 233 implemented. 235 3.2. STS-48c/STM-4 and above 237 By default, ether-like framing [RFC-yyyy] MUST be implemented. 239 4. Configuration Details 241 The standard LCP configuration defaults apply to SONET/SDH links. 243 The following Configuration Options are recommended: 245 Magic Number 246 No Address and Control Field Compression 247 No Protocol Field Compression 248 Link Quality Monitoring 249 Self Describing Padding 250 32-bit FCS 252 A. Payload Scrambling 254 Several suggestions have been made for reducing the possibility that 255 a maliciously chosen payload can cause a long sequence of one or zero 256 bits, resulting in the Loss of Signal (LOS) indication. Implementa- 257 tions strictly conforming to original SONET specification are not 258 subject to this problem, and the recommendations in the [RFC-zzzz] 259 profile completely prevent this problem. 261 However, the profile recommends testing for non-conforming installa- 262 tions. When the recommended installation test detects that line rate 263 clock recovery is not sufficiently stable to meet the requirements of 264 this specification, Prophylactic Octet Stuffing MAY be configured by 265 the sending peer. There is no requirement that this method be imple- 266 mented. 268 A.1. Prophylactic Octet Stuffing 270 The installation test SHOULD determine the maximum number of bytes 271 that can be safely sent, and configure the allowance at one less. 272 The transmitter checks the outgoing bytes, and adds an escape when- 273 ever the allowance is exceeded. 275 The principal advantage of this method is that it is fully backward 276 compatible. The receiver does not need to make any changes, as 277 octet-stuffing escapes are already handled. 279 Also, there are no additional error patterns introduced that are 280 undetectable by the FCS. 282 Moreover, this method operates on octets rather than bits, and is 283 parallelizable in the same fashion as HDLC-like framing. 285 Finally, the resulting protection is complete, rather than proba- 286 bilistic. 288 /* Detect SONET/SDH section scrambler pattern in PPP data. 289 * 1996 May, William Allen Simpson 290 */ 291 typedef unsigned char uint8; 293 /* Combining the patterns for all-zeros and all-ones, each 294 * byte in this table contains the next byte in the pattern. 295 * There are 2 bytes that do not appear in the patterns 296 * (00 and ff). These are both directed to 7d, as the series 297 * "7d 0e" is not a feasible PPP construct. 299 */ 300 uint8 pattern[256] = 301 { 0x7d, 0xfb, 0x0c, 0xf7, 0x18, 0xe3, 0x14, 0xef, 302 0x30, 0xcb, 0x3c, 0xc7, 0x28, 0xd3, 0x24, 0xdf, 303 0x61, 0x9a, 0x6d, 0x96, 0x79, 0x82, 0x75, 0x8e, 304 0x51, 0xaa, 0x5d, 0xa6, 0x49, 0xb2, 0x45, 0xbe, 305 0xc2, 0x39, 0xce, 0x35, 0xda, 0x21, 0xd6, 0x2d, 306 0xf2, 0x09, 0xfe, 0x05, 0xea, 0x11, 0xe6, 0x1d, 307 0xa3, 0x58, 0xaf, 0x54, 0xbb, 0x40, 0xb7, 0x4c, 308 0x93, 0x68, 0x9f, 0x64, 0x8b, 0x70, 0x87, 0x7c, 309 0x7e, 0x85, 0x72, 0x89, 0x66, 0x9d, 0x6a, 0x91, 310 0x4e, 0xb5, 0x42, 0xb9, 0x56, 0xad, 0x5a, 0xa1, 311 0x1f, 0xe4, 0x13, 0xe8, 0x07, 0xfc, 0x0b, 0xf0, 312 0x2f, 0xd4, 0x23, 0xd8, 0x37, 0xcc, 0x3b, 0xc0, 313 0xbc, 0x47, 0xb0, 0x4b, 0xa4, 0x5f, 0xa8, 0x53, 314 0x8c, 0x77, 0x80, 0x7b, 0x94, 0x6f, 0x98, 0x63, 315 0xdd, 0x26, 0xd1, 0x2a, 0xc5, 0x3e, 0xc9, 0x32, 316 0xed, 0x16, 0xe1, 0x1a, 0xf5, 0x0e, 0xf9, 0x02, 318 0xfd, 0x06, 0xf1, 0x0a, 0xe5, 0x1e, 0xe9, 0x12, 319 0xcd, 0x36, 0xc1, 0x3a, 0xd5, 0x2e, 0xd9, 0x22, 320 0x9c, 0x67, 0x90, 0x6b, 0x84, 0x7f, 0x88, 0x73, 321 0xac, 0x57, 0xa0, 0x5b, 0xb4, 0x4f, 0xb8, 0x43, 322 0x3f, 0xc4, 0x33, 0xc8, 0x27, 0xdc, 0x2b, 0xd0, 323 0x0f, 0xf4, 0x03, 0xf8, 0x17, 0xec, 0x1b, 0xe0, 324 0x5e, 0xa5, 0x52, 0xa9, 0x46, 0xbd, 0x4a, 0xb1, 325 0x6e, 0x95, 0x62, 0x99, 0x76, 0x8d, 0x7a, 0x81, 326 0x83, 0x78, 0x8f, 0x74, 0x9b, 0x60, 0x97, 0x6c, 327 0xb3, 0x48, 0xbf, 0x44, 0xab, 0x50, 0xa7, 0x5c, 328 0xe2, 0x19, 0xee, 0x15, 0xfa, 0x01, 0xf6, 0x0d, 329 0xd2, 0x29, 0xde, 0x25, 0xca, 0x31, 0xc6, 0x3d, 330 0x41, 0xba, 0x4d, 0xb6, 0x59, 0xa2, 0x55, 0xae, 331 0x71, 0x8a, 0x7d, 0x86, 0x69, 0x92, 0x65, 0x9e, 332 0x20, 0xdb, 0x2c, 0xd7, 0x38, 0xc3, 0x34, 0xcf, 333 0x10, 0xeb, 0x1c, 0xe7, 0x08, 0xf3, 0x04, 0x7d 334 }; 336 int pattern_allowed = 7; /* maximum number of bytes 337 permitted before escaping, 338 default 7 */ 339 int pattern_found = 0; /* count of bytes matched */ 341 uint8 pattern_next = 0x7e; /* next byte in pattern, 342 assume start of HDLC frame */ 344 /* Check a byte stream for a pattern matching sequence 345 * exceeding the allowed match length. Return true/false. 347 * On true, the caller will generate a two byte escape sequence, 348 * calling this routine again with both values. 349 */ 350 int pattern_escape_needed( uint8 current_byte ) 351 { 352 if ( current_byte != pattern_next ) 353 { 354 pattern_found = 0; 355 } 356 else 357 { 358 pattern_found++; 359 } 360 pattern_next = pattern[current_byte]; 361 return ((pattern_found > pattern_allowed) 362 && (current_byte != 0x5e) 363 && (current_byte != 0x7d) 364 && (current_byte != 0x7e)); 365 } 367 A.2. LFSR scrambling 369 A.3. ATM-style scrambling 371 The ATM (x**43 + 1) LFSR can be applied to the entire frame as it is 372 inserted into the payload. 374 The polynomial has an undesirable interaction with the HDLC 16-bit 375 FCS (x**16 + x**12 + x**5 + 1). Analysis has shown [FC97] that there 376 exist undetectable burst error patterns, and that protection against 377 errors in general is reduced. 379 A.4. Rejected Alternatives 381 An enhancement to the octet-stuffing technique has been suggested 382 that checks the scrambler output for the all-zeros pattern, and sig- 383 nals an escape insertion to the HDLC-like framer (or Frame Relay). 384 This is only useful for highly integrated devices, and protects only 385 the first section. Other payload alignments could occur on later 386 sections in the path. 388 Several recurrent suggestions are less desirable than octet stuffing. 389 These suggestions do not provide backward compatibility. 391 Moreover, none of these suggestions scale well. They do not accommo- 392 date parallel processing, as they are bit-oriented. 394 Furthermore, for the LFSR techniques, the resulting protection is 395 probabilistic, not a complete solution. 397 ATM employs a payload LFSR scrambler that affects only the data por- 398 tion of the ATM cell, and does not include the ATM header. The gen- 399 erating polynomial for the LFSR is x**43 + 1. 401 The equivalent technique applied to PPP encapsulated packets in HDLC- 402 like frames (or Frame Relay) as they are inserted into the payload 403 would not include the framing octets. 405 This is rejected, as the scrambled data could mimic the frame delim- 406 iting flag sequence, resulting in incorrect frame detection. 408 Other LFSR polynomials have been proposed. These have a similar 409 error multiplication effect. 411 Security Considerations 413 This specification introduces no known security vulnerabilities. 415 Acknowledgements 417 PPP over SONET was first proposed by Craig Partridge (BBN). Some 418 information was obtained from the good folks at Bellcore. 420 Technical assistance and information was also provided by Victor Dem- 421 janenko (SUNY Buffalo). 423 Anonymous, Karl Fox (Ascend), Peter Lothberg (Sprint), Subhash Roy 424 (TranSwitch), Stuart Venters (Adtran), and Eric Verwillow (Juniper) 425 provided useful critiques of earlier versions of this document. 427 Special thanks to Ascend Communications (nee Morning Star Technolo- 428 gies) for providing computing resources and network access support 429 for writing this specification. 431 References 433 [RFC-1661] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", 434 STD-51, DayDreamer, July 1994. 436 [RFC-1662] Simpson, W., Editor, "PPP in HDLC-like Framing", STD-51, 437 DayDreamer, July 1994. 439 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 440 Requirement Levels", BCP-14, Harvard University, March 441 1997. 443 [RFC-yyyy] Simpson, W., "PPP in Ether-like Framing", DayDreamer, 444 work in progress. 446 [RFC-zzzz] Simpson, W., "Applicability Statement for PPP over 447 SONET/SDH", DayDreamer, work in progress. 449 [SONET] "Synchronous Optical Network (SONET) Transport Systems: 450 Common Generic Criteria", Bellcore, TR-NWT-000253 Issue 451 2, December 1991. 453 [G.707] CCITT Recommendation G.707, "Synchronous Digital Hierar- 454 chy Bit Rates", June 1992. 456 Contacts 458 Comments about this document should be discussed on the 459 pppsdh@greendragon.com or ietf-ppp@merit.edu mailing lists. 461 This document was reviewed by the Point-to-Point Protocol Working 462 Group of the Internet Engineering Task Force (IETF). The working 463 group can be contacted via the current chair: 465 Karl Fox 466 Ascend Communications 467 655 Metro Place South, Suite 370 468 Dublin, Ohio 43017 470 karl@Ascend.com 472 Questions about this document can also be directed to: 474 William Allen Simpson 475 DayDreamer 476 Computer Systems Consulting Services 477 1384 Fontaine 478 Madison Heights, Michigan 48071 480 wsimpson@UMich.edu 481 wsimpson@GreenDragon.com (preferred) 483 Full Copyright Statement 485 Copyright (C) William Allen Simpson (1993-1994, 1997-1998). All 486 Rights Reserved. 488 This document and translations of it may be copied and furnished to 489 others, and derivative works that comment on or otherwise explain it 490 or assist in its implementation may be prepared, copied, published 491 and distributed, in whole or in part, without restriction of any 492 kind, provided that the above copyright notice and this paragraph are 493 included on all such copies and derivative works. However, this doc- 494 ument itself may not be modified in any way, except as required to 495 translate it into languages other than English. 497 This document and the information contained herein is provided on an 498 "AS IS" basis and the author(s) DISCLAIM ALL WARRANTIES, EXPRESS OR 499 IMPLIED, INCLUDING (BUT NOT LIMITED TO) ANY WARRANTY THAT THE USE OF 500 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 501 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.