Internet-Draft O. H. Levkowetz Expires: January 10, 2002 ABNW July 12, 2001 Wireless Micro-Mobility Handover Protocol (MM-HOP) Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents 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 "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. This Internet-Draft will expire on January 10, 2002. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract This Internet-Draft describes an experimental protocol, MM-HOP, which was defined during the fall of 2000 and is currently being implemented by ABNW. Using MM-HOP fast, state-preserving handovers between pico-cell wireless base-stations carrying IP traffic may be achieved. This draft is NOT submitted to seamoby as candidate for any standard protocol, only as a record of a limited implementation of context transfer and micro-mobility support. The mechanisms described here are limited to mobility within a single IP subnet, where the routing path does not change except with respect to the specific access point that maintains the radio connection with the mobile node. They do not cover mobility between IP subnets. It is assumed that IP Mobility Support according to RFC 2002 and associated RFC's will be used to support mobility over Levkowetz Expires January 10, 2002 [Page 1] Internet-Draft MM-HOP July 2001 larger areas than those considered here. The mechanisms may also be used without Mobile-IP Support, to handle mobility within a IP subnet only. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Physical layer . . . . . . . . . . . . . . . . . . . . . . . 5 2.1 Topology and Handover Frequency . . . . . . . . . . . . . . 5 2.2 Link-layer Address . . . . . . . . . . . . . . . . . . . . . 5 3. Link Layer . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1 Initial Connection . . . . . . . . . . . . . . . . . . . . . 6 3.2 Handover Preparation . . . . . . . . . . . . . . . . . . . . 6 3.3 Connection Loss . . . . . . . . . . . . . . . . . . . . . . 6 3.4 Reconnection Cases . . . . . . . . . . . . . . . . . . . . . 7 3.5 MN Actions During Handover . . . . . . . . . . . . . . . . . 7 3.6 LAP Actions During Handover . . . . . . . . . . . . . . . . 8 3.7 The Handover Candidate List . . . . . . . . . . . . . . . . 9 3.8 MN HCL Search Algorithm . . . . . . . . . . . . . . . . . . 10 3.9 MN Connection Setup During Handover . . . . . . . . . . . . 10 4. Network Layer . . . . . . . . . . . . . . . . . . . . . . . 12 4.1 Sample Handover Message Sequence . . . . . . . . . . . . . . 12 4.2 Message List . . . . . . . . . . . . . . . . . . . . . . . . 13 4.3 Message Type . . . . . . . . . . . . . . . . . . . . . . . . 13 4.4 LAP - LAP Messages . . . . . . . . . . . . . . . . . . . . . 14 4.4.1 Handover Status Request . . . . . . . . . . . . . . . . . . 14 4.4.2 Handover Status Response . . . . . . . . . . . . . . . . . . 16 4.4.3 Protocol State Request . . . . . . . . . . . . . . . . . . . 19 4.4.4 Protocol State Response . . . . . . . . . . . . . . . . . . 19 4.4.5 Buffered IP Request . . . . . . . . . . . . . . . . . . . . 21 4.4.6 Buffered IP Response . . . . . . . . . . . . . . . . . . . . 22 4.4.7 Identify LAP Request . . . . . . . . . . . . . . . . . . . . 22 4.4.8 Identify LAP Response . . . . . . . . . . . . . . . . . . . 24 4.5 LAP-MN Messages . . . . . . . . . . . . . . . . . . . . . . 27 4.5.1 LAP Announcement . . . . . . . . . . . . . . . . . . . . . . 27 4.5.2 Handover Candidate List Request . . . . . . . . . . . . . . 27 4.5.3 Handover Candidate List Response . . . . . . . . . . . . . . 28 4.5.4 New Handover Candidate Message . . . . . . . . . . . . . . . 30 4.5.5 New Handover Candidate Ack . . . . . . . . . . . . . . . . . 32 4.6 Handover Candidate Assessment . . . . . . . . . . . . . . . 33 4.6.1 Calculation of averages. . . . . . . . . . . . . . . . . . . 33 4.6.2 Relative Handover Frequency. . . . . . . . . . . . . . . . . 33 4.6.3 Handover Time. . . . . . . . . . . . . . . . . . . . . . . . 34 4.6.4 Link Quality . . . . . . . . . . . . . . . . . . . . . . . . 34 4.6.5 Link Capacity . . . . . . . . . . . . . . . . . . . . . . . 34 4.6.6 Link Latency . . . . . . . . . . . . . . . . . . . . . . . . 35 4.6.7 Link Cost . . . . . . . . . . . . . . . . . . . . . . . . . 35 4.6.8 Link Security . . . . . . . . . . . . . . . . . . . . . . . 35 4.6.9 Simple Assessment Example . . . . . . . . . . . . . . . . . 35 Levkowetz Expires January 10, 2002 [Page 2] Internet-Draft MM-HOP July 2001 4.7 Error Handling . . . . . . . . . . . . . . . . . . . . . . . 36 4.7.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . 36 4.7.2 Request Not Understood Message . . . . . . . . . . . . . . . 36 5. Security Considerations . . . . . . . . . . . . . . . . . . 38 References . . . . . . . . . . . . . . . . . . . . . . . . . 39 Author's Address . . . . . . . . . . . . . . . . . . . . . . 39 Full Copyright Statement . . . . . . . . . . . . . . . . . . 40 Levkowetz Expires January 10, 2002 [Page 3] Internet-Draft MM-HOP July 2001 1. Introduction Lightweight handheld computing devices, also called Personal Digital Assistants (PDAs) have become increasingly popular during the last couple of years, and ways of letting these be in constant contact with intranets or the internet have also received much attention. Light, cheap radio link technology have also started to appear to supply such connections, one point in case being the Bluetooth chip. As long as the PDA user sits in his office, a fixed radio link from PDA to his computer may be enough, but if he starts to move around, mechanisms are needed that will permit him to stay online, working, polling his mail-server, downloading information etc, while being connected to a series of different base stations. A simple radio link will not necessarily support mobility by providing mechanisms for handing over a connection from one base station to another. This Internet-Draft aims at defining a Micro-Mobility HandOver Protocol (MM-HOP) whereby fast, state-preserving handovers between simple pico-cell wireless base-stations may be achieved. The base-stations are assumed to be connected to an IP-network, and their function is to provide access to the IP-network for mobile nodes (MN). Such base-stations are also known as Lan Access Points (LAP) and will be so called in this Internet-Draft. Other names sometimes used are Access Points (AP) and Access Routers (AR). The mechanisms described here are limited to mobility within a single IP subnet, where the routing path does not change except with respect to the specific LAP that maintains the radio connection with the MN. This Internet-Draft does NOT cover mobility between IP subnets. It is assumed that IP Mobility Support according to RFC 2002 and associated RFC's, and possibly other mechanisms, will be used to support mobility over larger areas than those considered here. The mechanisms described here may also be used without any other IP Mobility Support, to handle mobility within a IP subnet only. These mechanisms are not, however, restricted to mobility between access points which use the same radio medium. As long as the nodes are within the same IP subnet, the physical medium may be different, it may for instance be desireable to cover an office building and its nearby grounds by a network using Bluetooth tranceivers in individual offices, and 802.11 outdoors. If the mobile node has support for both these standards the protocol described here will facilitate handover between both types of access points. Levkowetz Expires January 10, 2002 [Page 4] Internet-Draft MM-HOP July 2001 2. Physical layer 2.1 Topology and Handover Frequency The physical layer mechanisms to be used are assumed to be covered by the radio interface specification. What we still have to mention here is the physical layout assumptions with which we work. One aspect of this is the cell size and distance between cells, which determines handover frequency and base-station distance. For the typical base-station considered here the cell size is less than 10 meter in radius when 1/3 data rate forward error correction (FEC) is employed, and less than 3 meter in radius when the full data rate is used. This means that at an energic walk a handover may be needed every 2 seconds or so. We will want to use handover mechanisms which may be employed at this rate without deluging the network with messages, and we will also need fallback mechanisms in case we fail to perform handovers in time. 2.2 Link-layer Address In the remainder of this document, reference is made repeatedly to 'link-layer address', by which is meant the radio link-layer address, not the ID of the wired network side of the LAPs. Depending on the actual radio link technology, this may be a channel number or some other form of identification associated with the radio hardware. Example: The Bluetooth radio hardware uses a Bluetooth Device ID which is 48 bits long and unique for each Bluetooth unit. Levkowetz Expires January 10, 2002 [Page 5] Internet-Draft MM-HOP July 2001 3. Link Layer Within the link layer as seen from the viewpoint of the IP network, we have sub-layers which handles link establishment / maintenance / teardown and media access control. 3.1 Initial Connection Establishing a connection shall be done as defined for the appropriate link layer protocol. It is assumed that the LAP will use a standard protocol (RADIUS, RFC 2138, for instance) to handle authentication on the network side, using for instance PAP or CHAP on the MN side. The Authentication, Authorization and Accounting (AAA) details of the connection are not of relevance to this Internet-Draft, except in the respect that any state established has to be discoverable and transferable to another LAP, and that wireless communication is inherently insecure, so some special security support is needed. 3.2 Handover Preparation When a connection has been established, the current LAP provides the MN with a list of alternative access points, the handover candidate list. This information is transferred to the MN using IP over the wireless link. The handover candidate list is dynamically built and maintained by each LAP based on information gathered from the handover data exchanged by LAPs during a handover, and also based on data received from MNs which may scan for nearby LAPs during idle periods. The creation and maintenance of the handover candidate list will be described in more detail later in Section 3.7. Every time the MN connects to a new LAP, it will receive a new handover candidate list, completely replacing the handover candidate list it received from the previous LAP. In order to be able to participate in a handover where the link layer does not need to be set up from scratch (including new authentication), the MN needs to remember certain information regarding the latest LAP it has been connected to. This includes at least the IP address, link-layer address, and link key. Of these, the IP address and link-layer address will eventually be stored in the handover candidate list. 3.3 Connection Loss When a LAP looses connection with an MN, it should still continue to function as a proxy for the MN's IP address, keeping the link layer state intact, and buffer IP packages. Levkowetz Expires January 10, 2002 [Page 6] Internet-Draft MM-HOP July 2001 If an IP packet buffer for a disconnected MN overflows, new packets are thrown away. If the MN reconnects with some other LAP, the old packets are the ones least likely to have been captured by the new LAP. When an MN discovers that it has lost connection with the current LAP, it shall start its reconnection procedure, as described in Section 3.5, Section 3.8 and Section 3.9. 3.4 Reconnection Cases After a connection loss, the following reconnection cases are possible: 1. The MN reconnects with the same LAP. In this case, the connection is just resumed without bad feelings on either side. 2. The MN reconnects with a new LAP on the same IP subnet, in which case the old LAP will be notified, and turn over link layer state and buffered IP packets. It will stop acting as proxy for the MN, empty its buffers and tear down its side of the link. 3. The MN does not reconnect, or reconnects (possibly in some other network, with other routing) without notifying the old LAP. In this case the old LAP will keep state and buffers for a time, but should eventually time out and forget all about it. Buffers are emptyed, link layer torn down and IP packets for the MN IP address no longer received. The timeout should be no less than 15 s, and probably not greater than 5 minutes. 3.5 MN Actions During Handover On connection loss or unacceptable quality of service, the MN will attempt to establish a connection with a new LAP. It will attempt to use the following handover mechanisms in order: A. Fast handover with state preservation: The MN will attempt to establish a connection with the LAPs on the candidate list, in the order given. When connection is established, the state of the link layer of the connection is transferred from the old access point to the new access point. If no list of alternative access points have been provided, the list has been exhausted, or the MN has reached the limit set for unsuccessful connection attempts using the candidate list without finding an access point, fallback is done to: Levkowetz Expires January 10, 2002 [Page 7] Internet-Draft MM-HOP July 2001 B. Slow handover with state preservation: The MN link layer scans for any LAP within radio reach, until one is found. At the end of each complete failed scan, a status report is made upwards to the next protocol level, indicating loss of connection and continuing scan. After a time predetermined by the MN, scanning will stop and a failure message will be sent to the next higher protocol level. On a successful scan (i.e. one where one or more LAPs have been found), the MN will attempt to establish a connection. If no connection with preserved state can be established, we have to do: C. Establishment of a new connection, including new link protocol setup and authentication. This is a more lengthy procedure. A choice must be made in the mobile node with respect to caching of authentication tokens or not which is beyond the scope of this Internet-Draft. See Section 3.1, Initial Connection, for details on establishing a new connection. Of course, a prerequisite for a new connection is that the MN has moved to an area with radio coverage since it failed to do the handover. 3.6 LAP Actions During Handover If a successful reconnect have been done, the MN may inform the new LAP about the identity of the previous LAP, using link-layer messages. The new LAP will then: 1. Inform the previous LAP about the handover, using unicast if the previous LAP's IP address is known, otherwise using broadcast. The previous LAP may then update its handover candidate list if found appropriate. 2. Receive status information, including time elapsed since connection loss, from the old LAP, permitting the new LAP to update its list of candidate handover LAPs if found appropriate. 3. Attempt to transfer the link connection state from the old LAP. If too long time has passed, the state information in the old LAP may have expired, though. The message sequence and message layout involved in this will be discussed in detail in the next chapter. Levkowetz Expires January 10, 2002 [Page 8] Internet-Draft MM-HOP July 2001 3.7 The Handover Candidate List The Handover Candidate List (HCL) is an ordered list of LAPs, which is dynamically built and maintained by each LAP individually. When a LAP is first installed, the HCL is empty, which means that the first handovers done within the network will be based on the MN scanning for nearby LAPs, as described under handover mechanism B, Section 3.5 above. It is entirely up to the MN which criteria it will use to choose between candidates, if more than one is found during the scan. When a handover is then performed, both the old and the new LAP will have the other LAP as a potential candidate to put in its HCL; that is, both the new and old LAP may update its HCL as a result of a successful handover. If the HCL is empty, any entry will do, but with each entry shall be stored performance data, including time between connection loss and connection re-establishment, a number indicating the relative frequency of successful handovers to that LAP, a quality parameter and a capacity parameter. This will make it possible to order the entries and improve the list over time. In addition to the list information derived from completed handovers, handover candidates may be found by the MN. During gaps in communication the MN may scan the environment for additional LAPs, and if one is found, the MN will put it on its handover candidate list, and also inform the current LAP about the new candidate. The current LAP is free to add the new candidate to its own handover candidate list or not, based on heuristics; Least Recently Used (LRU) algorithms or whatever. It is not defined here how long the HCL list should be, but it is wise to let the list be somewhat longer than the number of good handover candidates expected, for the following reason: There may be LAPs nearby which in practice very seldom participate in a successful handover, but still may be discovered by the MN during scans. If the list is long enough to include such LAPs, no reshuffling will occur when an MN finds such a LAP during a scan. If such a LAP is NOT on the list, it would be prudent for the current LAP to add it, as it might actually be a new node recently added to the net to improve performance. If it is not a new node, however, just an old nearby node which seldom catches a handover, adding it to a short HCL may result in pushing a better handover candidate out of the list. In short, the HCL of a LAP should be long enough to hold all LAPs an MN might discover while connected to that LAP, plus a reasonable number of additional LAPs which might be further away. A suggested length, assuming an hexagonal LAP grid, would be 6 + 12 entries (first and second tier neighbours), with new candidates found by MN scanning to be placed in position 5 (or higher, if the list is less than 5 entries long). Levkowetz Expires January 10, 2002 [Page 9] Internet-Draft MM-HOP July 2001 A corollary to this is that the MN must attempt connection with not just the first few entries on the list. Otherwise a newly installed LAP would never be able to rise to its most appropriate position on the list. For this reason we define the following MN search algorithm, which shall be used by MNs. 3.8 MN HCL Search Algorithm This algorithm prescribes the use of a random decision to contact or not contact LAPs on the handover candidate list, in order to break up sub-optimal concentrations of MNs to a single LAP in topologies where actually more than one LAP are within reach. Otherwise the first LAP of two equally good candidates might end up taking all the handovers, and the second LAP on the list would gradually rank lower and lower, as a result of not receiving any handovers. 1. Use a search list consisting of all LAPs on the HCL. 2. Start at the top of the search list 3. Make a random choice with probability p >= 0.5 of trying to contact the entry. 4. If the choice is to try, do so and go to step 7. 5. Otherwise, continue down the list until an attempt has been made to contact a LAP. 6. If we hit end of list without contacting a LAP, contact the last LAP on the list. 7. If successful, end of algorithm. 8. If unsuccessful, eliminate the LAP we tried to contact from the search list. 9. If we have tried to contact more LAPs than a configurable give-up threshold, give up the HCL directed search and fall back to Section 3.5, part B. 10. Otherwise, continue from step 2 above (with the new shorter Search List). 3.9 MN Connection Setup During Handover A link layer connection set up between an MN and a LAP has to be done in several steps, as the MN and LAP initially can assume nothing about each other. For an MN which does not follow the MM-HOP protocol described here, any reconnection is done as a Levkowetz Expires January 10, 2002 [Page 10] Internet-Draft MM-HOP July 2001 initial connection (Section 3.1). Otherwise, the sequence during handover is as follows: 1. The MN attempts to set up a link layer connection with a LAP based on the link-layer address information in the handover candidate list. If successful, this gives a basic, unauthenticated but preferrably encrypted link layer connection. Over this connection the MN and the LAP may exchange IP addresses. 2. (Optional) Having exchanged IP addresses, an IP connection is set up, and the new LAP and the MN may exchange handover information using IP packets. At this time the LAP may not, however, forward any IP packets from the MN to the network or vice versa; the link is limited to transporting packets between the LAP and the MN exclusively. The new LAP now requests from the MN the IP address of the old LAP to which the MN was connected (using the 'Previous LAP Request' message described later). If no reply is received to this request, after being repeated as described in Section 4.7.1, we give up and fall back to setting up a new connection as in Initial Connection (Section 3.1). In order to prevent false authentication through outside nodes impersonating a LAP, the IP address of the old LAP is required to be on the same IP subnet as the new LAP, this must be verified by the new LAP before the address is used. 3. An MN status request is sent to the old LAP, using unicast if the IP address is known, broadcast otherwise. Information about status, handover parameters and link key is returned if the MN has already been authenticated and a valid link has been established. 4. With authentication and link key established, the new LAP can now complete the link setup, providing transport from the MN all the way through to the network. Levkowetz Expires January 10, 2002 [Page 11] Internet-Draft MM-HOP July 2001 4. Network Layer 4.1 Sample Handover Message Sequence In order to transfer the link layer state, there are 2 parts that need to be handled: The state of the actual link layer state machine, and messages that may have been buffered in the Old LAP, and now await transmission to the MN. A possible message exchange could look like this: Old Lan Access Point New Lan Access Point | | Old MN Connection lost | (Still buffering IP packets) New MN Connection setup | | |<---------- MN status request ---------| | | |--------------- MN Status ------------>| | | | Wireless connection setup | IF & ProxyARP setup | Link Protocol initialized | IP Buffering starts | | | <<--- Gratuitous ARP broadcast ---| | | IP Buffering stops | Repeat //---------------------------------------------// | | |<------ Protocol X state request ------| | | Protocol State collect | Protocol teardown | | | |------- Protocol X state transfer ---->| | | | Protocol state setup | | End repeat //---------------------------------------------// | Start IP forwarding | | |<------ Buffered packages request -----| | | |------ Buffered packages response ---->| | | |------- Buffered package for MN ------>| | ... | |------- Buffered package for MN ------>| | | Levkowetz Expires January 10, 2002 [Page 12] Internet-Draft MM-HOP July 2001 All messages illustrated here are described below, with the exception of the ARP messages which must follow RFC826[2], section 4.6., and the forwarded buffered packages, which are IP packets sent to the IP address of the MN without any change by either old LAP or new LAP. 4.2 Message List This is a complete list of the messages defined in this Internet-Draft, in the order they would normally be used (except for the last, Request Not Understood Message): Messages used during handover: Handover Status Request New LAP --> Old LAP Handover Status Response New LAP <-- Old LAP Protocol State Request New LAP --> Old LAP Protocol State Response New LAP <-- Old LAP Buffered IP Request New LAP --> Old LAP Buffered IP Response New LAP <-- Old LAP Messages used to handle Handover Candidate Lists: LAP Announcement New LAP --> MN Handover Candidate List Request New LAP <-- MN Handover Candidate List Response New LAP --> MN New Handover Candidate Message Old LAP <-- MN New Handover Candidate Ack Old LAP --> MN Identify LAP Request Old LAP --> LAP Candidate Identify LAP Response Old LAP <-- LAP Candidate Error handling message: Request Not Understood Message any --> any 4.3 Message Type It would seem reasonable to have the handover messages implemented as ICMP messages, however the ICMP message types 41..255 are marked as 'Reserved' in the IANA registry, so transport will be done using UDP messages on port number [TBD] (provisionally private port number 49999 which happens to be a prime number, which is of absolutely no relevance here). Information like source and destination IP address of an IP package, and package length, are assumed to be available and is not repeated in the messages defined below. Levkowetz Expires January 10, 2002 [Page 13] Internet-Draft MM-HOP July 2001 4.4 LAP - LAP Messages 4.4.1 Handover Status Request This message is sent from the new LAP to the old LAP after an MN has requested a connection and provided IP address and link-layer address of its previous LAP (presumably using link-layer messages). Alternatively, this message may be broadcast by the new LAP if no old LAP IP address is available. This message is not used if the IP address of its previous LAP belongs to a different IP subnet than the current LAP. In this case the MN is instead informed about the need to establish new routing using Mobile-IP. If there is no response to this message, it shall be repeated as described in section 4.5., and if still no response the handover is considered failed, the MN is informed, and no network layer connection is set up. It is then up to the MN to inform the application of the loss of connection, or to invisibly attempt to establish a new connection, possibly using cached user ID, password etc. The link-layer address of the new LAP is included so that the old LAP may update its handover candidate table, if it finds that appropriate. (The IP address of the new LAP is available in the IP header). Fields which are not used are sent as 0 (zero). Fields where the information required is unknown are sent as all ones (i.e. 255 for byte-wide fields, 65535 for 16-bit fields, etc.). 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 | Code | Version | Reserved-0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MN IP address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status | HO-delay | Quality | Capacity | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Latency | Cost | Security | Q-type|Resv1|M| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Media number | LAP HW ID Len | MN HW ID Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . New LAP Hw ID . . . Levkowetz Expires January 10, 2002 [Page 14] Internet-Draft MM-HOP July 2001 | | + +-+-+-+-+-+-+-+-+-+-+-+ | | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . MN Hw ID . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type Message type number = 1 Code Not used Version Message version number = 1 Reserved-0 Reserved bits, sent as zero MN IP address IP address of the MN being handed over, if known. Otherwise sent as all ones. Status Not used, sent as zero HO-delay Not used, sent as zero Quality Link quality for this link. See Section 4.6.4. Capacity Link capacity for this link. See Section 4.6.5. Latency Link latency for this link. See Section 4.6.6. Cost Link cost for this link. See Section 4.6.7. Security Link security for this link. See Section 4.6.8. Q-Type The type of the underlying Quality Measure: 0 - Undefined 1 - Bit Error Rate (BER) 2 - Frame Erasure Rate 3 - Frame Error Rate 4 - Message Erasure Rate (MER) 5 - Signal to Noise Ratio (S/N) 6 - Carrier (or Signal) to Interference Ratio (C/I) Resv1 Reserved bits, sent as zero Levkowetz Expires January 10, 2002 [Page 15] Internet-Draft MM-HOP July 2001 Media number A media identifier assigned by IANA to the Link-layer/Physical layer combination the LAP is using. This means that e.g. Bluetooth and 802.11 using the unlicensed 2.3 GHz band have different media identifiers, as do 802.11 on the 2.3 GHz and 5 GHz band. This uniquely identifies the Link and Physical layers used to contact this LAP, for multi-mode MNs. M flag Reserved, sent as zero Reserved-2 Reserved bits, sent as zero LAP HW ID Len Length in octets of the New LAP link-layer address field MN HW ID Len Length in octets of the MN link-layer address field New LAP Hw ID Link-layer address of the new LAP Padding Padding as needed to make the next block start at a multiple-of-4 octet offset from the start of the packet (the Type field). MN Hw ID Link-layer address of the MN 4.4.2 Handover Status Response This message is sent from the old LAP to the new LAP as a response to a Handover Status Request Message. The IP and link-layer address of the old LAP is included so that the new LAP may update its handover candidate table, if it finds that appropriate. The time is measured by the old LAP as elapsed between connection loss and receipt of the Handover Status Request message is included to help determine the goodness of the old LAP as a handover candidate. It is measured in tenths of seconds. A status code is sent back by the old LAP as part of this message. It may be composed of one or more of the following values ORed together: Status Meaning -------------------- 1 Known MN 2 Link key available Levkowetz Expires January 10, 2002 [Page 16] Internet-Draft MM-HOP July 2001 4 Protocol states available A returned status of 0 accordingly indicates that no MN with the given identity (IP address or HW ID) is known by the queried LAP. After this message has been sent, a timeout timer is set, with a suggested timeout value of 2 seconds. After the timer elapses, the old LAP will not respond to any Handover Status Request messages regarding this MN (until possibly a new connection has existed between this LAP and the same MN). It will still respond to Protocol State Request and Buffered IP Request messages relevant to this MN. The purpose of this timeout is to avoid a deluge of old and irrelevant responses when the Handover Status Request message is sent as a broadcast message. 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 | Code | Version | Reserved-0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MN IP address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status | HO-delay | Quality | Capacity | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Latency | Cost | Security | Q-type|Resv1|M| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Media number | Reserved-2 | HW ID Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Old LAP Hw ID . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Uptime | Link Key Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . MN Link key (Authentication key) . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type Message type number = 2 Code Not used Version Message version number = 1 Levkowetz Expires January 10, 2002 [Page 17] Internet-Draft MM-HOP July 2001 Reserved-0 Reserved bits, sent as zero MN IP address IP address of the MN being handed over Status As describe above. HO-delay The time between connection loss and receipt of the Handover Status Request message . See Section 4.6.3. Quality Link quality for this link. See Section 4.6.4. Capacity Link capacity for this link. See Section 4.6.5. Latency Link latency for this link. See Section 4.6.6. Cost Link cost for this link. See Section 4.6.7. Security Link security for this link. See Section 4.6.8. Q-Type The type of the underlying Quality Measure: 0 - Undefined 1 - Bit Error Rate (BER) 2 - Frame Erasure Rate 3 - Frame Error Rate 4 - Message Erasure Rate (MER) 5 - Signal to Noise Ratio (S/N) 6 - Carrier (or Signal) to Interference Ratio (C/I) Resv1 Reserved bits, sent as zero Media number A media identifier assigned by IANA to the Link-layer/Physical layer combination the LAP is using. This means that e.g. Bluetooth and 802.11 using the unlicensed 2.3 GHz band have different media identifiers, as do 802.11 on the 2.3 GHz and 5 GHz band. This uniquely identifies the Link and Physical layers used to contact this LAP, for multi-mode MNs. M flag Reserved, sent as zero Reserved-2 Reserved bits, sent as zero HW ID Length Length in octets of the link-layer address field Old LAP Hw ID Link-layer address of the old LAP Levkowetz Expires January 10, 2002 [Page 18] Internet-Draft MM-HOP July 2001 Link Uptime The accumulated time since the link was first authenticated, in seconds. Link Key Length Length in octets of the link key field Link key The LAP cryptographic link information 4.4.3 Protocol State Request This message is sent from the new LAP to the old LAP when the handover status response indicates that protocol state is available, in order to request protocol state information. 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 | Code | Version | Reserved-0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MN IP address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protocol number | Protocol port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type Message type number = 3 Code Not used Version Message version number = 1 Reserved-0 Reserved bits, sent as zero MN IP address IP address of the MN being handed over Protocol number The IANA protocol number for which state information is requested Protocol port The IANA protocol port for which state information is requested 4.4.4 Protocol State Response This message is the response to a Protocol State Request sent from the old LAP to the new LAP. If the Protocol State Request was sent erroneously, the code field is set to zero, and only the type, code, version and IP-address fields are returned. If valid Protocol State information is returned, the code field is set to 1. In addition to standardised Protocol state parameters --- (TBD) ---, a vendor specific state block is permitted. The vendor is identified by domain name. The length of vendor name and vendor state block is Levkowetz Expires January 10, 2002 [Page 19] Internet-Draft MM-HOP July 2001 determined by explicit length fields. The vendor information is optional, but if present, all 4 fields must be present. The vendor field may not be sent unless the standardised Protocol state parameters are sent. 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 | Code | Version | Reserved-0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MN IP address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protocol number | Protocol port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Param. length | Protocol param 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protocol param 1 | Protocol param 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o o o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor name len | Vendor block len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Vendor name . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Vendor block . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type Message type number = 4 Code 0 - no state information available 1 - has standard protocol state params 2 - has standard and vendor params Version Message version number = 1 Reserved-0 Reserved bits, sent as zero MN IP address IP address of the MN being handed over Levkowetz Expires January 10, 2002 [Page 20] Internet-Draft MM-HOP July 2001 Protocol number The IANA protocol number for which state information is requested Protocol port The IANA protocol port for which state information is requested Param. length The length of the block of standardised protocol parameters, in octets Protocol params The indicated length of standardized protocol parameters. Vendor name len The length in octets of the vendor identification. Vendor block lenThe length in octets of the vendor specific data block. Vendor name The domain name of the vendor, used for vendor identification. Vendor block A block of binary vendor-specific state data. 4.4.5 Buffered IP Request This message is sent from the new LAP to the old LAP after a link connection has been set up by the new LAP with the MN, for the purpose of catching any buffered packages that may still reside in the old LAP. This minimizes packet loss, and also allows the old LAP to reuse its buffer space as soon as possible, without waiting for any timeout. 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 | Code | Version | Reserved-0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MN IP address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type Message type number = 5 Code Not used Version Message version number = 1 Reserved-0 Reserved bits, sent as zero MN IP address IP address of the MN being handed over Levkowetz Expires January 10, 2002 [Page 21] Internet-Draft MM-HOP July 2001 4.4.6 Buffered IP Response This message is sent from the old LAP to the new LAP as a response to the Buffered IP Request, with code = 0 if no buffered IP packages are available, and with a code=1 if there are buffered IP packages available. The buffered IP packages are thereafter transmitted unchanged, as they were received, and will now be picked up by the LAP currently acting as proxy for the MN. It is not expected that the old LAP shall keep packages buffered after they have been forwarded. 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 | Code | Version | Reserved-0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MN IP address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type Message type number = 6 Code 0 - No packets available 1 - Packets available Version Message version number = 1 Reserved-0 Reserved bits, sent as zero MN IP address IP address of the MN being handed over 4.4.7 Identify LAP Request This message is broadcast from any LAP which has received a 'New Handover Candidate Message' (Section 4.5.4) where the IP address of the candidate LAP is unknown. This broadcast request fills two purposes, one is to verify that the candidate resides on the same subnet as the broadcasting LAP, and thus is a valid handover candidate in this respect. The other is to acquire the IP address that belongs with the Hardware ID which had been reported by the MN in the New Handover Candidate Message. If no reply to this request is received after being repeated as described in Section 4.7.1, the sender is to assume that the Candidate LAP is not present on the same subnet as the sender, and thus is disqualified as a valid Handover Candidate. This message has the same format as the 'New Handover Candidate Message' (Section 4.5.4), except that the Candidate LAP information Levkowetz Expires January 10, 2002 [Page 22] Internet-Draft MM-HOP July 2001 block is not repeated. 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 | Code | Version | Reserved-0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LAP IP address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Candidate LAP information block: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Candidate IP Addr. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Aver. Freq. | Aver. HO time | Aver. Quality | Aver. Capacity| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Aver. Latency | Aver. Cost | Security | Q-type|Resv1|M| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Media number | Reserved-2 | HW ID Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Candidate Hw ID . . . | | + +-+-+-+-+-+-+-+-+-+-+-+ | | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type Message type number = 7 Code Not used Version Message version number = 1 Reserved-0 Reserved bits, sent as zero LAP IP address Not used, sent as zero Candidate IP AddrNot used, sent as zero Aver. Freq. Not used, sent as zero Aver. HO Time Not used, sent as zero Aver. Quality Not used, sent as zero Aver. Capacity Not used, sent as zero Levkowetz Expires January 10, 2002 [Page 23] Internet-Draft MM-HOP July 2001 Aver. Latency Not used, sent as zero Aver. Cost Not used, sent as zero Security Not used, sent as zero Q-Type Not used, sent as zero Resv1 Reserved bits, sent as zero Media number Not used, sent as zero M flag Reserved, sent as zero Reserved-2 Reserved bits, sent as zero HW ID Length Length in octets in the link-layer address field Candidate Hw ID The link-layer address of the Candidate LAP. Padding Padding as needed to make the next block start at a multiple-of-4 octet offset from the start of the packet (the Type field). 4.4.8 Identify LAP Response This message is sent from a LAP which has a HW ID which matches the HW ID in a 'Identify LAP Request' message (Section 4.4.7). It has the same format as that message. On reply, all fields in the 'Candidate LAP information block' has been filled in, as far as possible. Where the information required is unknown, the fields are set to all ones (i.e. 255 for byte-wide fields, 65535 for 16-bit fields, etc.) in the same manner as in Section 4.5.3. 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 | Code | Version | Reserved-0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LAP IP address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Candidate LAP information block: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Candidate IP Addr. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Aver. Freq. | Aver. HO time | Aver. Quality | Aver. Capacity| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Aver. Latency | Aver. Cost | Security | Q-type|Resv1|M| Levkowetz Expires January 10, 2002 [Page 24] Internet-Draft MM-HOP July 2001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Media number | Reserved-2 | HW ID Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Candidate Hw ID . . . | | + +-+-+-+-+-+-+-+-+-+-+-+ | | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type Message type number = 8 Code Not used Version Message version number = 1 Reserved-0 Reserved bits, sent as zero LAP IP address Not used Candidate IP AddrThe IP address of the Handover Candidate LAP. Aver. Freq. recent average handover frequency. See Section 4.6.2 Aver. HO Time recent average handover time. See Section 4.6.3 Aver. Quality recent average link quality. See Section 4.6.4 Aver. Capacity recent average link capacity. See Section 4.6.5 Aver. Latency recent average link latency. See Section 4.6.6 Aver. Cost recent average link cost. See Section 4.6.7 Security link security for this LAP. See Section 4.6.8 Q-Type The type of the underlying Quality Measure: 0 - Undefined 1 - Bit Error Rate (BER) 2 - Frame Erasure Rate 3 - Frame Error Rate 4 - Message Erasure Rate (MER) 5 - Signal to Noise Ratio (S/N) 6 - Carrier (or Signal) to Interference Ratio (C/I) Levkowetz Expires January 10, 2002 [Page 25] Internet-Draft MM-HOP July 2001 Resv1 Reserved, sent as zero Media number A media identifier assigned by IANA to the Link-layer/Physical layer combination the LAP is using. This means that e.g. Bluetooth and 802.11 using the unlicensed 2.3 GHz band have different media identifiers, as do 802.11 on the 2.3 GHz and 5 GHz band. This uniquely identifies the Link and Physical layers used to contact this LAP, for multi-mode MNs. M flag Reserved, sent as zero Reserved-2 Reserved bits, sent as zero HW ID Length Length in octets in the link-layer address field Candidate Hw ID The link-layer address of the Candidate LAP. Padding Padding as needed to make the next block start at a multiple-of-4 octet offset from the start of the packet (the Type field). Levkowetz Expires January 10, 2002 [Page 26] Internet-Draft MM-HOP July 2001 4.5 LAP-MN Messages A LAP and an MN need to exchange messages about handover candidates. These messages are sent as UDP messages over the link between LAP and MN. 4.5.1 LAP Announcement This message is sent from a LAP to an MN to announce its presence and IP address. 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 | Code | Version | Reserved-0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type Message type number = 15 Code Not used Version Message version number = 1 Reserved-0 Reserved bits, sent as zero 4.5.2 Handover Candidate List Request This message is sent from the MN to the LAP after a connection has been established, in order to request the HCL for the current LAP. As it may also be advantageous to be able to send this message to some other node, e.g. a central repository with explicit knowledge of the physical LAP positions, the IP address of the LAP for which the HCL is requested is included in this message, although it is not strictly needed as long as the message only is used between MN and its current LAP. 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 | Code | Version | Reserved-0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LAP IP address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type Message type number = 18 Code Not used Version Message version number = 1 Levkowetz Expires January 10, 2002 [Page 27] Internet-Draft MM-HOP July 2001 Reserved-0 Reserved bits, sent as zero LAP IP address The IP address of the LAP for which the Handover Candidate List is requested. 4.5.3 Handover Candidate List Response This message is normally sent to the MN in response to a HCL Request, but may also, at the discretion of the LAP, be sent without being requested. It contains an ordered list of handover candidates, with the candidates with the highest expected likelihood of being able to catch a handover from the current LAP first on the list. The HCL is valid for the LAP with IP address given in the 'LAP IP Address' field. In case the LAP does not have a valid value for a handover parameter fields (Aver. Freq. etc), it should fill them with the value 255, in which case they should be ignored. The maximum valid value in any field is 254. The measurement, calculation and encoding of the 4 fields which give statistics about each list entry (Aver. Freq., Aver. HO time, Aver. Quality, Aver. Capacity, Aver. Latency, Aver. Cost, Security ) is described in detail in 'Handover Candidate Assessment' (Section 4.6) later. 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 | Code | Version | Reserved-0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LAP IP address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Repeated block: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Candidate IP Addr. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Aver. Freq. | Aver. HO time | Aver. Quality | Aver. Capacity| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Aver. Latency | Aver. Cost | Security | Q-type|Resv1|M| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Media number | Reserved-2 | HW ID Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Candidate Hw ID . . . | | Levkowetz Expires January 10, 2002 [Page 28] Internet-Draft MM-HOP July 2001 + +-+-+-+-+-+-+-+-+-+-+-+ | | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o o o Type Message type number = 19 Code Not used Version Message version number = 1 Reserved-0 Reserved bits, sent as zero LAP IP address The IP address of the LAP for which the Handover Candidate List is valid. Candidate IP AddrThe IP address of the Handover Candidate LAP. Aver. Freq. recent average handover frequency. See Section 4.6.2 Aver. HO Time recent average handover time. See Section 4.6.3 Aver. Quality recent average link quality. See Section 4.6.4 Aver. Capacity recent average link capacity. See Section 4.6.5 Aver. Latency recent average link latency. See Section 4.6.6 Aver. Cost recent average link cost. See Section 4.6.7 Security link security for this LAP. See Section 4.6.8 Q-Type The type of the underlying Quality Measure: 0 - Undefined 1 - Bit Error Rate (BER) 2 - Frame Erasure Rate 3 - Frame Error Rate 4 - Message Erasure Rate (MER) 5 - Signal to Noise Ratio (S/N) 6 - Carrier (or Signal) to Interference Ratio (C/I) Resv1 Reserved bits, sent as zero Media number A media identifier assigned by IANA to the Link-layer/Physical layer combination the LAP is Levkowetz Expires January 10, 2002 [Page 29] Internet-Draft MM-HOP July 2001 using. This means that e.g. Bluetooth and 802.11 using the unlicensed 2.3 GHz band have different media identifiers, as do 802.11 on the 2.3 GHz and 5 GHz band. This uniquely identifies the Link and Physical layers used to contact this LAP, for multi-mode MNs. M flag 1 - more blocks 0 - last block. Reserved-2 Reserved bits, sent as zero HW ID Length Length in octets in the link-layer address field Candidate Hw ID The link-layer address of the Candidate LAP. Padding Padding as needed to make the next block start at a multiple-of-4 octet offset from the start of the packet (the Type field). 4.5.4 New Handover Candidate Message This message is sent from an MN to the LAP it is connected to when the MN has discovered one or more new handover candidates. The format and fields are exactly as for the handover candidate list response. In most cases the MN will not have any valid values for the handover parameter fields (Aver. Freq. etc), and should fill them with the value 255, in which case they should be ignored by the LAP. If the MN has a valid value for a field, it should be filled in. The maximum valid value in this case would be 254. The same goes for the Candidate IP Address. Normally the MN will not know the IP address of a potential handover candidate LAP, and it may be wasteful to solicit this information over the air. The Candidate IP Addr. field will then be set to all ones, indicating that the IP address is unknown. This leaves it up to the receiver to do a broadcast, using message 'Identify LAP Request Broadcast' (Section 4.4.7), in order to verify that the Candidate LAP is on the same subnet, and retrieve its IP Address. 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 | Code | Version | Reserved-0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LAP IP address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Repeated block: Levkowetz Expires January 10, 2002 [Page 30] Internet-Draft MM-HOP July 2001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Candidate IP Addr. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Aver. Freq. | Aver. HO time | Aver. Quality | Aver. Capacity| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Aver. Latency | Aver. Cost | Security | Q-type|Resv1|M| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Media number | Reserved-2 | HW ID Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Candidate Hw ID . . . | | + +-+-+-+-+-+-+-+-+-+-+-+ | | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o o o Type Message type number = 20 Code Not used Version Message version number = 1 Reserved-0 Reserved bits, sent as zero LAP IP address Not used Candidate IP AddrThe IP address of the Handover Candidate LAP. Aver. Freq. recent average handover frequency. See Section 4.6.2 Aver. HO Time recent average handover time. See Section 4.6.3 Aver. Quality recent average link quality. See Section 4.6.4 Aver. Capacity recent average link capacity. See Section 4.6.5 Aver. Latency recent average link latency. See Section 4.6.6 Aver. Cost recent average link cost. See Section 4.6.7 Security link security for this LAP. See Section 4.6.8 Q-Type The type of the underlying Quality Measure: Levkowetz Expires January 10, 2002 [Page 31] Internet-Draft MM-HOP July 2001 0 - Undefined 1 - Bit Error Rate (BER) 2 - Frame Erasure Rate 3 - Frame Error Rate 4 - Message Erasure Rate (MER) 5 - Signal to Noise Ratio (S/N) 6 - Carrier (or Signal) to Interference Ratio (C/I) Resv1 Reserved bits, sent as zero Media number A media identifier assigned by IANA to the Link-layer/Physical layer combination the LAP is using. This means that e.g. Bluetooth and 802.11 using the unlicensed 2.3 GHz band have different media identifiers, as do 802.11 on the 2.3 GHz and 5 GHz band. This uniquely identifies the Link and Physical layers used to contact this LAP, for multi-mode MNs. M flag 1 - more blocks 0 - last block. Reserved-2 Reserved bits, sent as zero HW ID Length Length in octets in the link-layer address field Candidate Hw ID The link-layer address of the Candidate LAP. Padding Padding as needed to make the next block start at a multiple-of-4 octet offset from the start of the packet (the Type field). 4.5.5 New Handover Candidate Ack This message is sent from an MN to the LAP it is connected to as acknowledgement of a new handover candidate message. 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 | Code | Version | Reserved-0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LAP IP address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type Message type number = 21 Code Not used Levkowetz Expires January 10, 2002 [Page 32] Internet-Draft MM-HOP July 2001 Version Message version number = 1 Reserved-0 Reserved bits, sent as zero LAP IP address The IP address of the LAP for which the Handover Candidate List is acknowledged. 4.6 Handover Candidate Assessment In the messages 'Handover Candidate List Response' and 'New Handover Candidate Message' , there are 7 handover parameters given, by means of which an ordering of the list may be done. An MN may want to re-order the list according to a measure different from the one used by the LAP, according to the different requirements it may have as to bandwidth, urgency etc. The meaning of and calculation of these parameters are described here. (A more complete set would include a connection latency parameter too; we assume this is the same for all nodes on a IP subnet, and therefore omit it). 4.6.1 Calculation of averages. All handover parameters are 8-bit values with a range from 0 to 254, inclusive. In all cases, the number 255 signifies 'no value available'. Averaging calculations are to be done as decimating moving averages, where each new average is calculated from the previous according to the formula New_Average = Old_Average * (d) + Latest_Sample * (1 - d) where 0.0 < d < 1.0 (suggested value about 0.95). Example: using 16-bit arithmetics and a d of 240/256 we could calculate New_Average = (Old_Average * 240 + Latest_Sample * 16) / 256 4.6.2 Relative Handover Frequency. The Average Recent Relative Handover Frequency cannot be calculated for a single candidate LAP, but must be updated for all candidates on a HCL every time a successful handover has been done. The value for the LAP to which a successful handover was done is calculated with Latest_Sample = 1: New_Average = Old_Average * (d) + 1 * (1 - d) For all other LAPs the average frequency is updated with Latest_Sample = 0: Levkowetz Expires January 10, 2002 [Page 33] Internet-Draft MM-HOP July 2001 New_Average = Old_Average * (d) + 0 * (1 - d) 4.6.3 Handover Time. When a new succesful handover has been done, the Handover Time is communicated from the old to the new LAP, and the Average Recent Handover Time is updated in the HCL of the old LAP for the LAP to which the handover was done using the formula in Section 4.6.1. The Handover Time is measured in tenths of a second. Handover times longer than 25.4 seconds are set to 25.4 seconds (Handover Time Parameter = 254). 4.6.4 Link Quality This measure is derived from the quality measure or measures which are available from the underlying link layer. The preferred measure is Bit Error Rate (BER), however if this is unavailable other measures may be used. When the measure used is one of BER Frame Erasure Rate(FER), Carrier to Interference Ratio (C/I) or Signal to Noise Ratio (S/N), this is indicated with the Quality Measure Flags. The quality is normalised to a measure where the value 1.0 means perfect transmission and the value 0.0 means no correct transmission. Example: if the quality measure is based on Bit Error Rate (BER), this measure would be equal to (1 - 2*BER). How often and how the Link Quality is calculated is left unspecified. In order to calculate the Average Link Quality parameter, the Link Quality is remapped to the range 0..254, so that 254 means no errors. It may be done by LAP or MN, as an average or on a case-by-case basis. It is reported by the new LAP to the old LAP as part of the handover message exchange. It is averaged for the HCL using the formula in Section 4.6.1 4.6.5 Link Capacity This measure is calculated by each LAP, based on the available bandwidth at the time the handover is done. The bandwidth calculation may be done fairly simply, to get an approximate expected bandwith for a given LAP. Example: If it is known that the total available bandwidth of the radio interface of a LAP is 900 kb/s, and it has 4 clients at the time of handover, including the new MN, and 2 of the clients run at 1/3 data rate, the bandwidth averaged over the 4 Levkowetz Expires January 10, 2002 [Page 34] Internet-Draft MM-HOP July 2001 clients might be calculated as cap_raw = 900000 / 4 = 225000 cap = (225000 + 225000 + 75000 + 75000) / 4 = 150 000. The 2's logarithm of the Capacity will be reported as part of the handover information, and the old LAP will update its Aver. Capacity parameter, calculated using the formula in Section 4.6.1 with Latest_Sample set to log2(Capacity). 4.6.6 Link Latency The latency parameter is not defined at this time, and should always be set to 64. Average Latency is calculated using the formula in Section 4.6.1 4.6.7 Link Cost The cost parameter is not defined at this time, and should always be set to 64. Average Cost is calculated using the formula in Section 4.6.1 4.6.8 Link Security The Security parameter is simplemindedly defined as the 2's logarithm of the key length of the smallest one of the authentication and encryption keys used. The security parameter is never averaged, only used as reported. 4.6.9 Simple Assessment Example A simple example is given here of how some of the measures described above could be used to order the HCL: One possible heuristic for ordering the handover candidate list is the time a LAP registers between loss of connection with a given MN, and receipt of a status request from some other LAP regarding the same MN. If this time is very short, on the order of seconds, the querying LAP is probably a good handover candidate, while a time of minutes would mean probably not a realistic handover candidate. Additionally, handover candidates should be ordered according to the frequency of successful handovers, so that neighbouring LAPs (those with short handover latency) which often catch a handover from the current LAP are placed at the top of the list. Generally, it makes sense that the first LAP with which an MN attempts to connect after Levkowetz Expires January 10, 2002 [Page 35] Internet-Draft MM-HOP July 2001 a connection loss is the one which most often in the past has caught a handover from the current (latest) LAP. From this reasoning, a good heuristic might be to order the list according to a measure G = n_aver / t_aver, where n_aver is a sliding average of (successful) handovers made to the LAP in question t_aver is a sliding average of the time elapsed between connection loss and reconnect with the LAP in question. (with the entries with largest G at the top of the list). 4.7 Error Handling 4.7.1 General In the version of the messages defined in this Internet-Draft, all version fields are set to 1. For every request message there is a companion response message. If a LAP does not receive a response to a request message, it may assume that the message has been lost, and may resend the message 2 additional times before concluding that the recipient is unreachable. If a LAP receives a request with a version number other than the one(s) it understand, it should respond with a Request Not Understood message, as described in Section 4.7.2, and otherwise take no action. A LAP responding to a message must match the version of the request message in its response message. If a new version of either a request or response message is ever devised, the version number of the corresponding response or request message must also be changed to match. 4.7.2 Request Not Understood Message This message is sent as a response to any request in the State Handover Protocol which cannot be handled, due to a version field which does not match that or those a LAP explicitly know. The message is sent with the code field set to the same value as in the message which could not be handled, while the version field is set to the highest value understood by the responding LAP. The message which was not understood is included in its entirety. Levkowetz Expires January 10, 2002 [Page 36] Internet-Draft MM-HOP July 2001 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 | Code | Version | Reserved-0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Copy of Message . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type Message type number = 0 Code Not used Version Highest message version number accepted Reserved-0 Reserved bits, sent as zero Copy of Message A copy of the message which was not understood, exclusive of its IP and UDP headers. Levkowetz Expires January 10, 2002 [Page 37] Internet-Draft MM-HOP July 2001 5. Security Considerations Wireless communications are inherently insecure, so although the protocol proposed in this Internet-Draft only is relevant for routing and handover within a single IP subnet, some additional thought must be given to security considerations. It is assumed that the security level of the wired IP subnet to which the individual LAPs are connected is sufficiently secure. In this case the security of the wireless communications are above all controlled by the authentication, authorization and encryption security afforded by the wireless link layer in question. Provisions have been made in the protocol to provide security level information for the individual LAN Access Points, to limit LAN access as long as authentication and authorisation is unknown, and to transfer link keys (encryption/authorisation keys) between the LAN Access Points. It is fully possible for someone with access to the wired network to eavesdrop for encryption keys, and subsequently listen in to a wireless communication. This does not, however, break security more than has already been done by being able to listen in on the wired network, provided link key validity is limited in time. For this reason, the protocol also provides the means needed to keep track of accumulated link uptime, and it is suggested that LAPs are configured to close down a link after a certain time. The LAPs may additionally close down a link after it has been idle for some (configurable) time. In order to make it less interesting to cryptographically break the code of any individual link, the LAPs shall also be restricted to transmitting traffic which is specifically directed to one of its client MNs, as opposed to transmitting all traffic on the wire. (Transmitting all wirebound traffic on the air may not be feasible or wise bandwidth-wise, anyhow). Levkowetz Expires January 10, 2002 [Page 38] Internet-Draft MM-HOP July 2001 References [1] Perkins, C., "IP Mobility Support", RFC 2002, October 1996. [2] Plummer, D., "An Ethernet Address Resolution Protocol: Or Converting Network Protocol Addresses to 48.bit Ethernet Addresses for Transmission on Ethernet Hardware", STD 37, RFC 826, November 1982. [3] Postel, J., "User Datagram Protocol", RFC 768, August 1980. Author's Address O. Henrik Levkowetz A Brand New World (ABNW) Ůster÷gatan 1 Stockholm S-164 28 SE Phone: +46 8 477 9942 EMail: henrik@levkowetz.com Levkowetz Expires January 10, 2002 [Page 39] Internet-Draft MM-HOP July 2001 Full Copyright Statement Copyright (C) The Internet Society (2001). 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 Standards process must be followed, or as required to translate it into 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. Acknowledgement Funding for the RFC editor function is currently provided by the Internet Society. Levkowetz Expires January 10, 2002 [Page 40]