📄 rfc2103.txt
字号:
Network Working Group R. RamanathanRequest for Comments: 2103 BBN Systems and TechnologiesCategory: Informational February 1997 Mobility Support for Nimrod : Challenges and Solution ApproachesStatus of this Memo This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited.Abstract We discuss the issue of mobility in Nimrod. While a mobility solution is not part of the Nimrod architecture, Nimrod does require that the solution have certain characteristics. We identify the requirements that Nimrod has of any solution for mobility support. We also classify and compare existing approaches for supporting mobility within an internetwork and discuss their advantages and disadvantages. Finally, as an example, we outline the mechanisms to support mobility in Nimrod using the scheme currently being developed within the IETF - namely, the Mobile-IP protocol.Table of Contents 1 Introduction................................................... 1 2 Mobility : A Modular Perspective.............................. 2 3 Effects of Mobility............................................ 4 4 Approaches..................................................... 6 5 Solution using IETF Mobile-IP.................................. 10 5.1 Overview .................................................. 10 5.2 Protocol Details........................................... 11 6 Security Considerations........................................ 15 7 Summary........................................................ 16 8 Acknowledgements............................................... 16 9 Author's Address............................................... 171 Introduction The nature of emerging applications makes the support for mobility essential for any future routing architecture. It is the intent of Nimrod to allow physical devices as well as networks to be mobile. Nimrod, as a routing and addressing architecture, does not directly concern itself with mobility. That is, Nimrod does not propose a solution for the mobility problem. There are two chief reasons forRamanathan Informational [Page 1] RFC 2103 Nimrod Mobility Support February 1997 this. First, mobility is a non-trivial problem whose implications and requirements are still not well understood and will perhaps be understood only when a mobile internetwork is deployed on a large scale. Second, a number of groups (for instance the Mobile-IP working group of the IETF) are studying the problem by itself and it is not our intention to duplicate those efforts. This attitude towards mobility is consistent with Nimrod's general philosophy of flexibility, adaptability and incremental change. While a mobility solution is not part of the "core" Nimrod architecture, Nimrod does require that the solution have certain characteristics. It is the purpose of this document to discuss some of these requirements and evaluate approaches towards meeting them. We begin by identifying the precise nature of the functionality needed to accommodate mobile entities (section 2). Following that, we discuss the effects of mobility on Nimrod (section 3). Next, we classify current and possible approaches to a solution for mobility (section 4) and finally (in section 5) we describe how mobility can be implemented using the IETF's Mobile-IP protocol. This document uses many terms and concepts from the Nimrod Architecture document [CCS96] and some terms and concepts (in section 5) from the Nimrod Functionality document [RS96]. Much of the discussion assumes that you have read at least the Nimrod Architecture document [CCS96].2 Mobility : A Modular Perspective Nimrod has a basic feature that helps accommodate mobility in a graceful and natural manner, namely, the separation of the endpoint naming space from the locator space. The Nimrod architecture [CCS96] associates an endpoint with a globally unique endpoint identifier (EID) and an endpoint label (EL). The location of the endpoint within the Internetwork topology is given by its locator. When an endpoint moves, its EID and EL remain the same, but its locator might change. Nimrod can route a packet to the endpoint after the move, provided it is able to obtain its new locator.Ramanathan Informational [Page 2] RFC 2103 Nimrod Mobility Support February 1997 Thus, providing a solution to mobility in the context of Nimrod may be perceived as one of maintaining a dynamic association between the endpoints and the locators. Extending this viewpoint further, one can think of mobility-capable Nimrod as essentially consisting of two "modules": the Nimrod routing module and the dynamic association module (DAM). The DAM is an abstraction, embodying the functionality pertinent to maintaining the dynamic association. This is a valuable paradigm because it facilitates the comparison of various mobility schemes from a common viewpoint. Our discussion will be structured based on the DAM abstraction and will be in two parts, the themes of which are : o What constitutes mobility for the DAM and Nimrod? Is the realization of mobility as a mobility "module" that interacts with Nimrod viable? What then are the interactions between Nimrod and such a module? These points will be discussed in section 3. o What are some of the approaches one can take in engineering the DAM functionality? We classify some approaches and compare them in section 4. A word of caution: the DAM should not be thought of as something equivalent to the current day Domain Name Service (DNS) - the DAM is a more general concept than that. For instance, consider a mobility solution for Nimrod similar to the scheme described in [Sim94]. Very roughly, this approach is as follows: Every endpoint is associated with a "home" locator. If the endpoint moves, it tells a "home representative" about its new locator. Packets destined for the endpoint sent to the old locator are picked up by the home representative and sent to the new locator. In this scheme, the DAM embodies the functionalities implemented by all of the home representatives in regard to tracking the mobile hosts. The point is that the association maintenance, while required in some form or other, may not be an explicitly distinct part, but implicit in the way mobility is handled. Thus, the DAM is merely an abstraction useful to our discussion and should not be construed as dictating a design. In summary, we view the Nimrod architecture as carrying a functional "stub" for mobility, the details of the stub being deferred for later. The stub will be elaborated when a solution that meets the requirements of Nimrod becomes available (for instance from the IETF Mobile-IP research). We do not, however, preclude the modification of any such solutions to meet the Nimrod requirements or preclude the development of an independent solution within Nimrod.Ramanathan Informational [Page 3] RFC 2103 Nimrod Mobility Support February 19973 Effects of Mobility One consequence of mobility is the change in the locator of an endpoint. However, not all instances of mobility result in a locator change (for instance, there is no locator change if a host moves within a LAN) and a change in the locator is not the only possible effect of mobility. Mobility might also cause a change in the topology map. This typically happens when entire networks move (e.g., an organization relocates, a wireless network in a train or plane moves between cells, etc.). If the network is a Nimrod network, we might have a change in the connectivity of the node representing the network and hence a change in the map. In this section, we consider the effects of mobility on the two "modules" identified above: Nimrod, which provides routing to a locator, and a hypothetical instantiation of the DAM, which provides a dynamic endpoint-locator association, for use by Nimrod. We consider four scenarios based on whether or not the topology and an endpoint's locator changes and comment on the effect of the scenarios on Nimrod and the DAM. Scenario 1. Neither the locator nor the topology changes. This is the trivial case and affects neither the DAM nor Nimrod. An example of this scenario is when a workstation is moved to a new interface on the same local area network(This is not true for all LANs, only those in which all interfaces are part of the same Nimrod node) or when mobility is handled transparently (by lower layers). Scenario 2. The locator changes but the topology remains the same. This is the case when an endpoint moves from one node to another, thereby changing its locator. The DAM is affected in this case, since it has to note the new endpoint-locator association and indicate this to Nimrod if necessary. The effect on Nimrod is related to obtaining this change from the DAM. For instance, Nimrod may be informed of this change or ask for the association if and when it finds out that the mobile host cannot be reached. Scenario 3. The locator does not change but the topology changes. One way this could happen is if a network node moves and changes its neighbors (topology change) but remains within the same enclosing node. The DAM is not affected because the endpoint-locator association has not changed. Nimrod is affected in the sense that the topology map would now have to be updated.Ramanathan Informational [Page 4] RFC 2103 Nimrod Mobility Support February 1997 Scenario 4. Both the locator and the topology change. If a network node moves out of its enclosing node, we have a change both in the map and in the locators of the devices in the network. In this case, both Nimrod and the DAM are affected. In scenarios 3 and 4, it may not be sufficient to simply let Nimrod handle the topological change using the update mechanisms described in [RS96]. These mechanisms are likely to be optimized for relatively slow changes. Mobile wireless networks (in trains and cars for instance) are likely to produce more frequent changes in topology. Therefore, it might be necessary that topological updates caused by mobility be handled using additional mechanisms. For instance, one might send specific updates to appropriate node representatives, so that packets entering that node can be routed using the new topology. We observe that accommodating mobility of networks, especially the fast moving ones, might require a closer interaction between Nimrod and the DAM than required for endpoint mobility. It is beyond the scope of this document to specify the nature of this interaction; however, we note that a solution to mobility should handle the case when a network as a whole moves. Current trends [WJ92] indicate that such situations are likely to be common in future when wireless networks will be present in trains, airplanes, cars, ships, etc. In summary, if we discount the movement of networks, i.e., assume no topology changes, it appears that the mobility solution can be kept fairly independent of Nimrod and in fact can be accommodated by an implementation of the DAM. However, to accommodate network mobility (scenarios 3 and 4), it might be necessary for Nimrod routing/routers to get involved with mobility. Beyond the constraints imposed by the interaction with Nimrod, it is desirable that the mobility solution have some general features. By general, we mean that these are not Nimrod specific. However, their paramount importance in future applications makes them worth mentioning in this document. The desirable features are : o Support of both off-line and on-line mobility. Off-line mobility (or portability) refers to the situation in which a session is torn down during the move, while on-line mobility refers to the situation in which the session stays up during the move. While currently much of the mobility is off-line, trends indicate that a large part of mobility in the future is likely to be on-line. A solution that only supports off-line mobility would probably have limited applications in future.Ramanathan Informational [Page 5] RFC 2103 Nimrod Mobility Support February 1997 o Scalability. One of the primary goals of Nimrod is scalability, and it would be contrary to our design goals if the mobility solution does not scale. The Internet is rapidly growing and with the advent of Personal Communication Systems (PCS) [WJ92], the number and rapidity of mobile components in the Internet is also likely to increase. Thus, there are three directions in which scalability is important : size of the network, number of mobile entities and the frequency of movement of the mobile entities. Note that for any given system with minimum response time (to a move) of o seconds, if the mobile entity changes attachment points faster than 1=o changes per second, the system will fail to track the entity. Augmenting traditional location tracking mechanisms with special techniques such as predictive routing might be necessary in this case. Hooks in the mobility solution for such augmentation is a desirable feature. o Security. It is likely that in the future, there will be increased demand for secure communications. Apart from the non-mobility specific security mechanisms, the solution should address the following :- Authentication. The information sent by a mobile host about its location should be authenticated to prevent impersonation. Additionally, there should be mechanisms to decide if a mobile user who wishes to join a network has the privileges to do so or not.- Denial of service. The schemes employed for handling mobility in general could be a drain on the resources if not controlled carefully. Specifically, the resource intensive portions of the protocol should be guarded so that inappropriate use of them does not cause excessive load on the network.⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -