INTERNET-DRAFT T. Inzerilli Expires June 2001 University of Rome "La Sapienza" January 2001 Intra-domain Mobility Support with SIMPLE 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. Abstract In this document is proposed a protocol for intra-domain mobility management. This is intended to offer a transparent point-to-point transport service for IP datagrams that need to be delivered to mobile nodes. SIMPLE (Scalable Intra-domain Mobility Protocol using Local Encapsulation) makes it possible for a mobile node to change its point of attachment to a LAN, a group of LANs or even a MAN without changing its IP address, this link being the home or a foreign one. Protocols for intra-domain mobility management find their rationale in improving performances of communications when fast-moving mobile nodes are involved. Recent studies on modern cellular systems have Inzerilli [Page 1] INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001 shown that a conspicuous part of mobility is local. Consequently, handovers could be managed using local ad-hoc measures in large part. Not only does local handover management reduce latencies for location updates and packet loss, but it limits mobility signaling to local areas as well, preventing the Internet backbone from being congested by location-update messages. The goal of this protocol in particular is to achieve efficient forwarding of IP datagrams inside a link, good scalability properties, compatibility with Mobile IPv6 and, with some adaptations, to Mobile IPv4 and to provide multiple-gateway access to a domain. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology and acronyms . . . . . . . . . . . . . . . . . . . . 5 2.1. General Terms . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Mobile IP terms . . . . . . . . . . . . . . . . . . . . . . . . 6 2.3. Mobile IPv6 terms . . . . . . . . . . . . . . . . . . . . . . . 7 2.4. Mobile IP and Mobile IP6 terms . . . . . . . . . . . . . . . . 8 2.5. SIMPLE terms . . . . . . . . . . . . . . . . . . . . . . . . . 8 3. Overview of SIMPLE . . . . . . . . . . . . . . . . . . . . . . . 15 4. SIMPLE nodes . . . . . . . . . . . . . . . . . . . . . . . . . . 20 4.1. Switching node model . . . . . . . . . . . . . . . . . . . . . 22 4.2. Access Point model . . . . . . . . . . . . . . . . . . . . . . 25 4.2.1. Routing Registers (RRs) . . . . . . . . . . . . . . . . . . . 26 4.2.2. Access Point operation . . . . . . . . . . . . . . . . . . . 31 4.2.2.1. Access Point signaling . . . . . . . . . . . . . . . . . . 31 4.2.2.2. AP switching algorithm . . . . . . . . . . . . . . . . . . 32 4.3. Mobile node model . . . . . . . . . . . . . . . . . . . . . . . 33 4.3.1. Mobile node operation . . . . . . . . . . . . . . . . . . . . 35 4.3.1.1. Mobile node signaling . . . . . . . . . . . . . . . . . . . 35 4.3.1.2. Reception and transmission of data . . . . . . . . . . . . 36 4.4. Gateway model . . . . . . . . . . . . . . . . . . . . . . . . . 37 4.4.1. Reception and transmission of data . . . . . . . . . . . . . 37 5. SIMPLE signaling procedures . . . . . . . . . . . . . . . . . . . 38 5.1. Location discovery . . . . . . . . . . . . . . . . . . . . . . 40 5.2. Link-layer registration . . . . . . . . . . . . . . . . . . . . 42 5.3. DLA research procedures . . . . . . . . . . . . . . . . . . . . 45 5.4. State Refreshing . . . . . . . . . . . . . . . . . . . . . . . 48 5.5. Location update procedure . . . . . . . . . . . . . . . . . . . 49 5.6. Handovers and Error Recovery . . . . . . . . . . . . . . . . . 51 5.6.1. Forwarding strategy for handovers . . . . . . . . . . . . . . 53 Inzerilli [Page 2] INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001 5.6.2. Buffering and forwarding strategy for handovers and error recovery . . . . . . . . . . . . . . . . . . . . . . . . . . 57 6. Mobile IPv6 and Mobile IP non-standard routers' operation . . . . 58 6.1. Operation of home agents in IPv4 and IPv6 links . . . . . . . . 58 6.2. Operation of foreign agents in IPv4 links . . . . . . . . . . . 59 7. Considerations on SIMPLE . . . . . . . . . . . . . . . . . . . . 60 8. ACKNOWLEDGMENTS . . . . . . . . . . . . . . . . . . . . . . . . . 62 9. Security Considerations . . . . . . . . . . . . . . . . . . . . . 63 APPENDIX A: SIMPLE packet format . . . . . . . . . . . . . . . . . . 63 APPENDIX B: Routing Registers (RRs) format . . . . . . . . . . . . . 65 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 1. Introduction A single standard protocol to provide the Internet with mobility support could hardly represent an optimal solution. It would mean imposing a single approach to a number of domains without considering link peculiarities as for the technologies adopted and their geographical extension. The need of standardization to render interworking between heterogeneous links possible, together with the necessity of leaving a window open for research, suggest separating mobility at least into two levels. Mobility between domains (inter- domain mobility) can be handled with Mobile IP either version 6 or version 4, so as to allow a gradual transition from the current version of IP towards its successor together with a gradual deployment of mobile nodes. As regards to mobility inside domains (intra-domain mobility), many alternative protocols could coexist in the Internet to be better adapted to particular situations. A separate intra-domain mobility protocol finds its rationale in enhancing performances of communications when fast-moving mobile nodes are involved. In fact, mobility management needs ad-hoc signaling for location updates and handovers. Signaling propagated over long distances could result in poor performances as it would be subject to long latencies and could be affected by possible congestion on the route. Moreover, the additional load of mobility signaling itself could contribute to congesting the Internet backbone in a future scenario with a large number of mobile nodes. Recent studies on modern cellular systems have shown that a conspicuous part of mobility is local. Consequently, handovers could be managed using local ad-hoc measures in large part. Not only does local handover management reduce latencies for location updates but it limits mobility signaling to local areas as well, preventing the Internet backbone from being congested by location update messages. Inzerilli [Page 3] INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001 This document arises from the assumption that fundamental properties of an intra-domain mobility protocol for the Internet are the following: - Full compatibility with both Mobile IP and Mobile IPv6 and correlated Internet protocols should be guaranteed. Intra-domain mobility has to appear as a completely transparent service to IP entities. As a consequence, the scope of an intra-domain mobility protocol is a link. - Good scalability properties should be offered, in the sense that performances have not to degrade significantly when the number of mobile nodes registered to the link increases, or, more in general, when the traffic that is globally offered to the link increases. In addition, in large links where the number of switching levels is considerable, performances should remain satisfactory. This because solutions envisioning more than two mobility levels could be inefficient and not easily deployable. - The presence of an additional intra-domain mobility protocol should not restrict access to a link through a single gateway. This would become a single point of failure for a number of mobile nodes and a possible bottleneck in case of heavy load. - An intra-domain mobility protocol should fulfill its general task of enhancing performances, in other words, it should considerably reduce signaling latency and, hence, intervals of intermittent connectivity and packet loss. In this document an intra-domain mobility protocol is proposed . SIMPLE (Scalable Intra-domain Mobility Protocol using Local Encapsulation) could be used to bridge many different wireless and wired segments. The resulting network would then appear as a single link to Mobile IP ([2]) or Mobile IPv6 ([3]). The main goals of the protocol are the points listed above. Another feature of SIMPLE is a scalable auto-routing algorithm with limited utilization of memory resources. In addition, SIMPLE can be used to mask the non-multicast-capable nature of the networks it is built on when signaling for address resolution needs propagating. In fact, SIMPLE can enable to use ARP ([9]) and Neighbor Discovery ([7]) unchanged even on Non-Broadcast Multi-Access link (NBMA)([12]) without multicasting. Moreover, when Mobile IPv6 is used SIMPLE makes it possible to assign care-of addresses through IPv6 Stateless Address Autoconfiguration ([10]) independently of the nature of the underlying networks, which could be non-multicast-capable. This allows avoiding deployment of servers ([6]) for dynamic IP Address assignment. A preliminary version of this protocol can be found in [1]. Inzerilli [Page 4] INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001 2. Terminology and acronyms 2.1. General Terms Access Point (AP) A link node (generally with a wireless interface) which grants or denies mobile nodes access to the link. Domain A division of the Internet. Gratuitous ARP message ARP packets sent to spontaneously cause other nodes to update an entry in their ARP cache. Handover or handoff A movement of an active (receiving or transmitting) host to another cell. Host Any Internet node that is not a gateway. Interface A node's attachment to a link. Interface identifier A number used to identify a node's interface on a link. The interface identifier is the remaining low-order bits in the node's IP address after the subnet prefix. Internet node A device provided with the IP layer. In a SIMPLE link it can be a gateway (stationary device), a stationary host or a mobile node. Link A communication facility or medium over which nodes can communicate at the link layer level, such as an Ethernet (simple or bridged). A link is the layer immediately below IP. When SIMPLE is used, the link is the whole set of networks SIMPLE bridges and it is built on. SIMPLE is used to connect a number of links with a local routing rule to offer an alternative to IP routing. Link-layer address The address used to identify an endpoint of some Inzerilli [Page 5] INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001 communication over a physical link. Typically, the Link-Layer address is an interface's Media Access Control (MAC) address, such as IEEE 802 addresses on Ethernet links. (see also definition of link-layer addresses in SIMPLE below). Location update The process of updating the location information relevant to an idle mobile node after a change of cell. Neighbor Discovery unsolicited advertisement Neighbor Advertisement message to inform of a changed of link- layer address. Router An Internet node that forwards IP packets not explicitly addressed to itself. In a SIMPLE link routers can be either gateways, stationary devices providing the SIMPLE link with connectivity with the Internet, or mobile routers providing external LANs with temporary connectivity with the SIMPLE link. Subnet prefix A bit string that consists of some number of initial bits of an IP address. 2.2. Mobile IP terms Care-of Address The termination point of a tunnel toward a mobile node for datagrams forwarded to the mobile node while it is away from home. The protocol can use two different types of care-of addresses: a "foreign agent care-of address" is an address of a foreign agent the mobile node is registered to, and a "co-located care-of address" is an externally obtained local address which the mobile node has associated with one of its own network interfaces. In this document we will consider only access to a foreign link by means of a foreign agent and hence only foreign agent care-of addresses. Foreign Agent A router on mobile node's visited network which provides routing services to the mobile node while registered. The foreign agent detunnels and delivers datagrams to the mobile node that were tunneled by the mobile node's home agent. For datagrams sent by a mobile node, the foreign agent may serve as a default router for registered mobile nodes. Inzerilli [Page 6] INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001 Foreign Network Any network other than the mobile node's Home Network. Home Address An IP address that is assigned for an extended period of time to a mobile node. It remains unchanged regardless of where the node is attached to the Internet. Home Agent A router on a mobile node's visited network which tunnels datagrams to be delivered to the mobile node when it is away from home, and maintains current location information for the mobile node. Home Network A network, having a network prefix matching that of a mobile node's home address. Note that standard IP routing mechanisms will deliver datagrams destined to a mobile node's Home Address to the mobile node's Home Network. Visited Network A network other than a mobile node's Home Network, to which the mobile node is currently connected. .fi 2.3. Mobile IPv6 terms Care-of address An IP address associated with a mobile node while visiting a foreign link; the subnet prefix of this IP address is a foreign subnet prefix. Among the multiple care-of addresses that a mobile node may have at a time (e.g., with different subnet prefixes), the one registered with the mobile node's home agent is called its "primary" care-of address. Multiple care-of address aspects are out of the scope of this document. Foreign link Any link other than the mobile node's home link. Foreign subnet prefix Any IP subnet prefix other than the mobile node's home subnet prefix. Home address An IP address assigned to a mobile node within its home link. Home agent Inzerilli [Page 7] INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001 A router on a mobile node's home link with which the mobile node has registered its current care-of address. While the mobile node is away from home, the home agent intercepts packets on the home link destined to the mobile node's home address, encapsulates them, and tunnels them to the mobile node's registered care-of address. Home link The link on which a mobile node's home subnet prefix is defined. Standard IP routing mechanisms will deliver packets destined for a mobile node's home address to its home link. Home subnet prefix The IP subnet prefix corresponding to a mobile node's home address. 2.4. Mobile IP and Mobile IP6 terms Mobile node (MN) A node that can change its point of attachment from one link to another, while still being reachable via its home address. Correspondent node A peer node with which a mobile node is communicating. The correspondent node may be either mobile or stationary. Binding (or Mobility Binding) The association of the home address of a mobile node with a care-of address for that mobile node, along with the remaining lifetime of that association. 2.5. SIMPLE terms Access part A SIMPLE link consists of a distribution system and an access part. Internet nodes attach to the SIMPLE link in the access part through APs. APs and mobile nodes are typically provided with wireless interfaces. Access point number (APN) It identifies an AP in a SIMPLE link and corresponds to its switching number (see below). All current link-layer addresses (CLAs) assigned to mobile nodes served in the cell must begin with the same prefix, which is the APN. Inzerilli [Page 8] INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001 Advertisement message A signaling message broadcast by each AP regularly and carrying information about the link and the cell. In this document it is a SIMPLE specific message and not a Mobile IP message. Buffering Request message A signaling message generated by a mobile node during a period of degradation of the communication quality and sent to the AP, requesting the Access Point (AP) to buffer a copy of each packet which is transmitted into the channel and destined to the mobile node for a specified interval of time (buffering soft state). Buffering state (see also SIMPLE soft states) It is created in a Routing Register (AP routing table) on reception of a Buffering request message from a registered mobile node. When a registration state for a mobile node is turned into a buffering state, a copy of all packets transmitted to the mobile node is stored in the serving AP till a timer expires or a request of forwarding buffered packets for accomplishing a handover is received. In the former case, the buffering state is turned into a registration state again. In the latter case, is turned into a forwarding state. Current AP It is the AP where a mobile node is being served or tries to register to. A mobile node which is served in a cell will use a two-byte binary string beginning with its AP's access point number (APN) as its current link-layer address (CLA). Current LA (CLA) This is a two-byte address identifying the current location of the mobile node in the link and it is assigned by the serving AP. The current LA is changed each time a mobile node moves to a new AP. Internet nodes' caches contain the bindings (IP address, CLA). All packets destined to a mobile node will have to be sent using its CLA as the packet's destination link-layer address. Default AP Each mobile node registered to a SIMPLE link has a default AP where its current address (CLA) is contained. The mobile node's default AP is selected during a link-layer registration and kept by the mobile node all the time it remains attached to the link. If the mobile node is in its home link, it will correspond to the mobile node's reserved Inzerilli [Page 9] INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001 cell. Default LA (DLA) It is a two-byte pointer to a location where the mobile node's CLA is contained. It is used to deliver address resolution queries by means of a two-step routing when the destination CLA is not known. In the mobile node's home link the returned DLA is simply the last two bytes of the mobile node's home address. In a foreign link and when Mobile IPv6 ([3]) is used, this is the IPv6 interface identifier (without a 6-byte of initial zeros to respect the EUI-64 ([15]) format) that is passed to the mobile node's IP entity to obtain a dynamic care-of address through IPv6 Stateless Address Autoconfiguration ([10]). In a foreign IPv4 network, a DLA is the link-layer address of the foreign agent the mobile node is registered to. Distribution system A SIMPLE link consists of a distribution system and an access part. Nodes in the distribution system perform switching of packets not addressed to themselves and are called switching nodes. Switching in the distribution system exploits the auto- routing content of SIMPLE link-layer address in a suitably numbered link to forward packets. DLA Request message A message originated by an access point to request an available DLA to assign to a registering mobile node. DLA Reply message A message sent to an access point that assigns a unique DLA for a new registering mobile node. Forwarding Request message A signaling message generated during a mobile node's handover and sent from the new AP to the old AP to have packets destined to the mobile node and carrying the mobile node's old CLA as destination link-layer address forwarded to its new AP. This message creates a forwarding state in the old AP's Routing Register (RR). Forwarding State (see also SIMPLE soft states) When a registration state or a buffering state is turned into a forwarding state in the old AP on a forwarding request arrival, packets for a mobile node arriving at the old AP are diverted to the new mobile node's AP together with all the buffered packets, if any. When a forwarding state expires the mobile node's old CLA is released and can be assigned to Inzerilli [Page 10] INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001 another mobile node (AH bits set to 00). Handover Request message A signaling message sent by an active mobile node to the current AP while moving from a cell to another to request access to a new cell. Handover Reply message A signaling message sent by an AP to an active mobile node in response to a Handover Request message to grant or deny access to the cell. Home link identifier It is the link identifier of the mobile node's home link (see link identifier below). Link identifier It is a number broadcast in a SIMPLE Advertisement message. Each mobile node has its own home link identifier. It can then compare the advertised link identifier with its home link identifier to understand if it is in its home link. An access point receiving a registration message from a new mobile node can compare the advertised link identifier (the mobile node's home link identifier) with its configured link identifier (that broadcast regularly by all APs) to understand if the registering mobile node is in its home link. Link-layer address (LA) It is a SIMPLE specific two-byte address assigned to all Internet nodes on the link. Gateways' LAs are permanent and also called Static Link-Layer Addresses (SLAs). The set of SLAs in a link is always constituted by consecutive numbers starting from 0 to NUM_GT-1. Mobile node's LA are composed of a prefix, Access Point Number (APN), and a suffix, Local Mobile node Identifier (LMI). Each mobile node in the link has its own Current Link-layer Address (CLA), Default Link-layer address and Reserved Link-layer address (see below). Two of them or the all three can sometimes correspond for a same mobile node. Link-layer Registration It is the SIMPLE specific registration. This ends with the acceptance or the rejection of the registering mobile node in the cell. In the former case, a CLA and a DLA are returned to the registering mobile node. Link node (or SIMPLE node) Inzerilli [Page 11] INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001 A device which is provided with a SIMPLE entity but not necessarily with an IP entity. It can be a switching node (access point, switch, gateway) or a mobile node. Switching nodes are stationary devices, constitute the distribution system of a link and provide local transport of SIMPLE packets to be sent in the Internet or destined to mobile nodes in the link. Local mobile node Identifier (LMI) It is the suffix of an LA, identifying a mobile node that is being served in a cell. Location Refresh message A message generated by a mobile node's current AP following a Registration Refresh message by the mobile node. It is sent to the mobile node's default cell (or the mobile node's foreign agent in a foreign IPv4 network) to refresh a location state. Location State (or default state, see also SIMPLE soft states) It contains a pointer to a mobile node's current location (mobile node's CLA) and it is stored in the mobile node's default cell, which is selected during registration time. A location state is soft and lasts till the relevant registration state in the mobile node's current AP expires. It then needs to be continuously refreshed by Location Refresh messages by the mobile node's current AP. Location Update message A signaling message sent by a mobile node's current AP to update the mobile node's default state with its new CLA after a successful handover or location update. Location Update Request message A signaling message sent by an idle mobile node to the current AP while moving from a cell to another to request access to a new cell. Location Update Reply message A signaling message sent by an AP to an idle mobile node in response to a Location Update Request message to grant or deny access to the cell. Peer (link) node A switching node with a switching number as long as another switching node's. Registration Refresh message Inzerilli [Page 12] INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001 A message sent by a mobile node to its serving access point to refresh its registration state. A mobile node registered to a link has to regularly refresh its registration state to assure the current AP that it is still present in the cell. Registration Request message A signaling message sent by a mobile node to the current AP at the beginning of a link-layer registration to request access to a SIMPLE link. Registration Reply message A signaling message sent by an access point to a registering mobile node in response to a Registration Request message to deny or grant access to the link. Registration state (see also SIMPLE soft states) It is created after a successful link-layer registration to an AP. A registration state is soft, in other words, it needs to be regularly refreshed by data or ad-hoc Registration Refresh messages to be kept alive. Reserved AP Each mobile node has a reserved cell in its home link, where it holds a reserved LA, which cannot be assigned to any other mobile node as CLA. It consequently has guaranteed access to the link if it enters that cell. For the consistency of the protocol the mobile node's reserved LA must be always the two-byte suffix of the mobile node's home IP address and the reserved AP's APN must be a prefix of the mobile node's reserved LA. As a consequence, assigning an IP home address to a mobile node in a SIMPLE link, means providing it with a granted access in a reserved cell in the link Reserved LA (RLA) This is a two-byte link-layer address configured in the mobile node. It corresponds to the two-byte suffix of the mobile node's IP home address. The prefix of a RLA identifies the mobile node's reserved cell in its home link. A mobile node can never be rejected by its reserved cell in its home link. Routing Register (RR) It is a table where intra-domain mobility management information is contained (section 4.2.1 ). SIMPLE packet An IP datagram plus a SIMPLE header or a SIMPLE specific signaling message. Inzerilli [Page 13] INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001 SIMPLE soft states SIMPLE keeps track of all the mobile nodes registered to the link by means of a distributed set of tables referred to as Routing Registers, each of them containing a set of entries associated to an LA of the link. An entry can contain one or two soft states associated to the relevant LA. When an LA is used as a CLA for a mobile node there can be either a registration state or a buffering state or a forwarding state in the relevant entry. When an LA is used as a DLA for a mobile a default state is present. An LA can be used either as a CLA for a mobile node or a DLA for a mobile node or both a CLA and a DLA for the same or for two distinct mobile nodes. Static LA (SLA) It is a link-layer address of a gateway on a SIMPLE link. The set of SLAs in a SIMPLE link consists of binary strings corresponding to consecutive numbers starting from 0. Switching mask Binary mask assigned to each switching node in a SIMPLE link for routing purposes (see switching node definition). Switching node Switch, AP or gateway in a SIMPLE link. Each switching node performs an auto-routing algorithm of SIMPLE packets, basing on node-local information and the routing rule expressed by the content of packets' destination LAs (see appendix A and section 4.1). Node-local information consists of the node's switching number and its neighbor switching nodes'. Switching number (SWN) An identifier of a switching node used for switching purposes. It must be a prefix of all its downlink nodes' SWN. APs' switching numbers are also referred to as Access Point Numbers (APNs) and must be the prefix of all CLAs assigned in the relevant cell. Visitor Address Resolution Table It is a separate cache used by a foreign agent in IPv4 links to store (Home IP address, CLA) bindings of visiting mobile nodes. These correspond to default states associated to the visiting mobile nodes, which are not present in the dynamic-CLA entries of RRs in IPv4 links. Inzerilli [Page 14] INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001 3. Overview of SIMPLE SIMPLE (Scalable Intra-domain mobility Protocol using Local Encapsulation) provides mobile nodes with a local mobility service inside a link, which is completely transparent to the IP layer. In other words, it allows mobile nodes (MNs) to change their interface to a link and keep their IP address. SIMPLE provides intra-domain mobility support in both home and foreign links, these being IPv4 or IPv6 links. The SIMPLE network we consider is made of a distribution system and an access part (fig. 1). Internet nodes are all located at the edges of the link. They can be gateway on the distribution system or mobile nodes on the access part and use SIMPLE as a facility to exchange IP datagrams with neighboring IP nodes on the link. +----+ +----+ | GT |<=============>| GT | +----+ +----+ // \ +----+___________________+----+ | SW |-------------------| SW | +----+ +----+ // || \______+----+_______// \ // || ------ | AP |-------- \ // || +----+ \ +----+ || +----+ | SW | || | SW | +----+ || +----+ // || || // \ // || || // \ // || +----+ +----+ \ +----+ || | AP | | AP | \ | AP | || +----+ +----+ \ +----+ || +----+ || | AP | +----+ +----+ | AP | || +----+ || || +----+ +----+ | MN | | MN | +----+ +----+ Fig. 1-An example of SIMPLE link Inzerilli [Page 15] INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001 When a mobile node shows up in a SIMPLE link it will trigger suitable signaling procedures to attach to it. This will consist of two or three separate procedures in general: a With a first exchange of messages, which are peculiar of the access technology (i.e. Hiperlan II, IEEE802.11...) and often involves the physical and MAC layer, the mobile node will associate with an AP, establishing connectivity at the level of the access channel. In those technologies, where a wireless segment is integrated with a wired segment by means of bridges, this procedure will allow to use the wired segment as a distribution system for intercell communications as well. b In a SIMPLE link, either the previous association procedure has involved a wired segment or not, a second registration level (link-layer registration) will take place to establish full link connectivity to enable the mobile node to exchange IP datagrams with all Internet nodes on the link. A link could contain many wired segments and many wireless segments. Link-layer registrations will successfully end providing mobile nodes with two two-byte identifiers, a Current Link-layer Address (CLA) and a Default Link- layer Address (DLA). The former (CLA) identifies the mobile node's serving AP (or current AP) with its prefix and the particular mobile node in the cell with its suffix. The CLA will be changed each time the mobile node attaches to a new AP of the same link. The latter (DLA) is a pointer to a default location where the mobile node's CLA is constantly stored. Unlike the CLA, a DLA is kept unchanged till the mobile node leaves the link. A DLA always corresponds to the last two bytes of the IP address the mobile node will use in the link. c A Mobile IP or Mobile IPv6 registration with a remote home agent will take place only if the mobile node is visiting a foreign link. However, it can happen that a mobile node entering its home link needs to deregister explicitly with a home agent in its home link. Level-b connectivity is the intra-domain mobility level when SIMPLE is used. It is clear that this has some utility only if level b has a scope which is wider than level a. Its purpose is to make the distribution system plus the access part appear as a homogeneous link, where changes of link interface are completely transparent to the IP layer. Whereas, level c is the inter-domain mobility level ([2,3]) and is out of the scope of this document, if not only for those aspects which define the interfacing of SIMPLE with Mobile IP and Mobile IPv6. Transparency of SIMPLE to the inter-domain mobility level is achieved thanks to the fact that a mobile node while roaming inside the same Inzerilli [Page 16] INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001 link will keep its IP address and its DLA, which is easily derivable from the mobile node's IP address used in the link by extracting the last two bytes of the IP address (with the exception of IPv4 mobile nodes registered to a foreign agent), while it will change its CLA after a move to a new cell. A CLA of a registered mobile node can be discovered using the DLA. In fact, the mobile node's DLA is fix and points to a location where the mobile node's CLA is stored. Once a mobile node has acquired a CLA, it can send and receive IP datagrams. These are first encapsulated in SIMPLE packets, then routed using the destination LA field in their SIMPLE header and finally, on reception, decapsulated and delivered to the destination node's IP entity. The routing algorithm takes advantage of the format of LAs. In fact, SIMPLE LAs have auto-routing content, in the sense that an LA itself represents a rule to perform routing inside the link. All Internet nodes on the link are given a link-layer address (LA). An LA is two bytes long. As a consequence, a SIMPLE link can contain up to 65536 Internet nodes and SIMPLE packets have only a 4-byte header(see Appendix A). SIMPLE is then suited for managing local mobility in a rather large area adding a minimal overhead to IP datagrams (an IP datagram is typically 1500 bytes). A link can then correspond to a LAN, simple or bridged, a group of LANs, or a MAN. Gateways in a SIMPLE domain are stationary devices located at the highest switching level of the link and used both for switching within the SIMPLE link and as edge devices with the Internet. They need to be assigned what it is referred to as a Static Link-layer Address (SLA) to recognize packets destined to them when these contain their SLA in the destination LA field. The set of SLAs assigned in the link consists of two-byte binary strings corresponding to consecutive numbers starting from 0. So, when a SIMPLE link is provided with three gateways these have to be given the following SLAs: 0000000000000000, 0000000000000001, 0000000000000010. Instead, an LA assigned to a mobile node consists of two parts (see Appendix A), a prefix and a suffix. The prefix, Access Point Number (APN), identifies the Access Point (AP) the node is attached to. The suffix, Local mobile node Identifier (LMI), identifies a particular node in the cell. Link nodes other than mobile nodes constitute the distribution system of the SIMPLE link and are used for switching purposes. They are then referred to as switching nodes and are all provided with a unique parameter referred to as switching number (a string of bits shorter than two octets). Access point switching numbers are also called Inzerilli [Page 17] INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001 Access Point Numbers (APNs). An auto-routing algorithm is performed in the distribution system to enable packets relaying with routing tables containing only local information. This is obtained fixing a suitable numeration of the SIMPLE link by means of local configuration of the switching nodes. More precisely, a SIMPLE node has to be aware only of its switching number and of its neighboring switching node's. Figure 2 shows a possible logical link topology with a consistent numeration of the nodes, which allows automatic routing in the distribution system. All switching nodes have links to one uplink node (except for gateways), to some downlink nodes and to peer nodes (nodes with the switching number of the same length). All the downlink nodes from a same uplink node have their switching number of the same length and beginning with a same prefix, which is correspondent to the uplink node's switching number. Switching nodes of a same hierarchical level can be connected and will have their switching number of the same length (peer nodes). The routing algorithm exploits local information in each node plus the number-of-gateways-in-the-link information NUM_GT. It proceeds applying the following rules: 1 A SIMPLE packet with a destination LA which is grater than or equal to NUM_GT, originated in a gateway, is relayed downlink hop-by-hop, each node having its switching number equal to the prefix of the destination LA field in the packet header. 2 A SIMPLE packet with a destination LA which is smaller than NUM_GT, originated in a gateway, is sent towards the gateway having its SLA equal to the packet's destination LAs. 3 A SIMPLE packet with a destination LA which is grater than or equal to NUM_GT, originated in a mobile node, is relayed uplink till one of the following events occurs. 3.1 a node with a direct link to another peer node having its switching number equal to the prefix of the destination LA field in the packet header is reached; the packet is then relayed to the peer node and, afterwards, the packet will be relayed downlink till the destination node as specified in rule 1. 3.2 a node having its switching number equal to the prefix of the destination LA field in the packet header is reached and, afterwards, the packet will be relayed downlink till the destination node as specified in rule 1. 4 A SIMPLE packet with a destination LA which is smaller than NUM_GT, originated in a mobile node, is sent uplink till a gateway is reached. The packet will be then sent to the destination gateway having its SLA coinciding with the packet's destination LA. Inzerilli [Page 18] INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001 +----+ +----+ SWN:00 | GT |<============>| GT | SWN:01 +----+ +----+ // \ +----+__________________+----+ SWN:000 | SW |------------------| SW | SWN:010 +----+ APN:010 +----+ // || \_______+----+_____// \ // || --------| AP |------ \ // || +----+ \ +----+ || +----+ SWN:0000 | SW | || | SW | SWN:0101 +----+ || +----+ // || || // \ // || || // \ // || +----+ +----+ \ +----+ || | AP | APN:0001 | AP | \ | AP | || +----+ +----+ \ +----+ || APN:010101000 \ APN: || +----+ 00000001011 || APN: | AP | +----+ 010100110 +----+ | AP | APN:00000010000 || +----+ || // +----+ +----+ | MN | | MN | CLA:00000010000.01111 +----+ +----+ CLA:010100110.0001001 Fig. 2 - An example of SIMPLE routing In the following we provide an example of SIMPLE routing. Mobile node 00000010000.01111 needs to send a packet to mobile node 010100110.0001001 (fig. 2). - The packet is sent to the mobile node's current AP 00000010000. - Here, as the packet's destination LA is grater than 1 and the APN and the prefix of the packet's destination LA differ and no direct link with an AP 01010011000 is provided, the packet is relayed to the uplink node 0000. - Here, as the packet's destination LA is grater than 1 and the switching number of the node and the prefix of the packet's destination LA differ and no direct link with a node 0101 is provided, the packet is relayed to the uplink node 000. - Here, as the packet's destination LA is grater than 1 and the switching number of the node and the prefix of the packet's destination LA differ but a direct link for the node 010 is Inzerilli [Page 19] INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001 provided, the packet is relayed directly to it. - Here, as the packet's destination LA is grater than 1 and the switching number of the node and the prefix of the packet's destination LA coincide, the packet is relayed to the downlink node 0101, having its switching number that is a prefix of the packet's destination LA. - Here, as the packet's destination LA is grater than 1 and the switching number of the node and the prefix of the packet's destination LA coincide the packet is relayed to the downlink AP 010100110, having its switching number that is a prefix of the packet's destination LA. - Here, as the packet's destination LA is grater than 1 and the APN and prefix of the packet's destination LA coincide, the packet is relayed to the mobile node 010100110.0001001, having its CLA coinciding to the packet's destination LA. A SIMPLE can also enable stationary nodes to coexist with mobile nodes in a same IPv4 or IPv6 link. Stationary hosts can attach to an AP as mobile nodes do. They can be considered as particular cases of mobile nodes keeping a fix CLA, which corresponds to their DLA, which in turn is given by the last two-byte of the mobile node's IP address. In the following there will be no explicit reference to stationary host operation in a SIMPLE link. Suffice to say that what is applicable to mobile node is valid for stationary hosts as well, in particular switching of SIMPLE packets toward stationary hosts is performed in the same way as toward mobile nodes. Instead, all mobility related issues are excluded. 4. SIMPLE nodes A SIMPLE node can be either a mobile node or a switching node. The former is a device univocally identified in the link by its Current Link-layer Address (CLA), which it is changed each time it moves from a cell to another, and has a single uplink interface with the serving AP. The latter is a stationary device, which makes part of the SIMPLE link distribution system, allows intercell as well as intracell communication and provides connectivity with the Internet. Switching nodes can be Access Points (APs), Switches (SWs) or gateways (GTs). It is necessary that a packet destined to a mobile node contains its CLA in the destination LA field to reach the destination mobile node. However, it can happen that a gateway or a mobile node on the link, on sending a packet, be not provided with the destination mobile node's CLA, as mobile nodes can continuously change their point of attachment to the link. Inzerilli [Page 20] INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001 As a solution, each mobile node registered to the link is also provided with a Default Link-Layer Address (DLA), which is a fix pointer to a default location where the mobile node's CLA can be found (default state or location state). A DLA always corresponds to the last two bytes of the mobile node's IP address (either home address or IPv6 care-of address) used in the link (the link-layer registration will guarantee this condition), except when mobile nodes roam in a IPv4 foreign network. In this case it will correspond to the mobile node's foreign agent's SLA (see section 6.2). Unlike a mobile node's CLA, a DLA is kept all the time the mobile node remains registered to the link while moving from a cell to another. When a packet has to be sent to a mobile node whose CLA is not known, it is then possible to use first the mobile node's DLA as the packet's destination LA, which will lead the packet to the mobile node's default cell. Once arrived here, the CLA can be read and the packet sent again using the mobile node's CLA. Gateways in a SIMPLE domain are stationary devices located at the highest switching level of the link and used both for switching within the SIMPLE link and as edge devices with other networks. As a consequence, they need to be assigned a Static Link-layer Address (SLA) to recognize packets destined to them when these contain their SLA in the destination LA field. The set of SLAs assigned in the link consists of two-byte binary strings corresponding to consecutive numbers from 0. So, when a SIMPLE link is provided with three gateways these have to be given the following SLAs: 0000000000000000, 0000000000000001, 0000000000000010. Access points, switches and gateways perform switching of packets inside the link and constitute the distribution part of the SIMPLE link. Packets are forwarded inside the distribution system by means of an auto-routing algorithm which exploits a suitable numeration of switching nodes (see section 4.1).The algorithm is scalable as it exploits in each switching node only local information. The global information to perform routing end-to-end in the link is the packet's destination LA itself. An access point uses this algorithm in combination with a routing table, referred to as Routing Register (RR). This is used when the AP receives a packet with a destination LA beginning with its APN. The AP will be Then decide if to relay the packet in the channel or discard it, or buffer a copy or forward it to another destination on the basis of the Information contained in the RR for the packet's destination LA (see section 4.2.1). Inzerilli [Page 21] INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001 4.1. Switching node model In this section we provide a specification of the routing algorithm performed on the distribution system together with some implementation guidelines using right-shifts and two-byte binary masks. A different implementation approach could be adopted if proved to be more efficient and guaranteeing a correct operation. Access points, switches and gateways are referred to as switching nodes. They perform switching of packets inside the link and constitute the distribution part of the SIMPLE link. Packets are forwarded inside the distribution system by means of an auto-routing algorithm which exploits a suitable numeration of switching nodes. Each switching node is provided with a switching number, one interface toward an uplink node (apart from gateways, which have no uplink node in the link), a number of interfaces toward peer nodes and a number of interfaces toward downlink nodes. Each interface in a node is identified by the switching number of the neighboring node seen from that interface. The uplink node's switching number is always a prefix of the node's switching number. In other words, a set of nodes sharing a same uplink node has a switching number beginning with the same prefix, which is the uplink node's switching number. Figure 3 shows a model of node with consistent numeration of the switching number and the interfaces: || interface ---- 010 _______||______ | | interface | | interface 01011__ | __| switching |__ | __ 01100 -- | --| number |-- | -- | | | | | 01001 | | | |_______________| interface || || || interface 0100110 ---- ---- ---- 0100100 || || || interface 0100101 Fig. 3 - Switching node model Inzerilli [Page 22] INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001 Some switching nodes could not have all possible interfaces. For example, in a tree topology no nodes have interfaces to peer nodes. In addition, gateways are particular nodes without the uplink interface, as we said before. The routing algorithm in a SIMPLE link requires that each switching node has its switching number and interfaces consistently configured. Routing inside the distribution system is performed using local information on switching number and interfaces independently of the size of the link, the number of hierarchical levels, the number of mobile nodes actually registered to the link and their exact location. However, the global information on the number of gateways (NUM_GT) in the link must be present in each node for the correct operation of the switching algorithm. All switching nodes implement a scalable auto-routing algorithm, using local information on their switching number and interfaces. However, APs are the only nodes having knowledge of the mobile nodes registered to the link, which is contained in special distributed routing tables, which are used in combination with the auto-routing algorithm. These are called Routing Registers (RRs). RRs form a set of fixed-size single-lookup distributed databases, where routing information is stored with no duplications. As they are fixed-size and single-lookup, the time needed for a lookup is constant and independent of the table size. RRs are looked up on a packet arrival only when the packet's destination LA have a prefix equal to the AP's APN. This is done either to intercept signaling message destined to the AP or to check that the destination mobile node is being served in the cell before transmitting the packet or to buffer copies of packets or to divert packets to another AP (see section 4.2.1). All nodes in the distribution system, apart from APs, treat signaling messages in the same way as data packets. While APs use signaling messages to update their RR and perform data buffering and forwarding, the other switching nodes just relay packets from an AP or a gateway to another AP or gateway on the basis of their destination LA field only, without processing of control information in the packet header. Routing in the distribution system is performed exploiting the auto-routing content of LAs in a SIMPLE link consistently numbered (figure 2,3). A SIMPLE link is such if - all the downlink nodes from a node have their switching number of the same length and begins with a same prefix, which is correspondent to the uplink node's switching number; - peer nodes (those other than downlink nodes or the uplink node) have switching numbers distinct and of the same length as each node's switching number. Inzerilli [Page 23] INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001 In such a link, each node in the distribution system is locally configured with its own switching number and with its neighboring link nodes' and with the global information on the number of gateways on the link (NUM_GT). In addition, switching nodes are provided with a two-byte binary mask of k initial consecutive ones followed by 16-k zeros, the node's mask (N_MASK), where k is the length of the node's switching number. In addition, the downlink switching numbers' length n is provided. This parameter is equal to 16 in case the switching number is an access point. Neighboring nodes' switching numbers are needed for each switching node to configure each switching node's interfaces. The data structures were interfaces are specified are: - the downlink node interface list - the peer node interface list with the following format: [ index, interface, MAC address] Each entry of these lists associates an index to a peer or downlink neighboring node. When a packet with a destination LA not smaller than the number of gateways on the link (NUM_GT) arrives at a switching node, the packet's destination LA is right-shifted of 16-k bits to obtain an index to compare with the node's switching number. a If the index matches the node's switching number, a the packet's destination LA is put in AND with the complement of the N_MASK and right-shifted of 16-n bits to obtain another index. This new index is then used to look up the downlink list for an output interface to send the packet. b If, on the contrary, the index does not match the switching number of the node, the peer node interface list (if not empty) is looked up using the index as a key. If a match is found the packet is sent to the correspondent output interface. If the entry is not found, the packet is relayed to the uplink interface. When, instead, a packet with a destination LA smaller than the number of gateways on the link (NUM_GT) arrives at a switching node c the packet is relayed to the uplink node if the switching node is not a gateway d if the switching node is a gateway and the packet carries its SLA as destination LA, it is intercepted, otherwise, it is relayed Inzerilli [Page 24] INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001 to the gateway having its SLA corresponding to the packet's If the actions described above are applied locally in each switching node, the complete end-to-end SIMPLE routing algorithm then proceeds following the following rules: 1 A SIMPLE packet with a destination LA which is grater than or equal to NUM_GT, originated in a gateway, is relayed downlink hop-by-hop, each node having its switching number equal to the prefix of the destination LA field in the packet header. 2 A SIMPLE packet with a destination LA which is smaller than NUM_GT, originated in a gateway, is sent towards the gateway having its SLA equal to the packet's destination LAs. 3 A SIMPLE packet with a destination LA which is grater than or equal to NUM_GT, originated in a mobile node, is relayed uplink till one of the following events occurs. 3.1 a node with a direct link to another peer node having its switching number equal to the prefix of the destination LA field in the packet header is reached; the packet is then relayed to the peer node and, afterwards, the packet will be relayed downlink till the destination node as specified in rule 1. 3.2 a node having its switching number equal to the prefix of the destination LA field in the packet header is reached and, afterwards, the packet will be relayed downlink till the destination node as specified in rule 1. 4 A SIMPLE packet with a destination LA which is smaller than NUM_GT, originated in a mobile node, is sent uplink till a gateway is reached. The packet will be then sent to the destination gateway having its SLA coinciding with the packet's destination LA. .fi 4.2. Access Point model Access points represent the core of the SIMPLE protocol. Unlike the other switching nodes, which need to be aware only of their switching number and of their neighboring link nodes' together with the global information of the number of gateways on the link (NUM_GT), access points provide a set of distributed databases where routing information is contained. These are called Routing Registers (RRs) and are used to keep track of all the mobile nodes registered to the link and of their exact location. A peculiarity of SIMPLE is that however large a link is, APs are the only nodes that process and generate signaling, whose load on a Inzerilli [Page 25] INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001 single AP is independent of the size of the link. All the other nodes are passive forwarder of packets and do not distinguish signaling packets from data packet (IP datagrams or ARP packets encapsulated in SIMPLE packets). The main functions of APs are: broadcasting information about the link and the serving AP itself, routing packets and handling link- Layer registrations, state refreshing, location updates and handovers. Some parameters have to be configured in each access point to make these procedures possible (apart from what is present in each switching node for implementing the auto-routing algorithm), which are: - the link identifier, which must be the same for all APs of the link and can correspond to an IP subnet prefix of the link; this is used by mobile nodes to discover if they are in their home link or in a foreign link when they switch on and to detect link changes after a movement to a new cell while switched on; - the APN, which is used by mobile nodes in their home link to discover if they are in their reserved cell when they switch on and to detect changes of cell while switched on; - the Advertisement message interarrival time (ADV_TIME), which has to be the same for all APs in a same link, to enable mobile nodes to detect loss of connectivity to the link after a long time without receiving Advertisement messages from an AP; - a MAX_REG_TIME parameter, which corresponds to the maximum time a mobile node's registration state can last without being refreshed; - a MAX_DEF_TIME parameter, which corresponds to the maximum time a mobile node's default state can last without being refreshed; - a REFR_REG_TIME parameter, which is the time that has to elapse between two consecutive Registration Refresh messages; - at least one SLA of a foreign agent (only in IPv4 links) to which foreign IPv4 mobile nodes will have to register; 4.2.1. Routing Registers (RRs) Each AP has a routing table, which contains as much entries as the number of CLAs that can be assigned in the cell. This table is referred to as Routing Register (RR). If an AP has its APN k bits long, it can grant access to the cell to up to 2**(16-k) mobile nodes. In fact, each CLA that is assigned in that cell is a 16-bit string with a prefix of k bits correspondent to the APN and a suffix of 16-k bit which can be associated to a particular mobile node in the cell, the Local Mobile node Identifier (LMI). Inzerilli [Page 26] INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001 A RR is a fixed-size table with 16-k entries, each of which relevant to a CLA, either assigned to a mobile node registered in the cell or available for requesting mobile nodes. Each entry is also indexed by an LMI as all CLAs of the cell share the same prefix (APN) but have different suffix, the LMI. APs use RRs to modify the routing algorithm explained in section 4.1, as regards to point a in particular. When a SIMPLE packet arrives at an AP, if this has a destination LA beginning with the AP's APN, the LMI is extracted and used as an index for a RR lookup before trying to send the packet downlink. This is needed either for applying a two-step routing algorithm to an address resolution message, or for intercepting signaling, or for intercepting data to buffer or to forward during handovers, or finally to assure that a data packet to relay into the cell is destined to a mobile node effectively registered to the AP, which otherwise has to be dropped. An entry of a RR has the following format: [Available-CLA bit, Handover-in-progress bit, remote mobile node's CLA, mobile node's new CLA, registration state timer, default state timer]. The Available-CLA bit is set when the correspondent LMI (and, consequently, the associated CLA) has been assigned to a mobile node in the cell. This bit when set corresponds to a soft state that is created after a successful link-layer registration of a mobile node. A creation of a registration state triggers the correspondent registration state timer in the same entry. A mobile node attached to an AP must regularly refresh its registration state with suitable signaling before its expiration, otherwise, it is canceled by the link and the correspondent CLA becomes available for a new mobile node. The Handover-in-progress bit is set at conclusion of a handover or after a buffering request by the mobile node and it is used together with the Available-CLA bit and the registration state timer to implement a handover strategy or a simple error recovery technique (see section 5.9). The two bits together with the registration state timer can be used to store up to four types of states, to handle registrations, error recovery and handovers. Forwarding of packets from the old to the new AP at conclusion of a handoff can be performed by storing the mobile node's new CLA in the correspondent field of the entry pointed by the mobile node's old CLA in its old cell. A forwarding state is then created. This information allows implementing a handover strategy to improve performances of handovers. We make a distinction between a handover and a simple Inzerilli [Page 27] INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001 location update. The latter involves idle mobile nodes' movements to a new cell that need just to update their location in order to keep themselves reachable. The former applies to active (sending or receiving packets) mobile nodes, which needs the link to take some measures to minimize packet loss and latencies. Forwarding states are made soft to render the handover procedure more robust. They are left in place till the expiration of their relevant timer and cannot be refreshed. We will deal with handovers in section 5.9. The remote mobile node's CLA field contains values of default states. A default state (or location state) is used to forward SIMPLE packets to a mobile node current location when its CLA is not known at the sender node. Default states are looked up to implement two-step routing for transporting address resolution messages (ARP ([9]) or ND ([7])). Instead of broadcasting these messages to the whole link as it would be expected in a classical LAN, a single packet is first sent to the destination mobile node's default AP, where the correspondent default state, containing the destination mobile node's CLA, is stored. The packet is then diverted from the default AP to the destination mobile node's CLA. The steps of the algorithm for address resolution are the following: 1 An Internet node on sending an IP datagram would check its cache to resolve an IP address into a SIMPLE CLA. 1.1 If the needed entry is found, the IP datagram is encapsulated in a SIMPLE packet and sent directly to the destination mobile node. 1.1 Otherwise, one message for address resolution (ARP or ND) is created and encapsulated in a SIMPLE packet setting a special flag D in the packet header (see appendix A)and sent to the default cell using the last two bytes of the mobile node's IP address as the packet's destination LA and. This always corresponds to the mobile node's Default Link-layer Address (DLA), which is a pointer to the mobile node's default state. 1.2 The packet will reach the mobile node's default cell and recognized as carrying a destination LA of a CLA that can be assigned in the cell by its prefix (see section 4.1 point a). The D flag set will tell the AP, the destination LA field contain a DLA. The LMI extracted by the packet's destination LA will be used to retrieve the remote mobile node's CLA value in the relevant entry. The retrieve LA is the mobile node's CLA. This will overwrite the packet destination LA, the D flag set to 0 and the packet sent again, carrying the address resolution request to destination. 1.3 The address resolution request will trigger a response message (ARP or ND) on its arrival at the mobile node. 1.4 On the arrival of the response, the pending IP datagram will be Inzerilli [Page 28] INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001 sent to the mobile node A DLA is a pointer to a default state. The prefix of this pointer is an APN identifying a mobile node's default cell, where the default state is stored, the remaining suffix is an LMI pointing to the entry of the RR in the mobile node's default cell where the default state is stored. A mobile node, while moving in a SIMPLE link, will change its CLA but will keep its DLA (always correspondent to the last two bytes of its IP address) and will regularly update its current location (CLA) in its default state. The double use of a DLA and a CLA allows a mobile node to roam in a link and change interface (CLA) and keeping its IP address all the time it remains registered to it. A default state is soft. When a default state is created after a successful link-layer registration of a mobile node, the correspondent timer is triggered and the default state has to be regularly refreshed. If the timer expires the correspondent default state is canceled. It is the current AP where the mobile node is attached to which will generate suitable signaling to regularly refresh the remote mobile node's default state until the mobile node leaves the cell. Location Refresh messages are regularly issued by the AP a mobile node is currently attached to all the time its registration state is kept alive. The CLA and the DLA of a mobile node can sometimes coincide. This is a preferable situation because it avoids propagating refreshing messages for default states and two-step routing to deliver address resolution messages. This condition, however, cannot be always guaranteed, especially for fast-moving mobile nodes. This is because a DLA is assigned once for all when a mobile nodes registers to a link and is kept all the time it remains in the link, while the CLA is changed each time it moves to a new cell. There is a parameter that needs configuring in each AP to enable utilization of RRs, which is the Reserved Local mobile node Identifier (RESV_LMI). The RESV_LMI gives the number of reserved LAs in the AP. In fact, in order to reduce admission failures to a link during a link- layer registration or a change of cell, because all the available CLA have already been assigned, some LAs are kept reserved for particular mobile nodes in each AP. More precisely, all the reserved LAs (RLAs) are assigned the bit strings from 0 to (RESV_LMI-1). As a consequence, each RR of an AP is logically organized in two parts. The first RESV_LMI entries are reserved for particular mobile nodes, the other 2**(16-k)-RESV_LMI entries can be assigned to any mobile node who requested one of them dynamically. A cell where a mobile node holds a Reserved LA is said reserved cell with respect to that mobile node. A mobile node must have at least a Inzerilli [Page 29] INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001 Reserved cell in its home link and as much Reserved LAs as the number of its IP home addresses in its reserved cells. A Reserved LA is always given by the last two bytes of a home address. When a mobile node registers to its home link it must be always given a DLA correspondent to its Reserved LA. In addition, when a mobile node enters its Reserved cell (both in case of link-layer registration or after a movement to a new cell) in its home link it cannot be rejected and has to be assigned a CLA equal to its Reserved LA as well. When the mobile node registers in its home link it must be given a DLA equal to its RLA, wherever it enters it. The presence of Reserved LAs is necessary not only to reduce admission failures. Reserved LAs are also needed to allow correct operation of SIMPLE in home links. In fact, here mobility at the IP level is not provided and IP datagrams have to reach a mobile node only through its IP home address. If the provisions above are respected, the address resolution algorithm described above operates correctly in all home links. In a IPv4 link RRs have a different format. We will consider only the case in which a foreign agent is used and no co-located care-of addresses are assigned, as it is the typical case. All the entries relevant to reserved CLAs remain the same: [Available-CLA bit, Handover-in-progress bit, remote mobile node's CLA, mobile node's new CLA, registration state timer, default state timer]. On the contrary, the entries relevant to dynamic CLAs have the following format: [Available-CLA bit, Handover-in-progress bit, mobile node's new CLA registration state timer]. In fact, default states for foreign mobile nodes would not be of any use if placed in APs. This is because the IP address used by a mobile node in a foreign link (for link-layer routing) is the IP home address. So an easy mechanism for deriving a DLA from the mobile node's IP address cannot be exploited. However, as all traffic toward a foreign mobile node flows through the foreign agent it is registered to, default states can be stored here. So, a table for address resolution will be used by the foreign agent and will store default states. This, however, is called Visitors Address Resolution Table have a slightly different format: [ mobile node's IP home address, mobile node's CLA, CLA timer] Inzerilli [Page 30] INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001 4.2.2. Access Point operation Each AP point uses its RR to route data packets and to process and generate SIMPLE specific signaling. 4.2.2.1. Access Point signaling An AP processes and generates the following SIMPLE specific signaling: 1 It broadcasts Advertisement messages, which convey information on the link and the specific cell they are serving. This includes: - the link identifier to help the mobile node understand whether it is in its home link or not and, consequently, to trigger a suitable Mobile IP or Mobile IPv6 registration or deregistration when a change of link identifier is detected by the mobile node after a movement to a new cell; - its APN, which the mobile node needs to understand if it is in its reserved cell of its home link and to detect changes of cell; - an interarrival-time parameter for Advertisement messages (ADV_TIME), which can be used by the mobile node to initialize a timer at each Advertisement arrival in order to detect loss of connectivity with the link (Advertisement messages could be solicited by mobile nodes on switching on or after the timer for Advertisement messages expires); - a REFR_REG_TIME parameter, which the mobile node will use to set the frequency of Registration Refresh message generation. 2 It processes registration requests from new mobile nodes and grants or denies them access to the link. A successful link-layer registration has to assign a unique CLA (among all those already assigned in the cell) and a unique DLA (among all those already assigned in the link). In order to assign a CLA does an AP first need to look up its local RR for an available CLA (scanning the RR and find an Available-CLA bit not set yet) and activate the relevant registration state (setting this Available-CLA bit). In order to assign a DLA can it use an LA of the cell which is not being used as a DLA by any mobile node in the link (this is signaled by a default state timer null). It can also query a centralized database, a set of distributed databases or a recursive algorithm for DLA research. We will discuss all these alternatives section 5.3. 3 It generates and processes refreshing messages for default states all the time the correspondent mobile node remains registered to the cell. Inzerilli [Page 31] INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001 4 It processes and generates location update messages to update default states when and idle mobile node changes cell and participates to the exchange of signaling and data buffering and forwarding during handovers. 5 APs have also to process proxy ARP messages and ND messages, which are not broadcast in a SIMPLE link to enable the operation of home agents (see section 6.1). 4.2.2.2. AP switching algorithm An AP routes all packets in the same way as any other switching node in the distribution system except for those carrying a destination LA prefix which matches the AP's APN. When this event occurs (section 4.1 point a) the RR is looked up using the LMI extracted from the packet's destination LA as a key. There are then two possibilities: - the special flag D in the packet header is set (see appendix A and section 4.2.1): this means that the two-step routing algorithm has to be applied, as the sender of the packet didn't know the destination mobile node's CLA and used its DLA to discover it, - the special flag D is not set: the packet's destination LA is the mobile node's CLA the sender had in its cache; there are then four cases depending on the state associated to the entry pointed by the packet's destination LA. Each of such states is identified by a code assigned to the AH bits. The following pseudo code illustrates the complete forwarding algorithm of an access point receiving a data packet which matches the APN with the prefix of its destination LA. It also considers a possible handover or error recovery technique taking place (see section 5.6.1). Handovers and error recovery exploits buffering and forwarding of data. When a data packet (the SIMPLE header will begin with the 000 prefix (see appendix A)arrives at an AP and has the prefix of its destination LA coinciding with the AP's APN, the D flag is checked: 1 if the D flag is set, the LMI of the packet's destination LA is used as an index to look up the RR and retrieve the remote mobile node's CLA value; the packet's destination LA is then overwritten with this value and the D flag set to 0; if the prefix of the packet's new destination LA matches the APN, rule 2 is applied, otherwise, the auto-routing algorithm is used to send the packet uplink or to a peer neighboring node; Inzerilli [Page 32] INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001 2 if the D flag is not set, the LMI of the packet's destination LA is used as a key to look up the RR and check the AH bits, 2.1 if these are set to 10, the packet is sent to the downlink interface after looking up the downlink node interface list. 2.1 if these are set to 00, the packet is dropped. 2.1 if these are set to 11, the packet is sent to the downlink interface after looking up the downlink node interface list and a copy of it is buffered. 2.1 if these are set to 01, the mobile node's new CLA value is read and used to overwrite the packet destination LA and the auto- routing algorithm is used to send the packet uplink or to a peer neighboring node. Note that sometimes a mobile node's default state is contained in its current cell. In this case rule 1 is followed by rule 2 and it will not be necessary to send the packet to another AP to complete the two-step algorithm. Steps 2.1 when the AH bits are set to 11 or 01 are associated to error recovery and handovers (see section 5.6). 4.3. Mobile node model A mobile node is an Internet node, in other words is provided with an IP entity. It then creates SIMPLE packets adding a header to IP datagrams when they need to be sent to a neighboring Internet node, decapsulates SIMPLE packets and pass them to the destination IP entity on their arrival. IP processing is out of the scope of this section if not relatively to the interfacing aspects with SIMPLE only. As regards to the SIMPLE level capabilities, a mobile node has to be provided with signaling and data transporting services, first of all, to request access to the link and then to send and receive SIMPLE packets. In addition, it should be able to change AP both in idle state and in active state without loosing connectivity and reducing packet loss and delay at the most during a movement to another cell. To render the above feature possible to realize, a mobile node should be configured with two parameters: - a Reserved LA (RLA) - a home link identifier Inzerilli [Page 33] INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001 Alternatively the two parameters can be calculated, as the RLA could be derived from the mobile node's home IP address and the link identifier could be made correspondent to the subnet prefix of the mobile node's IP home address. In addition, a couple of timers are needed: - an Advertisement message timer - a registration refresh timer As a first Advertisement message from an AP is received, the mobile node should store the current APN and the current link identifier. It should also store the Advertisement message interarrival time ADV_TIME, the REFR_REG_TIME parameter and initialize the correspondent timers. The mobile node will then try to register to the link. If the link- layer registration is successful a CLA and a DLA have to be stored in the mobile node. In the meanwhile the mobile node should constantly listen to Advertisement messages in order to detect changes of cell or of link, in which cases new values for CLA or CLA plus DLA have to be requested respectively and stored together with the new values for the current link identifier, APN, ADV_TIME, REFR_REG_TIME and the timers reinitialized to the new values. A mobile node can derive the APN of its Reserved cell from its Reserved LA. More precisely, as the length of APNs is not fixed a priori, but can be different from AP to AP, a mobile node entering a cell has to listen to Advertisement messages broadcast by the AP. - If the advertised link identifier is the same of its home link identifier, it means the mobile node has entered its home link. - It can then compare the advertised APN with the first bits of its Reserved LA and understand if it is in its dedicated cell. - If so, it can then send a registration request to the serving access point (see section 5.2) and immediately set both its DLA and CLA to its Reserved LA without waiting for a response message from the AP. A mobile node has to be provided with another couple of constants that Are used to set buffering and forwarding state timers during handovers and error recovery: a) FWD_TIME, if implementing a forwarding strategy only b) BUFF_TIME and FWD_TIME, if implementing a buffering and forwarding strategy Inzerilli [Page 34] INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001 We will examine the two techniques in section 5.6.1. 4.3.1. Mobile node operation 4.3.1.1. Mobile node signaling Each mobile node uses the pre-configured constants and the CLA and DLA dynamically acquired to register to a link to send and receive data packets and to move from cell to cell inside a SIMPLE link. To make this possible it is necessary a mobile node processes and generates the following SIMPLE specific signaling: - It listens to Advertisement messages conveying information on the link and the specific cell. These include the number of gateways on the link to derive the set of SLAs, the link identifier to help the mobile node understand whether or not it is in its home link and to trigger a suitable Mobile IP or Mobile IPv6 registration or deregistration when a change of link identifier is detected. While it listens it also has to store the Advertisement interarrival time, ADV_TIME, which is needed to detect loss of connectivity with the link, and the REFR_REG_TIME, which regulates the mobile node's Registration Refresh message generation frequency. - It has to send registration request messages, once understood where it is and optionally set immediately its DLA and/or CLA to its Reserved LA, when it understands that it has entered its Reserved cell or its home link. - It processes registration responses from the serving AP and sets its CLA and DLA if the link-layer registration accomplishes successfully. - It generates refreshing messages for registration states to assure the serving AP that it is still present in the cell. - It generates location update messages to update registration states when it is idle and changes cell and exchanges signaling massages with the old and new AP to request data buffering and forwarding during handovers or simply to request data buffering during period of low-quality communication. Inzerilli [Page 35] INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001 4.3.1.2. Reception and transmission of data A mobile node uses its single uplink interface with the AP to send and receive data. So, no particular switching capability is needed in the mobile node. Its only task to accomplish on a data packet reception is to assure that it is really destined to it, checking the packet's destination LA, which must correspond to its CLA, decapsulate the packet and send it to the IP layer. If the check is not passed, the packet is discarded. On transmission, an IP datagram has to be encapsulated in a SIMPLE packet using a CLA as the packet's destination LA if the next IP hop is another mobile node. If the destination node is a gateway, its SLA has to be retrieved. CLA and SLA bindings with IP addresses are contained in the mobile node's address resolution cache. When the destination IP node is not located in the link the packet can be sent to the default gateway. The default gateway can be assigned the SLA equal to 0. This guarantees that if a gateway exist on the link, the Packet will be certainly sent to a gateway. Instead, when the destination node is a host on the link, its CLA will be looked for in the cache. If this is found the packet will be sent, otherwise, the address resolution algorithm with the two-step routing will take place. The SLAs of a specific gateway or a mobile router can be discovered with the same mechanism (see also section 4.2.1). When the destination mobile node's CLA is not available , an address resolution request message is generated (ARP for IPv4 or ND for IPv6) and encapsulated in a SIMPLE packet and the data packet is put in a pending state, waiting for the node's CLA to be communicated. The node's DLA (last two bytes of the mobile node's IP address used in the link) has to be used as the encapsulated address resolution message's destination LA, and the D flag must be set to signal that a two-step algorithm has to be applied. The destination LA set to the mobile node's DLA will make sure the packet reaches the mobile node's default cell, which has the mobile node's CLA stored in its RR. Once here, the D flag set will guarantee that the packet is relayed again using the mobile node's CLA. The signaling message will arrive at destination triggering a response, which will be sent using directly the sending mobile node's CLA. As the response reaches the sending node, the pending data packet will be sent. When it is a gateway's SLA not available, the same action as before will be taken. So an address resolution request will be encapsulated Inzerilli [Page 36] INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001 in a SIMPLE packet, the destination LA will be set to the last-two byte address of the gateway's IP address, the D flag will be set and the packet will be sent. The packet will reach the gateway directly. Here, the D flag will be ignored and the packet recognized as destined to the gateway, which will send a reply to the sending mobile node. So, it not necessary that a mobile node be aware of transmitting to a gateway or to a mobile node. This routing mechanism is completely transparent to ARP or Neighbor Discovery. Even if these messages are not repeatedly broadcast and only A single packet is created, this will be correctly routed to the destination mobile node's no matter how large the link is. It then provides ARP and ND with a transparent and efficient service independently of the link topology. 4.4. Gateway model A gateway is a switching node provided with the IP layer and serves as a point of ingress and exit to and from the Internet. It has SIMPLE interfaces on the link to other gateways (peer nodes) in multiple-access-gateway links and to other downlink nodes. 4.4.1. Reception and transmission of data As an Internet node it has to send a receive IP datagrams. It is then provided with a link-layer address, referred to as Static Link-layer Address (SLA). When sending a datagram, it has to encapsulate it in a SIMPLE packet retrieving the destination node's LA (neighboring Internet node). If this is not available, it must be capable of resolving the destination node's IP address into its link-layer address with the same mechanism specified in section 4.3.1.2, before sending the data. In addition, when receiving a packet it will check if it carries its SLA as destination LA. If so, it will decapsulate it and send it to the IP layer, otherwise, it will relay it to another gateway or to a downlink node. As a switching SIMPLE node, it has to perform the same actions as any other switching node. It is then provided with a switching number, and the other parameters necessary for performing the switching algorithm explained in section 4.1. In addition, it must be capable Inzerilli [Page 37] INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001 of sending packets to other gateways on the basis of their SLAs. This is a facility that the auto-routing algorithm explained in section 4.1 does not specify. In fact, packet's carrying an SLA are relayed uplink till a gateway is reached if originated by mobile nodes. Once here, an output interface associated with the destination gateway's SLA is needed. In addition if a packet is originated in a gateway and it has to be sent to another gateway, the same issues arise. So, besides the peer node interface list and the downlink interface list, gateways has an additional static table, which is referred to as gateway interface list, whose entries have the following format. [destination SLA, interface, MAC address] Unlike the other two, this table could contain non-local information. This can happen if the gateways of a link are not connected with a full mash topology. It is in fact, necessary that all gateway knows to which output interface sending a packet for any other gateway. So, if NUM_GT is number of gateways on a link each gateway interface list of a gateway will have exactly one NUM_GT-1 entries. This will make sure that a chain of forwarding entries from any gateway to any other gateway of a same link will be present if a physical path is available. 5. SIMPLE signaling procedures In this section, the signaling procedures performed by SIMPLE are described. They consist of the following: location discovery, link- layer registration, DLA research, state refreshing, location update, error recovery, handover. 1 The location discovery procedure allows a mobile node to discover the link and the cell it has entered on switching on and on moving to a new cell while powered on and gather useful information about the link and the current cell. 2 The link-layer registration procedure is used by the mobile node to request and obtain admission to a link through an AP. An AP will reject a registration request if the registering mobile node has not a Reserved LA in the cell and all the dynamic CLAs have already been assigned. If, on the contrary, the procedure is successful the mobile node can attach to the link and use the network for intercell communications with other mobile nodes in the link. A link-layer registration attempt terminates successfully if the mobile nodes is returned a CLA to send and receive packets in the Inzerilli [Page 38] INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001 cell and a DLA to render its current interface to the link (CLA) obtainable through a two-step routing. 3 The DLA research procedure is used to find a unique DLA to assign to foreign mobile nodes (mobile nodes which are not in their home link) during a link-layer registration. This could be done either having the serving AP querying a centralized database, a set of distributed databases or using a recursive algorithm for DLA research in which a DLA Request message is relayed from AP to AP recursively till a lookup of a RR returns an available DLA. 4 The state refreshing procedure is needed to keep registration and default states alive during the staying of a mobile node in a link. While a mobile node is attached to an AP, it has to send Registration Refreshing messages to the serving AP regularly. On a Registration Refreshing message arrival, the AP will generate a Location Refreshing message to keep the mobile node's remote default state alive (unless mobile node's default state is contained in the same RR as the mobile node's registration state). As this procedure is likely to account for the majority of the signaling that a mobile node has to generate (for fast-moving mobile nodes location update procedure generate a large part of the overall signaling from a mobile node as well), data sent by a mobile node can be used to refresh the correspondent registration state in the serving AP to save battery in the mobile node. In this case Location Refreshing message will be triggered after a period of continuous transmission of data. 5 The Location update procedure allows a mobile node moving to another cell while idle to update its remote default state with its new location (CLA). The procedure consists of a couple of messages in general. With a first message a mobile node registers to the new AP. The new serving AP will then send another message to the mobile node's default cell to update the mobile node's default state. If the mobile node's new cell corresponds to the mobile node's default cell the second signaling message is obviously not needed. If the mobile node's is being served in a foreign IPv4 network, location update message will be addressed to a foreign agent rather than a default cell. 6 The error recovery procedure allows a mobile node to request a buffering of a copy of each data packets transmitted during a period of poor communication quality and it is requested by the mobile node with a Buffering Request message. If a handover follows a buffering request buffered packets can be forwarded to the new AP on request to reduce packet loss. Otherwise after thee expiration of a timer buffered packets are released in a single burst into the channel. The applicability of a buffering strategy depends on the type of wireless interface a mobile node is provided, which should trigger a Buffer Request message when the communication quality drops below a certain threshold. 7 The Handover procedure allows a mobile node moving to another cell Inzerilli [Page 39] INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001 while communicating with other Internet nodes on the link to update its remote default state with its new location (CLA) and avoid losing packets or minimizing packet loss during the move. There are alternative strategies which exploit a previous buffering for error recovery and forwarding from the old to the new AP or directly forwarding from the old AP. All the procedures synthetically introduced above take place only after the standard underlying technology cell selection, association and re-association procedures. Mobile IP ([2]) or Mobile IPv6 ([3]) signaling follow SIMPLE signaling procedures when necessary. Therefore, we distinguish three levels of connectivity corresponding to three architectural levels (we the term connectivity we intend the capability of exchanging packets between peer entities at a certain architectural level): - a wireless channel connectivity, which is provided by the underlying wireless access technology by means of its standard association and re-association processes; this could optionally include connectivity to a core network through bridges; - a link connectivity, which is provided by the intra-domain mobility protocol interfacing with both the access part and the distribution system; many different segments could be present in the distribution system as well as in the access part of the same link; the APs and the switching nodes of the intra-domain mobility protocol will bridge all these segments so that they all appeared as a single homogeneous link to the IP layer; - an Internet connectivity, which is provided by Mobile IP or Mobile Ipv6 in a foreign link and by IP or IPv6 in a home link; 5.1. Location discovery When a mobile node switches on the first procedure it activates is location discovery. This procedure will continue running in background while the mobile node is switched on to enable the mobile node to detect changes of location (interfaces or links). Location discovery consists in listening to Advertisement messages that are broadcast by APs and trigger either link-layer registration or location update procedure or handovers (in SIMPLE handovers are mobile-node-initiated). Below is a description of this procedure: UPON SWITCHING ON 1 The mobile node initializes its Advertisement message timer to a default value and listens to the channel for an Advertisement message from an AP. If this timer expires without the mobile Inzerilli [Page 40] INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001 node's receiving an Advertisement message, the mobile node issues a solicitation Message carrying no parameters. Solicitations can be repeated an undetermined number of times till an Advertisement message is received, or a finite number of attempts can be made before the mobile node switches off automatically. 2 An AP, receiving a solicitation message will reply broadcasting an Advertisement message which carries a current link identifier, the APN, the Advertisement message interarrival time and the default gateway's SLA. Even if not solicited each AP will have to broadcast Advertisement regularly. 3 The mobile node, on receiving an Advertisement message, will set its Advertisement interarrival timer and the registration refresh timer to the advertised values and store the default gateway's SLA. It will then compare the advertised link identifier and APN with its home link identifier and its reserved APN. One of the following possibilities can occur: CASE A) The advertised link identifier and APN coincide with the mobile node's home link identifier and the mobile node's reserved APN. The mobile node is then in its reserved cell in its home link. A link-layer registration will be triggered. CASE B) The advertised link identifier coincides with the mobile node's home link identifier but the advertised APN and the mobile node's reserved APN do not match. The mobile node is then in its home link but not in its reserved cell. A link- layer registration will be triggered. CASE C) The advertised link identifier does not coincide with the mobile node's home link identifier. The mobile node is then in a foreign link. A link-layer registration will be triggered and a Mobile IP or Mobile IPv6 registration will follow. WHILE SWITCHED ON Points 1 and 2 are the same as when the mobile node switches on. Below are the following points when location discovery is performed while the mobile node is on. 3 The mobile node, on receiving an Advertisement message, will set its Advertisement interarrival timer and the registration refresh timer to the advertised values and update its default gateway's SLA, if necessary. It will then compare the advertised link identifier and APN with its previously stored link identifier and APN. One of the following possibilities can occur: CASE A) The advertised link identifier and APN coincide with the mobile node's previously stored link identifier and APN. The mobile node is still in the same cell as before. Then, nothing has to be done. Inzerilli [Page 41] INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001 CASE B) The advertised link identifier coincides with the previously stored link identifier but the advertised APN and the previously stored APN do not match. The mobile node has then moved to another cell of the same link. This information can be optionally provided by the underlying network to reduce times for handovers or location updates. There are then two possibilities: 1) The mobile node is active (receiving or transmitting data packets). A Handover procedure will be then triggered 2) The mobile node is idle (neither receiving nor transmitting data packets). A location update procedure will be then triggered CASE C) The advertised link identifier does not coincide with the previously stored link identifier. The mobile node has then moved to another link. One of the following possibilities can occur: 1) The advertised link identifier and APN coincide with the mobile node's home link identifier and the mobile node's reserved APN. The mobile node is then in its reserved cell in its home link. A link-layer registration will be triggered. A Mobile IP or Mobile IPv6 deregistration will follow. 2) The advertised link identifier coincides with the mobile node's home link identifier but the advertised APN and the mobile node's reserved APN do not match. The mobile node is then in its home link but not in its reserved cell. A link- layer registration will be triggered. A Mobile IP or Mobile IPv6 deregistration will follow. 3) The advertised link identifier does not coincide with the mobile node's home link identifier. The mobile node is then in a foreign link. A link-layer registration will be triggered and a Mobile IP or Mobile IPv6 registration will follow. 5.2. Link-layer registration Mobile node in its reserved cell in its home link: upon mobile node's switching on CASE A), while the mobile node is switched on CASE C)1. 1 The mobile node has simply to inform the serving AP of its presence through a Registration Request message containing its home link identifier and its reserved LA. It can also immediately set its CLA and DLA to its reserved LA (RLA). 2 The AP will recognize the mobile node as having a reserved access Inzerilli [Page 42] INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001 to the cell on the request arrival, will create a registration state for it in the entry pointed by the mobile node's reserved LA (the Available-CLA bit in the RR will be set), will create a default state for it in the same entry (the remote mobile node's CLA field in the AP's RR will be filled with the assigned CLA and the relevant timer triggered) and finally will send a Registration Reply to the mobile node to inform it of the successful registration. 3 The mobile node on the Registration Reply message arrival will check the provided DLA and CLA. These must both coincide with the mobile node's reserved LA. This consistency check could be used to detect malfunctioning of the serving AP. Mobile node in its home link but not in its reserved cell: upon mobile node's switching on CASE B), while the mobile node is switched on CASE C)2. 1 The mobile node tries to register with the serving AP and send a Registration Request message containing its home link identifier and its reserved LA. It can also immediately set its DLA to its reserved LA (RLA). 2 The AP will recognize the mobile node as belonging to the link but not having a reserved access to the cell and will look for a dynamic CLA to assign to the mobile node. If no dynamic CLA is available, the mobile node will be rejected through a Registration Reply message. If, on the contrary, a dynamic CLA is still available, this will be assigned to the mobile node, a registration state for it will be created in the entry pointed by the selected CLA(the Available-CLA bit in the RR will be set) and a Registration Reply will be sent to the mobile node to inform it of the successful registration. In addition, a Location update message will be created and sent from the current AP to the mobile node's reserved AP. 3 If the registration is successful the mobile node on the Registration Reply message arrival will store the provided CLA and check the provided DLA. This must coincide with the mobile node's reserved LA. This consistency check could be used to detect malfunctioning of the serving AP. If the registration is not successful the mobile node can wait for a while to try again. Either an undetermined number or a finite number of attempts before the mobile node automatic switching-off can be made. 4 If the registration is successful and a Location update message arrives at the mobile node's reserved cell, a default state will be created for it in the entry pointed by the mobile node's reserved LA (the remote mobile node's CLA field in the AP's RR will be filled with the mobile node's reserved LA and the relevant timer triggered). Inzerilli [Page 43] INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001 Mobile node in a foreign link: upon mobile node's switching on CASE C), while the mobile node is switched on CASE C3. 1 The mobile node tries to register with the serving AP and send a Registration Request message containing its home link identifier and its reserved LA. 2 The AP will recognize the mobile node as not belonging to the link and will look for a dynamic CLA to assign to the mobile node. If no dynamic CLA is available, the mobile node will be rejected through a Registration Reply message. If, on the contrary, a dynamic CLA is still available, this will be assigned to the mobile node, a registration state for it will be created in the entry pointed by the selected CLA (the Available-CLA bit in the will be set) and a DLA to assign to the mobile node will be looked for. In a IPv4 link the DLA to assign must coincide with the static LA of a foreign agent, pre-configured in the AP. In addition, the serving AP will generate a Location update message and will send it to the foreign agent. In a IPv6 link, there are a number of possibilities for assigning a DLA. As a first choice, the AP will try to assign a DLA equal to the CLA just selected. This, however, cannot be done if this DLA has already been assigned to another mobile node (a DLA must always correspond to the last two bytes of the mobile node's IP address). This can be verified by simply looking at the correspondent DLA timer. If the timer is not null, it means that another mobile node is using that DLA. If a DLA correspondent to the selected CLA can be assigned, a default state is created in the entry pointed by the just selected CLA (the remote mobile node's CLA field in the AP's RR will be filled with the mobile node's CLA and the relevant timer triggered). On the contrary, if a DLA correspondent to the just selected CLA cannot be assigned, as a second choice, the AP can scan its RR for an entry with a null value of the default state timer among the dynamic CLA only. If such an entry is found the correspondent DLA is assigned and a default state is created in the entry pointed by the just selected DLA(the remote mobile node's CLA field in the AP's RR will be filled with the mobile node's CLA and the relevant timer triggered). If even this second choice attempt fails an algorithm for DLA research (we will examine a set of possible algorithms in the next section) will be triggered. This will always return a DLA not already assigned in the link to a mobile node and will create a default state for the mobile node in a remote AP. A Registration Reply will be sent to the mobile node to inform it of the successful registration. 3 if the registration is successful the mobile node on the Registration Reply message arrival will store the provided CLA and DLA. In a IPv6 link the DLA will be used to create a dynamic IP Inzerilli [Page 44] INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001 address through IPv6 Stateless Address Autoconfiguration ([10]). The DLA plus a six-octet prefix of zeros will become the interface identifier the mobile node will use in that link. A subnet prefix advertised in a ND ([7]) message plus the interface identifier will become the IPv6 dynamic care-of address the mobile node will use in the link. If the registration is not successful the mobile node can wait for a while to try again. Either an undetermined number or a finite number of attempts before the mobile node automatic switching-off can be made. 4 In a IPv4 link after a successful registration a Location update message will reach a foreign agent. This message will create a default state in the foreign agent's Visitor Address Resolution Table. This corresponds to a binding (mobile node's IP home address, mobile node's CLA). 5.3. DLA research procedures During a link-layer registration of a foreign mobile node (a mobile node not in its home link) in a IPv6 link an available DLA which no mobile nodes in the link is using has to be found and assigned to the registering mobile node. Unlike the cases of a mobile node in its home link or a mobile node in a IPv4 foreign link provided with a foreign agent, where the assignment of a DLA is straightforward (in the former case the DLA coincide with the mobile node's pre-configured reserved LA, in the latter with a static LA which is pre-configured in each access point and belonging to a foreign agent), a separate procedure is needed to discover an available DLA when all DLAs of the serving AP have already been assigned. An important consideration to make at this point is that when one of such procedure is called it will always return an available DLA. This is because a DLA procedure is activated by an AP only when a CLA has been assigned but not a DLA. As CLAs and DLAs in a link are of the same number, when such a procedure begins there will always be an available DLA in the link to assign. There are three possible options: A)A centralized database recording all the DLAs already assigned in the link can be used. This can be any Internet node on the link. So, when an AP needing an available DLA could query this database directly to conclude a link-layer registration. The following exchange of messages will take place: Inzerilli [Page 45] INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001 1 The access point will send a DLA Request message to the centralized database carried the assigned CLA as parameter. 2 On the arrival of this message the node where the database is stored will scan a table to find an available DLA. An available DLA will be returned, the table updated consequently and a DLA Reply carrying the selected DLA will be sent using the mobile node's CLA as the message's destination LA. 3 On the arrival of this message the AP will be able to continue the registration procedure and send a Registration Reply message carrying the assigned CLA and DLA. B)Another choice could be providing the link with a set of distributed databases, one for each gateway. If n=2**k is the number of DLAs that can be administered by a single gateway. All APs looking for an available DLA and sharing the first k bits of prefix in their APNs will query a same database as first choice, identified by that prefix, which corresponds to its switching number. If all DLAs in the first choice database have already been assigned, the first choice database can forward the DLA request to another gateway. DLA Requests can be forwarded recursively from a gateway to another till an available DLA is found in a database. DLA Reply can be then sent directly to the querying AP using the registering mobile node's CLA as destination LA of the message. C)Another option needs no additional database as it uses directly the existing RRs in APs. The algorithm originates from these considerations: Consider the case of an IPv6 mobile node that successfully registers to a foreign link, acquiring a DLA equal to the assigned CLA and moving out of the cell after a while. If, later, another foreign mobile node (we will call it the new-comer) registers in the cell which was left by the old one and acquires the CLA that the old mobile node used there as both its CLA and DLA, it will not be able to use this LA as its DLA. This is because the old mobile node is still using it as its DLA. A DLA must be unique for each mobile node, otherwise, two mobile nodes in the link will share the same IPv6 care-of address, obtained using the assigned DLA and IPv6 Stateless Address Autoconfiguration ([10]). As a solution, one could think that the newcomer may use the value of the old mobile node's CLA to assign to the new comer's DLA. The result of this technique would be the same as if the new comer had first registered in the old mobile node's current cell acquiring a DLA and a CLA both equal to the old mobile node's CLA. Afterwards both the new comer and the old mobile node would have swapped cell and CLA simultaneously. Inzerilli [Page 46] INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001 Actually, the algorithm above has a bug. It does not take into account the possibility that someone else could be using the old mobile node's CLA as its DLA. We can call this mobile node old-old mobile node. Assigning the old-old mobile node's CLA to the new comer as its DLA could not be a solution as an old-old-old mobile node could be using the old-old mobile node's CLA as its DLA. There seem to be no strategy that solves the problem. Actually, this technique could return a correct result if applied recursively, each time checking if a mobile node's CLA is already used by another mobile node as its DLA, till this is no longer true. The DLA research algorithm then follows these steps: 1 A mobile node is assigned an available CLA, the correspondent Available-CLA bit in the RR is set and, from now on, this is the mobile node's CLA until it remains in the cell. 2 The default state timer field is then read. As this is not null, the remote mobile node's CLA value of the same entry is retrieved. A DLA Request packet is sent using the retrieved value as destination LA. The message reaches the destination AP and the entry of the RR pointed by the message's destination LA is looked up. 2.1 The default state timer field is then read. As this is not null, the remote mobile node's CLA value of the same entry is retrieved. A DLA Request packet is sent using the retrieved value as destination LA. The message reaches the destination AP and the entry of the RR pointed by the message's destination LA is looked up. 2.1.1 The default state timer field is then read. As this is not null, the remote mobile node's CLA value of the same entry is retrieved. A DLA Request packet is sent using the retrieved value as destination LA. The message reaches the destination AP and the entry of the RR pointed by the message's destination LA is looked up. ............................................................... 2.1..............1 The default state timer field is then read. As this is null, the remote mobile node's CLA field is written with the registering mobile node's CLA, the correspondent default state timer is activated and a DLA Reply message carrying the assigned DLA is returned to the registering mobile node's current cell, using the registering mobile node's CLA as destination LA. It can be proven that this algorithm terminates in a finite number of steps. Inzerilli [Page 47] INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001 An improvement of this algorithm, which minimizes the number of signaling messages, could use the chain of CLAs to point to RRs, which are completely scanned for an available DLA before e new DLA Request message is generated instead of limiting to checking the pointed entries only. So, before sending the first DLA Request message from the registering mobile node's current AP and each time a subsequent RR is looked up, before sending a new DLA Request message to a new AP, all the table is completely scanned beginning from the pointed entry and if necessary the rest of the RR is read afterwards. Only if no available DLA is found in the RR a new DLA Request message is generated and sent along the chain of CLA. The RRs to scan are selected using the chain of CLA because this measure gives the guarantee that the algorithm terminates. RRs are scanned completely to limit the number of access to new RRs and accelerate the termination of the algorithm. 5.4. State Refreshing While a mobile node moves within a link, its default and registration states have to be regularly refreshed. If these soft states expire (this happens after a MAX_REG_TIME and MAX_DEF_TIME interval without refreshing messages) the mobile node is canceled from the link and its CLA can be assigned to a new mobile node. If the mobile node was visiting an IPv6 foreign link, its DLA and IPv6 dynamic care-of address become available for a new mobile node. Soft states render the protocol robust and are mandatory with wireless access. However, They could be not necessary to grant access to stationary hosts, as a consequence timers and state refreshing procedures could be removed for such nodes. What follows in this section is then to consider applicable to mobile nodes with a wireless interface in particular. The procedure for refreshing registration and default states is the following: 1 Every REFR_REG_TIME seconds a mobile node which is being served in a cell sends a Registration Refresh message to the serving AP to refresh its registration state. This message contains the mobile node's DLA. 2 When the Registration Refresh message is received by the AP, the mobile node's registration state is refreshed by reinitializing the relevant registration state timer to MAX_REG_TIME. If the MAX_REG_TIME is three times bigger than REFR_REG_TIME up to a couple of Registration Refresh messages can be lost in the wireless channel without disconnecting the mobile node from the link. Inzerilli [Page 48] INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001 3 A Location Refresh message is then created by the AP using the advertised DLA as the message's destination LA. This carries the mobile node's CLA. 4 In the mobile node's home link or in a IPv6 foreign link the message will arrive at the mobile node's default cell. The mobile node's default state will be then refreshed by setting the relevant default state timer to MAX_DEF_TIME. If the MAX_DEF_TIME is three times bigger than REFR_REG_TIME up to a couple of Registration Refresh messages can be lost in the wireless channel without freeing the mobile node's DLA. In an IPv4 foreign link the message will arrive at the foreign Agent the mobile node is registered to. Here the Visitor Address Resolution Table will be scanned using the mobile node's CLA as a key. The mobile node's default state will be then refreshed by setting the default state timer to MAX_DEF_TIME seconds. 5.5. Location update procedure A location update can be much faster than a link-layer registration as only a CLA but not a DLA has to be assigned. It can be either activated by the location discovery procedure running in background when a move to a new cell is detected or through an explicit feedback from the underlying access technology. In the latter case a location update can be faster. The actions taken during this procedure are different in the three cases of a mobile node entering its reserved cell, not entering its reserved cell but moving in its home link, and moving in a foreign link: MOBILE NODE ENTERING ITS RESERVED CELL 1 The mobile node moving to the new cell sends a Location update message, carrying the mobile node's home link identifier, the mobile node's reserved LA and the mobile node's DLA, to the new AP. As the mobile node cannot be rejected from the link, its CLA can be immediately set to its reserved LA, which must be the same as its DLA. It can then wait for a confirmation in the following Location Update Reply. 2 When the Location update message arrives at the new AP the mobile node is recognized as having a reserved access in the cell. The advertised reserved LA and the advertised DLA must be equal. This consistency check can be used to detect mobile node's malfunctioning. The new AP creates a registration state for the Inzerilli [Page 49] INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001 mobile node in the entry pointed by the mobile node's reserved LA and refreshes the mobile node's default state in the same entry. It then sends a Location update Reply, carrying the mobile node's new CLA. 3 When the mobile node receives the Location update Reply it check the advertised new CLA, which must correspond to the mobile node's reserved LA. This consistency check can be used to detect AP's malfunctioning. MOBILE NODE NOT ENTERING ITS RESERVED CELL BUT MOVING IN ITS HOME LINK 1 The mobile node moving to the new cell sends a Location update message, carrying the mobile node's home link identifier, the mobile node's reserved LA and the mobile node's DLA, to the new AP. 2 When the Location update message arrives at the new AP the mobile node is recognized as belonging to the link but not having a reserved access in the cell. If no dynamic CLA is available for the mobile node, this is rejected through a Location update Reply. On the contrary, if an available CLA is found the relevant registration state is created and a Location update reply, carrying the mobile node's new CLA, is sent to inform the mobile node of the successful location update. In addition, a Location update message for the mobile node's default cell is sent to update its default state. This will carry the new mobile node's CLA and its destination LA will be the mobile node's DLA. 3 If the mobile node receives a successful Location Update Reply it will store the advertised new CLA. If the registration is not successful the mobile node can wait for a while to try again. Either an undetermined number or a finite number of attempts before the mobile node's automatic switching-off can be made. 4 If the location update is successful a location update message carrying the mobile node's new CLA will arrive at the mobile node's default cell and update the mobile node's default state. MOBILE NODE MOVING IN A FOREIGN LINK 1 The mobile node moving to the new cell sends a Location update message, carrying the mobile node's home link identifier, the mobile node's reserved LA and the mobile node's DLA, to the new AP. 2 When the Location update message arrives at the new AP the mobile node is recognized as not belonging to the link. If no dynamic CLA is available for the mobile node, this is rejected through a Location update Reply. On the contrary, if an available CLA is found the relevant registration state is created and a Location update reply, carrying the mobile node's new CLA, is sent to inform the mobile node of the successful location update. In a IPv6 link Inzerilli [Page 50] INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001 the mobile node's default state could be stored in the new cell. In this case the new AP updates it directly. Otherwise, a Location update message is sent to the mobile node's default cell to update its default state. This will carry the new mobile node's CLA and its destination LA will be the mobile node's DLA. If the mobile node is moving in a IPv4 link, a Location update message is sent to the mobile node's foreign agent to update its default state in the foreign agent's Visitor Address Resolution Table. 3 If the mobile node receives a successful Location Update Reply it stores the advertised new CLA. If the registration is not successful the mobile node can wait for a while to try again. Either an undetermined number or a finite number of attempts before the mobile node's automatic switching-off can be made. 4 In a IPv6 link, if the location update is successful a Location update message carrying the mobile node's new CLA will arrive at the mobile node's default cell and update the mobile node's default state. In a IPv4 link, if the location update is successful a location update message carrying the mobile node's new CLA will arrive at the mobile node's foreign agent and update the mobile node's default state in the foreign agent's Visitor Address Resolution table. 5.6. Handovers and Error Recovery SIMPLE makes a distinction between a simple location update, which involves idle mobile nodes only, from a handover procedure, where particular measures have to be taken to reduce packet loss and delay during a move of an active mobile node to a new cell. Different handover strategies can be used advantageously depending on the characteristics of the wireless interface the mobile node is provided with. In particular those technologies allowing a mobile node to keep multiple associations with many APs simultaneously can reach better performances. In the following section two alternative approaches for handovers are described to consider both multiple- association-capable mobile nodes and non-multiple-association-capable mobile nodes. In order to improve the performances of a handover with respect to a simple location update some extra signaling is needed. In fact, when a mobile node moves to a new cell while communicating with other Internet nodes on the link, the mobile node should inform them of its new CLA as soon as possible. Otherwise, packets will continue to be Inzerilli [Page 51] INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001 sent to the old CLA and will be lost till the IP layer detects the mobile node's unreachability. In a IPv6 link a mobile node after a move can send an Unsolicited Neighbor Discovery Advertisement message to each Internet node it is communicating with. The same thing can be done with Gratuitous ARP messages in a IPv4 link. We can substantially reduce packet loss with this measure. However, some packets on the flight during the mobile node's movement will not be routed correctly altogether. To further reduce packet loss can a mobile node, after a movement, create a forwarding state in the old AP which is used to divert all packets for the mobile node which arrive at the old cell to the new one. This could be done by the new AP immediately after the assignment of the new CLA by sending a Forwarding Request message to the old AP, carrying the mobile node's new CLA, the mobile node's old CLA, a forwarding time value (FWD_TIME) to initialize a timer to create a forwarding state in the AP's RR. The strategy presented above is the forwarding strategy. Optionally, if the physical layer of the mobile node's wireless interface, which monitors the quality of the signal in the channel, can tell the upper layers that a re-association attempt will be made soon, the mobile node can send a Buffering Request message to the old AP before making the move in order to have a copy of each packet relayed in the wireless channel for it buffered in the old AP and waiting to be forwarded to the new mobile node's CLA on a Forward Request arrival. This message carries a BUFF_TIME value to initialize a buffering soft state in the old AP. With this additional measure the handover uses a buffering and forwarding strategy rather than a simple forwarding. It can happen that a Buffering Request is not followed by a handover because the degradation of the communication quality is only transient. If this is the case at the expiration of the buffering state, all buffered copies will be released in a single burst into the wireless channel and the buffering state will be turned into a registration state again. The buffering followed by the flushing of packets will have served as an error recovery technique. It is possible to express a buffering or a forwarding state for a CLA, assigning a code to the Available-CLA and Handover-in-progress bits in the entry pointed by the CLA. As a consequence we have the following meaning for the two-bit codes: Inzerilli [Page 52] INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001 AH | MEANING | ACTION ----|----------------------|--------------------------------------- 00 | CLA not assigned | on a packet arrival throw away packet | | 10 | registration state | on a packet arrival relay packet in | | the wireless channel 11 | buffering state | on a packet arrival relay packet in | | the wireless channel and store a copy 01 | forwarding state | on a packet arrival send packet to | | the new CLA only Tab. 1 - Routing Register state coding 5.6.1. Forwarding strategy for handovers A handover with a forwarding strategy can be used in those mobile nodes provided with a wireless interface which enables keeping multiple associations with many APs at a time. It would proceed as follows, considering the three cases of a mobile node entering its reserved cell, not entering its reserved cell but moving in its home link, and moving in a foreign link: MOBILE NODE ENTERING ITS RESERVED CELL 1 The mobile node moving to the new cell sends a Handover Request message, carrying the mobile node's home link identifier, the mobile node's reserved LA, the mobile node's DLA and the mobile node's old CLA (that held in the old cell) to the new AP. This is done while receiving from the old AP. As the mobile node cannot be rejected from the cell, its CLA can be immediately set to its reserved LA, which must be the same as its DLA. The mobile node can then wait for a confirmation in a Handover Reply. 2 When the Handover Request message arrives at the new AP the mobile node is recognized as having a reserved access in the cell. The advertised reserved LA and the advertised DLA must be equal. This consistency check can be used to detect mobile node's malfunctioning. The new AP creates a registration state for the mobile node in the entry pointed by the mobile node's reserved LA and refreshes the mobile node's default state in the same entry. It then sends a Handover Reply, carrying the mobile node's new CLA, to the mobile node and a Forwarding Request to the mobile node's old AP, which carries a FWD_TIME parameter and the mobile node's new CLA and uses the mobile node's old CLA as destination LA. 3 When the mobile node receives the Handover Reply it checks the Inzerilli [Page 53] INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001 advertised new CLA, which must correspond to the mobile node's reserved LA. This consistency check can be used to detect AP's malfunctioning. It then sends an unsolicited neighbor discovery message (if it is in a IPv6 link) or a gratuitous ARP (if it is in a IPv4 link) to all the Internet nodes on the link it is communicating with. 4 When the Forwarding Request arrives at the old AP, a forwarding state for the mobile node's old CLA is created. The entry of the RR pointed by the mobile node's old CLA is set to the mobile node's new CLA. The CLA timer and the Handover-in-progress bit and the Available-CLA bit of the entry in the RR pointed by the mobile node's old CLA are set to FWD_TIME, 1 and 0 respectively. 5 Each Internet node communicating with the mobile node will update its cache on the unsolicited ND advertisement message or gratuitous ARP arrival. MOBILE NODE NOT ENTERING ITS RESERVED CELL BUT MOVING IN ITS HOME LINK 1 The mobile node moving to the new cell sends a Handover Request message, carrying the mobile node's home link identifier, the mobile node's reserved LA, the mobile node's DLA and the mobile node's old CLA to the new AP. This is done while receiving from the old AP. 2 When the Handover Request message arrives at the new AP the mobile node is recognized as belonging to the link but not having a reserved access in the cell. If no dynamic CLA is available for the mobile node, this is rejected through a Handover Reply. On the contrary, if an available CLA is found the relevant registration state is created and a Handover Reply, carrying the mobile node's new CLA, is sent to inform the mobile node of the successful handover. In addition, a Location update message for the mobile node default cell is sent to update its default state. This will carry the new mobile node's CLA and its destination LA will be the mobile node's DLA. In addition, a Forwarding Request is sent to the mobile node's old AP, which carries a FWD_TIME parameter and the mobile node's new CLA and uses the mobile node's old CLA as destination LA. 3 If the mobile node receives a successful Handover Reply it will store the advertised new CLA. It will then send an unsolicited neighbor discovery message (if it is in a IPv6 link) or a gratuitous ARP (if it is in a IPv4 link) to all the Internet nodes on the link it is communicating with. If the registration is not successful the mobile node can wait for a while to try again. Either an undetermined number or a finite number of attempts before the mobile node's automatic switching-off can be made. 4 If the handover is successful a Handover Reply message, carrying Inzerilli [Page 54] INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001 the mobile node's new CLA will arrive at the mobile node's default cell and update the mobile node's default state. 5 If the handover is successful, when the Forwarding Request arrives at the old AP, a forwarding state for the mobile node's old CLA is created. The entry of the RR pointed by the mobile node's old CLA is set to the mobile node's new CLA. The CLA timer, the Handover-in- progress bit and the Available-CLA bit of the entry in the RR pointed by the mobile node's old CLA are set to FWD_TIME, 1 and 0 respectively. 6 If the handover is successful, each Internet node communicating with the mobile node will update its cache on the unsolicited ND advertisement message or gratuitous ARP arrival. MOBILE NODE MOVING IN A FOREIGN LINK 1 The mobile node moving to the new cell sends a Handover Request message, carrying the mobile node's home link identifier, the mobile node's reserved LA, the mobile node's DLA and the mobile node's old CLA to the new AP. This is done while receiving from the old AP. 2 When the Handover request message arrives at the new AP the mobile node is recognized as not belonging to the link. If no dynamic CLA is available for the mobile node, this is rejected through a Handover Reply. On the contrary, if an available CLA is found the relevant registration state is created and a Handover reply, carrying the mobile node's new CLA, is sent to inform the mobile node of the successful handover. In a IPv6 link the mobile node's default state could be stored in the new cell. In this case, the new AP updates it directly. Otherwise, a Location update message is sent to the mobile node's default cell to update its default state. This will carry the new mobile node's CLA and its destination LA will be the mobile node's DLA. If the mobile node is moving in a IPv4 foreign link, a Location update message is sent to the mobile node's foreign agent to update its default state in the foreign agent's Visitor Address Resolution Table. In addition, a Forwarding Request is sent to the mobile node's old AP, which carries a FWD_TIME parameter and the mobile node's new CLA and uses the mobile node's old CLA as destination LA. 3 If the mobile node receives a successful Handover Reply it stores the advertised new CLA. Inzerilli [Page 55] INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001 MN New AP Old AP Default AP Peer node | | | | | |(Home Link Identifier)| | | | | (Reserved LA) | | | | | (Default LA) | | | | | (old Current LA) | | | | |--------------------->| | | | | | | | | | | | | | | (Current LA) | | | | |<---------------------| (Current LA) | | | |------------------------------>| | | | | | | | | (FWD_TIME) | | | | | (Current LA) | | | | |-------------->| | | | | | | | | (Unsolicited Neighbor Discovery) | | |---------------------------------------------------------------->| | | | | | Fig. 4 - Handoff in a foreign link with successful registration If the mobile node is in a IPv6 link, it will then send an unsolicited neighbor discovery message to all the Internet nodes on the link it is communicating with. If the registration is not successful the mobile node can wait for a while to try again. Either an undetermined number or a finite number of attempts before the mobile node's automatic switching-off can be made. 4 In a IPv6 link, if the location update is successful, a location update message carrying the mobile node's new CLA will arrive at the mobile node's default cell and update the mobile node's default state. In a IPv4 link, if the location update is successful, a location update message carrying the mobile node's new CLA will arrive at the mobile node's foreign agent and update the mobile node's default state in the foreign agent's Visitor Address Resolution table. 5 If the handover is successful, when the Forwarding Request arrives at the old AP, a forwarding state for the mobile node's old CLA is created. The entry of the RR pointed by the mobile node's old CLA is set to the mobile node's new CLA. The CLA timer, the Handover-in- progress bit and the Available-CLA bit of the entry in the RR pointed by the mobile node's old CLA are set to FWD_TIME, 1 and 0 respectively. 6 If the handover is successful, each Internet node communicating with the mobile node will update its cache on the unsolicited ND advertisement message (this is not done in IPv4 foreign links). Inzerilli [Page 56] INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001 5.6.2. Buffering and forwarding strategy for handovers and error recovery A handover strategy with buffering and forwarding could be used in those mobile nodes provided with a wireless interface which enables keeping only a single association with an AP at a time. It exploits a separate error recovery technique, which takes place immediately before. The signaling associated with the error recovery consists of a single message which should be sent by the mobile node when communication quality drops below a certain threshold and could not be followed by a handover. The events associated with this procedure are the following: 1 The mobile node is informed by the underlying access technology of a drop in the communication quality. This could be ascribed to a movement to a new cell or could be just a transient degradation of the communication. In any case the mobile node sends a Buffering Request to the serving AP, carrying a BUFF_TIME parameter. 2 On this message arrival the AP will turn the registration state associated to the mobile node's CLA into a buffering state by setting the Handover-in-progress bit and the CLA timer to 1 and BUFF_TIME respectively. This will cause the AP to store a copy of all subsequent packets which are relayed into the channel for the mobile node till the buffering state is in place. Two cases are then possible: 2.1 if a Forwarding Request messages arrives at the AP before the expiration of the buffering state, all buffered packets will be forwarded to the mobile node's new CLA together with all subsequent packets arriving at the AP and for the mobile node till the forwarding state is place. 2.1 If the buffering state expires before a Forwarding Request reaches the AP, the buffered packets will be released into the channel in a single burst and the buffering state will be turned in a registration state. A handover using a buffering and forwarding strategy will proceed similarly as before with the only difference the a Forwarding request arriving at the old AP will cause some buffered packets to be forwarded to the new mobile node's CLA. Below are reported only the differences with respect to the previous handover scheme, considering again the three cases of a mobile node entering its reserved cell, not entering its reserved cell but moving in its home link, and moving in a foreign link: Inzerilli [Page 57] INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001 MOBILE NODE ENTERING ITS RESERVED CELL 4 When the Forwarding Request arrives at the old AP, a forwarding state for the mobile node's old CLA is created. The entry of the RR pointed by the mobile node's old CLA is set to the mobile node's new CLA. The CLA timer and the Available-CLA bit of the entry in the RR pointed by the mobile node's old CLA are set to FWD_TIME and 0 respectively. Any buffered packets destined to the mobile node's old CLA will have its destination LA overwritten with the mobile node's new CLA and sent. The old AP will have buffered packets only if the Forwarding Request arrives before the expiration of the buffering state. EITHER MOBILE NODE NOT ENTERING ITS RESERVED CELL BUT MOVING IN ITS HOME LINK OR MOBILE NODE MOVING IN A FOREIGN LINK 5 If the handover is successful, when the Forwarding Request arrives at the old AP, a forwarding state for the mobile node's old CLA is created. The entry of the RR pointed by the mobile node's old CLA is set to the mobile node's new CLA. The CLA timer and the Available-CLA bit of the entry in the RR pointed by the mobile node's old CLA are set to FWD_TIME and 0 respectively. Any buffered packets destined to the mobile node's old CLA will have its destination LA overwritten with the mobile node's new CLA and sent. . The old AP will have buffered packets only if the Forwarding Request arrives before the expiration of the buffering state. 6. Mobile IPv6 and Mobile IP non-standard routers' operation 6.1. Operation of home agents in IPv4 and IPv6 links Home agents are non-standard IP routers. They are used to forward IP datagrams destined to a mobile node and arriving at its home link to the mobile node current link when this is "away from home" through IP tunneling. In other words, home agents enables mobile node roaming out of their home link. They are fundamental devices for the operation of both Mobile IP and Mobile IPv6. Home agents must be able to intercept all datagrams destined to mobile nodes when these are away from home. This is done by allowing home agents to work as proxies ([7,12]) for them. Inzerilli [Page 58] INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001 When a mobile node away from home registers to a home agent in its home link through Mobile IP or Mobile IPv6, the home agent must be able to store an address resolution entry (mobile node's IP home address, home agent's link-layer address) in the caches of the nodes on the mobile node's home link. This is done by broadcasting suitable signaling messages to the whole link, repeatedly for reliability reasons. In addition, each time a node on the link broadcasts a request for the mobile node's link-layer address, the home agent will reply for it providing the home agent's link-layer address. These measures guarantee the home agent's intercepting all datagrams destined to mobile node's and are implemented through gratuitous ARP ([13]) and proxy ARP ([12]) in IPv4 links, whereas, through Neighbor Discovery ([7]) in IPv6 links. SIMPLE links use default states to allow interception of datagrams by home agents without broadcasting signaling messages and using existing ARP or Neighbor Discovery signaling. The following actions are taken in a SIMPLE link to allow a home agent to intercept datagrams destined to a mobile node's registered to it while this is away from home: - On a remote mobile node's registration, a home agent will not broadcast a gratuitous ARP message to the whole link but will send a single SIMPLE Location Update message, carrying its static LA as the mobile node's CLA, to the mobile node's default cell, using the mobile node's DLA (last two bytes of its IP home address) as the message's destination LA. - The home agent will have to send Location Refresh messages to the mobile node's default cell regularly all the time the mobile node's mobility binding survives in the home agent binding cache. Each refreshment message will be sent every REG_TIME seconds. All nodes on the mobile node's home link when sending a datagram destined to the mobile node whose CLA is not known will send a single ARP or Neighbor Discovery request (no broadcast is needed) to the mobile node's DLA, this will be intercepted in the mobile node's default cell and diverted to the Mobile node's home agent, using the home agent's static LA, stored in the default state as the packet's new destination LA. The home agent will reply with a proxy ARP or proxy Neighbor Discovery message. 6.2. Operation of foreign agents in IPv4 links Foreign agents are non-standard IP routers used in Mobile IP. They Inzerilli [Page 59] INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001 intercept packets for visiting mobile node's and delivers them to the destination mobile nodes through link-layer mechanisms. In a SIMPLE link all foreign agents have a Visitor Address Resolution Table where SIMPLE default states are centralized. The entries of this table have the following format: [visiting mobile node's IP home address, mobile node's CLA] They are created on foreign mobile node's registrations to the link and need to be regularly refreshed through Location Refresh messages by mobile nodes' current cells. A SIMPLE link can have more than a foreign agent. When multiple foreign agents are present in a SIMPLE link, APs have to be divided into groups, and each group assigned to a foreign agent. A set of APs sharing the same k-bit prefix in their APN could be assigned a same foreign agent. 7. Considerations on SIMPLE SIMPLE is a protocol that provides mobile nodes with intra-domain mobility both in the home link and in foreign links, either IPv6 or IPv4. It is then intended to enhance performances of fast-moving mobile nodes during handovers, implementing local link-layer location updates, and to reduce the impact of mobility signaling on the internet by limiting it to the SIMPLE link. A couple of strategies for facing intermittent connectivity during handovers, one of them coupled with an error recovery technique, were discussed. The forwarding strategy exploits multiple-association capability which some wireless interfaces provides for mobile nodes. When such a feature is not available, the forwarding strategy can be strengthen with preventive buffering requests. Buffering request messages, however, can be triggered only if a feedback from the underlying access technology to SIMPLE is provided. The physical layer should trigger a buffering request, each time the quality of the transmission drops under a certain threshold before a re-association with a new AP is made by the wireless interface. However, communication degradation could be just momentary at some times and could not correspond to a move to a new cell. In this case buffered packets will be released into the wireless channel when their buffering state expire. This preventive buffering even when a handover does not follow can improve channel reliability as it correspond to a retransmission of a group of packets during times of Inzerilli [Page 60] INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001 "bad channel". In addition to intra-domain mobility support and performance enhancing during handovers, SIMPLE provides a facility to use IPv6 Stateless Address autoconfiguration ([10]) in any link, no matter what topology has the whole link. This could be in fact very large, containing up to 65536 Internet nodes and with many switching levels. IPv6 Stateless Address Autoconfiguration can be applied on any SIMPLE link thanks to a facility offered by one of the possible SIMPLE algorithms. These calculate a unique link identifier from which the mobile node can obtain a dynamic IPv6 care-of address. In SIMPLE links broadcast of address resolution messages is not needed, as a mobile node's link-layer address is always stored in a well known location, which is independent of the link topology. This is the mobile node's default state and the pointer to this state is simply derivable from the IP address (either home address or care-of address) the mobile node is using in the link, as it correspond just to the last two bytes of it. Home agents exploit default states to avoid broadcasting ND or ARP messages as well for intercepting packets destined to mobile nodes away from home. Repeated broadcasting of signaling a very large link could be very inefficient, SIMPLE allows avoiding it. SIMPLE is a scalable protocol as its performances do not degrade significantly in very big links, with many Internet nodes and many switching levels. The following arguments support this statement: - SIMPLE guarantees efficient packet forwarding by means of an auto-routing algorithm on the distribution system. The fact that an implicit end-to-end forwarding rule inside the link is adopted makes it possible to keep routing information only in APs. In fact, these are the only points where routing information is needed. The other nodes need simply to know their switching number and their neighboring link nodes'. Local configuration of nodes makes the routing algorithm and its performances independent of the size of the link. - SIMPLE guarantees compressed and small routing databases in the APs. RRs are fixed-size and very small and they account only for the mobile nodes having a default or a registration state in the AP and not in general for all the mobile nodes in the SIMPLE link. Their number can grow indeterminately, without changing the size of any RR in the link. - As RRs are fixed-size and single-lookup tables, lookups are fixed-cost operations that are independent of the RR size. This could be particularly efficient with respect to other lookup techniques which need routing table scanning. If N is the number of the entries of a table, these latter have a complexity of O(N) or Inzerilli [Page 61] INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001 O(log(N)) when a exhaustive research or a binary research is applied. - Signaling load on the distribution system is low as mainly signaling between access points and their served mobile nodes is needed. Signaling that is propagated over the distribution system consists of some location updates and location refresh messages which are sent from current cells to default cells and what is needed to implement a DLA research, which is performed during some link-layer registrations. - In addition, SIMPLE signaling is processed only by APs and mobile nodes, intermediate nodes on the distribution system are passive forwarders, which do no make distinction between signaling messages an data packets. - Signaling load on an AP cannot exceed a well defined limit as it is proportional to the number of mobile nodes registered at the AP and of those using the cell as default cell, which is limited by the choice of the APN length. Other favorable features of SIMPLE are that it has a vast range of applicability, as a SIMPLE logical link can be built on a number of physical topologies, tree-like and meshed too, as it exploits possible direct links between peer nodes. These are used in the routing algorithm as shortcuts, to minimize delay and network resources utilization. Moreover, SIMPLE signaling packets are very small (4 bytes of header plus a few parameters vs. 20 bytes for an IPv4 header or 40 bytes for an IPv6 header). This reduces the probability of being corrupted while crossing a wireless channel and the bandwidth utilization of signaling. Finally, SIMPLE provides multiple-gateway access to a link Preventing a single gateway from being a single point of failure for many Internet nodes and from becoming a bottleneck in case of heavy load. 8. ACKNOWLEDGMENTS Special thanks to Prof. Francesco Delli Priscoli for making it possible to develop this work from initial ideas started with a thesis and for his constant support. Thanks also to Paolo Di Lorenzo and Guido Paolucci for their past and present help in defining important aspects of the protocol operation and for their assistance in writing this document. Inzerilli [Page 62] INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001 Finally, thanks to the WINE Consortium, within which the protocol was studied and developed benefiting from an intense and stimulating debate on mobility. 9. Security Considerations This document deals with no security issues. This memo is focused on interworking of various Internet protocols in particular without examining security aspects. In a future version some security aspects could be dealt with as generally needed with wireless access. APPENDIX A: SIMPLE packet format 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | APN | LMI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 16 - k bits k bits Figure A - SIMPLE Current Link-Layer Address (CLA) APN Prefix of a SIMPLE Link-Layer address (LA) identifying the access point where the mobile node is being served. LMI Suffix of an LA, identifying a mobile node that is being served at the AP identified by the APN. Control info Field specifying options regarding data or signaling packet. Option bit formats are detailed below. Destination LA SIMPLE specific two-bytes address, composed by a prefix (APN) and a suffix (LMI), identifying the destination node. Inzerilli [Page 63] INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Control info | Destination LA | Hop Limit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| | | | Payload | | ............................ | Figure B - SIMPLE packet Hop Limit Time to Live. It is incremented at each hop from a link node to another. When it arrives at 255, the packet is discarded. In order to limit the number of hops of a packet to N, when the packet is sent this field is initialized to 255-N. Payload Variable-length field, used to contain an IP datagram or an ARP message as for SIMPLE data packets or parameters as for SIMPLE signaling messages. 0 0 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ |0 0 0|R|R|R|R|D| |0 0 1| CODE | +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ Data Header Signaling Header Figure C - Control info field R Reserved for future use. D Default delivery flag. CODE Bits identifying the type of signaling message. Inzerilli [Page 64] INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001 APPENDIX B: Routing Registers (RRs) format A H CLA New CLA CLA timer DLA timer +-+-+--------+--------+--------------+--------------+ ^ 000000 | | | | | | | | +-+-+--------+--------+--------------+--------------+ | 000001 | | | | | | | | Reserved +-+-+--------+--------+--------------+--------------+ | LMIs 000010 | | | | | | | |(RESV_LMI) +-+-+--------+--------+--------------+--------------+ | 000011 | | | | | | | | +-+-+--------+--------+--------------+--------------+ v . . . . . ^ . . . . . | . . . . . | +-+-+--------+--------+--------------+--------------+ | 111110 | | | | | | | | Dynamic +-+-+--------+--------+--------------+--------------+ | LMIs 111111 | | | | | | | | +-+-+--------+--------+--------------+--------------+ v bits 1 1 16 16 64 64 APN 10 bits, LMIs 6 bits (up to 64 mobile nodes) Figure D - Routing Register A Available CLA bit. When set, it means that the relevant CLA is being used by a mobile node in the cell. H Handover in progress bit. It is used in combination with the A bit to signal a buffering of a forwarding state for the relevant CLA CLA Two-byte address identifying the current location of the mobile node in the link. New CLA Two-Byte address identifying the new address assigned to a mobile host after a handoff and used to forward packets. Inzerilli [Page 65] INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001 CLA timer Current Link-layer Address timer. A registration state cell MUST be periodically refreshed every REFR_REG_TIME. The CLA timer is set to MAX_REF_TIME > REFR_REG_TIME after each refreshment. DLA timer Default Link-Layer Address timer. A default or location state needs to be regularly refreshed by the relevant mobile node's current AP every REFR_REG_TIME. The CLA timer is set to MAX_DEF_TIME > REFR_REG_TIME after each refreshment. Reserved LMIs Identifier of a mobile node having a reserved link-layer Address (RLA) in a cell. It corresponds to the RLA without the APN prefix. The first RESV_NUM LMIs in a cell are reserved LMIs. Dynamic LMIs Identifier that can be assigned to any mobile node without a reserved link-layer Address (RLA) in a cell. The APN prefix followed by the assigned LMI corresponds to the CLA assigned to the mobile node. The last (16-RESV_NUM) LMIs in a cell can be assigned to any mobile node without an RLA in the cell. References [1] Tiziano Inzerilli, "SIMPLE, a Scalable Intra-domain Mobility Protocol using Local Encapsulation for Mobile IPv6 and Mobile IP", IST Mobile Summit 2000, Galway (Ireland). [2] "IP Mobility Support" - C. Perkins, October 1996 - RFC 2002. [3] "Mobility Support in IPv6" - D. B. Johnson, C. Perkins - 10 February 2000, Internet Draft. [4] "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" - Jim Bound and Charles Perkins - February 1999. Work in progress. [5] "Internet Protocol version 6 (IPv6) specification" - Stephen E. Deering and Robert M. Hinden - RFC 2460, December 1998 [6] "Dynamic Host Configuration Protocol" - R. Droms - RFC (Draft Standard) 2131, IETF, March 1997. [7] "Neighbor Discovery for IP version 6 (IPv6)" - Thomas Narten, Erik Nordmark, and William Allen Simpson - RFC 2461, December1998. [8] "Reserved IPv6 subnet anycastaddresses" - David B. Johnson and Inzerilli [Page 66] INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001 Stephen E. Deering -RFC 2526, March 1999 [9] "An Ethernet address resolution protocol: Or converting network protocol addresses to 48.bit Ethernet addresses for transmission on Ethernet hardware" - David C. Plummer - RFC 826, November 1982. [10] "IPv6 stateless address Autoconfiguration" - Susan Thomson and Thomas Narten - RFC 2462, December 1998. [11] "Network Time Protocols (Version 3): Specification, Implementation and Analysis" - D.Mills - March 1992, RFC 1305 [12] "Ipv6 over Non-Broadcast Multiple Access (NBMA) Networks", G. Armitage, P. Schulter, M. Jork, G. Harter, January 1999, RFC 2491. [13] Postel, J., "Multi-LAN Address Resolution", RFC 925, October 1984. [14] W. Richard Stevens. TCP/IP Illustrated, Volume 1: The Protocols. Addison-Wesley, Reading, Massachusetts, 1994. [15] "IPv6 version 6 Addressing Architecture",R. Hinden, S. Deering, July 1998, RFC 2373. Authors' Addresses Tiziano Inzerilli Dipartimento di Informatica e Sistemistica, Universita' di Roma "La Sapienza" Via Eudossiana 18, 00184 Rome, Italy Phone: +39-3333070111 fax : +39-0686203163 email: inzerilli@tiscalinet.it Inzerilli Expires June 2001 [Page 67]