idnits 2.17.1 draft-kempf-cdma-appl-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: ---------------------------------------------------------------------------- ** 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 the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 9 instances of too long lines in the document, the longest one being 7 characters in excess of 72. == There are 7 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 531 has weird spacing: '... copied and ...' == Line 532 has weird spacing: '...s, and deriv...' == Line 534 has weird spacing: '...ed, in whole...' == Line 535 has weird spacing: '...hat the above...' == Line 536 has weird spacing: '... and this ...' == (5 more instances...) -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-02) exists of draft-oneill-ema-00 == Outdated reference: A later version (-03) exists of draft-calhoun-mobileip-proactive-fa-00 Summary: 8 errors (**), 0 flaws (~~), 10 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT James Kempf 3 Category: Informational Sun Microsystems, Inc. 4 Title: draft-kempf-cdma-appl-01.txt Peter McCann 5 Date: July 2000 Lucent Technologies 6 Philip Roberts 7 Motorola, Inc. 9 IP Mobility and the CDMA Radio Access Network: 10 Applicability Statement for Soft Handoff 12 Status of this Memo 14 This document is an individual contribution for consideration by the 15 Mobile IP Working Group of the Internet Engineering Task Force. 17 Distribution of this memo is unlimited. 19 This document is an Internet-Draft and is in full conformance with 20 all provisions of Section 10 of RFC2026. Internet-Drafts are working 21 documents of the Internet Engineering Task Force (IETF), its areas, 22 and its working groups. Note that other groups may also distribute 23 working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at: 32 http://www.ietf.org/ietf/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be accessed at: 36 http://www.ietf.org/shadow.html. 38 Copyright (C) The Internet Society 2000. All Rights Reserved. 40 Abstract 42 Recently, there have been a variety of proposals submitted to the 43 Mobile IP Working Group and to other IETF working groups for IP 44 mobility solutions that seek to enhance or replace mobile IP. These 45 proposals, often characterized as micromobility or fast handoff, are 46 addressed primarily at the perceived need of multimedia sessions such 47 as video or voice over IP for faster handoff between radio base 48 stations, and are primarily directed at real time multimedia traffic 49 in 3rd generation cellular access networks. In this paper, we discuss 50 the design of CDMA radio access networks (RANs) and the applicability 51 of IP mobility to soft handoff in a CDMA RAN. We attempt to show that 52 given current IP routing algorithms and the constraints on a CDMA 53 RAN, IP mobility solutions have little, if any, role to play in 54 handoff within the RAN. In contrast, an IP mobility solution is 55 likely to play a big role in fast handoff between RANs, also called 56 hard handoff. While future developments in IP networking may change 57 this situation, IP mobility in CDMA networks currently seems to apply 58 only when the mobile node roams between disconnected RANs rather than 59 between base stations within a RAN or between connected RANs. 61 Table of Contents 63 1.0 Introduction 64 2.0 Terminology 65 3.0 RAN Architecture and Characteristics 66 4.0 Applicability of IP Mobility to Soft Handoff 67 5.0 Applicability of IP Mobility to Hard Handoff 68 6.0 Future Prospects for IP Mobility in the CDMA RAN 69 7.0 Summary 70 8.0 References 71 9.0 Authors' Addresses 72 10.0 Full Copyright Statement 74 1.0 Introduction 76 Mobile IP [1] allows IP hosts that change their point of attachment 77 to the network to keep their IP address as they change from their 78 home subnet to other subnets. Recently, there have been a variety of 79 proposals advanced for augmenting or replacing mobile IP in access 80 networks for cellular telephony systems. These proposals are often 81 characterized as supporting micromobility or fast handoff, and are 82 directed towards real time multimedia streams in 3rd generation 83 cellular networks (see [2] [3] [4] [5] and [7]). 85 While these proposals may have some applicability if handoff between 86 disconnected RANs is very frequent, their utility is lessened in the 87 presence of RAN mobility like that offered by today's TDMA and CDMA 88 systems. In fact if the RAN protocols offer transparent mobility 89 throughout a given domain of interconnected RANs, these proposals do 90 not contribute anything since they are essentially intra-domain 91 mobility management protocols. As cellular networks evolve towards 92 more pervasive IP technologies, host mobility within these networks 93 must accommodate some level of movement of IP traffic. 95 In this paper, we discuss CDMA radio access networks and why current 96 IP mobility solutions (including mobile IP) are not applicable to 97 soft handoff in a CDMA RAN. In effect, the CDMA RAN network with soft 98 handoff is a mobility mechanism transparent to L3 and above on the 99 mobile terminal and its corresponding host, similar to but not 100 identical with the mechanisms used for interaccess point mobility in 101 wireless LAN technologies such as IEEE 802.11 [8]. It is therefore 102 not an appropriate candidate for moving into the network layer given 103 current IP routing algorithms. In contrast, IP mobility solutions 104 that are directed at improving handoff performance within the core 105 network, often called hard handoff, are likely to play an important 106 role in enhancing the performance of IP networking for CDMA (see [6] 107 for an example). 109 2.0 Terminology 111 mobile terminal 112 A mobile IP host. In mobile IP terminology, this is called the 113 mobile node. 115 base station 116 A fixed, land-based radio transmitter and receiver, used to provide 117 cellular telephony radio coverage in a limited geographic area. A 118 mobile terminal may be in contact with one or more base stations at 119 a time in CDMA networks. Also called the Base Transceiver Station 120 (BTS) or Node B. 122 RAN 123 The radio access network. This is a wired network that sits between 124 a collection of base stations and the core, wired telephone 125 network. The RAN in CDMA systems is involved in real-time 126 distribution and collection of physical layer radio frames to and 127 from base stations, a topic that is discussed in the next section. 129 soft handoff 130 The process by which a moving CDMA mobile terminal is transferred 131 between one base station or set of base stations to another within 132 the radio access network. Soft handoff is typically very fast (on 133 the order of 20 ms) and has a low probability of dropping ongoing 134 real time connections. 136 hard handoff 137 The process by which a moving mobile terminal is transferred 138 between one cellular service provider's network and another or 139 between two RANs that do not share a direct connection within a 140 provider's network. Hard handoffs have a higher probability of 141 connection droppage, and are slower (usually 100 ms or more). 143 macrodiversity 144 A term used to describe the fact that within the CDMA RAN, there is 145 no single octet stream corresponding to the data that arrives at or 146 is sent by the mobile terminal. Macrodiversity results because the 147 mobile terminal can be in contact with more than one base station 148 at a time. 150 frame selector 151 A combination software/hardware unit at the gateway to the RAN that 152 combines the multiple octet streams from multiple base stations in 153 contact with a single mobile terminal into a single octet stream. A 154 similar process happens at the mobile terminal. Also called the 155 macrodiversity combiner or Selection and Distribution Unit (SDU). 157 RAN gateway 158 A functional unit positioned between the RAN and the core network. 159 The RAN gateway includes the frame selector, in addition to 160 functional units that perform soft handoff and radio frame 161 processing. Also called the Base Station Controller (BSC) or Radio 162 Network Controller (RNC). 164 radio frame 165 A short (usually 20 millisecond) unit of transmission at the 166 physical radio layer used to transmit data over the air to and from 167 the mobile terminal. The frames do not usually contain complete IP 168 packets as sent or received by applications on the mobile terminal, 169 but rather contain small sections of octet stream data that must be 170 framed by a higher layer protocol (such as PPP) to form IP packets. 171 On a basic fundamental data rate channel one radio frame contains 172 about 20 octets. Radio frames may be retransmitted a small number 173 of times to increase the reliability of the octet stream transport. 174 This is performed by a negative- acknowledgement protocol known as 175 the Radio Link Protocol (RLP). 177 3.0 RAN Architecture and Characteristics 179 A RAN consists of a RAN gateway connected to one or more base 180 stations. In the network to mobile terminal (forward) direction, the 181 RAN gateway performs the following functions: 183 1) Receive packets from the core network destined to the mobile 184 terminal, 186 2) Process those packets into radio frames, 188 3) Replicate the radio frames and transmit copies to base stations 189 that are currently in contact with the mobile terminal in a way 190 such that the frames arrive at each base station in a timely 191 fashion, 193 4) Manage the retransmission of individual radio frames when 194 negative acknowledgements are received. 196 In the mobile terminal to network (reverse) direction, the RAN 197 gateway performs the following functions: 199 1) Collect copies of the radio frames fowarded by base stations 200 that are currently in contact with the mobile terminal, 202 2) Combine these (possibly errorful) copies into one (hopefully 203 error-free) radio frame using some algorithm, 205 3) From the resulting radio frame stream, synthesize an outgoing 206 octet stream of packets for the core network. 208 In both directions, the RAN gateway performs the following function: 210 1) Manage the power with which mobile nodes and base stations are 211 transmitting, so as to maintain a low error rate while at the same 212 time minimizing the transmitted power and therefore interference 213 among different transmitters (and drain on the mobile terminal's 214 battery). 216 2) In concert with the mobile terminal, manage the set of base 217 stations with which a mobile terminal is in contact such that the 218 quality of the radio signal is maintained as the mobile terminal 219 moves. 221 The use of multiple base stations to transmit and receive the same 222 radio frames to and from the mobile node at the same time is known as 223 "macrodiversity" and can help to improve the reliability of the 224 wireless link. Note that some of the base stations may be owned by a 225 neighboring RAN and this necessitates a RAN-to-RAN interface to carry 226 the radio frames. 228 The following figure illustrates the architecture and how the CDMA 229 RAN network works: 231 Core Network 233 ^ 234 | incoming/outgoing octet stream 235 | from/to corresponding node 236 | (e.g. 129.142.68.79) 237 v 238 +-----------------------------------------------------+ 239 | RAN Gateway | 240 | | 241 | +-------------+ +-----------+ +----------+ | 242 | | | | | | | | 243 | | Frame | | Frame | | Soft | |-----------> 244 | | Selection | | Splitting | | Handoff | | to another 245 | | | | | | Control | | RAN Gateway 246 | +-------------+ +-----------+ +----------+ | in neighboring 247 | | RAN 248 | +---------------+ | 249 | | | | 250 | | Radio Frame | | 251 | | Processing | | 252 | | | | 253 | +---------------+ | 254 | | 255 +-----------------------------------------------------+ 256 | | | | * 257 | | | | * 258 | | ... | | * radio 259 | | | | * frames 260 | | | | * 261 | | | | * 262 +---------+ +---------+ +---------+ +---------+ 263 | Base | | Base | | Base | | Base | 264 | Station | | Station | | Station | | Station | 265 | B1 | | B2 | | B42 | | B43 | 266 +---------+ +---------+ +---------+ +---------+ 267 \ | 268 \ V 269 \---------> 270 | 271 ----- 272 / \ 273 ----- ----- 162.42.42.42 275 | mobile terminal|( ---> 276 ------------------ 277 ( ) ( ) 279 The links between the RAN gateway and the base stations are typically 280 point to point links today, though provisions exist in the 3rd 281 generation standards for switched networks. 283 In the above figure, a mobile terminal with IP address 162.42.42.42 284 is corresponding with a host having the IP address 129.142.68.79, 285 through a CDMA cellular network. The mobile terminal is in contact 286 with two base stations, B1 and B2. The RAN gateway takes incoming 287 packets from 129.142.68.79 and splits them into two streams that it 288 sends to base stations B1 and B2. A mobile terminal can be in 289 communication with up to 3 and, in some CDMA systems, up to 6 base 290 stations at a time. When the multiple octet streams are received at 291 the mobile terminal, the mobile terminal performs a sophisticated 292 combination of the multiple packet streams at L1 to deliver the end 293 packet to the application. 295 Packets flowing in the other direction, from 162.42.42.42 to 296 129.142.68.79, are put into an octet stream which is then divided 297 into radio frames. Each radio frame is received by B1 and B2 and 298 delivered to the frame selector in the RAN gateway. The frame 299 selector performs signal processing on the incoming radio frames and 300 produces a single frame that is then sent to the re-sequencing buffer 301 where the octet stream is re-created. The IP packets are formed from 302 the octet stream and transmitted into the core IP network. 304 An important point to note about the RAN is that, even if the RAN 305 itself is running IP, routing in the RAN does not use the mobile's IP 306 address. In fact, the IP packets sent by the mobile terminal are not 307 tunneled through the RAN nor do they necessarily appear in a form 308 that would be recognizable using a packet sniffer. The packets in the 309 RAN contain radio frames that have been highly processed into a form 310 that is extremely efficient for the base stations to handle and that 311 efficiently uses radio spectrum, including compensations for the 312 inherently lossy nature of the radio medium. 314 On the forward leg to the mobile terminal, because the delay and 315 jitter constraints between multiple base stations transmitting to the 316 same mobile terminal are so tight (5ms to 80ms), the RAN gateway 317 essentially puts out streams of radio frames that the base station 318 can quickly pull off the wire and transmit over the air. On the 319 reverse leg from the mobile terminal, the base station simply pulls 320 the radio frames off the air and puts them on the wire without any 321 further processing. The RAN gateway's radio frame processor is 322 responsible for making sure that the jitter and delay constraints are 323 met, and for processing packets from the core network into radio 324 frames. 326 When the mobile terminal begins to move out of range of stations B1 327 and B2, the RAN gateway adds and deletes base stations from the set 328 currently serving the mobile node. This process is called soft 329 handoff. Note that new base stations may belong to a connected 330 neighboring RAN which requires closely-coupled RAN-to-RAN 331 interaction. The real time constraints on soft handoff are extremely 332 tight. All base stations involved in soft handoff must transmit the 333 command for the mobile to move at the same time. North American 334 cellular networks use the Global Positioning System as a time source 335 to assure that these timing constraints are met. 337 As shown in the figure, two RAN gateways can be connected together 338 through a direct link. This link allows radio frames containing data 339 and RAN control protocol to flow between two RANs. As a result, two 340 RANs can perform soft handoff between them, increasing the quality 341 and reliability of the connection when a user moves between coverage 342 areas. A RAN gateway and its collection of base stations can only 343 cover a limited geographic area, so RAN interconnection is very 344 important in cellular networks for maintaining good connection 345 quality over large geographic areas. 347 4.0 Applicability of IP Mobility to Soft Handoff 349 Most of the proposals for IP mobility in the RAN assume the 350 following: 352 1) An end-to-end IP routing model for routing through the RAN. 354 2) A one-to-one mapping between the mobile terminal and the base 355 station with which it is in contact. 357 3) The IP packets coming from the mobile terminal are transported 358 directly on L2 in the RAN. 360 As the above discussion has attempted to show, the extremely tight 361 real time constraints on traffic in the RAN require that RAN traffic 362 be highly processed as radio frames for efficient delivery into and 363 from the radio medium by the base stations. This precludes routing IP 364 packets from the mobile directly over the RAN. Furthermore, because 365 there are multiple octet streams flowing over the RAN that correspond 366 to one logical octet stream going to and from the mobile terminal, 367 there is no one-to-one mapping between the mobile terminal and a base 368 station. 370 Taking mobile IP as an example, using mobile IP in the RAN would 371 require that a mobile IP foreign agent (FA) be present at each base 372 station. However, because the mobile terminal can be in contact with 373 up to 6 base stations at once, there is no unique care-of address for 374 the mobile (unless the mobile uses a co-located care-of address). 375 Therefore, the home agent (HA) would need to forward packets to 376 multiple FAs. Furthermore, on the reverse leg, a frame selector is 377 still necessary to generate a single packet for the corresponding 378 node. 380 In effect, the RAN controller is an application level transport and 381 mobility mechanism specialized to the CDMA radio medium. An 382 application's packets to/from the mobile effectively run over a 383 "stratified stack" in the RAN, in which the bottom stratum is the RAN 384 protocol stack, and the upper stratum is the IP stack on the mobile 385 terminal and corresponding node. The RAN controller is therefore not 386 a good candidate for replacing with current network level mobility 387 mechanisms. Because of the hard real time constraints involved in 388 soft handoff, the RAN controller's soft handoff function is also not 389 a good candidate for replacing with more general application level 390 mechanisms, such as SIP [4]. 392 5.0 Applicability of IP Mobility to Hard Handoff 394 Note that the above considerations do not apply to hard handoff, 395 which occurs outside of the RAN. When a mobile terminal moves between 396 two RANs that are not interconnected, the RAN controller defers 397 handoff to the core network. Some mechanism is necessary in the core 398 network to move the mobile terminal's point of attachement at the 399 network level. IP mobility solutions for fast handoff are applicable 400 here. 402 Proposals such as [6] that apply after frame selection do not involve 403 soft handoff and therefore are appropriate for implementing fast, 404 hard handoff. 406 6.0 Future Prospects for IP Mobility in the CDMA RAN 408 What would it take to enable IP mobility in the RAN? The question is 409 worth examining because the end-to-end model of networking which 410 would be required to make IP mobility work in the RAN has attractions 411 from the point of view of simplicity of network management and 412 transparency. 414 Certainly, routing the mobile's packets directly in the RAN would be 415 a major contributor. For that to happen, IP over the air interface 416 would be necessary. The major impediment to IP over the air is 417 currently header size, but new work in header compression may 418 eliminate this objection. Given that a spectrally efficient 419 representation of IP on the radio medium is possible, IP packets can 420 be sent out over the air by the mobile terminal, and the base 421 stations can handle the packets precisely as they currently do with 422 the specialized radio frames. The result would be that IP packets 423 from the radio would appear directly on L2 in the RAN, rather than in 424 a stratified stack. 426 However, there is still a problem with the multipath nature of 427 macrodiversity. On the forward leg, the routing from a single source 428 at the RAN gateway to multiple base stations looks like multicast, 429 but the real time constraints are extremely tight. On the the reverse 430 leg, however, traffic still needs to be combined in the wired network 431 behind the base stations. In order to accommodate macrodiversity, the 432 RAN would need to be a routing domain in which a multipath routing 433 protocol that performed frame selection in the border routers and 434 featured real time routing table convergence (for soft handoff) was 435 in use. These characteristics involve a considerable change from 436 existing IP routing algorithms (which do not require real time 437 convergence and do not involve multipath nor selection of particular 438 packets based on some algorithm). 440 While the prospects for moving IP into the RAN for transport of RAN 441 protocols and data/voice traffic from the mobile are good, it seems 442 unlikely that IP mobility will play any role in replacing CDMA soft 443 handoff in the immediate future. The stratified RAN stack supporting 444 CDMA soft handoff is a specialized, and therefore not a good 445 candidate for replacement by more general network or application 446 level mechanisms. In addition, even if IP is used for transport in 447 the RAN, if voice over IP is to completely replace the current radio 448 voice protocols, voice packets may need to be processed at the RAN 449 gateway for maximum efficiency and robustness over the radio medium. 451 7.0 Summary 453 Most proposals for IP mobility require a one-to-one mapping between 454 the mobile terminal and a base station with which it is in contact, 455 and assume end-to-end connectivity and consequently routing in the 456 radio access network based on the mobile's IP address. In CDMA 457 networks, macrodiversity and the need for extremely low delay and 458 jitter invalidate these assumptions. Consequently, IP mobility 459 solutions are not applicable to CDMA soft handoff. These 460 considerations do not, however, apply to hard handoff which occurs in 461 the core network after frame selection. 463 8.0 References 465 [1] Perkins, C. (ed.), IP Mobility Support for IPv4, revised, draft- 466 ietf-mobileip-rfc2002-bis.txt (work in progress), January, 2000. 468 [2] Vakil, Faramak, et. al., Host Mobility Management Protocol: 469 Extending SIP to 3G-IP Networks, draft-itsumo-hmmp-00.txt (work 470 in progress), October, 1999. 472 [3] E. Wedlund and H. Schulzrinne. Mobility Support Using SIP. Second 473 ACM/IEEE International Conference on Wireless and Mobile 474 Multimedia (WoWMoM'99). Seattle, Washington. Aug. 1999. 476 [4] O'Neill, A. and Corson, S., Edge Mobility Architecture, draft- 477 oneill-ema-00.txt (work in progress), October, 1999. 479 [5] Campbell, A., et. al., Cellular IP, draft-ietf-mobileip- 480 cellularip-00.txt, January, 2000. 482 [6] Kempf, J. and Calhoun, P., Foreign Agent Assisted Hand-off, 483 draft-calhoun-mobileip-proactive-fa-00.txt (work in progress), 484 January, 2000. 486 [7] Ramjee, R., et. al., IP micro-mobility support using HAWAII, 487 Internet Draft (work in progress), June 1999. 489 [8] IEEE, "Wireless LAN Medium Access Control and Physical Layer 490 Specifications", IEEE Std 802.11-1997, November 1997. 492 9.0 Authors' Addresses 494 Questions about this memo can be directed to: 496 James Kempf 497 Network and Security Research Center, Sun Labs 498 Sun Microsystems, Inc. 499 901 San Antonio Rd., UMPK15-214 500 Palo Alto, CA, 94303 501 USA 503 Phone: +1 650 786 5890 504 Fax: +1 650 786 6445 505 E-Mail: james.kempf@sun.com 507 Peter McCann 508 Bell Laboratories 509 263 Shuman Boulevard 510 Room 2Z-305 511 P.O. Box 3050 512 Naperville, IL, 60566 513 USA 515 Phone: +1 630 713 9359 516 Fax: +1 630 713 4982 517 E-Mail: mccap@research.bell-labs.com 519 Philip Roberts 520 Motorola, Inc. 521 1501 W. Shure Dr. 522 Arlington Heights, IL, 60015 524 Phone: +1 847 632 3148 525 E-Mail: qa3445@email.mot.com 527 9.0 Full Copyright Statement 529 Copyright (C) The Internet Society (2000). All Rights Reserved. 531 This document and translations of it may be copied and furnished 532 to others, and derivative works that comment on or otherwise 533 explain it or assist in its implementation may be prepared, copied, 534 published and distributed, in whole or in part, without 535 restriction of any kind, provided that the above copyright notice 536 and this paragraph are included on all such copies and derivative 537 works. However, this docu- ment itself may not be modified in any 538 way, such as by removing the copyright notice or references to the 539 Internet Society or other Inter- net organizations, except as needed 540 for the purpose of developing Internet standards in which case 541 the procedures for copyrights defined in the Internet Standards 542 process must be followed, or as required to translate it into 543 languages other than English. The limited permis- sions granted 544 above are perpetual and will not be revoked by the Internet 545 Society or its successors or assigns. This document and the 546 information contained herein is provided on an "AS IS" basis and 547 THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE 548 DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 549 LIMITED TO ANY WAR- RANTY THAT THE USE OF THE INFORMATION HEREIN 550 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 551 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."