- 1 - Network Working Group C. Perkins Request for Comments: DRAFT T.J. Watson Research Center, IBM Corp. Y. Rekhter T.J. Watson Research Center, IBM Corp. January 1993 Support for Mobility with Connectionless Network Layer Protocols (Transport Layer Transparency) Abstract This memo describes an approach to transparent mobile internetworking that allows hosts to move around an internet in a fashion transparent to transport layer protocols, assuming that these transport layer protocols run over a connectionless network layer protocol. Status of this Memo This document describes an approach to transparent mobile internetworking. This RFC specifies an IAB standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. Distribution of this document is unlimited. This document is an Internet Draft. 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. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress". Topological Model An internet can be modeled as a collection of Layer 2 (Link Layer) subnetworks; each subnetwork has a set of hosts attached to it; the subnetworks are interconnected via network layer routers. Expiration Date July 1993 [Page 1] - 2 - A segment of an internet is defined as a connected (at the network layer) subset of the internet's topology. A segment is connected to the rest of an internet via one or more attachment points. A mobile segment is defined as a segment whose attachment point(s) may change over time. In general, the average frequency with which the attachment point(s) of a mobile segment may change is expected to be higher than the average frequency with which transport connections of the hosts, where at least one of the host is within a mobile segment, are established and terminated. However, any segment of an internet may be viewed as a mobile segment, even if its attachment point(s) are relatively static. This proposal describes a scheme to support mobile segments in internets that use a connectionless network layer protocol (e.g. IP, [9] CLNP [6], IPX [10]) in such a way, as to make changes in the attachment point(s) of a mobile segment transparent to the transport layer protocols (e.g. TCP, UDP, TP4, CLTP) running between any pair of hosts, where at least one of the hosts is within a mobile segment. Transparent means that changing a segment's attachment points might produce a pause, but no other observable effect on the transport connection between a pair of hosts that communicate across the mobile segment boundaries. Since a mobile host represents a degenerate case of a mobile segment, the scheme describes in this proposal supports host mobility. Since a mobile customer premises network (such as a ship, airplane, or train) is a mobile segment, the scheme described in this proposal supports mobile customer premises networks. 2 Implications on the Network Layer This proposal is designed to operate in conjunction with a connectionless network layer protocol, where each packet (i.e, Network Protocol Data Unit or NPDU) carries both source and destination addresses. The proposal places no additional restriction on the format of the addresses assigned to hosts. The proposed scheme works with either unidirectional or bidirectional traffic between hosts. The proposed scheme may benefit from the capability of a network layer protocol to support an error message indicating inability to further forward a packet -- for the rest of this document we'll refer to such an error message as an Error Report Protocol Data Unit (ER PDU) indicating Destination Unreachable. It is assumed that the the payload carried by such a PDU includes both the Home and the Expiration Date July 1993 [Page 2] - 3 - Forwarding destination address of the packet that cannot be forwarded (see Section 3 for the discussion of Home and Forwarding addresses). The proposed scheme may benefit from the capability of a network layer protocol to support an error message indicating changes in the attachment point(s) of a mobile segment. For the rest of this document we'll refer to such an error message as an Error Report Protocol Data Unit (ER PDU), which is to carry updated Host Location Information -- including both the Home and Forwarding address of a host. Note that while none of the existing network layer protocols support such messages, adding such functionality to any of the existing network layer protocols should not viewed as a significant problem. The mechanisms employed by the proposal are independent of a particular Link Layer technology. Thus, the proposal is equally applicable to "wireless" (e.g. infra-red or radio-frequency) and to "wired" (e.g. Ethernet) Link Layers. The proposal does not preclude other means of supporting mobility, e.g, supporting mobility at the Link Layer (providing Network Layer transparency). To the contrary, the proposal may be used to complement such techniques. 3 Home vs Forwarding addresses Every host within a mobile segment that is expected to communicate with hosts outside the segment, has two network layer addresses associated with it. This is in contrast with hosts in conventional, non-mobile segments that need to have only one network layer address. The first address, called the Forwarding address, carries topological significance. Thus it may change as the mobile segment to which the host belongs changes its attachment point(s), without affecting the Transport layer protocols. The second address, called the Home address, is the address that doesn't change as the mobile segment to which the host belongs changes its attachment point(s). The transport layer can unambiguously identify a peer host by the location independent Home address of the peer. Any name-to-address mapping should return a host's Home address. The proposal uses the Home address of a host to obtain information about the host's Forwarding address. If mobile segments are not nested then each host within a mobile segment has only one Forwarding address; the case of nested mobile is Expiration Date July 1993 [Page 3] - 4 - described in Section 6. 4 Overview of forwarding This proposal assumes that in general, forwarding a packet to a host within a mobile segment cannot be accomplished solely by using either the Home or Forwarding address of the host. Rather, forwarding a packet from a host outside a mobile segment to a host within the mobile segment may be modeled as a three phase process, where during each phase either the Home or the Forwarding address is used for forwarding. In the first phase a packet (originated by a source host) is forwarded based on the destination host's Home address. The first phase results in the packet being delivered to an entity that can obtain information about the destination host's Forwarding address This information is obtained using the destination host's Home address. In the second phase the destination host's Home address is "hidden" and the packet is forwarded solely based on the Forwarding address of the destination host. At the completion of the second phase the packet gets delivered to an entity that can complete the forwarding based solely on the Home address of the destination host. The third phase consists of forwarding from that entity to the destination host. Forwarding during the third phase is done solely based on the Home address of the destination host. The relative fractions of a complete path from a source to a destination that are spawned by each of the three phases depends on the location of entities that perform the Readdressing Server (RS) function (for the description of RS see Section 9). To accomplish the three phases of the forwarding the proposal requires that all packets, sent to a host within a mobile segment from a host outside the segment, carry the destination host's Forwarding address at certain points along the path to the host. All such packets will also naturally always contain the destination host's Home address all the way from the source to the destination. Depending on the current attachment point(s) of a mobile segment, entities within the segment (e.g. hosts) may be reachable by hosts outside the segment just by using entities' Home addresses. This situation may be described by saying that the mobile segment is connected to the rest of an internet via its "home" attachment points. By definition, all the attachment points of a non-mobile segment are "home" attachment points. Expiration Date July 1993 [Page 4] - 5 - 5 Re-addressing To accomplish the three-phase forwarding procedure described in Section 4 the proposal introduces the concept of re-addressing. Re- addressing is defined as a capability to hide/expose Home address and to obtain a mapping between a Home address and a Forwarding address. The proposal assumes that re-addressing is performed by an entity that either resides on a host or is situated along the path between a pair of communicating hosts. The proposal suggests the two potential techniques for re-addressing: - use of network layer options - use of network layer encapsulation. Typical examples of the first technique (use of options) is the use of IP Loose Source Routing option or Virtual Internet Protocol (VIP) [2], [3]. The proposal further subdivides the second technique, network layer encapsulation, into: - pure encapsulation/decapsulation, and - compact encapsulation/decapsulation. Pure encapsulation/decapsulation means that a packet (including the network layer header) is encapsulated into another packet by prepending a new network layer header to the original packet; the inner network layer header carries Home addresses, the outer network layer header carries Forwarding addresses. Typical examples of the pure encapsulation are Internet Packet Forwarding Protocol (IPTP) [4], and IPIP [1]. Compact encapsulation/decapsulation differs from pure encapsulation/decapsulation by requiring to carry only source and destination addresses, rather than the whole inner network layer header. Thus, with compact encapsulation/decapsulation an encapsulated packet consists of the network layer header that carries Forwarding addresses, followed by the source and destination Home addresses followed by the network layer payload of the original packet (the packet that was encapsulated). Discussion of the relative merits of each of the techniques mentioned above is outside the scope of this document. Expiration Date July 1993 [Page 5] - 6 - 6 Handling Nested Mobile Segments The proposal supports mobile segments that are nested. Thus, for instance, the proposal supports a mobile customer premises network (e.g. airplane) that has both hosts that are permanently attached to the network (e.g. computers that are permanently part of an airplane), as well as mobile hosts, whose attachment to the network is temporary (e.g. mobile computers carried by the passengers of an airplane). In the former case we have just a single mobile segment (mobile customer premises network), while in the latter case we have two nested mobile segments (the mobile segment that represents a mobile host is nested within the mobile segment that represents the mobile customer premises network). If a mobile segment is nested within another mobile segment(s), then each host within the nested segment has multiple Forwarding address - one per level of nesting. The nesting order of mobile segments imposes an order relation on the set of Forwarding addresses of a host within a nested mobile segment. For example, in the case of a mobile customer premises network that has both permanently attached hosts (to the network), as well as mobile hosts (whose attachment to the network is temporary), the hosts that are permanently attached to the network have only one Forwarding address, while the mobile hosts have two Forwarding addresses. Forwarding to a host that has multiple Forwarding addresses (the host is within several nested mobile segments) may be modeled by the following recursive procedure: - recursion termination: a packet having only one Forwarding address forwarding is handled as described in Section 4 - recursion step: extract the next Forwarding address (as determined by the order relation) and treat it as the Home address, then perform forwarding as described in Section 4 Forwarding to a host that has multiple Forwarding addresses implies that all packets sent to that host carry the host's multiple Forwarding addresses at certain points along the path to the host. The presence of multiple Forwarding addresses implies multiple occurrences of re-addressing. Thus, for example, if the re- addressing is realized via encapsulation/decapsulation, then the original packet may be encapsulated into several envelopes, each corresponding to a particular Forwarding address associated with the destination host. Expiration Date July 1993 [Page 6] - 7 - Since handling of nested mobile segments is inherently recursive, the rest of the proposal describes just the termination case of the recursion -- the case where an internet may contain one or more mobile segments, but these segments are not nested. 7 Cells Fundamental to the proposal is a concept of a "cell". A cell consists of precisely one Re-addressing Server (RS) that serves the cell and one or more hosts and routers served by the RS. The hosts and the routers served by an RS are called Re-addressing Service Clients - RSCs. The proposal requires all the hosts or routers located within a given mobile segment to be within at least one cell. Consequently there is at least one RS that serves hosts and/or routers within a given mobile segment; each such host or router is an RSC. Hosts and routers in non-mobile segments (i.e. stationary hosts) may belong to a cell as well, or may not be in any cell. A single cell may span both a mobile and a non-mobile segment. Thus, some of the RSCs within a single cell may belong to a mobile segment, while other RSCs within the same cell may belong to a non-mobile segment (e.g. a cell may contain both stationary and mobile hosts). By definition an RSC is within its "home" cell, if the RSC is located within a segment that is attached via its home attachment points. As a corollary, any stationary host, if located within a cell, is in its "home" cell. The components of the cell have the following properties: - forwarding packets from the RS destined to its RSCs can be performed by using only the RSCs' Home addresses - if an RSC in a cell is unreachable from the RS of the cell (based on the RSC's Home address), then that RSC cannot be served by the RS and thus, effectively, is not part of the cell - other entities outside a cell (either hosts or routers) shall be able to forward packets destined to the RS of the cell using RS's Home address - packets that cross a cell's boundaries will flow through the RS of the cell - for every RSC within a cell either: Expiration Date July 1993 [Page 7] - 8 - - the RS of the cell should be able to determine whether the cell is the "home" cell for the RSC, or - the RSC should know the cell's RS Home address. The concept of a cell is a logical concept. The physical extents corresponding to cells may spatially overlap, be nested, or be disjoint. Essential to the concept of a cell is the ability to control the scope of the distribution of reachability information about entities within the cell to entities (e.g. routers) outside the cell. Therefore, a cell's boundaries are likely to be congruent to certain routing boundaries, depending upon the realization of the cell (e.g. single host, a Link Layer subnetwork, single OSPF or IS-IS area, a routing domain). The mechanisms for ascertaining whether a RS and a collection of hosts form a cell are specific to the particular realization of the cell. By definition of a cell, if hosts in different cells are expected to communicate with each other, then it is expected that there will be two RSs along the path between these two hosts. The first host and the first RS will be within the same cell, and likewise the second host and the second RS will be within the same cell. Thus, the first phase of the three-phase forwarding (as described in Section 4) covers the portion of the path from the originating host to the RS of the cell the originating host is in; the second phase covers the portion of the path from the RS of the cell in which the source host is located to the RS of the cell in which the destination host is located; the third phase covers the portion of the path from the RS of the cell in which the destination host is located to the destination host. Supporting communication between a host within a mobile segment and a host within a non-mobile segment, when the latter is not in any cell, may result in potentially suboptimal routing of packets from the host in the non-mobile segment to the host in the mobile segment (i.e., triangular routing). Handling nested mobile segments is accomplished by treating an RS that serves a cell covering the inner segment as a Re-addressing Server Client (see Section 8) of the cell that covers the outer segment. Expiration Date July 1993 [Page 8] - 9 - 8 Re-addressing Server Clients (RSCs) By definition, a host or a router located within a cell is called a Re-addressing Server Client -- abbreviated RSC. For each RSC within a cell the RSC's Forwarding address is set to the Home address of the cell's RS. The RSC's Forwarding address establishes an association between an RSC and an RS. The explicit association may be maintained either at the RS or at the RSC. Specifically, if (for a given RSC in a cell) an RS of the cell can determine whether the cell is the "home" cell for the RSC or not, then the RSC need not know its Forwarding address (which is the RS's Home address). In all other cases an RSC should know the cell's RS Home address (the RSC uses this address as its Forwarding address). The procedures for originating/receiving packets by an RSC are the same as for any host or router and are not described here. Procedures by which an RSC obtains its Home Address(es) are outside the scope of this document. 9 Re-addressing Servers (RSs) To accommodate hosts that are either located within a mobile segment, or communicate with hosts located within a mobile segment, this proposal introduces entities called Re-addressing Servers (RSs). The RS provides RSCs in its cell with a Forwarding address. Use of this address for packet forwarding will cause packets originated by a host outside the cell and destined to an RSC (e.g. host) within the cell to be directed to the RS of the cell; the RS will then forward the (re-addressed) packet to the RSC. An RS maintains a list (possibly empty) of the RSCs within its cell. An RS of a cell maintains a local cache, called Address Mapping Table (AMT), that contains mapping between the Home and Forwarding addresses of the peer hosts (outside the cell) that the RSCs in the cell communicate with. The RS acquires and updates this mapping via several possible mechanisms: - the mapping may be extracted from incoming packets (see Section 12.1) - the mapping may be obtained directly from a Location Directory (LD) Expiration Date July 1993 [Page 9] - 10 - - the mapping may be obtained as a result of receiving an ER PDU indicating Host Location Information - the mapping shall be invalidated when an RS receives an ER PDU indicating Destination Unreachable (if such an ER PDU is supported); receipt of such PDU shall be used as an indication that the entry associated with the Home and Forwarding addresses (as carried in the PDU's payload) is no longer valid and shall be purged from the cache. An RS shall remove an AMT entry associated with a particular Forwarding address as soon as the RS determines that the address mapping is incorrect. A RS may remove a valid AMT entry from its cache at any time. 10 Modes of operations The proposal allows three modes of operations: "fully autonomous", "quasi-autonomous", and "forwarding". In the fully autonomous mode each peer is in a cell, and RSs serving these cells can obtain any mapping between the Forwarding and Home addresses of their RSC peers directly from a LD. In the quasi-autonomous mode each peer is in a cell, but at least one of the RSs serving these cells cannot obtain a mapping between the Forwarding and the Home addresses of their RSC peer directly from the LD; rather the RS obtains this mapping either from the incoming packets, or as a result of receiving ER PDU indicating Host Location Information (see Section 9). In the forwarding mode one of the peers is not inside of any cell. Thus, if an RSC is not in its home cell, then forwarding to that RSC from its peer (that is not inside of any cell), would always involve routing through the Redirection Server (RDS) associated with the RSC. This may yield suboptimal (i.e, triangular) routing. 11 Processing packets forwarded through an RS This section describes handling packets whose destination address is different from the RS's address. Expiration Date July 1993 [Page 10] - 11 - 11.1 Intra-cell forwarding When a RS has to forward a packet, which was originated by one of its clients (RSCs) and is destined to another of its clients (RSCs), the RS just forwards the packet to its destination using normal forwarding procedures. 11.2 Inter-cell forwarding When a RS has to forward a packet, which was originated by one of its clients (RSCs) and is destined to a host that is not a client of the RS, the RS checks its AMT for the presence of an entry whose Home address is equal to the destination address of the packet. If such an entry exists, the RS then tries to determine whether to insert the mapping into the packet. The mapping shall be inserted if the entry indicates that the destination host is not in its home cell (that is, the Forwarding and Home addresses of the entry are different). If the entry indicates that the destination host is in its home cell then the mapping need not be inserted on every packet, but should be inserted each time the packet originator changes cells. That is, if the destination host is in its home cell, and the RS serving that home cell may be presumed to have received current location information (a Forwarding address) for the originating host, the RS may forward the packet without inserting any address mapping. The existence of an AMT entry for the destination host may be taken as an indication that the RS associated with the destination host has current information about the location of the RS's client (the RSC). Such an AMT entry may also include relevant information regarding particular RSCs. If the RS determines that a mapping should be inserted into the outgoing packet according to the information stored in its AMT (as outlined above), then the Home Addresses for both the RSC and the destination host will be remapped to their respective Forwarding Addresses. Otherwise, if no mapping is possible, the RS follows one of the following alternatives: - if the RS can determine that the originating host (the RSC) is in its "home" cell (say, by using pre-configured information), then forward the outgoing packet using normal forwarding procedures; otherwise, - a packet carrying update information to the LD (see Section 14) has to be re-addressed only if the RS can determine that the host originating the packet (the RSC) is not in its home cell; the outgoing packet is re-addressed using the destination Expiration Date July 1993 [Page 11] - 12 - address from the packet as both the Home and the Forwarding address of the destination; the packet also carries the mapping between the RSC's Home address and the RSC's Forwarding address (which is to say, the Home address of the RS itself); otherwise, - if the RS can determine that the originating host (the RSC) is not in its "home" cell, and the destination host is in a cell, then re-address the outgoing packet using the destination address from the packet as both the Home and the Forwarding address of the destination; the packet also carries the mapping between the RSC's Home address and the RSC's Forwarding address (which is to say, the Home address of the RS itself); otherwise, - if the RS can determine that the originating host (the RSC) is not in its "home" cell, and the destination host is outside of any cell, then forward the outgoing packet using normal forwarding procedures; otherwise, - if the RS cannot determine whether the originating host (the RSC) is in its "home" cell or not, the RS forwards the outgoing packet using normal forwarding procedures The above procedure requires an RS to being able to ascertain whether the destination host is within a cell or not. Below are several possible mechanisms that may be used for this determination: - static configuration - an RS may be preconfigured with a list of hosts that are not within any cell; alternatively the list may contain hosts that are known to be within a cell - an RS may assume that the destination host is within a cell; however, receipt of certain type of error messages may be used as an indication that the host is not within a cell (e.g. when using encapsulation the receipt by an RS of ICMP message unreachable indicating Bad Protocol may be used as an indication that the host is not within any cell) A conservative strategy suggests that if none of the above mechanisms are available, the RS should assume that the destination host is not within any cell. A more optimistic approach might only assume that destination hosts are likely to obey existing network layer protocol specifications. Expiration Date July 1993 [Page 12] - 13 - 12 Processing packets addressed to a RS When a RS receives a packet addressed to it, the RS shall check whether the packet contains an address mapping. 12.1 Packets addressed to a RS, containing an address mapping. If a RS can determine that the destination Home Address indicates a RSC served by the RS, the RS extracts the source Home and Forwarding addresses and uses these addresses to update its AMT. If originating host did not have an entry in the AMT, and the RSC is in its home cell, the RS may send a Location Update packet back to the originating host. This will allow the originating host to avoid sending out re-addressed packets to the RS's client (RSC) while the client remains in its home cell, in those cases where no RDS would have otherwise updated the originating host. The RS then performs the address mapping and forwards the re-addressed packet to the RSC. Otherwise (if the host is not within one of the cells the RS belongs to), the RS copies the Home address into the field for the Forwarding address and forwards the packet - presumably to a RDS associated with the Home address (as described in Section 13.1.2). In addition, if the network layer protocol supports an ER PDU indicating Destination Unreachable, then the RS should also send such a PDU to the entity indicated by the source Forwarding address in the packet. The payload of the PDU should contain the destination Home and Forwarding addresses. 12.2 Packets addressed to a RS, not containing any address mapping. These packets will be processed normally. In other words, they will be received for further processing by other protocols running on the RS. 13 Redirection Server (RDS) The purpose of a RDS is to provide (in a conjunction with the Location Directory (LD), see Section 14) a mechanism for forwarding packets that fall into the following two categories: - packets originated by a host outside any cell, or Expiration Date July 1993 [Page 13] - 14 - - packets originated by a host within a cell, whose RS does not have a correct mapping in its AMT for the destination's Home address Each RDS has a pool of network layer addresses to which it claims direct network layer reachability. This may be realized by requiring a RDS to participate in a routing protocol. The pool of addresses will often be expressed as address prefixes, but may be expressed as individual addresses as well. A host that is assigned an address out of the pool is called a Redirection Server Client (RDSC). Thus, this pool of addresses will contain the Home addresses assigned to the RDSCs associated with the RDS. The advertisement of reachability to this pool of Home addresses establishes an association between a RDSC and a RDS. This association is retained as long as the Home address of the RDSC remains unchanged. It is assumed that a RDS can query the Location Directory to obtain mapping between Forwarding and Home addresses of all of its RDSCs. To improve robustness in presence of failures the RDS may be replicated. That is, multiple entities may claim direct network layer reachability to the same pool of network layer addresses. Then a given RSC will be associated not with one, but with multiple RDSs. It is assumed that a RDS is able to query a LD to obtain a valid mapping between a Home address and a Forwarding address of an RDSC associated with the RDS. Despite claiming direct reachability to the associated RDSCs, the RDS may not have single network layer hop connectivity to any of these RDSCs (a RDS and a RDSC may be separated by more than one Network Layer hop). However, by being able to obtain (from the LD) a valid Forwarding address of a RDSC associated with the RDS, and by employing re-addressing, the RDS is capable of relaying packets addressed to these RDSCs as follows. 13.1 Processing incoming packets When a RDS receives a packet addressed to one of its RSCs, the RDS shall determine whether the packet contains an address mapping. 13.1.1 Incoming packets with no address mapping If the Forwarding and Home addresses of the destination are not the same, the RDS re-addresses the packet to the Forwarding address (this address is obtained by querying a LD using destination's Home address) and inserts into the packet an address mapping between the Expiration Date July 1993 [Page 14] - 15 - Forwarding address and the Home address. Then, the RDS forwards the packet (modified or not) for normal routing (the forwarding is done based on the Forwarding address). The RDS may also send a Host Location Information PDU to the source address of the incoming packet. If the source host that originated the incoming packet is not within a cell, then the host will ignore such a PDU. The host will continue to send packets to the RDS. That potentially may result in unnecessary messages indicating Host Location Information being sent to the host. It is assumed that the RDS has mechanisms to detect this situation and avoid such unnecessary transmissions. 13.1.2 Incoming packets containing an address mapping When the RDS receives an incoming packet destined for an RDSC associated with the RDS, the RDS checks whether the packet shows an identity mapping between the Home and Forwarding address for the RDSC. If so, then the RDS assumes that the incoming packet was forwarded to it from a RS which doesn't have the correct mapping for the destination RDSC. The RDS revises the existing address mapping between the two addresses in the packet, to indicate the latest valid information available from the LD. Then, the RDS forwards the revised packet for normal routing. In addition, if the network layer protocol supports an ER PDU indicating Destination Unreachable, then the RDS should also send such a PDU to the entity depicted by the source Forwarding address in the incoming packet. The payload of the PDU should contain the destination's Home and Forwarding addresses. Alternatively the RDS should also send a PDU indicating Host Location Information to the entity indicated by the source Forwarding address of the incoming packet. Care must be taken to avoid sending repeatedly such PDUs to the same entity. 14 Location Directory (LD) The LD keeps track of the valid Forwarding addresses of RSCs. To ensure prompt update of the information maintained by the LD, the RSC shall update the LD each time the RSC changes cells. The mechanisms for determining when a cell switch occurs are specific to the realization of a cell and are outside the scope of this document. Procedures used by the RSC to update the LD may be slightly different based on whether the RSC explicitly maintains its Forwarding address or not (see Section 8). If the RSC explicitly maintains its Expiration Date July 1993 [Page 15] - 16 - Forwarding address, then it is the RSC's responsibility to specify this address, when updating the LD. Otherwise, it is assumed that the RS associated with the RSC can determine whether the RSC is in its "home" cell, and if not, then specify RSC's Forwarding address as part of the re-addressing performed by the RS (see Section 11). The LD should get updates even when the RSC is in its home cell. To reduce the volume of information, the LD may maintain a Forwarding address for a group of hosts whose addresses form a contiguous segment of Network layer addresses by using longest-prefix matching. In other words, the LD may return a Forwarding address for an address whose initial bits match the initial bits of a collection of addresses, and if two matches are possible the LD will select the match which uses the longest initial bit string. In this way, the LD can support a single Forwarding address for a whole collection of addresses, and thus support mobility at the network or subnetwork level of addressing. The LD may employ timeouts to get rid of the stale information. Even if the RSC doesn't move to a new cell, the RSC may periodically send information about its present Forwarding address to the LD. The LD may be either distributed or centralized. To improve robustness the LD may be replicated. 15 Acknowledgements [To be filled later.] Security Considerations Security issues are not discussed in this memo. Appendix A: Possible Cell Realizations This section presents several possible alternatives for realizing the concept of a cell. A.1 Colocated RSC and RS Conceptually, a host capable of re-addressing may be modeled as two co-located logical entities: a RSC (whose behavior is described in Section 8) and a RS (whose behavior is described in Section 9). By Expiration Date July 1993 [Page 16] - 17 - using their Forwarding addresses, a pair of hosts, both performing re-addressing, can communicate with each other in presence of mobility without altering the operation of any entities along the path. A host within a non-mobile segment (e.g. stationary host) wishing to serve as its own RS shall set its Home address equal to its Forwarding address, when performing re-addressing. A host within a mobile segment may need to obtain its Forwarding address. In general, the procedures for obtaining this address are specific to a particular network layer protocol. In CLNP environment [6], such address may be obtained via Dynamic NSAP configuration ISO 9542 [5], [7]. In IP environment [9], such address may be obtained via DHCP [8]. A.2 Cell realization as a single Link Layer subnetwork. This section provides an example of how the concept of a cell can be realized via a single Link Layer subnetwork. The example further assumes that the network layer used within the cell is CLNP [6]. Each RS must have interfaces to at least two Level 2 subnetworks. Each RS may serve multiple cells, for instance if it has multiple adapters supporting "wireless" interfaces. The RS acts as a CLNP router (IS). A RS keeps track of the NSAP addresses of the RSCs within its cell(s) by participating in ISO 9542 [5]. Hosts within a cell may discover each other's SNPAs by performing the ISO 9542 Query Configuration Function. Alternatively, they may discover each other's SNPAs as a result of the RS performing the ISO 9542 Request Redirect Function. The RS can perform the ISO 9542 Request Redirect Function only if the Level 2 subnetwork of the cell is capable of supporting direct host to host communication within the cell. To increase the longevity of a redirection without allowing an incorrect mapping to persist indefinitely, the host may employ the ISO 9542 Refresh Redirect Function. Since a MH may move out of the cell, the holding time carried in ISO 9542 needs to be short enough to ensure the detection of such move and subsequent flush of the stale information by executing either the ISO 9542 Flush Old Configuration function or the ISO 9542 Flush Old Redirect function. When a MH changes its cell the MH shall perform ISO 9542 Flush Old Configuration function and ISO 9542 Flush Old Redirect function. Expiration Date July 1993 [Page 17] - 18 - In some implementations, it may be that a MH, as it prepares to change cells, can perform the ISO 9542 Report Configuration function with the Holding Time set to 0. Other techniques (particularly notifications from the Link Layer of the cell) may be used to supplement/improve adaptability of the scheme to changes in the MH's location. It is expected that with very minor changes single Link Layer cell's realization with CLNP may be applicable to other network layer protocols like IP or IPX. The only part of this proposal that is ISO-specific is the use of ISO 9542. When applying this proposal to other network layer protocols one may either decide to use the appropriately modified ISO 9542 or to provide comparable functionality with other protocols. A.3 Cell realization as a single routing domain This section provides an example of how the concept of a cell can be realized via a single routing domain. It is assumed that a mobile segment consists of a single host. The example further assumes that the intra-domain routing protocol within the domain is capable of supporting host routes. An example of such protocol is OSPF. Each RS is colocated with a router that connects the domain to other domains (such router is usually called border router, or Border Intermediate System). Routing between hosts (either mobile or stationary) within the domain is supported via intra-domain routing. Mobile hosts advertise their addresses into the intra-domain routing; these addresses are propagated as host routes throughout the domain. A border router does not propagate host routes outside of the domain the router belongs to. The presence of a host route at a border router (colocated with an RS) serves as an indication that the RSC (host specified in the route) is not in its home cell. One possible way for a mobile host within a domain can update its LD is described in Appendix B. Note that such a mobile host need not know the address of its RS, since the RS can keep track of all its RSCs that are not in their home cells (see previous paragraph). Appendix B: Possible realization of co-located LD and RDS (RDS/LD) This section describes one likely realization of a RDS and an LD. In this realization, the LD is distributed, and each segment of the LD Expiration Date July 1993 [Page 18] - 19 - is co-located with a particular RDS. This realization assumes that the network layer supports an Echo function (Echo Request -- Echo Reply). RSCs use the Echo packets for updating their LD. Each RSC can be preconfigured with the addresses of the RDS/LD whose RDS component is associated with the RSC. For each RSC associated with a given RDS, the segment of the LD that is co-located with the RDS needs to keep track of the Forwarding address of that RSC. This is achieved by sending Echo Request PDUs from the RSC to the RDS/LD. To ensure reliable delivery of the information, the RSC shall retransmit the Echo Request PDU until it receives an Echo Reply PDU from the RDS/LD. The Echo Request PDU may be transmitted, however, without requiring reliable delivery; this takes care of the the case when a RSC moves again before receiving the Echo Reply PDU from the RDS/LD. As mentioned in section 7, to ensure that the location information at the LD is always valid, the RSC shall send the Echo Request PDU each time the RSC changes cells. An example of one possible mechanism, where a cell is realized as a single Link Layer subnetwork, is presented in Appendix A.1. Even if the RSC doesn't change its cell, the RSC may send the Echo Request PDU, say every MaxMRUpdateInterval (5 minutes). For a host that performs re-addressing (i.e, a co-located RSC and RS), the Echo Request will carry the host's Home address, but will also contain an address mapping indicating the host's Forwarding address. Otherwise the Echo Request will carry the host's Home address. Then if the RDS associated with the host is in a different cell, the RS serving the RSC will re-address the Echo Request, mapping the RSC's Home address into its Forwarding address. If the RDS associated with the RSC is in the same cell as the RSC, the Echo Request may carry only the Home address and will arrive at the RDS unmapped. When the RDS/LD receives an Echo Request PDU destined to it, containing an address mapping, the RDS/LD checks whether the Home address in the Echo Request PDU indicates a RSC associated with the RDS component of the RDS/LD. If so, the LD component associates the Forwarding address with the indicated Home address to update its mapping. The RDS/LD then transmits an Echo Reply PDU with the destination address set to the Forwarding address of the RSC, and using the updated address mapping. If the RDS/LD receives an unmapped Echo Request PDU destined to it, it will assume that it is a standard NPDU unrelated to any of its special operations to support forwarding of NPDUs to RSCs. To improve robustness of the scheme a RDS/LD may be replicated. This Expiration Date July 1993 [Page 19] - 20 - can be accomplished by requiring a group of entities that perform RDS/LD to advertise direct reachability to a common range of address prefixes. Then a given MH will be associated not with one, but with multiple RDSs. Such a MH can be preconfigured with a list of addresses of several RDSs associated with the MH. As a MH moves from one cell to another it may be required to notify all of its associated RDSs about such moves. To deal with RDS/LD failures (e.g. RDS/LD crash) when a RDS/LD is replicated, an entity that participates in the replicated RDS/LD is required after a restart to wait at least the amount of time greater than MaxMRUpdateInterval before claiming reachability to the range of addresses given to the RDS component of the RDS/LD. To improve robustness it is recommended that the group of entities that perform RDS/LDs will be located in places with redundant connectivity. That would reduce the probability that communication between RSCs and the group of RDS/LDs associated with them would be disrupted by network failures. Communication between the participating RDS/LDs is not necessarily required, but may be introduced to alleviate the amount of work that must be performed by RSCs when they enter new cells. Appendix C: Possible realizations of ER PDU indicating Destination Unreachable In the IP environment an ER PDU indicating Destination Unreachable can be realized via the ICMP message indicating Destination Unreachable (with code Host Unreachable). Since the payload of the message is required to carry the full internet header plus 8 octets of the original network layer payload, the message should be able to carry both the Home and the Forwarding address when the re-addressing is realized as either IP option or as a compact encapsulation/decapsulation. Use of this message with pure encapsulation/decapsulation is problematic (since the message may not include sufficient information). In CLNP environment an ER PDU indicating Destination Unreachable can be realized via the ISO 8473 ER PDU indicating Destination Address Unreachable. Since the payload of the PDU is required to carry the full internet header, the PDU should be able to carry both the Home and the Forwarding address when the re-addressing is realized as CLNP option. The feasibility of using this PDU with encapsulation (either pure or compact) is fully predicated on the amount of network layer payload of the original packet that will be included in the ER PDU. Appendix D: Possible realization of an ER PDU indicating Host Expiration Date July 1993 [Page 20] - 21 - Location Information Regardless of the particular network layer protocol, an ER PDU indicating Host Location Information should carry the following information: - Home Address - Forwarding Address - Timestamp - Authentication information (optional) In the IP environment, an ER PDU indicating Host Location Information can be realized via new type of ICMP message indicating Host Location Information. In CLNP environment ER PDU indicating Host Location Information can be realized via new type of ISO 8473 ER PDU indicating Host Location Information. It is also possible to share Host Location Information among the various entities concerned by sending messages to specific transport-layer sockets. References 1. John Ioannidis and Dan Duchamp and Gerald Q. Maguire Jr. IP- Based protocols for mobile internetworking. Proceedings of SIGCOMM'91, ACM, September, 1991, pp. 235--245. 2. Fumio Teraoka, Yasuhiko Yokote, and Mario Tokoro, A Network Architecture Providing Host Migration Transparency, Proceedings of SIGCOMM'91, ACM, September, 1991, pp. 209-220 3. Fumio Teraoka, Kim Claffy, and Mario Tokoro, "Design, Implementation, and Evaluation of Virtual Internet Protocol", Proceedings of 12th International Conference on Distributed Computing Systems", June 1992, pp. 170-177 4. Hiromi Wada, Tatsuya Ohnishi, and Brian Marsh, "Packet Forwarding for Mobile Hosts", Internet Draft, November 1993 5. ISO 9542, "End system to Intermediate system routing exchange protocol for use in conjunction with the Protocol for providing the Expiration Date July 1993 [Page 21] - 22 - connectionless-mode network service (ISO 8473)" 6. ISO 8473, "Protocol for providing the connectionless-mode network service". 7. ISO 9542 DAM1 8. Droms, R., "Dynamic Host Configuration Protocol", Internet Draft, November 1992. 9. John Postel, Internet Protocol, Tech Rept. RFC791, Network Working Group, September 1981. 10. Turner, Paul, "NetWare Communications Processes", September 1990. Authors' Addresses Yakov Rekhter T.J. Watson Research Center IBM Corporation P.O. Box 218 Yorktown Heights, NY 10598 Phone: (914) 945-3896 email: yakov@watson.ibm.com Charles Perkins T.J. Watson Research Center IBM Corporation P.O. Box 218 Yorktown Heights, NY 10598 Phone: email: perk@watson.ibm.com Expiration Date July 1993 [Page 22]