Mobile IP Working Group Eunsoo Shim Richard D. Gitlin Internet Draft Columbia University Document: draft-shim-mobileip-neighbor-00.txt November 2000 Category: Informational Fast Handoff Using Neighbor Information Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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 We propose a new fast handoff mechanism in wireless IP using neighboring Foreign Agent information. Our proposal is based on the policy of utilizing, or perhaps even wasting, wired bandwidth between Foreign Agents, while minimizing rf (radio frequency) bandwidth exchanges, in order that handoff latency is minimized. We minimize the handoff latency by initiating data forwarding to the possible new foreign agent candidates (i.e., the neighbor foreign agents) immediately when the mobile node is about to start the link layer handoff procedure. This proposal builds upon the Mobile IP handoff procedure by adding a couple of additional message types. The handoff mechanism is a unified procedure for inter- and intra-domain handoffs and provides flexible choices to the network while maintaining transparency to the mobile node. The neighbor learning process is a distributed and dynamic mechanism. 1. Introduction Shim/Gitlin Expires April 2001 1 Internet Draft Fast Handoff Using Neighbor Info November 2000 Mobile IP [3]Æs handoff latency can be separated into two elements: motion detection time and forwarding setup time. Forwarding setup time is the time consumed to register the new care-of address with the Home Agent (HA) in the Mobile IP protocol. The registration procedure starts after the mobile node (MN) detects that it is in an area with a new attachment point, that is, a new Foreign Agent (FA). When a MN hands over from FA æAÆ to FA æBÆ, FA æAÆ is called an old FA and FA æBÆ is called a new FA in this draft. There are several proposals that reduce forwarding setup time by localizing forwarding setup for intra-domain handoffs such as Regional Registration [4]. Many of these proposals retain the latency aspect of motion detection. One could wonder whether the MN or the network can predict the new FA before data transport from the old FA to MN is interrupted. If this is possible, the network can start forwarding setup to the new FA while the MN is still communicating with the old FA and thus reduce the handoff latency significantly. But this is not easy or feasible in general in the current wireless networks. It is not preferable to impose such a capability considering the complexity of the prediction either. While it is difficult to predict the new FA exactly, it is not too difficult to find a reasonable set of candidate FAs that are likely to be the new FA after a handoff. If we allow data forwarding to these prospective FAs just before, or during, the handoff process, then we can achieve very low handoff latency, without introducing significant complexity to the network or MN. Obviously forwarding to all the prospective FAs consumes more bandwidth in the wired network that connects the prospective FAs. The bandwidth of wired network is getting more abundant, as well as cheaper, and the available bandwidth of wired networks can be larger than that of the rf bandwidth by one or more orders of magnitude. With this in mind, achieving minimal handoff latency and thus providing the best possible quality of service to mobile IP applications at the expense of inefficient bandwidth usage in the wired networks is a sound engineering tradeoff. When a MN can hand over from FA æAÆ to FA æBÆ, FA æAÆ and FA æBÆ are called neighbor FAs to each other. A reasonable set of prospective new FAs is the set of neighbor FAs, while the set of prospective new FAs can be reduced down to one depending on the capabilities of the network or MN. We define a protocol through which each FA learns about its neighbor FAs. Then detailed handoff procedures are presented in various scenarios. Our proposal is built upon Mobile IP. Several new messages are introduced while keeping the Mobile IP protocol. Our proposal provides a framework for fast handoff that allows utilizing of different capabilities of the networks or MNs. 1.1. Conventions used in this document Shim/Gitlin Expires April 2001 2 Internet Draft Fast Handoff Using Neighbor Info November 2000 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [2]. 1.2. Terminology old FA: When a MN hands over from FA æAÆ to FA æBÆ, FA æAÆ is the old FA in the handoff. new FA: When a MN hands over from FA æAÆ to FA æBÆ, FA æBÆ is the new FA in the handoff. neighbor FA: When a MN can hand over from FA æAÆ to FA æBÆ, FA æAÆ and FA æBÆ are called a neighbor FA to each other. 2. Neighbor FA Information Each FA can learn about its neighbor FAs from the MN. That is, the MN keeps the address of the old FA and notifies the new FA about it. Then the new FA learns about one of its neighbor FAs and notifies the neighbor (the old FA) about itself. A FA can learn about all of its neighbor FAs as time goes by and many handoffs occur. +-----+ | oFA | (4)Update Neighbor FA table +-----+ ^ +----+ | | MN | | (3)Neighbor FA Notification +----+ | | | | +-----+ +----------------->| nFA | (2)Update Neighbor FA table +-----+ (1)Registration message with Previous FA Notification Extension Figure 1 û Neighbor FA Learning Procedure Figure 1 shows the procedure through which each FA learns about its Neighbor FAs. In Mobile IP, the MN sends a Registration Request message to the new FA after it gets the Agent Advertisement message. In [4], Previous Foreign Agent Notification Extension is proposed. This extension is used to notify the new FA of the old FA address. But the semantics of the extension is different from that of [4]. It depends on whether Route Optimization proposed in [4] is adopted Shim/Gitlin Expires April 2001 3 Internet Draft Fast Handoff Using Neighbor Info November 2000 whether the new FA should send a Binding Update message to the old FA. And the old FA should not remove the visitor entry for the MN immediately even if it receives the Binding Update message. Each FA maintains a Neighbor FA table. Each entry of the Neighbor FA table contains the following fields: - Neighbor FA Address - Notified Time - Notification Time - Neighbor FAÆs Neighbor FA Cache Timeout Period After being notified of the old FA, the new FA updates its Neighbor FA table. Notified Time is the latest time the FA got notified of the Neighbor FA, which is updated every time the FA gets notification of the Neighbor FA. If the Notified Time is not updated for a certain period of time, called Neighbor FA Cache Timeout Period, the Neighbor FA entry is removed from the table. Then, the new FA checks whether it needs to notify the old FA of its address. Notification Time is the latest time the FA notified the Neighbor FA of itself. To avoid too frequent notification, the FA sends Neighbor Notification to the Neighbor FA only when it has passed since the Notification Time by more than a half of the Neighbor FAÆs Neighbor FA Cache Timeout Period. By default, the Neighbor FAÆs Neighbor FA Cache Timeout Period has the same value as the local FAÆs Neighbor FA Cache Timeout Period. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Neighbor FA Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Neighbor FA Cache Timeout Period | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / | Authentication | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The old FA gets the Neighbor FA Notification message and updates its Neighbor FA table. If the Neighbor FA Cache Timeout Period included in the Neighbor FA Notification message is different from the value in the table, the timeout value in the table is modified to the value in the message. Also if there is large difference between the old FAÆs Neighbor FA Cache Timeout Period and that of the new FA, the old FA can send a Neighbor FA Notification message to the new FA so that the new FA can have the correct value for the old FAÆs Neighbor FA Cache Timeout Period in its table. Shim/Gitlin Expires April 2001 4 Internet Draft Fast Handoff Using Neighbor Info November 2000 This Neighbor FA information is of soft state, that is, each entry expires after Neighbor FA Cache Timeout Period has passed without any new notification for the Neighbor FA entry. 3. Handoff Schemes 3.1. Scenario 1 In this scenario, we assume each base station belongs to a different subnet and thus each layer 2 (L2) handoff is accompanied by layer 3 (L3) handoff, that is, Mobile IP handoff. We assume also no Route Optimization or Regional Registration is incorporated to simplify the description. Interoperation with each proposal will be covered later. The L2 handoff procedure can be initiated due to various causes. The cause may be detection of low signal strength or too high bit error rate. In most cases, the MN can know that it is going to do handoff before actual handoff occurs. Even in the case of network-controlled handoff mechanisms, the MN is informed of the L2 handoff in the early stage of L2 handoff. We assume the Mobile IP protocol stack is notified of the impending or beginning L2 handoff. ^ ^ (1) Handoff | H Notification +-----+ +------------------>| | |H==================| oFA |===================H |H Data +-----+ H |V |^ H H +----+ (2)|| H (3-a) +----+ | | Forwarding|| H Data | | | MN | Notification|| H | HA | +----+ || H (3-b) +----+ V| V Forwarding +-----+ Acknowledgement | | | nFA | +-----+ ----> Signaling Message ====> Data Figure 2û Handoff Procedure, Scenario 1, Phase 1 Shim/Gitlin Expires April 2001 5 Internet Draft Fast Handoff Using Neighbor Info November 2000 Our handoff protocol in this scenario is shown in Figure 2,3, and 4. While the MN is bound to the old FA, the L2 handoff starts and the Mobile IP protocol stack gets notification of the handoff. Then the Mobile IP protocol stack generates a Handoff Notification message and sends it to the old FA. The following is the Handoff Notification message format. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | LAC |N| Reserved | Seq | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MN Home IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / | Authentication | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | New FA Address (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Layer Address Extension (optional) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / . . . / / / | Link Layer Address Extension (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ LAC Link Layer Address Count, that is, the number of Link Layer Address Extension contained in the message N New FA Address. N bit is set if the new FAÆs address is contained MN Home IP Address Home IP Address of the mobile node sending the message Seq Sequence number assigned by the MN New FA Address IP address of the new FA at the current handoff Authentication Values needed for authentication of the mobile node Link Layer Address Extension [5] Shim/Gitlin Expires April 2001 6 Internet Draft Fast Handoff Using Neighbor Info November 2000 Extension for the link layer address of an interface of the mobile node The MN Home IP Address is used to identify the MN sending the Handoff Notification message. MN assigns the same value to the Seq field when it sends multiple Handoff Notification messages to the old FA for one instance of handoff. Thus the old FA can filter out Handoff Notification messages which were sent in the past handoffs by checking the Seq field. When the MN sends Handoff Notification before it registers with the new FA as assumed in this scenario, the MN does not know the new FAÆs address in general. But it may be possible for the MN to it depending on the technology. Then the MN set N bit and fills this New FA Address field. It enables the old FA to forward data to the new FA only. Each Link Layer Address Extension provides the link layer address of a network interface of the MN. The MN may have multiple radio interfaces and it may use the different interface after the handoff. It is possible in particular in the cases of heterogeneous wireless overlay networks where the MN may hand over from a network to another network using a different technology. As soon as the old FA gets Handoff Notification from a MN, it reads its Neighbor FA table and sends Forwarding Notification messages to the Neighbor FAs. If the Handoff Notification message from the MN contains the new FAÆs address, the old FA sends Forwarding Notification only to the new FA. The Neighbor FAs of the old FA should then add the information into their temporary forwarding table and should reply to the old FA with the Forwarding Acknowledgement message. If the old FA does not receive Forwarding Acknowledgement from a Neighbor FA within a certain period, Forwarding Acknowledgement Wait Timeout Period, it sends again Forwarding Notification to the Neighbor FA. Even if the old FA does not receive Forwarding Acknowledgement from a Neighbor FA, it forwards data to the Neighbor FA up to Forwarding No ACK Timeout Period. The Forwarding Notification message format is the following. Shim/Gitlin Expires April 2001 7 Internet Draft Fast Handoff Using Neighbor Info November 2000 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | LAC |Reserve| Sequence | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MN Home IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / | Authentication | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Layer Address Extension (optional) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / . . . / / / | Link Layer Address Extension (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ LAC Link Layer Address Count, that is, the number of Link Layer Address Extension contained in the message Sequence Sequence number of the Forwarding Notification Message assigned by the FA sending the message MN Home IP Address Home IP Address of the MN for which data is headed Authentication Values needed for authentication of the FA sending the message Link Layer Address Extension Extension for the link layer address of an interface of the mobile node Shim/Gitlin Expires April 2001 8 Internet Draft Fast Handoff Using Neighbor Info November 2000 The format of the Forwarding Acknowledgement is the following. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Reserved | Sequence | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MN Home IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / | Authentication | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sequence Copied from the sequence number of the corresponding Forwarding Notification message MN Home IP Address Home IP Address of the MN for which the data forwarding is Authentication Values needed for authentication of the FA sending the message Using the sequence number and the MN Home IP Address, the old FA can match the Forwarding Acknowledgement message to the corresponding Forwarding Notification message. Since each FA puts its own IP address as the source address in the IP header, the FAs can figure out the sender of the Forwarding Notification message or the Forwarding Acknowledgement message. Data forwarding from the old FA to the Neighbor FAs is done using tunneling. Now the question is how the new FA can forward the data to the MN. While the new FA as a router forwards IP packets using its routing table, the new FA handles the IP packets destined for the IP addresses registered in the temporary forwarding table differently. It is the same mechanism how each FA forwards IP packets toward a MN bound to the FA. That is, the new FA is aware that the MN is or will be located in the local subnet and tries to find its L2 address using ARP(Address Resolution Protocol)[] or something similar. If the new FA finds the L2 address of the MN or a proxy, it forwards IP packets using a L2 protocol with the L2 headerÆs destination address set as the found L2 address. What we need is L2 connectivity between the new FA and the MN. How it is established is out of the scope of this memo. It is a standard problem in supporting IP in any network and thus there are already solutions for many situations or it would be possible to find a solution. One thing to be noticed is that it is not necessary to have the base station and the FA co-located or connected with a direct link. To illustrate the point, a case when the new FA and the MN is connected through multiple routing hops is investigated later. While the MN has not finished its L2 handoff, the Shim/Gitlin Expires April 2001 9 Internet Draft Fast Handoff Using Neighbor Info November 2000 new FA cannot find a corresponding L2 address of the MN and thus it may buffer the data or discard it. In some situations, the new FA may be able to forward IP packets to the MN relying on the MAC address of an interface of the MN. Since the MAC address is the same before and after the handoff, the old FA can provide the MAC addresses of the interfaces of the MN to the new FA and the new FA can forward IP packets to the MN using the provided MAC addresses. Then the new FA does not have to rely on the ARP or something similar. It would save time for the new FA to start forwarding data to the MN. Since it is not generally possible, each FA should be configured about whether it should try the MAC addresses or use the MNÆs home IP address with a kind of the ARP mechanism. The point here is that the MN can receive data even before it receives the new FAÆs Advertisement message. So the handoff latency becomes independent of the speed of the Mobile IP motion detection and registration process. ^ H +-----+ | | | oFA |===================H +-----+ H H H +----+ H +----+ | | H Data | | | MN | H | HA | +----+ H +----+ |^ ^ H | ^ || H (7)Reg. Reply V | | || H=================+-----+ (6)Reg. Reply | | |+-------------------| | <------------------+ | +------------------->| nFA | ---------------------+ (4)Reg. Request +-----+ (5)Reg. Request ----> Signaling Message ====> Data Figure 3û Handoff Procedure, Scenario 1, Phase 2 While the MN is receiving data, it follows the procedure described in RFC 2002[3], that is, motion detection and registration. The new FA sends an Agent Advertisement message periodically and the MN sends the Registration Request message to the new FA. One thing to be noticed is that the MN should not use co-located care-of address. Shim/Gitlin Expires April 2001 10 Internet Draft Fast Handoff Using Neighbor Info November 2000 ItÆs because the data forwarding mechanism described in the above requires that the FA is in the data path and the FA should know the data traffic destined for the MN. Also the Registration Request message [4] from the MN should contain Previous Foreign Agent Extension or a similar extension to let the new FA learn about the old FA as one of its Neighbor FAs. If the MN does not include the Previous FA Notification Extension, we would need a separate message to provide the information about the old FA to the new FA. Following the Registration Request message sent to the new FA, come another Registration Request message from the new FA to the HA, the Registration Reply message from the HA to the new FA, and then the Registration Reply message from the new FA to the MN. The details of the procedure are as described in RFC 2002[3]. +-----+ | | | oFA | +-----+ ^ +----+ | (8) +----+ | | | Neighbor FA | | | MN | | Notification | HA | +----+ | +----+ ^ | H H +-----+ H H==================| | <==================H Data | nFA | Data +-----+ ----> Signaling Message ====> Data Figure 4û Handoff Procedure, Scenario 1, Phase 3 After the procedure described in RFC 2002 completes, the HA forwards the data to the new FA and then the new FA to the MN. The old FA will stop data forwarding shortly because no data is forwarded to the old FA from the HA any longer. The new FA may send the Neighbor FA Notification message to the old FA as described in the previous section if needed. Shim/Gitlin Expires April 2001 11 Internet Draft Fast Handoff Using Neighbor Info November 2000 3.2. Scenario 2 Here we consider the case the MN could not send Handoff Notification to the old FA while it was bound to the old FA. We assume everything else is the same as in the scenario 1 described in the above. Actually the handoff scheme is almost the same as that of the scenario 1. We assume the MN gets informed that the L2 handoff has completed. Then it sends the Handoff Notification message to the old FA. That is, our proposal requires notifications from L2 stack before the L2 handoff starts and after it finishes. The MN does not have to know about the new FA yet. The Handoff Notification messageÆs IP header contains the old FAÆs IP address as the destination address and the new FA will function just as a router. So the same Handoff Notification message is forwarded to the old FA as shown in Figure 5. The old FA does not differentiate the Handoff Notification sent through the new FA from that sent over the direct link between the old FA and the MN. After that, everything is the same as the scenario 1. +-----+ | | Data | oFA |<==================H +-----+ H ^ H +----+ | +----+ | | | (2) | | | MN | | Handoff | HA | +----+ | Notification +----+ | | | +-----+ | | | +------------------>| nFA | (1) Handoff +-----+ Notification ----> Signaling Message ====> Data Figure 5û Handoff Procedure, Scenario 2, the first step 3.3. Handoff Scheme for Ipv6 We can use the almost the same handoff scheme for Ipv6 while achieving the same effect for server disruption minimization. The details of the message format should be different because the IP Shim/Gitlin Expires April 2001 12 Internet Draft Fast Handoff Using Neighbor Info November 2000 address format is different first of all. The more details will be dealt with in the next version of this Memo. 3.4. Network Expansion or Removing Subnets When a new subnet and a new FA are added, the first MN doing handoff between the new subnet and other subnets can experience slow handoff and thus significant service disruption. But this is transitional and disappears from the second MN. The timeout period of the Neighbor FA Table entries can be adjusted easily to accommodate the usage pattern of the network. If the network topology change does not occur daily basis, one day can be a good example value for the timeout period. Setting a proper timeout period is out of the scope of this Memo. Since the Neighbor FA information is of soft state, the invalid entries of the Neighbor FA Table are removed automatically after the timeout occurs. 4. References [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 [3] C. Perkins. IP Mobility Support. Request for Comments (Proposed Standard) 2002, Internet Engineering Task Force, October 1996. [4] C. E. Perkins and D. Johnson. Route Optimization in Mobile IP (work in progress). draft-ietf-mobileip-optim-09.txt, February 2000. [5] P. Calhoun, T. Hiller, J. Kempf, P. McCann, C. Pairla, A. Singh, S. Thalanany. Foreign Agent Assisted Hand-off. draft-calhoun- mobileip-proactive-fa-02.txt (work in progress), September 2000. 5. Author's Addresses Questions about this memo can also be directed to the authors: Eunsoo Shim Shim/Gitlin Expires April 2001 13 Internet Draft Fast Handoff Using Neighbor Info November 2000 Department of Electrical Engineering Columbia University 530 West 120th Street New York, NY 10027 Email: eunsoo@ctr.columbia.edu Richard D. Gitlin Department of Electrical Engineering Columbia University 530 West 120th Street New York, NY 10027 Email: rich@ee.columbia.edu Shim/Gitlin Expires April 2001 14 Internet Draft Fast Handoff Using Neighbor Info November 2000 Full Copyright Statement "Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into Shim/Gitlin Expires April 2001 15