idnits 2.17.00 (12 Aug 2021) /tmp/idnits53150/draft-na-nemo-gen-ro-model-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 3667, Section 5.1 on line 31. -- Found old boilerplate from RFC 3978, Section 5.5 on line 472. ** The document claims conformance with section 10 of RFC 2026, but uses some RFC 3978/3979 boilerplate. As RFC 3978/3979 replaces section 10 of RFC 2026, you should not claim conformance with it if you have changed to using RFC 3978/3979 boilerplate. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3978 Section 5.4 (updated by RFC 4748) Copyright Line. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 12 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' Scope Binding Updates)", draft-ernst-mobileip-v6-network-03' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 6. Security Considerations' ) ** 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 are 220 instances of too long lines in the document, the longest one being 16 characters in excess of 72. ** The abstract seems to contain references ([2], [20], [15], [16], [3], [17], [4], [18], [5], [19], [7], [8], [9], [10], [11], [12], [13], [1], [14]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 (July 2004) is 6519 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 section? '15' on line 410 looks like a reference -- Missing reference section? '14' on line 406 looks like a reference -- Missing reference section? '1' on line 363 looks like a reference -- Missing reference section? '4' on line 375 looks like a reference -- Missing reference section? '5' on line 380 looks like a reference -- Missing reference section? '19' on line 424 looks like a reference -- Missing reference section? '20' on line 428 looks like a reference -- Missing reference section? '10' on line 393 looks like a reference -- Missing reference section? '17' on line 417 looks like a reference -- Missing reference section? '2' on line 367 looks like a reference -- Missing reference section? '3' on line 370 looks like a reference -- Missing reference section? '7' on line 384 looks like a reference -- Missing reference section? '8' on line 387 looks like a reference -- Missing reference section? '9' on line 390 looks like a reference -- Missing reference section? '11' on line 396 looks like a reference -- Missing reference section? '12' on line 399 looks like a reference -- Missing reference section? '13' on line 403 looks like a reference -- Missing reference section? '16' on line 414 looks like a reference -- Missing reference section? '18' on line 420 looks like a reference Summary: 16 errors (**), 0 flaws (~~), 3 warnings (==), 23 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 NEMO Working Group Jongkeun Na 2 Internet Draft Seongho Cho 3 Expires: January 2005 Chongkwon Kim 4 Seoul National University 5 Changhoi Koo 6 Samsung Electronics 7 July 2004 9 Generic Route Optimization Model for NEMO Extended Support 10 draft-na-nemo-gen-ro-model-00 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other 24 documents at any time. It is inappropriate to use Internet-Drafts 25 as reference material or to cite them other than as "work in 26 progress. 28 By submitting this Internet-Draft, I certify that any applicable 29 patent or other IPR claims of which I am aware have been disclosed, 30 or will be disclosed, and any of which I become aware will be 31 disclosed, in accordance with RFC 3668. 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 Abstract 40 In this memo, we introduce the generic Route Optimization (RO) 41 model that can be used as a framework to evaluate the existing RO 42 models. Then, we analyze typical RO problems by virtue of that. And, 43 we discuss on the feasibility of achieving a unified RO in NEMO, 44 and enumerate the issues that should be cleared for the purpose of 45 that. 47 Conventions used in this document 49 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 50 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 51 this document are to be interpreted as described in RFC-2119. 53 Table of Contents 55 1. Introduction.................................................3 56 2. Generic Route Optimization Model.............................3 57 3. The Analysis of RO Problems in NEMO..........................5 58 3.1 RO in the infrastructure................................6 59 3.2 Nested Tunnels Optimization (NTO).......................7 60 4. Toward to a unified route optimization in NEMO...............8 61 5. Open Issues..................................................9 62 6. Security Considerations......................................9 63 References......................................................10 64 Acknowledgments.................................................11 65 Authors' Addresses..............................................11 67 1. Introduction 69 NEMO Basic Support Protocol [15] would suppose to support the 70 transparent mobility to mobile network nodes (MNNs) in mobile 71 networks by using MR-HA bi-directional tunnel. However, inherently 72 due to the use of the bi-directional tunnel, there are some types 73 of route optimization problem [14] that need our attention. 75 RO problems have a common property that there is an optimized path, 76 but it cannot be used due to support the transparent mobility to 77 the IP terminals. While preserving the goals of Mobile IP [1] and 78 NEMO Basic [15], it is impossible to realize RO without introducing 79 the tunnel-based virtual path over IP routing through some 80 extensions or new functionalities of routing facilities. This is 81 the reason why the existing proposed solutions for RO at least use 82 tunnel-based packet redirection or re-routing mechanism in the 83 extended routing facilities such as Correspondent Router (CR). 85 As a requirement about RO, we argue that RO in NEMO should be 86 provided by a unified solution which can solve most of RO problems 87 by applying the same principle to the routing facilities such as HA, 88 MR, CR. If each different RO solution is used to solve each RO 89 problem, it will produce the protocol redundancy and complexity in 90 the routing facilities. 92 In this memo, we introduce the generic RO model that can be used as 93 a framework to evaluate the existing RO models. Then, we analyze 94 typical RO problems by virtue of the generic RO model. And, we 95 discuss on the feasibility of achieving a unified RO in NEMO, and 96 enumerate the issues that should be cleared for the purpose of that. 98 2. Generic Route Optimization Model 100 Route Optimization in NEMO means that one routing entity uses an IP 101 tunnel to redirect the original packets to the other routing entity 102 that is most closely located from the destination. To enable such a 103 route optimization, two routing entities must recognize each other, 104 in other words, anyone among them should feel the need of RO tunnel 105 and initiate the signaling procedure to make an IP tunnel between 106 them. We can define such an IP tunnel as `RO Tunnel (ROT)` in NEMO 107 context because it is established for the purpose of route 108 optimization in NEMO. This is like the basic principle of Mobile IP. 109 In Mobile IP, MN detects its movement and initiates BU to HA. Such 110 an analogy can be extended to RO problem in NEMO. In this point of 111 view, we can extract some of statements characterizing how to 112 achieve RO tunnel. For example, which routing facilities can 113 initiate RO tunnel? What information does trigger such a RO tunnel? 114 How can the trigger information be delivered to the initiator of RO 115 tunnel? And so on. The answer to those of questions depends on the 116 problem spaces [14] and the proposed solutions [4][5][19][20] in 117 each problem space. 119 The attributes of RO tunnel can concretely well express the RO 120 context including the purpose of RO, the operation of RO, and the 121 effectiveness of RO. 123 TE[1] TS[0..n] TR[0..n] TE[1] 124 +--+---------+--+--------+--+--------+--+ 125 ====|XX|=========|XX|========|==|========|XX|==== 126 +--+---------+--+--------+--+--------+--+ 128 XX: Tunnel Processing (Encap./Decap.) 129 TE: Tunnel Endpoint 130 TS: Tunnel Switcher 131 TR: Tunnel Relay 133 Fig.1 Generic RO Tunnel (ROT) Model 135 Fig.1 shows the generalized ROT model. ROT can be made of at least 136 two TEs. In here, TE is a router or host which is allowed to 137 initiate or terminate the RO tunnel in the view of route 138 optimization. According to the type of ROT, ROT can include zero or 139 more TS for switching an incoming tunnel to an outgoing tunnel at 140 that point, zero or more TR for relaying the tunneled packets to 141 next intermediate point. As of TR, The difference is that it 142 operates a routing mechanism, such as Source Routing using RH0 143 header [10], based on the packet header information without the 144 knowledge of the end-to-end tunneling, while TS processes the 145 tunnel switching based on a given tunnel mapping information that 146 consistently maintained in that point by interacting with other 147 tunnel endpoints. 149 From the general ROT model, we can drive the following attributes 150 which can be exploited to characterize a specific RO model. 152 RO Initiator (ROI) 154 We need to identify which TE among two TEs can be the initiator 155 in making a RO tunnel. This parameter depends on the applied RO 156 scheme. In one RO scheme, MR is only the initiator, on the other 157 hand, HA and CR can be the initiator in the other RO scheme. 159 RO Responder (ROR) 160 We need to identify which routing facilities can be the 161 responder in making a RO tunnel. This parameter also depends on 162 the applied RO scheme. 164 RO Trigger Source (ROTS) 166 The RO initiator (ROI) is recognized for the need of RO from 167 this information. For example, an explicit RO bit in the packet 168 header can be used to force the receiver to start the RO. 170 RO Responder Information (RORI) 172 This information is used for the RO initiator (ROI) to identify 173 the RO responder (ROR). It would include the address information 174 of the moving entity such as MR, or the address information of 175 the correspondent nodes. 177 RO Discovery Mechanism (RODM) 179 This mechanism describes that how RORI can be delivered to the 180 RO initiator (ROI). In other words, ROI can get RORI by using 181 this discovery mechanism. For example, if ROI itself try to find 182 its ROR using IPv6 anycast address, RORI becomes an address of 183 ROR and we can say that RODM is IPv6 anycasting mechanism. 185 RO Tunnel Type (ROTT) 187 ROTT can be classified as the followings: Simple ROT (SiROT), 188 Switched ROT (SwROT), Releyed ROT (ReROT). SiROT consists of 189 only two TEs. SwROT consists of one or more TS between two TEs. 190 ReROT consists of one or more TR between two TEs. For example, 191 we can say that RRH [4] uses ReROT as RO Tunnel Type, HMIPv6 192 uses SwROT. 194 More attributes to be defined. 196 3. The Analysis of RO Problems in NEMO 198 In this section, we analyze typical RO problems in NEMO using the 199 generic ROT model. 201 3.1 RO in the infrastructure 203 TE[1] TE[1] 204 +--+---------------------------------+--+ 205 ====|XX|=================================|XX|==== 206 +--+---------------------------------+--+ 208 Fig.2 SiROT based RO in the infrastructure 210 Fig.2 shows the simple RO in the infrastructure. This RO model was 211 used in ORC [19]. According to the generic ROT model, the following 212 formulation is possible. 214 TE: Mobile Router (MR), Optimized Route Cache (ORC) Router 215 ROI: MR 216 ROR: ORC Router 217 ROTS: the packet sent from any CN via MR-HA default tunnel 218 RORI: the global IPv6 address of ORC Router 219 RODM: IPv6 anycast addressing 220 ROTT: SiROT 222 Above attributes compactly describes that this RO implements ROT 223 between MR and ORC Router, and MR initiates the signaling procedure 224 for ROT to ORC Router after getting the global IPv6 address of ORC 225 Router through IPv6 anycast addressing. This RO model also includes 226 some RO approaches, such as C-Side Router or Correspondent Router 227 (CR), mentioned in RO-Taxonomy [14]. To include those of RO 228 approaches, we can loosely redefine above attributes as follows: 230 TE: Mobile Router (MR), Optimized Route Cache (ORC) Router, C-Side 231 Router, Correspondent Router (CR) 232 ROI: MR 233 ROR: ORC Router, C-Side Router, CR 234 ROTS: the packet sent from any CN via MR-HA default tunnel 235 RORI: the global IPv6 address of ROR 236 RODM: IPv6 anycast addressing 237 ROTT: SiROT 239 TE[1] TS[1] TE[1] 240 +--+---------------------+--+--------+--+ 241 ====|XX|=====================|XX|========|XX|==== 242 +--+---------------------+--+--------+--+ 244 Fig.3 SwROT based RO in the infrastructure 246 Fig.3 shows extended RO in the infrastructure. This RO model 247 includes one TS entity and two TEs. Distributed Anchor Routers 248 described in RO-Taxonomy [14] can be expressed as this model like 249 below. 251 TE: Mobile Router (MR), C-Side Anchor Router 252 TS: M-Side Anchor Router (a.k.a Mobility Anchor Point in HMIPv6) 253 ROI: Not mentioned 254 ROR: Not mentioned 255 ROTS: Not mentioned 256 RORI: Not mentioned 257 RODM: Not mentioned 258 ROTT: SwROT 260 In this case, most of attributes in the ROT model are not 261 determined, so it is required to deeply understand this RO problem 262 and derive its viable solution. 264 3.2 Nested Tunnels Optimization (NTO) 266 NTO can be modeled like Fig.4 by using the ROT model. For example, 267 the attributes of RRH [4] model are as follows: 269 TE[1] TR[1..n] TE[1] 270 +--+---------------------+--+--------+--+ 271 ====|XX|=====================|==|========|XX|==== 272 +--+---------------------+--+--------+--+ 274 Fig.4 ReROT based NTO 276 TE: Mobile Router (MR), Home Agent (HA) 277 TR: MR (via Source Routing) 278 ROI: MR 279 ROR: HA 280 ROTS: TIO option in RA [14] 281 RORI: Nested Path Information like MR3->MR2->MR1->HA3 282 RODM: Using Reverse Routing Header (RRH) 283 ROTT: ReROT 285 Similarly, ARO [5] can be expressed as follows: 287 TE: Mobile Router (MR), Home Agent (HA) 288 TR: MR (via Source Routing) 289 ROI: MR 290 ROR: HA 291 ROTS: BU with ARO option, Recursive Binding Update by ancestor MRs 292 RORI: Nested Path Information like MR3->MR2->MR1->HA3 293 RODM: Using Access Router Option (ARO) & Recursive BU 294 ROTT: ReROT 296 4. Toward to a unified route optimization in NEMO 298 There are some efforts for Route Optimization (RO). For RO in the 299 routing infrastructure, some approaches such as VIP [17], ORC [19] 300 require a special router or the extension of the existing router 301 which can handle the packet redirection to gain RO effect. The RO 302 schemes belong to this category can be applied to both Mobile IP 303 and NEMO in IP routing infrastructure. On the other hand, There are 304 other kinds of the NEMO-specific RO problem. [14] well defines RO 305 problem spaces of NEMO and briefly analyzes the proposed interim 306 solutions. Typically, one of NEMO-specific RO problem is a nested 307 tunneling problem that can be formed due to the network mobility. 308 Most of proposed solutions are for solving that problem. As of now, 309 it's not easy to say how RO problems in NEMO can be best solved in 310 the reasonable manner. However, the sure thing is that current 311 proposed solutions can be applied only to one problem space of RO. 312 That is an uncomfortable and unnatural facet in supporting coherent 313 network mobility. We need a simple and effective, unified route 314 optimization scheme for network mobility. 316 With the help of the ROT model, we can evaluate whether or not 317 there is the feasibility of achieving a unified route optimization 318 in NEMO, and enumerate the issues that should be cleared for the 319 purpose of that. As a unified RO model, let us illustrate one 320 example as Fig.5. In here, TR can be zero. That is only difference 321 in comparing with Fig.4. However, this trivial difference in the 322 model implies that this model can support SiROT based RO in the 323 infrastructure as well as ReROT based NTO. PCH [20] approach 324 belongs to this model. 326 TE[1] TR[0..n] TE[1] 327 +--+---------------------+--+--------+--+ 328 ====|XX|=====================|==|========|XX|==== 329 +--+---------------------+--+--------+--+ 331 Fig.5 A unified RO supporting ReROT as well as SiROT 333 As an instance of a unified RO, The attributes of PCH [20] model 334 can be summarized as follows: 336 TE: Mobile Router (MR), Home Agent (HA), Correspondent Router (CR) 337 TR: MR (via Source Routing) 338 ROI: CR, HA 339 ROR: MR 340 ROTS: Receiving the packet with Path Control Header (PCH) 341 RORI: Nested Path Information like MR1-MR2-MR3, contained in PCH 342 RODM: PCH Piggybacking by HA 343 ROTT: SiROT+ReROT 345 5. Open Issues 347 ? Functional entities involving in RO 349 ? Source routing in the inside of nested mobile network 351 ? Considerations on RO in multi-homed mobile networks 353 ? Performance / Evaluation Metric for RO 355 TBD 357 6. Security Considerations 359 TBD 361 References 363 [1] Perkins, C., Johnson, D. and J. Arkko, "Mobility Support in 364 IPv6", draft-ietf-mobileip-ipv6-18 (work in progress), July 365 2002. 367 [2] Ernst, T. and H. Lach, "Network Mobility Support Terminology", 368 draft-ietf-nemo-terminology-00 (work in progress), May 2003. 370 [3] Ernst, T., Castelluccia, C., Bellier, L., Lach, H. and A. 371 Olivereau, "Mobile Networks Support in Mobile IPv6 (Prefix 372 Scope Binding Updates)", draft-ernst-mobileip-v6-network-03 373 (work in progress), March 2002. 375 [4] Thubert, P., and Molteni, M., "IPv6 Reverse Routing Header 376 and Its Application to Mobile Networks", Internet Draft: 377 draft-thubert-nemo-reverse-routing-header-01 378 (work in progress), Oct 2002. 380 [5] Chan-Wah Ng, and Takeshi Tanaka, "Securing Nested Tunnels 381 Optimization with Access Router Option", Internet Draft:draft 382 -ng-nemo-access-router-option-00(work in progress), Oct 2002. 384 [7] Kent, S. and R. Atkinson, "Security Architecture for the 385 Internet Protocol", RFC 2401, November 1998. 387 [8] Kent, S. and R. Atkinson, "IP Authentication Header", 388 RFC 2402, November 1998. 390 [9] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload 391 (ESP)", RFC 2406, November 1998. 393 [10] Deering, S. and R. Hinden, "Internet Protocol, 394 Version 6 (IPv6) Specification", RFC 2460, December 1998. 396 [11] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery 397 for IP Version 6 (IPv6)", RFC 2461, December 1998. 399 [12] Conta, A. and S. Deering, "Internet Control Message Protocol 400 (ICMPv6) for the Internet Protocol Version 6 (IPv6) 401 Specification", RFC 2463, December 1998. 403 [13] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by 404 an On-line Database", RFC 3232, January 2002. 406 [14] Thubert, P., and Molteni, M., "Taxonomy of Route Optimization 407 Models in the NEMO Context", Internet Draft: draft-thubert- 408 nemo-ro-taxonomy-00(work in progress), Oct 2002. 410 [15] vijay, D., Ryuji, W., Alexandru, P., Pascal, T., "NEMO Basic 411 Support Protocol", draft-ietf-nemo-basic-support-00(work in 412 process), June 2003. 414 [16] A. Conta, S. Deering, "Generic Packet Tunneling in IPv6 415 Specificiation", RFC2473, December 1998. 417 [17] Fumio Teraoka, Keisuke Uehara, Hideki Sunahara, and Jun Murai, 418 ``VIP : A Protocol Providing Host Mobility,`` Aug. 1994 420 [18] Weidong Chen, Eric Lin, ``Route Optimization and Location 421 Updates for Mobile Hosts,`` International Conference on 422 Distributed Computing Systems,1996 424 [19] Ryuji Wakikawa, Susumu Koshiba, Keisuke Uehara, Jun Murai, 425 ``ORC: Optimized Route Cache Management Protocol for Network 426 Mobility,`` Proc. of ICT2003, Nov 2003. 428 [20] Jongkeun Na, et.al. ``Route Optimization Scheme based on Path 429 Control Header,`` draft-na-nemo-path-control-header-00(work 430 in process), April 2004. 432 Acknowledgments 434 Authors' Addresses 436 Jongkeun Na 437 Information Networking & Computing Lab. 438 School of Computer Science and Engineering, 439 Seoul National University, Seoul Korea 440 EMail: jkna@popeye.snu.ac.kr 442 Sungho Cho 443 Information Networking & Computing Lab. 444 School of Computer Science and Engineering, 445 Seoul National University, Seoul Korea 446 EMail: shcho@popeye.snu.ac.kr 448 Chongkwon Kim 449 Information Networking & Computing Lab. 450 School of Computer Science and Engineering, 451 Seoul National University, Seoul Korea 452 EMail: ckim@popeye.snu.ac.kr 454 Changhoi Koo 455 Global Standards & Research Team 456 Telecommunication R&D Center, 457 Samsung Electronics, KOREA 458 Email : chkoo@samsung.com 460 Copyright (C) The Internet Society (year). This document is 461 subject to the rights, licenses and restrictions contained in BCP 462 78, and except as set forth therein, the authors retain all their 463 rights. 465 This document and the information contained herein are provided on 466 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 467 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 468 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 469 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 470 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 471 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 472 PARTICULAR PURPOSE.