idnits 2.17.1 draft-ietf-seamoby-mobility-terminology-00.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. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 7 instances of too long lines in the document, the longest one being 9 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 1089: '... MAY be stored separately from t...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 31, 2002) is 7902 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) -- Possible downref: Normative reference to a draft: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' ** Obsolete normative reference: RFC 2460 (ref. '3') (Obsoleted by RFC 8200) -- No information found for draft-ietf-mobileip-fast-mipv6 - is the name correct? -- Possible downref: Normative reference to a draft: ref. '4' ** Downref: Normative reference to an Informational RFC: RFC 2753 (ref. '5') == Outdated reference: A later version (-03) exists of draft-kempf-cdma-appl-00 -- Possible downref: Normative reference to a draft: ref. '6' ** Downref: Normative reference to an Informational draft: draft-ietf-seamoby-context-transfer-problem-stat (ref. '7') -- Possible downref: Non-RFC (?) normative reference: ref. '8' ** Obsolete normative reference: RFC 2002 (ref. '9') (Obsoleted by RFC 3220) -- Possible downref: Non-RFC (?) normative reference: ref. '10' == Outdated reference: A later version (-04) exists of draft-ietf-seamoby-cardiscovery-issues-02 ** Downref: Normative reference to an Informational draft: draft-ietf-seamoby-cardiscovery-issues (ref. '11') Summary: 11 errors (**), 0 flaws (~~), 4 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force J. Manner (ed.) 3 Internet-Draft M. Kojo (ed.) 4 Expires: February 28, 2003 University of Helsinki 5 August 31, 2002 7 Mobility Related Terminology 8 10 Status of this Memo 12 This document is a working group contribution for the Seamoby Working 13 Group. 15 Distribution of this memo is unlimited. 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. Internet-Drafts are working 19 documents of the Internet Engineering Task Force (IETF), its areas, 20 and its working groups. Note that other groups may also distribute 21 working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire in February, 2003. 36 Copyright Notice 38 Copyright (C) The Internet Society (2000). All Rights Reserved. 40 Abstract 42 There is a need for common definitions of terminology in the work to 43 be done around IP mobility. This memo defines terms for mobility 44 related terminology. It is intended as a living document for use by 45 the Seamoby working group in Seamoby drafts and in WG discussions. 46 Other working groups dealing with mobility may also take advantage of 47 this terminology. 49 Changes from -03 51 - Added CAR Discovery terminology 52 - Added placeholder for security terminology 54 - Edited the introduction and the figure in the network nodes section 56 Changes from draft-manner-seamoby-terms-04.txt 58 - Removed a few security related terms based on discussions in 59 Yokohama. Some key mobility-related security terms will be added 60 later. 62 TODOs (some ideas) 64 - Add basic terminology about mobile networks. 66 - Re-write the Network Components section 68 - Compare to the definitions in FMIPv6 and add missing parts 70 - Add more terms, eg. MPR (Multipoint Relay), "Reverse Routability", 71 BU, FBU, etc. 73 - Compare against definitions in the LMM documents of the IRTF MM- 74 subgroup. See if there is some harmonization to be done. 76 Table of Contents 78 1 Introduction ................................................. 3 79 2 General Terms ................................................ 3 80 3 Network Components ........................................... 7 81 4 Handover Terminology ......................................... 11 82 4.1 Scope of Handover .......................................... 11 83 4.2 Handover Control ........................................... 13 84 4.3 Simultaneous connectivity to Access Routers ................ 14 85 4.4 Performance and Functional Aspects ......................... 14 86 4.5 Micro Diversity, Macro Diversity, and IP Diversity ......... 15 87 4.6 Paging, and Mobile Node States and Modes ................... 16 88 4.7 Context Transfer ........................................... 18 89 4.8 Candidate Access Router Discovery .......................... 19 90 4.9 User, Personal and Host Mobility ........................... 19 91 5 Specific Terminology for Mobile Ad-Hoc Networking ............ 20 92 6 Security-related Terminology ................................. 21 93 7 Security Considerations ...................................... 22 94 8 Contributors ................................................. 22 95 9 Acknowledgement .............................................. 22 96 10 References .................................................. 23 97 11 Author's Addresses .......................................... 24 98 12 Appendix A - Examples ....................................... 26 99 13 Appendix B - Index of Terms ................................. 28 100 1. Introduction 102 This document presents terminology to be used for documents and 103 discussions within the Seamoby Working Group. Other mobility related 104 working groups could like take advantage of this terminology, in 105 order to create a common terminology for the area of mobility. These 106 groups would include MIP, MANET, ROHC and possibly NEMO. 108 Some terms and their definitions that are not directly related to the 109 IP world are included for the purpose of harmonizing the terminology, 110 for example, 'Access Point' and 'base station' refer to the same 111 component, from the point of view of IP, but 'Access Router' has a 112 very different meaning. The presented terminology may also, it is 113 hoped, be adequate to cover mobile ad-hoc networks. 115 The proposed terminology is not meant to assert any new terminology. 116 Rather the authors would welcome discussion on more exact definitions 117 as well as missing or unnecessary terms. This work is a 118 collaborative enterprise between people from many different 119 engineering backgrounds and so already presents a first step in 120 harmonizing the terminology. 122 The terminology in this draft is divided into several sections. 123 First, there is a list of terms for general use, followed by some 124 terms related to handovers, and finally some terms used within the 125 MANET working group. 127 2. General Terms 129 Bandwidth 131 The total capacity of a link to carry information (typically 132 bits). 134 Bandwidth Utilization 136 The actual amount of information delivered over a link, expressed 137 as a percent of the available bandwidth on that link. 139 Beacon 141 A control message broadcast by a node (especially, a base 142 station) informing all the other nodes in its neighborhood of the 143 continuing presence of the broadcasting node, possibly along with 144 additional status or configuration information. 146 Channel 148 A subdivision of the physical medium allowing possibly shared 149 independent uses of the medium. Channels may be made available 150 by subdividing the medium into distinct time slots, or distinct 151 spectral bands, or decorrelated coding sequences. 153 Channel Access Protocol 155 A protocol for mediating access to, and possibly allocation of, 156 the various channels available within the physical communications 157 medium. Nodes participating in the channel access protocol can 158 communicate only when they have uncontested access to the medium, 159 so that there will be no interference. 161 Control Message 163 Information passed between two or more network nodes for 164 maintaining protocol state, which may be unrelated to any 165 specific application. 167 Distance Vector 169 A style of routing protocol in which, for each desired 170 destination, a node maintains information about the distance to 171 that destination, and a vector (next hop) towards that 172 destination. 174 Fairness 176 A property of channel access protocols whereby a medium is made 177 fairly equal to all eligible nodes on the link. Fairness does 178 not strictly imply equality, especially in cases where nodes are 179 given link access according to unequal priority or 180 classification. 182 Flooding 184 The process of delivering data or control messages to every node 185 within the network under consideration. 187 Forwarding node 189 A node which performs the function of forwarding datagrams from 190 one of its neighbors to another. 192 Home Address 194 An IP address that is assigned for an extended period of time to 195 a mobile node. It remains unchanged regardless of where the node 196 is attached to the Internet [10]. 198 Interface 200 A node's attachment to a link. 202 IP access address 204 An IP address (often dynamically allocated) which a node uses to 205 designate its current point of attachment to the access network. 206 The IP access address is typically to be distinguished from the 207 mobile node's home address; in fact, the former may be considered 208 unsuitable for use by any but the most short-lived applications. 210 Link 212 A communication facility or physical medium that can sustain data 213 communications between multiple network nodes, such as an 214 Ethernet (simple or bridged). A link is the layer immediately 215 below IP. 217 Asymmetric Link 219 A link with transmission characteristics which are different 220 depending upon the relative position or design characteristics of 221 the transmitter and the receiver of data on the link. For 222 instance, the range of one transmitter may be much higher than 223 the range of another transmitter on the same medium. 225 Link Establishment 227 The process of establishing a link between the mobile node and 228 the access network. This may involve allocating a channel, or 229 other local wireless resources, possibly including a minimum 230 level of service or bandwidth. 232 Link State 234 A style of routing protocol in which every node within the 235 network is expected to maintain information about every link 236 within the network topology. 238 Link-level Acknowledgement 240 A protocol strategy, typically employed over wireless media, 241 requiring neighbors to acknowledge receipt of packets (typically 242 unicast only) from the transmitter. Such strategies aim to avoid 243 packet loss or delay resulting from lack of, or unwanted 244 characteristics of, higher level protocols. 246 Link-layer acknowledgements are often used as part of ARQ 247 algorithms for increasing link reliability. 249 Local Broadcast 251 The delivery of data to every node within range of the 252 transmitter. 254 Loop-free 256 A property of routing protocols whereby the path taken by a data 257 packet from source to destination never transits the same 258 intermediate node twice before arrival at the destination. 260 Medium-Access Protocol (MAC) 261 A protocol for mediating access to, and possibly allocation of, 262 the physical communications medium. Nodes participating in the 263 medium access protocol can communicate only when they have 264 uncontested access to the medium, so that there will be no 265 interference. When the physical medium is a radio channel, the 266 MAC is the same as the Channel Access Protocol. 268 Mobility Factor 270 The relative frequency of node movement, compared to the 271 frequency of application initiation. 273 Neighbor 275 A "neighbor" is any other node to which data may be propagated 276 directly over the communications medium without relying the 277 assistance of any other forwarding node 279 Neighborhood 281 All the nodes which can receive data on the same link from one 282 node whenever it transmits data. 284 Next Hop 286 A neighbor which has been selected to forward packets along the 287 way to a particular destination. 289 Payload 291 The actual data within a packet, not including network protocol 292 headers which were not inserted by an application. 294 DISCUSSION: How shall we say that payloads are different between 295 layers: user data is the payload of TCP, which are the payload of 296 IP, which three are the payload of link layer protocols etc. 298 Prefix 300 A bit string that consists of some number of initial bits of an 301 address. 303 Route Table 305 The table where forwarding nodes keep information (including next 306 hop) for various destinations. 308 Route Entry 310 An entry for a specific destination (unicast or multicast) in the 311 route table. 313 Route Establishment 314 The process of determining a route between a source and a 315 destination. 317 Route Activation 319 The process of putting a route into use after it has been 320 determined. 322 Signal Strength 324 The detectable power of the signal carrying the data bits, as 325 seen by the receiver of the signal. 327 Source Route 329 A source route from node A to node B is an ordered list of IP 330 addresses, starting with the IP address of node A and ending with 331 the IP address of the node B. Between A and B, the source route 332 includes an ordered list of all the intermediate hops between A 333 and B, as well as the interface index of the interface through 334 which the packet should be transmitted to reach the next hop. 336 Spatial re-use 338 Simultaneous use of channels with identical or close physical 339 characteristics, but located spatially far enough apart to avoid 340 interference (i.e., co-channel interference) 342 System-wide Broadcast 344 Same as flooding, but used in contrast to local broadcast. 346 Topology 348 A network can be viewed abstractly as a "graph" whose "topology" 349 at any point in time is defined by set of "points" connected by 350 (possibly directed) "edges." 352 Triggered Update 354 An unsolicited route update transmitted by an router along a path 355 to a destination. 357 3. Network Components 359 Figure 1 presents a reference architecture which illustrates an IP 360 network with components defined in this section. The figure presents 361 two examples of access network (AN) topologies. 363 We intend to define the concept of the Access Network (AN) which 364 supports enhanced mobility.It is possible that to support routing and 365 QoS for mobile nodes, existing routing protocols (i.e., OSPF or other 366 standard IGPs) may not be appropriate to maintain forwarding 367 information for these mobile nodes as they change their points of 368 attachment to the Access Network. These new functions are 369 implemented in routers with additional capability. We can 370 distinguish three types of Access Network components: Access Routers 371 (AR) which handle the last hop to the mobile; Access Network Gateways 372 (ANG) which form the boundary on the fixed network side and shield 373 the fixed network from the specialized routing protocols; and 374 (optionally) other internal Access Network Routers which may also be 375 needed in some cases to support the protocols. The Access Network 376 consists of the equipment needed to support this specialized routing, 377 i.e. AR/ANG/ANR. 379 Note: this reference architecture is not well suited for people 380 dealing with MANETs. We need to refine this section in the future. 382 Mobile Node (MN) 384 An IP node capable of changing its point of attachment to the 385 network. A Mobile Node may have routing functionality. 387 Mobile Host (MH) 389 A mobile node that is an end host and not a router. 391 Access Link (AL) 393 A last-hop link between a Mobile Node and an Access Router. That 394 is, a facility or medium over which an Access Point and the 395 Mobile Node can communicate at the link layer, i.e., the layer 396 immediately below IP. 398 --- ------ ------- | 399 --- | <--> | | -------| AR | -------------------| | | 400 | |--[] --- /------ \ /| ANG |--| 401 --- AP / \ / | | | 402 MN / \ / ------- | 403 (+wireless ___ / ------- | 404 device) | |---- | ANR | | 405 --- ------- | 406 AP / \ | 407 / \ ------- | 408 --- ------ / \| | | 409 | |-------| AR |---------------------| ANG |--| 410 --- ------ | | | 411 AP ------- | 412 | 413 Access Network (AN) 1 | 414 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -| 415 Access Network (AN) 2 | 416 | 417 | 418 --- ------ ------- | 419 --- |<--> | | -------| AR | -------------------| | | 420 | |--[] --- /------ /| ANG |--| 421 --- AP / / | | | 422 MN / / ------- | 423 (+wireless ___ / / | 424 device) | |---- / | 425 --- / | 426 AP / | 427 / | 428 --- ------ ------- | 429 | |-------| AR |---------| ANR | | 430 --- \ ------ ------- | 431 AP \ / | 432 \ / | 433 --- \ ------ / | 434 | |-------| AR |------- | 435 --- ------ | 436 AP | 438 Figure 1: Reference Network Architecture 440 Access Point (AP) 442 An Access Point is a layer 2 device which is connected to one or 443 more Access Routers and offers the wireless link connection to 444 the Mobile Node. Access Points are sometimes called base 445 stations or access point transceivers. An Access Point may be a 446 separate entity or co-located with an Access Router. 448 Radio Cell 450 The geographical area within which an Access Point provides radio 451 coverage, i.e. where radio communication between a Mobile Node 452 and the specific Access Point is possible. 454 Access Network Router (ANR) 456 An IP router in the Access Network. An Access Network Router may 457 include Access Network specific functionalities, for example, 458 related to mobility and/or QoS. This is to distinguish between 459 ordinary routers and routers that have Access Network-related 460 special functionality. 462 Access Router (AR) 464 An Access Network Router residing on the edge of an Access 465 Network and connected to one or more Access Points. The Access 466 Points may be of different technology. An Access Router offers 467 IP connectivity to Mobile Nodes, acting as a default router to 468 the Mobile Nodes it is currently serving. The Access Router may 469 include intelligence beyond a simple forwarding service offered 470 by ordinary IP routers. 472 Access Network Gateway (ANG) 474 An Access Network Router that separates an Access Network from 475 other IP networks, much in the same way as an ordinary gateway 476 router. An Access Router and an Access Network Gateway may be 477 the same physical node. The Access Network Gateway looks to the 478 other IP networks like a standard IP router. 480 Access Network (AN) 482 An IP network which includes one or more Access Network Routers. 484 Administrative Domain (AD) 486 A collection of networks under the same administrative control 487 and grouped together for administrative purposes. [5] 489 Serving Access Router (SAR) 491 The Access Router currently offering the connectivity to the 492 Mobile Host. This is usually the point of departure for the 493 Mobile Node as it makes its way towards a new Access Router (then 494 Serving Access Router takes the role of the Old Access Router). 495 There may be several Serving Access Routers serving the Mobile 496 Node at the same time. 498 Old Access Router (OAR) 500 An Access Router that offered connectivity to the Mobile Node 501 prior to a handover. This is the Serving Access Router that will 502 cease or has ceased to offer connectivity to the Mobile Node. 504 New Access Router (NAR) 505 The Access Router that offers connectivity to the Mobile Node 506 after a handover. 508 Previous Access Router (PAR) 510 An Access Router that offered connectivity to the Mobile Node 511 prior to a handover. This is the Serving Access Router that will 512 cease or has ceased to offer connectivity to the Mobile Node. 513 Same as OAR. 515 Candidate Access Router (CAR) 517 An Access Router to which the Mobile Node may do a handoff. 519 4. Handover Terminology 521 These terms refer to different perspectives and approaches to 522 supporting different aspects of mobility. Distinctions can be made 523 according to the scope, range overlap, performance characteristics, 524 diversity characteristics, state transitions, mobility types, and 525 control modes of handover techniques. 527 Roaming 529 An operator-based term involving formal agreements between 530 operators that allows a mobile to get connectivity from a foreign 531 network. Roaming (a particular aspect of user mobility) 532 includes, for example, the functionality by which users can 533 communicate their identity to the local AN so that inter-AN 534 agreements can be activated and service and applications in the 535 MN's home network can be made available to the user locally. 537 Handover 539 (also known as handoff) the process by which an active MN (in the 540 Active State, see section 4.6) changes its point of attachment to 541 the network, or when such a change is attempted. The access 542 network may provide features to minimize the interruption to 543 sessions in progress. 545 There are different types of handover classified according to 546 different aspects involved in the handover. Some of this 547 terminology follows the description of [4]. 549 4.1. Scope of Handover 551 Note: the definitions of horizontal and vertical handover are 552 different than the ones commonly used today. These definitions try to 553 look at the handover from the IP layer's point of view; the IP layer 554 works with network interfaces, rather than specific technologies used 555 by those interfaces. 557 Layer 2 Handover 559 When a MN changes APs (or some other aspect of the radio channel) 560 connected to the same AR's interface then a layer 2 handover 561 occurs. This type of handover is transparent to the routing at 562 the IP layer (or it appears simply as a link layer 563 reconfiguration without any mobility implications). 565 Intra-AR Handover 567 A handover which changes the AR's network interface to the 568 mobile. That is, the Serving AR remains the same but routing 569 changes internal to the AR take place. 571 Intra-AN Handover 573 When the MN changes ARs inside the same AN then this handover 574 occurs. Such a handover is not necessarily visible outside the 575 AN. In case the ANG serving the MN changes, this handover is seen 576 outside the AN due to a change in the routing paths. Note that 577 the ANG may change for only some of the MN's data flows. 579 Inter-AN Handover 581 When the MN moves to a new AN then this handover occurs. This 582 requires some sort of host mobility across ANs, which typically 583 is be provided by the external IP core. Note that this would 584 have to involve the assignment of a new IP access address (e.g., 585 a new care-of address [9]) to the MN. 587 Intra-technology Handover 589 A handover between equipment of the same technology. 591 Inter-technology Handover 593 A handover between equipment of different technologies. 595 Horizontal Handover 597 A handover in which the mobile node's network interface does not 598 change (from the IP point of view); the MN communicates with the 599 access network via the same network interface before and after 600 the handover. A horizontal handover is typically also an intra- 601 technology handover but it can be an inter-technology handover if 602 the MN can do a layer 2 handover between two different 603 technologies without changing the network interface seen by the 604 IP layer. 606 Vertical Handover 608 In a vertical handover the mobile node's network interface to the 609 Access Network changes. A vertical handover is typically an 610 inter-technology handover but it may also be an intra- technology 611 handover if the MN has several network interfaces of the same 612 type. That is, after the handover, the IP layer communicates with 613 the Access Network through a different network interface. 615 The different handover types defined in this section and in section 616 4.1 have no direct relationship. In particular, a MN can do an 617 intra-AN handover of any of the types defined above. 619 Note that the horizontal and vertical handovers are not tied to a 620 change in the link layer technology. They define whether, after a 621 handover, the IP packet flow goes through the same (horizontal 622 handover) or a different (vertical handover) network interface. 623 These two handovers do not define whether the AR changes as a result 624 of a handover. 626 4.2. Handover Control 628 A handover must be one of the following two types (a): 630 Mobile-initiated Handover 632 the MN is the one that makes the initial decision to initiate the 633 handover. 635 Network-initiated Handover 637 the network makes the initial decision to initiate the handover. 639 A handover is also one of the following two types (b): 641 Mobile-controlled Handover (MCHO) 643 the MN has the primary control over the handover process. 645 Network-controlled Handover (NCHO) 647 the network has the primary control over the handover process. 649 A handover may also be either of these three types (c): 651 Mobile-assisted handover 653 information and measurement from the MN are used by the AR to 654 decide on the execution of a handover. 656 Network-assisted handover 658 a handover where the AN collects information that can be used by 659 the MN in a handover decision. 661 Unassisted handover 662 a handover where no assistance is provided by the MN or the AR to 663 each other. 665 A handover is also one of the following two types (d): 667 Backward handover 669 a handover either initiated by the OAR, or where the MN initiates 670 a handover via the OAR. 672 Forward handover 674 a handover either initiated by the NAR, or where the MN initiates 675 a handover via the NAR. 677 The handover is also either proactive or reactive (e): 679 Planned handover 681 a proactive (expected) handover where some signalling can be done 682 in advance of the MN getting connected to the new AR, e.g. 683 building a temporary tunnel from the old AR to the new AR. 685 Unplanned handover 687 a reactive (unexpected) handover, where no signalling is done in 688 advance of the MN's move of the OAR to the new AR. 690 The five handover types (a-e) are mostly independent, and every 691 handover should be classiable according to each of these types. 693 4.3. Simultaneous connectivity to Access Routers 695 Make-before-break (MBB) 697 During a MBB handover the MN can communicate simultaneously with 698 the old and new AR. This should not be confused with "soft 699 handover" which relies on macro diversity. 701 Break-before-make (BBM) 703 During a BBM handover the MN cannot communicate simultaneously 704 with the old and the new AR. 706 4.4. Performance and Functional Aspects 708 Handover Latency 710 Handover latency is the time difference between when a MN is last 711 able to send and/or receive an IP packet by way of the OAR, until 712 when the MN is able to send and/or receive an IP packet through 713 the NAR. Adapted from [4]. 715 Smooth handover 717 A handover that aims primarily to minimize packet loss, with no 718 explicit concern for additional delays in packet forwarding. 720 Fast handover 722 A handover that aims primarily to minimize delay, with no 723 explicit interest in packet loss. 725 Seamless handover 727 A handover in which there is no change in service capability, 728 security, or quality. In practice, some degradation in service 729 is to be expected. The definition of a seamless handover in the 730 practical case should be that other protocols, applications, or 731 end users do not detect any change in service capability, 732 security or quality, which would have a bearing on their (normal) 733 operation. See [7] for more discussion on the topic. 735 Throughput 737 The amount of data from a source to a destination processed by 738 the protocol for which throughput is to be measured for instance, 739 IP, TCP, or the MAC protocol. The throughput differs between 740 protocol layers. 742 Goodput 744 The total bandwidth used, less the volume of control messages and 745 protocol overhead from the data packets. 747 Pathloss 749 A reduction in signal strength caused by traversing the physical 750 medium constituting the link. 752 Hidden-terminal problem 754 The problem whereby a transmitting node can fail in its attempt 755 to transmit data because of destructive interference which is 756 only detectable at the receiving node, not the transmitting node. 758 Exposed terminal problem 760 The problem whereby a transmitting node prevents another node 761 from transmitting although it could have safely transmitted to 762 anyone else but that node. 764 4.5. Micro Diversity, Macro Diversity, and IP Diversity 766 Certain air interfaces (e.g. UTRAN FDD mode) require or at least 767 support macro diversity combining. Essentially, this refers to the 768 fact that a single MN is able to send and receive over two 769 independent radio channels ('diversity branches') at the same time; 770 the information received over different branches is compared and that 771 from the better branch passed to the upper layers. This can be used 772 both to improve overall performance, and to provide a seamless type 773 of handover at layer 2, since a new branch can be added before the 774 old is deleted. See also [6]. 776 It is necessary to differentiate between combining/diversity that 777 occurs at the physical and radio link layers, where the relevant unit 778 of data is the radio frame, and that which occurs at layer 3, the 779 network layer, where what is considered is the IP packet itself. 781 In the following definitions micro- and macro diversity refer to 782 protocol layers below the network layer, and IP diversity refers to 783 the network layer. 785 Micro diversity 787 for example, two antennas on the same transmitter send the same 788 signal to a receiver over a slightly different path to overcome 789 fading. 791 Macro diversity 793 Duplicating or combining actions taking place over multiple APs, 794 possibly attached to different ARs. This may require support 795 from the network layer to move the radio frames between the base 796 stations and a central combining point. 798 IP diversity 800 the splitting and combining of packets at the IP level. 802 4.6. Paging, and Mobile Node States and Modes 804 Mobile systems may employ the use of MN states in order to operate 805 more efficiently without degrading the performance of the system. The 806 term 808 A MN is always in one of the following three states: 810 Active State 812 when the AN knows the MN's SAR and the MN can send and receive IP 813 packets. The AL may not be active, but the radio layer is able 814 to establish one without assistance from the network layer. The 815 MN has an IP address assigned. 817 Dormant State 819 A state in which the mobile restricts its ability to receive 820 normal IP traffic by reducing its monitoring of radio channels. 822 The AN knows the MH's Paging Area, but the MH has no SAR and so 823 packets cannot be delivered to the MH without the AN initiating 824 paging. 826 Time-slotted Dormant Mode 828 A dormant mode implementation in which the mobile alternates 829 between periods of not listening for any radio traffic and 830 listening for traffic. Time-slotted dormant mode 831 implementations are typically synchronized with the network so 832 the network can deliver traffic to the mobile during listening 833 periods. 835 Inactive State 837 the MH is in neither the Active nor Dormant State. The host is no 838 longer listening for any packets, not even periodically, and not 839 sending packets. The host may be in a powered off state, it may 840 have shut down all interfaces to drastically conserve power, or 841 it may be out of range of a radio access point. The MN does not 842 necessarily have an IP access address from the AN. 844 Note: in fact, as well as the MN being in one of these three states, 845 the AN also stores which state it believes the MN is in. Normally 846 these are consistent; the definitions above assume so. 848 Here are some additional definitions for paging, taking into account 849 the above state definitions. 851 Paging 853 a procedure initiated by the Access Network to move an Idle MN 854 into the Active State. As a result of paging, the MN establishes 855 a SAR and the IP routes are set up. 857 Location updating 859 a procedure initiated by the MN, by which it informs the AN that 860 it has moved into a new paging area. 862 Paging Area 864 A part of the Access Network, typically containing a number of 865 ARs/APs, which corresponds to some geographical area. The AN 866 keeps and updates a list of all the Idle MNs present in the area. 867 If the MN is within the radio coverage of the area it will be 868 able to receive paging messages sent within that Paging Area. 870 Paging Area Registrations 872 Signaling from a dormant mode mobile node to the network, by 873 which it establishes its presence in a new paging area. Paging 874 Area Registrations thus enable the network to maintain a rough 875 idea of where the mobile is located. 877 Paging Channel 879 A radio channel dedicated to signaling dormant mode mobiles for 880 paging purposes. By current practice, the protocol used on a 881 paging channel is usually dictated by the radio link protocol, 882 although some paging protocols have provision for carrying 883 arbitrary traffic (and thus could potentially be used to carry 884 IP). 886 Traffic Channel 888 The radio channel on which IP traffic to an active mobile is 889 typically sent. This channel is used by a mobile that is 890 actively sending and receiving IP traffic, and is not 891 continuously active in a dormant mode mobile. For some radio 892 link protocols, this may be the only channel available. 894 4.7. Context Transfer 896 Context 898 The information on the current state of a routing-related service 899 required to re-establish the routing-related service on a new 900 subnet without having to perform the entire protocol exchange 901 with the mobile host from scratch. 903 Feature context 905 The collection of information representing the context for a 906 given feature. The full context associated with a mobile host is 907 the collection of one or more feature contexts. 909 Context transfer 911 The movement of context from one router or other network entity 912 to another as a means of re-establishing routing related services 913 on a new subnet or collection of subnets. 915 Routing-related service 917 A modification to the default routing treatment of packets to and 918 from the mobile host. Initially establishing routing-related 919 services usually requires a protocol exchange with the mobile 920 host. An example of a routing-related service is header 921 compression. The service may also be indirectly related to 922 routing, for example, security. Security may not affect the 923 forwarding decision of all intermediate routers, but a packet may 924 be dropped if it fails a security check (can't be encrypted, 925 authentication failed, etc.). Dropping the packet is basically a 926 routing decision. 928 4.8. Candidate Access Router Discovery 930 Geographically Adjacent AR (GAAR) 932 An AR whose coverage area is such that an MN may move from the 933 coverage area of the AR currently serving the MN into the 934 coverage area of this AR. In other words, GAARs have APs whose 935 coverage areas are geographically adjacent or overlap. 937 Capability of AR 939 A characteristic of the service offered by an AR that may be of 940 interest to an MN when the AR is being considered as a handoff 941 candidate. 943 Candidate AR (CAR) 945 This is an AR that is a candidate for MN's handoff. CAR is 946 necessarily a GAAR of the AR currently serving the MN, and also has 947 the capability set required to serve the MN. 949 Target AR (TAR) 951 This is an AR with which the procedures for the MN's IP-level 952 handoff are initiated. TAR is usually selected from the set of 953 CARs. 955 TAR Selection Algorithm 957 The algorithm that determines a unique TAR for MN's handoff from 958 the set of CARs. The exact nature and definition of this 959 algorithm is outside the scope of this document. 961 4.9. User, Personal and Host Mobility 963 Different sorts of mobility management may be required of a mobile 964 system. We can differentiate between user, personal and host 965 mobility. 967 User mobility 969 refers to the ability of a user to access services from different 970 physical hosts. This usually means, the user has an account on 971 these different hosts or that a host does not restrict users from 972 using the host to access services. 974 Personal mobility 976 complements user mobility with the ability to track the user's 977 location and provide the user's current location to allow 978 sessions to be initiated by and towards the user by anyone on any 979 other network. Personal mobility is also concerned with enabling 980 associated security, billing and service subscription 981 authorization made between administrative domains. 983 Host mobility 985 refers to the function of allowing a mobile host to change its 986 point of attachment to the network, without interrupting IP 987 packet delivery to/from that host. There may be different sub- 988 functions depending on what the current level of service is being 989 provided; in particular, support for host mobility usually 990 implies active and idle modes of operation, depending on whether 991 the host has any current sessions or not. Access Network 992 procedures are required to keep track of the current point of 993 attachment of all the MNs or establish it at will. Accurate 994 location and routing procedures are required in order to maintain 995 the integrity of the communication. Host mobility is often 996 called 'terminal mobility'. 998 Two subcategories of "Host mobility" can be identified: 1000 Global mobility 1002 Same as Macro mobility. 1004 Local mobility 1006 Same as Micro mobility. 1008 Macro mobility 1010 Mobility over a large area. This includes mobility support and 1011 associated address registration procedures that are needed when a 1012 mobile host moves between IP domains. Inter-AN handovers 1013 typically involve macro-mobility protocols. Mobile-IP can be 1014 seen as a means to provide macro mobility. 1016 Micro mobility 1018 Mobility over a small area. Usually this means mobility within 1019 an IP domain with an emphasis on support for active mode using 1020 handover, although it may include idle mode procedures also. 1021 Micro-mobility protocols exploit the locality of movement by 1022 confining movement related changes and signalling to the access 1023 network. 1025 5. Specific Terminology for Mobile Ad-Hoc Networking 1027 Cluster 1029 A group of nodes located within close physical proximity, 1030 typically all within range of one another, which can be grouped 1031 together for the purpose of limiting the production and 1032 propogation of routing information. 1034 Cluster head 1036 A cluster head is a node (often elected in the cluster formation 1037 process) that has complete knowledge about group membership and 1038 link state information in the cluster. Each cluster should have 1039 one and only one cluster head. 1041 Cluster member 1043 All nodes within a cluster EXCEPT the cluster head are called 1044 members of that cluster. 1046 Convergence 1048 The process of approaching a state of equilibrium in which all 1049 nodes in the network agree on a consistent collection of state 1050 about the topology of the network, and in which no further 1051 control messages are needed to establish the consistency of the 1052 network topology. 1054 Convergence time 1056 The time which is required for a network to reach convergence 1057 after an event (typically, the movement of a mobile node) which 1058 changes the network topology. 1060 Laydown 1062 The relative physical location of the nodes within the ad hoc 1063 network. 1065 Pathloss matrix 1067 A matrix of coefficients describing the pathloss between any two 1068 nodes in an ad hoc network. When the links are asymmetric, the 1069 matrix is also asymmetric. 1071 Scenario 1073 The tuple 1074 characterizing a class of ad hoc networks. 1076 6. Security-related Terminology 1078 1082 The following were in the previous versions of this document: 1084 Mobility Security Association 1086 A collection of security contexts, between a pair IP nodes, each 1087 of which is configured to be applied to mobility-related protocol 1088 messages exchanged between them. Mobility security associations 1089 MAY be stored separately from the node's IPsec Security Policy 1090 Database (SPD). 1092 Security Context 1094 A security context between two routers defines the manner in 1095 which two routers choose to mutually authentication each other, 1096 and indicates an authentication algorithm and mode. 1098 Security Parameter Index (SPI) 1100 An index identifying a security context between a pair of routers 1101 among the contexts possible in the mobility security association. 1103 7. Security Considerations 1105 There are no security issues in this document. 1107 8. Contributors 1109 This draft was initially based on the work of 1111 o Tapio Suihko, VTT Information Technology, Finland 1113 o Phil Eardley and Dave Wisely, BT, UK 1115 o Robert Hancock, Siemens/Roke Manor Research, UK, 1117 o Nikos Georganopoulos, King's College London 1119 o Markku Kojo and Jukka Manner, University of Helsinki, Finland. 1121 Since revision -02, Charles Perkins has given as input terminology 1122 related to ad-hoc networks. 1124 9. Acknowledgement 1126 This work has been partially performed in the framework of the IST 1127 project IST-2000-28584 MIND, which is partly funded by the European 1128 Union. The authors would like to acknowledge the help of their 1129 colleagues in preparing this document. 1131 Some definitions of terminology have been adapted from [1], [7], [3], 1132 [2], [4], [9], [10] and [11]. 1134 10. References 1136 [1] D. Blair, A. Tweedly, M. Thomas, J. Trostle, and 1137 M. Ramalho. Realtime Mobile IPv6 Framework (work in 1138 progress). Internet Draft, Internet Engineering Task Force. 1139 draft-blair-rt-mobileipv6-seamoby-00.txt, November 2000. 1141 [2] P. Calhoun, G. Montenegro, and C. Perkins. Mobile IP 1142 Regionalized Tunnel Management (work in progress). Internet 1143 Draft, Internet Engineering Task Force, November 1998. 1145 [3] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6) 1146 Specification. Request for Comments (Draft Standard) 2460, 1147 Internet Engineering Task Force, December 1998. 1149 [4] G. Dommety (ed.). Fast Handovers for Mobile IPv6 (work 1150 in progress). draft-ietf-mobileip-fast-mipv6-04.txt, November 1151 2001. 1153 [5] Yavatkar et al. A Framework for Policy-based Admission Control. 1154 Request for Comments 2753, Internet Engineering Task Force, 1155 January 2000. 1157 [6] J. Kempf, P. McCann, and P. Roberts. IP Mobility and the CDMA 1158 Radio Access Network: Applicability Statement for Soft Handoff 1159 (work in progress). Internet Draft, Internet Engineering Task 1160 Force. draft-kempf-cdma-appl-00.txt, July 2000. 1162 [7] J. Kempf (ed.). Problem Description: Reasons For Doing Context 1163 Transfers Between Nodes in an IP Access Network. Internet Draft, 1164 Internet Engineering Task Force. 1165 draft-ietf-seamoby-context-transfer-problem-stat-04.txt, May 2002. 1167 [8] R. Pandya. Emerging Mobile and Personal Communication Systems. 1168 IEEE Communications Magazine, 33:44--52, June 1995. 1170 [9] C. Perkins. IP Mobility Support. Request for Comments 1171 (Proposed Standard) 2002, Internet Engineering Task Force, 1172 October 1996. 1174 [10] R. Ramjee, T. La Porta, S. Thuel, K. Varadhan, and 1175 L. Salgarelli. IP micro-mobility support using HAWAII (work in 1176 progress). Internet Draft, Internet Engineering Task Force, 1177 June 1999. 1179 [11] D. Trossen, G. Krishnamurthi, H. Chaskar, J. Kempf, "Issues in candidate 1180 access router discovery for seamless IP-level handoffs. Internet Draft 1181 (work in progress), draft-ietf-seamoby-cardiscovery-issues-02.txt, 1182 January 2002. 1184 11. Author's Addresses 1186 Questions about this document may be directed to: 1188 Jukka Manner 1189 Department of Computer Science 1190 University of Helsinki 1191 P.O. Box 26 (Teollisuuskatu 23) 1192 FIN-00014 HELSINKI 1193 Finland 1195 Voice: +358-9-191-44210 1196 Fax: +358-9-191-44441 1197 E-Mail: jmanner@cs.helsinki.fi 1199 Markku Kojo 1200 Department of Computer Science 1201 University of Helsinki 1202 P.O. Box 26 (Teollisuuskatu 23) 1203 FIN-00014 HELSINKI 1204 Finland 1206 Voice: +358-9-191-44179 1207 Fax: +358-9-191-44441 1208 E-Mail: kojo@cs.helsinki.fi 1210 Charles E. Perkins 1211 Communications Systems Lab 1212 Nokia Research Center 1213 313 Fairchild Drive 1214 Mountain View, California 94043 1215 USA 1216 Phone: +1-650 625-2986 1217 E-Mail: charliep@iprg.nokia.com 1218 Fax: +1 650 625-2502 1220 Tapio Suihko 1221 VTT Information Technology 1222 P.O. Box 1203 1223 FIN-02044 VTT 1224 Finland 1226 Voice: +358-9-456-6078 1227 Fax: +358-9-456-7028 1228 E-Mail: tapio.suihko@vtt.fi 1229 Phil Eardley 1230 BTexaCT 1231 Adastral Park 1232 Martlesham 1233 Ipswich IP5 3RE 1234 United Kingdom 1236 Voice: +44-1473-645938 1237 Fax: +44-1473-646885 1238 E-Mail: philip.eardley@bt.com 1240 Dave Wisely 1241 BTexaCT 1242 Adastral Park 1243 Martlesham 1244 Ipswich IP5 3RE 1245 United Kingdom 1247 Voice: +44-1473-643848 1248 Fax: +44-1473-646885 1249 E-Mail: dave.wisely@bt.com 1251 Robert Hancock 1252 Roke Manor Research Ltd 1253 Romsey, Hants, SO51 0ZN 1254 United Kingdom 1256 Voice: +44-1794-833601 1257 Fax: +44-1794-833434 1258 E-Mail: robert.hancock@roke.co.uk 1260 Nikos Georganopoulos 1261 King's College London 1262 Strand 1263 London WC2R 2LS 1264 United Kingdom 1266 Voice: +44-20-78482889 1267 Fax: +44-20-78482664 1268 E-Mail: nikolaos.georganopoulos@kcl.ac.uk) 1270 12. Appendix A - Examples 1272 This appendix provides examples for the terminology presented. 1274 A.1. Mobility 1276 Host mobility is logically independent of user mobility, although in 1277 real networks, at least the address management functions are often 1278 required to initially attach the host to the network. In addition, 1279 if the network wishes to determine whether access is authorized (and 1280 if so, who to charge for it), then this may be tied to the identity 1281 of the user of the terminal. 1283 An example of user mobility would be a campus network, where a 1284 student can log into the campus network from several workstations and 1285 still retrieve files, emails, and other services automatically. 1287 Personal mobility support typically amounts to the maintenance and 1288 update of some sort of address mapping database, such as a SIP server 1289 or DNS server; it is also possible for the personal mobility support 1290 function to take a part in forwarding control messages between end 1291 user and correspondent rather than simply acting as a database. SIP 1292 is a protocol for session initiation in IP networks. It includes 1293 registration procedures which partially support personal mobility 1294 (namely, the ability for the network to route a session towards a 1295 user at a local IP address). 1297 Personal mobility has been defined in [8] as "the ability of end 1298 users to originate and receive calls and access subscribed 1299 telecommunication services on any terminal in any location, and the 1300 ability of the network to identify end users as they move. Personal 1301 mobility is based on the use of a unique personal identity (i.e., 1302 personal number)." 1304 Roaming, in its original (GSM) sense, is the ability of a user to 1305 connect to the networks owned by operators other than the one having 1306 a direct formal relationship with the user. More recently (e.g., in 1307 data networks and UMTS) it also refers providing user-customized 1308 services in foreign networks (e.g., QoS profiles for specific 1309 applications). 1311 HAWAII, Cellular IP, Regional Registration and EMA are examples of 1312 micro mobility schemes, with the assumption that Mobile IP is used 1313 for macro mobility. 1315 WLAN technologies such as IEEE 802.11 typically support aspects of 1316 user and host mobility in a minimal way. User mobility procedures 1317 (for access control and so on) are defined only over the air 1318 interface (and the way these are handled within the network is not 1319 further defined). 1321 PLMNs (GSM/UMTS) typically have extensive support for both user and 1322 host mobility. Complete sets of protocols (both over the air and on 1323 the network side) are provided for user mobility, including 1324 customized service provision. Handover for host mobility is also 1325 supported, both within access networks, and also within the GSM/UMTS 1326 core network for mobility between access networks of the same 1327 operator. 1329 A.2. Handovers 1331 A hard handover is required where a MN is not able to receive or send 1332 traffic from/to two APs simultaneously. In order to move the traffic 1333 channel from the old to the new access point the MN abruptly changes 1334 the frequency/timeslot/code on which it is transmitting and listening 1335 to new values associated with a new access point. Thus, the handover 1336 is a break-before-make handover. 1338 A good example of hard handover is GSM where the mobile listens for 1339 new base stations, reports back to the network the signal strength 1340 and identity of the new base station(s) heard. When the old base 1341 station decides that a handover is required it instructs the new base 1342 station to set up resources and, when confirmed, instructs the mobile 1343 to switch to a new frequency and time slot. This sort of hand over 1344 is called hard, mobile assisted, network initiated and backward 1345 (meaning that the old base station is responsible for handling the 1346 change-over). 1348 In a TDMA system, such as GSM, the hard hand over is delayed until 1349 the mobile has moved well within the coverage of the new base 1350 station. If the handover threshold was set to the point where the 1351 new base station signal exceeded the old then there would be a very 1352 large number of handovers as the mobile moved through the region 1353 between the cells and radio signals fluctuated, this would create a 1354 large signalling traffic. To avoid this a large hysteresis is set, 1355 i.e. the new base station must be (say) 10dB stronger for handover 1356 to occur. If the same was done in W-CDMA then the mobile would be 1357 transmitting a powerful signal to the old base station and creating 1358 interference for other users, since in CDMA everyone else's 1359 transmissions are seen as noise, thus reducing capacity. To avoid 1360 this soft handover is used, giving an estimated doubling in capacity. 1361 Support for soft handover (in a single mode terminal) is 1362 characteristic of radio interfaces which also require macro diversity 1363 for interference limitation but the two concepts are logically 1364 independent. 1366 A good example of soft handover is the UTRAN FDD mode. W-CDMA is 1367 particularly suited to soft handover because of the design of the 1368 receivers and transmitters: typically a rake receiver will be used 1369 to overcome the multi-path fading of the wide-band channel. Rake 1370 receivers have a number of so-called fingers, each effectively 1371 separate detectors, that are tuned to the same signal (e.g. 1372 spreading code) but delayed by different times. When the delay times 1373 are correctly adjusted and the various components properly combined 1374 (this is micro diversity combining) the effect of multi-path fading 1375 is removed. The rake receiver can also be used to detect signals 1376 from different transmitters by tuning the fingers to different 1377 spreading codes. Soft handover is used in UTRAN FDD mode to also 1378 increase capacity. 1380 Every handover can be seen as a context-aware Handover. In PLMNs the 1381 context to be fulfilled is that the new AP can accommodate the new 1382 mobile, for example, the new GSM cell can serve the incoming phone. 1383 Lately, the notion of Context-aware Handovers has been enlarged by, 1384 for example, QoS-aware handovers, meaning that the handover is 1385 governed by the need to support the QoS-context of the moving mobile 1386 in order to keep the service level assured to the user of the MN. 1388 A.3. Diversity combining 1390 In the case of UMTS it is radio frames that are duplicated at some 1391 point in the network (the serving RNC) and sent to a number of 1392 basestations and, possibly via other (drift) RNCs. The combining 1393 that takes place at the serving RNC in the uplink direction is 1394 typically based on some simple quality comparison of the various 1395 received frames, which implies that the various copies of these 1396 frames must contain identical upper layer information. The serving 1397 RNC also has to do buffering data frames to take account of the 1398 differing time of flight from each basestation to the RNC. 1400 A.4. Miscellaneous 1402 In a GPRS/UMTS system the Access Network Gateway node could be the 1403 GGSN component. The ANG can provide support for mobility of hosts, 1404 admission control, policy enforcement, and Foreign Agent 1405 functionality [9]. 1407 When presenting a mobile network topology, APs and ARs are usually 1408 pictured as separate components (see Figure 1. This is the case with 1409 GSM/GPRS/UMTS presentations, for example. From the IP point of view 1410 APs are not directly visible. An AP should only be seen from the 1411 MN's or AR's IP layer as a link (interface) connecting MNs to the AR. 1413 When the mobile moves through the network, depending on the mobility 1414 mechanism, the OAR will forward packets destined to the old MNs 1415 address to the SAR which currently serves the MN. At the same time 1416 the handover mechanism may be studying CARs to find the best NAR 1417 where the MN will be handed next. 1419 13. Appendix B - Index of Terms 1421 1423 Full Copyright Statement 1425 Copyright (C) The Internet Society (2001). All Rights Reserved. 1427 This document and translations of it may be copied and furnished to 1428 others, and derivative works that comment on or otherwise explain it 1429 or assist in its implementation may be prepared, copied, published 1430 and distributed, in whole or in part, without restriction of any 1431 kind, provided that the above copyright notice and this paragraph are 1432 included on all such copies and derivative works. However, this 1433 document itself may not be modified in any way, such as by removing 1434 the copyright notice or references to the Internet Society or other 1435 Internet organizations, except as needed for the purpose of 1436 developing Internet standards in which case the procedures for 1437 copyrights defined in the Internet Standards process must be 1438 followed, or as required to translate it into languages other than 1439 English. 1441 The limited permissions granted above are perpetual and will not be 1442 revoked by the Internet Society or its successors or assigns. 1444 This document and the information contained herein is provided on an 1445 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1446 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1447 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1448 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1449 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.