Mobile IP Working Group Hee Young Jung, ETRI Internet Draft Jun Seob Lee, ETRI Internet Engineering Task Force Seok Joo Koh, ETRI Expires November 2003 Hesham Soliman, Flarion May 2003 Karim El-Malki, Ericsson Fast Handover for Hierarchical MIPv6 (F-HMIPv6) Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026 [1]. Internet-Drafts are valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as a "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document addresses Fast Handover over HMIPv6 networks. A simple integration of FMIPv6 with HMIPv6 may induce unnecessary processing overhead for re-tunneling at the previous Access Router and inefficient usage of network bandwidth. This document describes the Fast Handover for HMIPv6 (F-HMIPv6), which is designed to be friendly with the data transport feature of HMIPv6. In F-HMIPv6, the Mobile Nodes inform the MAP about its movement anticipation and thus the bi- directional tunnels for fast handover are established between MAP and NAR, not between PAR and NAR. The F-HMIPv6 scheme utilizes the existing FMIPv6 messages, without defining any new control messages. Jung, Lee, Koh, Soliman, El-Malki [Page 1] INTERNET DRAFT Fast Handover for HMIPv6 May 2003 Table of Contents 1. Introduction..................................................3 2. Terminology...................................................3 3. Motivations...................................................4 4. F-HMIPv6 Operations...........................................7 5. Messages for F-HMIPv6.........................................9 5.1 A New Flag in the HMIPv6 MAP Option.......................9 5.2 Use of FMIPv6 messages...................................10 6. Further Considerations on F-HMIPv6...........................10 6.1 F-HMIPv6 based on Access Routers.........................10 6.2 Fast Handover between different MAP domains..............11 6.3 Bicasting in F-HMIPv6....................................12 6.4 Other Naming of F-HMIPv6 Messages........................13 6.5 Use of L2 Triggers in F-HMIPv6...........................13 6.6 Unidirectional tunnel between MAP and NAR................13 6.7 Consideration of Network-Initiated Handover..............13 6.8 Tunnel Extension and HI/HACK Messages....................14 7. Security Considerations......................................14 8. Acknowledgement..............................................14 9. References...................................................15 Author's Addresses..............................................15 Jung, Lee, Koh, Soliman, El-Malki [Page 2] INTERNET DRAFT Fast Handover for HMIPv6 May 2003 1. Introduction The overall handover latency in Mobile IPv6 (MIPv6) is dependent on the various delay factors such as movement detection, IP address configuration, and location (or binding) update. The Hierarchical MIPv6 (HMIPv6) facilitates to reduce the delay concerned with the location update, in which an MN sends a local Binding Updates (BU) to the local MAP, rather than the Home Agent and Correspondent Nodes that are typically further away. On the other hand, the Fast Handover for MIPv6 (FMIPv6) uses L2 signals for earlier movement detection and configuration of a new CoA for the new access router in advance, so as to minimize the disruption of services during handover. For these purposes, the FMIPv6 defines a set of various messages and also establishes bi-directional tunnels between Access Routers concerned. This document addresses Fast Handover over HMIPv6 networks. It may be straightforward to simply integrate the FMIPv6 scheme with HMIPv6. However, such simple integration may induce unnecessary processing overhead for re-tunneling at the previous Access Routers and also inefficient usage of network bandwidth. The main reason for this is that the data transport of HMIPv6 is based on the tunneling from the MAP to MNs (i.e., ARs are not involved here), while the FMIPv6 uses the tunneling between the previous and new Access Routers for fast handover. This document describes the Fast Handover scheme for HMIPv6 (F- HMIPv6). In F-HMIPv6, the bi-directional tunnels for fast handover are established between MAP and NAR, not between PAR and NAR. The F- HMIPv6 is friendly with the data transport feature of HMIPv6 and utilizes the well-defined FMIPv6 messages, without defining any new messages. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [2]. This document uses all the terminology described in the MIPv6 [3], HMIPv6 [4], and FMIPv6 [5] documents. In addition, this document uses the following terms for the on-link Care of Address (LCoA): PLCoA: MN's LCoA valid on the Previous Access Router (PAR). It corresponds to the PCoA of the FMIPv6. NLCoA: MN's LCoA valid on the New Access Router (NAR). It corresponds to the NCoA of the FMIPv6. Jung, Lee, Koh, Soliman, El-Malki [Page 3] INTERNET DRAFT Fast Handover for HMIPv6 May 2003 3. Motivations Figure 1 illustrates a reference configuration for fast handover in HMIPv6 networks. In the figure, the MAP acts as an aggregation router in the hierarchical domain. In the domain, a mobile node (MN) moves from the previous AR (PAR) region into the new AR (NAR) region, and the corresponding LCoA will change from PLCoA to NLCoA. +-------+ | HA | +-------+ | | +----+ | | CN | | +----+ +-----+ | | | | +---+ | | +-------+ | MAP | RCoA +-------+ | | | +--------+ | | | | +-----+ +-----+ PLCoA | PAR | | NAR | NLCoA +-----+ +-----+ +----+ | MN | +----+ ------------> Movement Figure 1: Fast Handover in HMIPv6 networks A natural choice for fast handover in HMIPv6 networks may be to apply the existing FMIPv6 scheme over the HMIPv6 networks. In this case, a bi-directional tunnel will be established between PAR and NAR by the FMIPv6 procedures. However, it is noted that such simple integration of FMIPv6 with HMIPv6 may possibly induce additional processing overhead for re- tunneling at PAR and also inefficient usage of network bandwidth. Jung, Lee, Koh, Soliman, El-Malki [Page 4] INTERNET DRAFT Fast Handover for HMIPv6 May 2003 Figure 2 shows the data flow by the simple integration of FMIPv6 with HMIPv6. According to the HMIPv6 operations, the data packets sent by CN will arrive at MAP and then be tunneled to MN over PLCoA. CN PAR(MN) MAP NAR(MN) | | | | | HMIPv6 | | | |---------------------->| | | | | | | | HMIPv6 | | | |<----------| | | | | | | | FMIPv6 (tunnel) | | |---------------------->| | | | | Figure 2: Data flows by simple integration of FMIPv6 with HMIPv6 When the handover is initiated, a bi-directional tunnel will be established between PAR and NAR according to the FMIPv6 procedures. To forward the data packets to the NAR by using the tunnel, the PAR must first intercept those data packets flowing from the MAP, and then perform the re-tunneling process. This may be done by adding a new outer IP header of to the data packets sent by MAP according to the HMIPv6 operations. In the viewpoint of the HMIPv6 operations, the above approach has the following disadvantages: (1) The PAR must perform the tunneling operations for fast handover, in addition to the HMIPv6 tunneling from MAP to MN. To do this, the PAR must first intercept the data packets flowing from the MAP, which will be an additional overhead for HMIPv6. It is noted that the data delivery in HMIPv6 is performed based on MAP. (2) In HMIPv6, the actual data path of the bi-directional tunnel between PAR and NAR may include the MAP (i.e., PAR û MAP û NAR). Accordingly, the data packets will flow twice along the path between PAR and MAP. This induces inefficiency of network bandwidth usage. (3) From such detouring feature, the overall handover latency may possibly increase during the handover period. Jung, Lee, Koh, Soliman, El-Malki [Page 5] INTERNET DRAFT Fast Handover for HMIPv6 May 2003 From the observations described above, it is clear that the fast handover for HMIPv6 needs to be designed by considering the data transport features of the HMIPv6 (i.e., in HMIPv6, all data packets are intercepted by MAP and delivered over the tunnel between MAP and MNs). This document describes the scheme of Fast Handover for HMIPv6 (F- HMIPv6), in which the MAP performs the tunneling for fast handover instead of the PAR. By the F-HMIPv6 scheme, the data packets sent by CN will be tunneled by the MAP toward the NAR during the handover. Figure 3 illustrates the data flows by the F-HMIPv6. CN PAR(MN) MAP NAR(MN) | | | | | HMIPv6 | | | |---------------------->| | | | | | | | HMIPv6 | | | |<----------| | | | | | | | | F-HMIPv6 (tunnel) | | |---------->| | | | | Figure 3: Data flows by F-HMIPv6 Before handover, according to the HMIPv6 operations, the data packets sent by CN are tunneled by MAP to MN with the following IP fields: - Inner IP header: - Outer IP header: When the F-HMIPv6 handover is triggered (e.g., by receiving the FBU message from the MN), the MAP will establish a bi-directional tunnel with the NAR, and then begin to forward the data packets to the NAR over the tunnel. By the tunnel, each data packet has an additional outer IP header to the normal HMIPv6 headers with the following IP fields: - Additional outer IP header: When receiving the tunneled data packets from the MAP, the NAR will de-capsulate them and then be caching the de-capsulated data packets. When the MN moves into the NAR region, the NAR will deliver the cached data packets to the MN, as done in FMIPv6. Jung, Lee, Koh, Soliman, El-Malki [Page 6] INTERNET DRAFT Fast Handover for HMIPv6 May 2003 4. F-HMIPv6 Operations This section describes the F-HMIPv6 operations for fast handover in HMIPv6 networks. The control messages for F-HMIPv6 are identical to those for FMIPv6, except for the source/destination addresses of IP fields. The correspondent node (CN) and Home Agent (HA) operations will not be affected. Basically, the F-HMIPv6 procedures described in this section are based on the assumption that the MAP has already the information about all the ARs located in the HMIPv6 domain, including the network prefix and link layer identifier/address of the respective ARs. The behaviors of MN and MAP in F-HMIPv6 are identical to those defined in the HMIPv6 document. In addition, when an MN is about to change its subnet within the HMIPv6 domain (i.e., to change LCoA from PLCoA to NLCoA), the F-HMIPv6 procedures will be applied for fast handover. The overall F-HMIPv6 procedures are illustrated in Figure 4. MN PAR MAP NAR | | | | | RtSolPr | | | |------------------------------>| | | PrRtAdv | | | |<------------------------------| | | FBU | | HI | |------------------------------>|-------------->| | | | HACK | | | |<--------------| | | FBACK | FBACK | | <--------------------|--------> | Disconnect | | | | | |Packet Forward | | | |==============>| Connect | | | | RS(with FNA option) | |---------------------------------------------->| | RA(with NAACK option) | |<----------------------------------------------| | | |Deliver Packets| |<==============================================| | | | | Figure 4: F-HMIPv6 Procedures Jung, Lee, Koh, Soliman, El-Malki [Page 7] INTERNET DRAFT Fast Handover for HMIPv6 May 2003 (1) When an MN receives information about L2 handover anticipation in the PAR region, it sends the RtSolPr message to MAP (not PAR). The RtSolPr will contain information about the link layer address or identifier of the NAR. (2) In response to the RtSolPr message, the MAP sends the PrRtAdv message to the MN, which may contain information about the pre- configured NLCoA. (3) The MN sends Fast Binding Update (FBU) message to MAP, as done in FMIPv6. (4) After receiving the FBU message from MN, the MAP will send a Handover Initiate (HI) message to the NAR so as to establish a bi-directional tunnel. In response to the HI message, the NAR will set up a host route entry for the MN's PLCoA and then respond with a Handover Acknowledge (HACK) message. As a result of exchanging these HI and HACK messages, a bi- directional tunnel between MAP and NAR will be established. By this, the MAP and NAR will be informed about PLCoA, NLCoA and link layer address of the MN. (5) After successfully establishing the bi-directional tunnel, the MAP sends the Fast Binding ACK (FBACK) messages toward the MN via both PAR and NAR. (6) Then, the MAP will begin to forward the data packets destined to MN to the NAR by using the established tunnel, until the MN complete a new Local BU to MAP, as done in HMIPv6. Over the tunnel, the data packets sent by MAP have the additional outer IP header with the following IP fields of . The NAR may cache those data packets flowing from the MAP, until it receives the RS (with FNA option) message from the newly incoming MN. The NAR will begin to deliver the cached data packets, when it receives the RS message from the MN. On the other hand, the MAP will clear the tunnel for fast handover, when it receives the new Local Binding Update with NLCoA from the MN. The remaining handover procedures are identical to those defined in the FMIPv6. Jung, Lee, Koh, Soliman, El-Malki [Page 8] INTERNET DRAFT Fast Handover for HMIPv6 May 2003 5. Messages for F-HMIPv6 The F-HMIPv6 uses all the messages defined in FMIPv6 and HMIPv6 with the following exceptions: - A new flag is defined in the HMIPv6 MAP option, so as to indicate whether the MAP supports the F-HMIPv6 or not within the HMIPv6 domain. - Some of the FMIPv6 messages have different IP source and destination addresses in the respective IP fields. In particular, the MAP address is used instead of the PAR address. 5.1 A New Flag in the HMIPv6 MAP Option When a MN moves into a new MAP domain, it receives the Router Advertisement with a MAP option from an access router. When the F bit set in the MAP option indicates that the mobile node MAY use F-HMIPv6. If the MN is not aware of F-HMIPv6, or the F bit is not set, it SHOULD NOT use F-HMIPv6. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Dist | Pref |R|I|P|V|F| Res | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Valid Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Global IP Address for MAP + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: A new flag in the MAP option Fields: F When set indicates that the MAP support Fast Handover. Jung, Lee, Koh, Soliman, El-Malki [Page 9] INTERNET DRAFT Fast Handover for HMIPv6 May 2003 5.2 Use of FMIPv6 messages F-HMIPv6 uses the messages for fast handover defined in FMIPv6, with different source and destination IP addresses. Table 1 summarizes the use of these messages. Table 1. Use of FMIPv6 Messages in F-HMIPv6 +--------------+-----------+-------------+---------------------+ | F-HMIPv6 | Source IP | Destination | Usage in FMIPv6 | | Messages | address | IP address | | +--------------+-----------+-------------+---------------------+ | RtSolPr | MN | MAP | Destination = PAR | +--------------+-----------+-------------+---------------------+ | PrRtAdv | MAP | MN | Source = PAR | +--------------+-----------+-------------+---------------------+ | FBU | MN | MAP | Destination = PAR | +--------------+-----------+-------------+---------------------+ | FBACK | MAP | MN | Source = PAR | | | |(via PAR/NAR)| | +--------------+-----------+-------------+---------------------+ | HI | MAP | NAR | Source = PAR | +--------------+-----------+-------------+---------------------+ | HACK | NAR | MAP | Destination = PAR | +--------------+-----------+-------------+---------------------+ 6. Further Considerations on F-HMIPv6 In this section, several issues are described for further considerations. Some of them may be incorporated into the main part of this document after appropriate resolution. 6.1 F-HMIPv6 based on Access Routers In this document, it is assumed that the MAP has already all the information about Access Routers located within the HMIPv6 domain, which includes the network prefix and link layer address of the respective ARs. In certain cases, as done in FMIPv6, the network administrator may prefer that all the ARs share all the necessary information with their neighboring ARs. Jung, Lee, Koh, Soliman, El-Malki [Page 10] INTERNET DRAFT Fast Handover for HMIPv6 May 2003 In this scenario, the RtSolPr may be sent to the PAR, rather than the MAP, as done in FMIPv6. The PAR will then respond with the PrRtAdv message that contains a new NLCoA address, as shown in Figure 6. MN PAR MAP NAR | | | | | RtSolPr | | | |-------------->| | | | PrRtAdv | | | |<--------------| | | | FBU | | HI | |------------------------------>|-------------->| | | | HACK | | | |<--------------| Figure 6: F-HMIPv6 based on ARs The remaining procedures are the same with those for F-HMIPv6, as described in Section 4. How to integrate the F-HMIPv6 and the existing FMIPv6 is for further study. 6.2 Fast Handover between different MAP domains This document focuses on the fast handover within an HMIPv6 domain. It is also noted that one of the challenging issues is how to support the fast handover between different MAP domains. For Inter-MAP handover, we may need to address the following issues: (1) Fast movement detection in the new MAP domain When a MN moves to a new MAP domain, it may need to obtain the associated MAP information for fast handover, before the normal HMIPv6 Local BU procedures begin. To do this, the HMIPv6 MAP option may be contained in the RtSolPr and/or PrRtAdv messages. (2) Tunneling between MAPs For fast handover between different MAPs, the bi-directional tunneling may need to be established between the associated old and new MAPs. Such tunneling may need to be extended from the new MAP toward the new Access Router attached to the MAP. Jung, Lee, Koh, Soliman, El-Malki [Page 11] INTERNET DRAFT Fast Handover for HMIPv6 May 2003 (3) BU procedure For the inter-MAP handover, the MN needs to perform the Binding Updates with the CN and HA, as well as the local binding update with the new MAP. Additional considerations on inter-MAP handover are for further study. 6.3 Bicasting in F-HMIPv6 It is noted that the bicasting can be used to enhance the handover performance, in particular, for addressing the ping-pong effect. In F-HMIPv6, it is strongly recommended that the bicasting be used for stable and fast handover. Figure 7 shows the bicasting scenario in F-HMIPv6. MN PAR MAP NAR | | | | | RtSolPr | | | |------------------------------>| | | PrRtAdv | | | |<------------------------------| | | FBU | | HI | |------------------------------>|-------------->| | | | HACK | | | |<--------------| | | FBACK | FBACK | | <--------------------|--------> | | | | | | |Packet Forward(with bicasting) | |<==============================|==============>| | | | | | RS(with FNA option) | |---------------------------------------------->| | RA(with NAACK option) | |<----------------------------------------------| | | |Deliver Packets| |<==============================================| | | | | Figure 7: Bicasting in F-HMIPv6 Jung, Lee, Koh, Soliman, El-Malki [Page 12] INTERNET DRAFT Fast Handover for HMIPv6 May 2003 In F-HMIPv6, if the bicasting is enabled, when the packet forwarding to the NAR is indicated, the MAP will also continue to send the data packets to the MN (over PLCoA). That is, after transmitting the FBACK messages, the MAP will send the data packets destined to MN toward the NAR over the established tunnel as well as the MN over the PLCoA. The packet forwarding to the MN over PLCoA will stop, when the MAP receives a new Local Binding Update (by HMIPv6) from the MN that has moved into the NAR. 6.4 Other Naming of F-HMIPv6 Messages The F-HMIPv6 uses the RtSolPr and PrRtAdv messages, as defined in FMIPv6. It is noted that those messages are exchanged between MN and MAP in F-HMIPv6, not between MN and PAR in FMIPv6. In F-HMIPv6, those messages may be named differently from F-HMIPv6 in the future so as to indicate such distinction. 6.5 Use of L2 Triggers in F-HMIPv6 Issues on the use of L2 triggers for fast handover are the same with those in FMIPv6 [5]. With help of the various L2 triggers such as source and target triggers, the F-HMIPv6 mechanisms could be simplified and enhanced, which is for further study. 6.6 Unidirectional tunnel between MAP and NAR In FMIPv6, the tunnel between PAR and NAR is bi-directional. In HMIPv6, however, the MN may send the data packets directly to the CN without using the tunnel with MAP, if the RCoA could be used in the AR region. Accordingly, the F-HMIPv6 tunnel from MAP to NAR may not be necessarily bi-directional, differently from FMIPv6. In the unidirectional tunneling case, the MN will send the data packets to the CN without tunneling (i.e., with the IP fields of ), regardless of being in the PAR or NAR regions. 6.7 Consideration of Network-Initiated Handover The F-HMIPv6 described in this document may be particularly useful for Mobile-Initiated Handover scenarios or for the wireless networks where the MN needs to send a solicitation by anticipating the movement (e.g. WLAN). Jung, Lee, Koh, Soliman, El-Malki [Page 13] INTERNET DRAFT Fast Handover for HMIPv6 May 2003 For some network links such as cellular network or for a Network- Initiated handover scenario, there may be no need for the solicitation message. In this case, the ARs would already know that the MN is about to move and where it is going toward, so the appropriate AR could send an unsolicited PrRtAdv to the MN. Inclusion of such network-initiated handover case into the F-HMIPv6 will be done in the future. 6.8 Tunnel Extension and HI/HACK Messages Another flavor of this F-HMIPv6 solution can be achieved if the HI/HACK exchanges are eliminated. In this case, the MN may instead be required to use optimistic DAD, which will work almost all the time. As an alternative, the tunnel from MAP for Fast Handover can be terminated to the MN, not the NAR. This will be helpful to reduce the signaling of HI/HACK and also to avoid having to send a local BU, after F-BU (i.e. only one local BU would be sufficient). This extensional use will be examined in the further works. 7. Security Considerations The security issues on F-HMIPv6 are basically the same with those on FMIPv6 and HMIPv6. Noting that the MN and the MAP could have an IPsec SA in the HMIPv6, the PrRtSol and PrRtAdv messages can be protected with IPsec. This feature actually provides an advantage over FMIPv6 where ND messages cannot be secured in its present form. In addition, the MAP MUST ensure that the RtSolPr and FBU packets arrived from an MN that legitimately owns the RCoA. Otherwise, a bogus node could attempt to disrupt packets meant for the MN and redirect them to some access router. 8. Acknowledgement The Authors would like to give special thanks to the following people for their valuable contributions: Sung Han Kim (sh-kim@etri.re.kr), ETRI Jae Hong Min (jhmin@etri.re.kr), ETRI Jung, Lee, Koh, Soliman, El-Malki [Page 14] INTERNET DRAFT Fast Handover for HMIPv6 May 2003 9. References [1] S. Bradner, "The Internet Standards Process -- Revision 3", BCP, RFC 2026, October 1996. [2] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP, RFC 2119, March 1997. [3] D. Johnson, et al., "Mobility Support in IPv6", draft-ietf- mobileip-ipv6-21, February 2003. [4] H. Soliman, et al., "Hierarchical Mobile IPv6 mobility management (HMIPv6)", draft-ietf-mobileip-hmipv6-07, October 2002. [5] R. Koodli, et al., "Fast Handovers for Mobile IPv6", draft-ietf- mobileip-fast-mipv6-06, March 2003. uthor's Addresses Hee Young Jung hyjung@etri.re.kr Protocol Engineering Center, ETRI Jun Seob Lee juns@etri.re.kr Protocol Engineering Center, ETRI Seok Joo Koh sjkoh@etri.re.kr Protocol Engineering Center, ETRI Hesham Soliman H.Soliman@flarion.com Flarion Karim El Malki Karim.El-Malki@era.ericsson.se Ericsson Radio Systems AB Jung, Lee, Koh, Soliman, El-Malki [Page 15] NTERNET DRAFT Fast Handover for HMIPv6 May 2003 ull Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." ung, Lee, Koh, Soliman, El-Malki [Page 16]