idnits 2.17.1 draft-ietf-malloc-madcap-nest-opt-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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. == 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 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 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 157 has weird spacing: '...= scope a...' == Line 390 has weird spacing: '...Y where zero...' == Line 469 has weird spacing: '...ent and nulli...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (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 (29 October 1999) is 8939 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'OPTID' is mentioned on line 454, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'KERM' -- Possible downref: Non-RFC (?) normative reference: ref. 'MAAA' == Outdated reference: A later version (-07) exists of draft-ietf-malloc-madcap-03 == Outdated reference: A later version (-06) exists of draft-ietf-mboned-mzap-03 ** Downref: Normative reference to an Historic draft: draft-ietf-mboned-mzap (ref. 'MZAP') Summary: 5 errors (**), 0 flaws (~~), 9 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Malloc Working Group Roger Kermode 2 Internet Engineering Task Force Motorola 3 INTERNET-DRAFT 29 April 1999 4 Expires 29 October 1999 6 MADCAP Multicast Scope Nesting State Option 7 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance 12 with all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as 17 Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other 21 documents at any time. It is inappropriate to use Internet- 22 Drafts as reference material or to cite them other than as 23 "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 This document defines a new option to the Multicast Address Dynamic 34 Client Allocation Protocol (MADCAP) to support nested scoping. The 35 new option's purpose is to allow clients to learn which scopes nest 36 inside each other, and hence may be used for expanding scope searches 37 or hierarchical multicast transport. 39 Copyright Notice 41 Copyright (C) The Internet Society (1999). All Rights Reserved. 43 Contents 44 Abstract. . . . . . . . . . . . . . . . . . . . . . . . . 1 46 1. Introduction. . . . . . . . . . . . . . . . . . . . . 3 47 1.1 Time-To-Live (TTL) Scoping Split Horizon Effect. . 3 48 1.2 Eliminating the Split Horizion Effect with 49 Administrative Scoping . . . . . . . . . . . . . 4 50 1.3 Terminology. . . . . . . . . . . . . . . . . . . . 5 52 2. Nested Scope Discovery. . . . . . . . . . . . . . . . 5 53 2.1 MADCAP processing of MZAP messages . . . . . . . . 6 54 2.1.1 Zone Nesting State . . . . . . . . . . . . . 6 55 2.1.2 Updating Scope Nesting State via the 56 observation of NIMs. . . . . . . . . . . . . 7 57 2.1.3 Updating Scope Nesting State due to 58 Timer Expiration . . . . . . . . . . . . . . 7 59 2.2 Multicast Scope List Option. . . . . . . . . . . . 8 60 2.3 Multicast Scope Nesting State Option . . . . . . . 8 61 2.3.1 Representing the Multicast 62 Scope Nesting State. . . . . . . . . . . . . 8 63 2.3.2 Multicast Scope Nesting State Option Usage . 10 65 3. Multicast Scope Nesting State Option Format . . . . . 10 67 4. Constants . . . . . . . . . . . . . . . . . . . . . . 11 69 5. Security Considerations . . . . . . . . . . . . . . . 11 71 6. IANA Considerations . . . . . . . . . . . . . . . . . 11 73 7. Acknowledgements. . . . . . . . . . . . . . . . . . . 11 75 8. References. . . . . . . . . . . . . . . . . . . . . . 12 77 9. Author's Address. . . . . . . . . . . . . . . . . . . 12 79 10. Full Copyright Statement. . . . . . . . . . . . . . . 12 81 1. Introduction 83 The Multicast Address Dynamic Client Allocation Protocol (MADCAP) 84 [MADCAP] affords client applications the ability to request multicast 85 address allocation services from multicast address allocation 86 servers. As part of the Multicast Address Allocation Architecture 87 [MAAA], MADCAP gives clients the ability to reserve, request, and 88 extend leases on multicast addresses. 90 A new MADCAP option, the "Multicast Scope Nesting State" option is 91 proposed to allow clients to learn not only which scopes exist via 92 the existing "Multicast Scope List" option, but how these scopes nest 93 inside each other. This new option will also afford clients the 94 ability to make better scope selections for a given session and also 95 to construct hierarchies of administratively scoped zones. These 96 hierarchies may then be used to perform expanding scope searches 97 instead of the expanding ring or increasing-TTL searches. Expanding 98 scope searches do not suffer from the Split-Horizon Effect present in 99 expanding ring searches, and therefore both simplify protocol design 100 and provide better localization. 102 1.1 Time-To-Live (TTL) Scoping Split Horizon Effect 104 Multicast searching and localized recovery transport techniques that 105 rely on TTL scoping are known to suffer when deployed in a wide scale 106 manner. The failing lies in the split horizon effect shown below in 107 Figure 1. Here a requestor and responder must each use a TTL that is 108 sufficiently large that they will reach the other. When they are 109 separated by many hops the TTL becomes large and the number of 110 receivers within the multicast tree that only receive either the 111 request or the response can become very large. 113 ....... ******* 114 ... *** *** A Only hears S 115 .. ** .. ** B hears S and R 116 . * . * C Only hears R 117 . * . * 118 . S<------->R * . TTL Boundary for S 119 . * . * * TTL Boundary for R 120 . A * B . C * 121 .. ** .. ** 122 ... *** *** 123 ....... ******* 125 Figure 1 : Split Horizon Problem from TLL scoping 127 1.2 Eliminating the Split Horizon Effect with Administrative Scoping 129 Ideally, a mechanism that either eliminates or minimizes the size of 130 the A and C regions in Figure 1. as shown in Figure 2. is needed to 131 solve this problem. One mechanism that affords this ability is 132 administrative scoping [RFC2365], in which routers prevent the 133 passing of packets within a certain range of multicast addresses. 134 Routers that have this feature can be configured to provide a 135 perimeter around a region of the network. This perimeter is said to 136 encompass an administratively scoped zone inside of which traffic 137 sent to that particular range of multicast addresses can neither 138 leave nor enter. Routers can construct and manage administratively 139 scoped zones using the MZAP [MZAP] protocol. 141 ........................ 142 . . 143 . many hops . 144 .S<------------------------>R. 145 . . 146 . . 147 ........................ 149 Figure 2 : Eliminating the Split Horizon Effect 151 MZAP also includes the ability to determine whether or not 152 administratively scoped regions nest inside one another. This allows 153 hierarchies such as that shown in Figure 1. to be constructed. 155 . . . . . . . . . . . . . . . . . . 156 . scope a . Scope Boundaries 157 . . . = scope a 158 . _______________ ________________ . - = scopes b,c 159 . / scope b \ / scope c \ . # = scopes d,e,f, & g 160 .| | | |. 161 .| ##### ##### | | ##### ##### |. 162 .| #scope# #scope#| | #scope# #scope# |. 163 .\ # d # # e #| | # f # # g # /. 164 .\ #### #####/ \ ##### #### /. 165 .\____________/ \_____________/. 166 . . . . . . . . . . . . . . . . . 168 Figure 3 : Admin Scope Zone Nesting Hierarchy example 170 A generic expanding scope search algorithm [KERM] that exploits the 171 existence of a hierarchy of administratively scoped zones is: 173 1) Starting with the smallest known scope for the session, a 174 requestor in that session issues a request and waits for a reply. 176 2) If a node within that scope hears a request at a certain scope 177 that it can satisfy it sends a response at that same scope, 178 possibly after some random delay to reduce duplicate responses. 180 3) Nodes that receive a response to a particular request while 181 waiting to send a response to that request, suppress their own 182 response. 184 4) If a requestor issues a request to a scope, and does not hear a 185 response after specified amount of time, it retransmits its 186 request at the same scope a small number of additional times. 187 Should these retries fail to elicit a response, the requestor 188 increases the scope to the next largest scope and tries 189 again. 191 5) Requestors increase the scope of the request according to 192 step 4 until either a response is received, or the largest 193 legal scope for the session is reached. Should attempts to 194 elicit a response at the largest possible scope for the 195 session fail to yield a response, the requestor may conclude 196 that the request cannot be met. 198 1.3. Terminology 200 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 201 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and"OPTIONAL" in this 202 document are to be interpreted as described in RFC 2119 [RFC2119]. 204 Throughout the rest of this document, the words "server" or "MADCAP 205 server" refer to a host providing multicast address allocation 206 services via MADCAP. The words "client" or "MADCAP client" refer to a 207 host requesting multicast address allocation services via MADCAP. 209 2. Nested Scope Discovery 211 The "Multicast Scope Nesting State" option is proposed to augment the 212 "Multicast Scope List" option within the MADCAP protocol by providing 213 additional information to applications about how scopes nest. MADCAP 214 servers shall learn this additional information for their clients by 215 noting the contents of Zone Not Inside Messages (ZNIM) that are 216 periodically transmitted by the Zone Border Routers that enforce the 217 boundaries of administratively scoped zones. 219 2.1 MADCAP Server processing of MZAP messages 221 MADCAP servers listen to MZAP traffic originated by ZBRs to learn 222 which scopes exist (via Zone Announcement Messages, ZAMs) and which 223 of these scopes do not nest (via Not Inside Messages, NIMs). This 224 state must be cached within the MADCAP server. 226 2.1.1 Scope Nesting State 228 Two scopes, X and Y, can be related in one of four possible ways. 229 1) X nests inside Y, 230 2) Y nests inside X, 231 3) X and Y do not nest (the overlap case), and 232 4) X and Y nest inside each other. 234 The fourth case SHOULD be interpreted as meaning that X and Y have 235 exactly the same border. This does not mean that X and Y are the same 236 scope since X and Y may correspond to different ranges of the 237 multicast address space. 239 This state MUST be stored in the MADCAP servers which MUST allow the 240 state to be updated as network conditions change. Each MADCAP server 241 SHOULD therefore define two pieces of state that describe whether 242 "scope X nests in scope Y" or vice versa. For the remainder of this 243 document the nesting relationship shall be denoted as the "/" where 244 X/Y defines the relation "X nests inside Y". This relation shall be 245 understood to take one of the values "true", or "false." Nesting 246 relationship state that is indeterminate is considered to be "false." 248 Since the decision as to whether one scope nests inside another must 249 be made in a collective fashion by all the routers for a scope, 250 MADCAP servers MUST include mechanisms to allow for: 252 a) whether the nesting decision is still under consideration or 253 can be considered definitive, and therefore be announced to 254 MADCAP clients. 256 b) whether one or both scopes for a particular nesting state entry 257 have been destroyed, and hence whether the nesting state should 258 therefore be discarded. 260 c) whether the scope boundaries have changed so that whereas scope 261 X did or did not nest inside scope Y, the opposite is now true. 263 To realize a) and b) MADCAP servers MUST implement the following two 264 timers; NEST_NO_NIM_TIMER, SCOPES_EXIST_TIMER. 266 The first timer, NEST_NO_NIM_TIMER, is used to mark time between a 267 MADCAP server's first hearing of a scope and making a decision about 268 its relationship to other zones. Up until the time this timer expires 269 MADCAP servers MUST NOT conclude that the scope nests within another. 271 The NEST_NO_NIM_TIMER timer will also be used to timeout X/Y = 272 "false" state to allow X/Y to be reset to true in the event that the 273 boundaries for zone X and zone Y change so that zone X now nests 274 inside zone Y. 276 The second timer SCOPES_EXIST_TIMER will be used to timeout the 277 internal state between two scopes in the event that one or both 278 scopes are destroyed. 280 2.1.2 Updating Scope Nesting State via the observation of NIMs 282 When a MADCAP server S receives a NIM from a ZBR containing 283 information that scope X does not nest in scope Y, it MUST update its 284 internal state in the following manner. 286 1) S SHOULD update its internal X/Y state to "false". 287 2) S SHOULD restart NEST_NO_NIM_TIMER for the newly updated 288 X/Y state. 290 2.1.3 Updating Scope Nesting State due to timer expiration. 292 MADCAP servers will also update X/Y nesting state upon the expiration 293 of timers. 295 o If the NEST_NO_NIM_TIMER expires for a state entry X/Y AND no 296 NIMs have been received that indicate scope X does not nest 297 inside scope Y, a MADCAP Server, S, MAY conclude that scope X 298 nests inside scope Y. As a result S will change X/Y from "false" 299 to "true". 301 When a state change from "false" to "true" occurs for X/Y, S must 302 also start the ZONES_EXIST_TIMER timer for X/Y. The 303 ZONES_EXIST_TIMER should only reset when a ZAM has been received 304 for both zone X and zone Y since the last time it was restarted. 305 This ensures that both zone X and zone Y are known to still exist. 307 o If the ZONES_EXIST_TIMER expires for a state entry X/Y, S 308 SHOULD conclude that either zone Y or zone X no longer exists and 309 hence that both X/Y and Y/X state should be destroyed. 311 2.2 Multicast Scope List Option 313 To understand the "Multicast Scope Nesting State" option one must 314 first understand the the "Multicast Scope List" option. 316 The Multicast Scope List option in MADCAP is used by MADCAP servers 317 to inform MADCAP clients of which zones are visible. Visible scopes 318 are enumerated inside the option as successive tuples, where each 319 tuple consists of the following information: 321 o Scope ID: 322 The smallest address for the range of multicast addresses 323 covered by this scop 325 o Last Address: 326 The largest address for the range of multicast addresses 327 covered by this scope. 329 o TTL: 330 The TTL to be used when sending message to this scope. 332 o Name(s): 333 One or more languages specific name for the scope. 335 2.3 Multicast Scope Nesting State Option 337 Given a Multicast Scope List containing descriptions for n scopes one 338 can form n(n-1)/2 pairings. As was shown in section 2.1.1 each 339 pairing can take on one of four possible states. Thus, for a list of 340 n scopes there exists 2 pieces of information for each pairing for a 341 total of n(n-1) pieces of information regarding which scopes do and 342 do not nest inside each other. This information is most easily and 343 efficiently conveyed in the a compressed bit matrix as shown in 344 section 2.4. 346 2.3.1 Representing the Multicast Scope Nesting State 348 As was stated in section 2.3, the Multicast Nesting State option must 349 convey a total of n(n-1) pieces of state, where n is the number of 350 scopes listed in the preceding Multicast Scope List Option. This 351 information will be sparse, since at most only a few scopes will 352 nest. 354 There are several ways to represent this information using full 355 matricies, sparse-matricies, and using lists of variable length 356 lists. In the interests of maximal efficiency and flexibility, the 357 Multicast Nesting State Option uses a bit-packed matrix approach. In 358 this approach a matrix constructed for each piece of X/Y state where 359 X is the row and Y is the column. A "1" in the matrix means that the 360 relationship "row nests inside column" is true, while a "0" means 361 that this relationship is wither false or indeterminate. The 362 diagonal of the matrix is removed, since this is the case where X is 363 the same as Y, and each row is then zero-padded to the next byte 364 boundary to give the final representation. 366 An example of how a matrix would be constructed for the following 367 scope nestings S1/S2, S2/S3, S2/S4, S3/S5, S4/S5, S5/S6, and S6/S7. 368 Note that a number of additional nesting relationships are implied 369 from this set. ________________________________ 370 /............ \ \ \ 371 /.S3 _________._____ \ \ \ 372 |. /+--+ \ . \ | | | 373 |. | |S1| S2 | . S4 | S5 | S6 | S7 | 374 |. \+--+ / . | | | | 375 \. \______/ . | | | | 376 \....\....... / / / / 377 \ \___________/ / / / 378 \___________________/ / / 379 \ Y \______________________/ / 380 X \ 1 2 3 4 5 6 7 \_________________________/ 381 +-+-+-+-+-+-+-+ 382 1 |1 1 1 1 1 1 1| *111111 1111 1100 0xfc 383 2 |0 1 1 1 1 1 1| 0*11111 0111 1100 0x7c 384 3 |0 0 1 0 1 1 1| 00*0111 0001 1100 0x1c 385 4 |0 0 0 1 1 1 1| => 000*111 => 0001 1100 => 0x1c 386 5 |0 0 0 0 1 1 1| 0000*11 0000 1100 0x0c 387 6 |0 0 0 0 0 1 1| 00000*1 0000 0100 0x04 388 7 |0 0 0 0 0 0 1| 000000* 0000 0000 0x00 389 +-+-+-+-+-+-+-+ ^^ 390 * = X/Y where zero padding 391 X == Y 392 Final Representation: 0xfc 0x7c 0x1c 0x1c 0x0c 0x04 0x00 394 Figure 4. Scope Nesting Example 396 2.3.2 Multicast Scope Nesting State Option Usage 398 The "Multicast Scope Nesting State" option is dependent upon the 399 "Multicast Scope List" option. This decision was made according to 400 the following reasoning. The Multicast Nest State Option requires 401 that the scopes be identified along with their nesting properties. 402 Since the information needed to describe a scope is contained in the 403 Multicast Scope List option and this information can change, the 404 MADCAP messages that contain the Multicast Scope Nesting State option 405 must be atomic and therefore must include the "Multicast Scope List 406 Option." 408 Thus, the "Multicast Scope Nesting State" option MAY only be used in 409 messages that carry the "Multicast Scope List" option, specifically: 411 DISCOVER, OFFER, ACK (in response to RENEW) 413 The "Multicast Scope Nesting State" option MUST NOT be used in 414 messages that do not carry the "Multicast Scope List" option, 415 specifically: 417 INFORM, ACK (in response to INFORM), RENEW, RELEASE, 418 ACK (in response to RELEASE), NAK, 419 any DISCOVER/OFFER/ACK (in response to RENEW) that 420 does not carry the "Multicast Scope List" 422 Since the Multicast Nest State option is dependent upon the Multicast 423 Scope List option, it MUST follow, and NEVER precede, the Multicast 424 Scope List option. 426 3. Multicast Scope Nesting State Option Format 428 Code Len Count Nest State Matrix 429 +-----+-----+-----+-----+-----+-----+-...-+-----+ 430 | OPTID | p | m | N1 | | Nm | 431 +-----+-----+-----+-----+-----+-----+-...-+-----+ 433 Code: 16 bits 434 Option identifier (OPTID), to be assigned by IANA. 436 Len: 16 bits 437 The length of the option in bytes. 439 Count: 8 bits 440 The number of zones present in the Nest State Matrix. This value 441 MUST be identical to the Count field in the preceding Multicast 442 State List option. 444 Nest State Matrix: 445 The compressed bit-packed representation of the matrix, derived 446 in the same manner as shown in Figure 4. Note for N scopes 447 the compressed matrix will be Nxceil((N-1)/8) bytes long. The 448 scopes corresponding to the rows and columns of this matrix 449 list in the same order as they appear in the Multicast Scope 450 List Option. 452 4. Constants 454 [OPTID] The option identifier for the Mutlicast Scope Nesting State 455 option, to be assigned by IANA. 457 5. Security Considerations 459 Since this draft proposes an extension to the MADCAP protocol via the 460 addition of a new option, the same set of security concerns apply. 462 In addition to these concerns are those that would arise were the 463 information in the Multicast Scope Nesting State option to be 464 falsified. In this case the clients would be misinformed as to which 465 scopes nest inside one another. In this event, the client would then 466 make incorrect decisions regarding the order in which to use the 467 scopes. The effect of this would be to use larger scopes than 468 necessary, which would effectively flatten any scope hierarchy 469 present and nullify the advantage afforded by the hierarchy's 470 presence. 472 Thus a malformed or tampered Multicast Scope Nesting option may cause 473 protocols that rely upon the existence of a scoping hierarchy to 474 scale less well, but it would not prevent them from working. 476 6. IANA Considerations 478 The Multicast Nesting State Option will require the assignment of an 479 additional option code to the MADCAP [MADCAP] protocol. 481 7. Acknowledgments 483 The Author would like to acknowledge Mark Handley and Dave Thaler for 484 the helpful discussions and feedback which helped shape and refine 485 this document. 487 8. References 489 [KERM] Kermode, R., "Smart Network Caches: Localized Content 490 and Application Negotiated Recovery Mechanisms for 491 Multicast Media Distribution", Ph.D. Thesis, MIT 492 Media Laboratory, June 1998. 494 [MAAA] Handley, M., Thaler, D., and D. Estrin, "The Internet 495 Multicast Address Allocation Architecture", Internet 496 Draft, December 1997. 498 [MADCAP] Patel. B.V., Shah, M., Hanna, S.R., "Multicast Address 499 Dynamic Client Allocation Protocol (MADCAP)", Internet 500 Draft, draft-ietf-malloc-madcap-03.txt 502 [MZAP] Handley, M., Thaler, D., Kermode, R., "Multicast-Scope 503 Zone Announcement Protocol (MZAP)", 504 draft-ietf-mboned-mzap-03.txt, Internet-Draft, February, 505 1999. 507 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 508 Requirement Levels", BCP, RFC 2119, March 1997. 510 [RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP, 511 RFC 2365, July 1998. 513 9. Author's Address 515 Roger Kermode 516 Motorola Australian Research Centre 517 12 Lord St, 518 Botany, NSW 2091 519 Australia 520 Email: Roger_Kermode@email.mot.com 522 10. Full Copyright Statement 524 Copyright (C) The Internet Society (1999). All Rights Reserved. 526 This document and translations of it may be copied and furnished to 527 others, and derivative works that comment on or otherwise explain it 528 or assist in its implementation may be prepared, copied, published 529 and distributed, in whole or in part, without restriction of any 530 kind, provided that the above copyright notice and this paragraph are 531 included on all such copies and derivative works. However, this 532 document itself may not be modified in any way, such as by removing 533 the copyright notice or references to the Internet Society or other 534 Internet organizations, except as needed for the purpose of 535 developing Internet standards in which case the procedures for 536 copyrights defined in the Internet languages other than English. 538 The limited permissions granted above are perpetual and will not be 539 revoked by the Internet Society or its successors or assigns. 541 This document and the information contained herein is provided on an 542 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 543 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 544 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 545 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 546 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."