Internet Engineering Task Force K. Okanoue INTERNET DRAFT T. Ohsawa NEC Corp. 13 June 1996 Routing optimization by a router with cache agent functionality draft-okanoue-mobileip-R+A-00.txt Status of This Memo This document is a submission by the Mobile-IP Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the mobile-ip@SmallWorks.COM mailing list. Distribution of this memo 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, and 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.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the internet-drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Abstract It is considered that a routing optimization mechanism between mobile nodes and existing IPv4 nodes is important especially in IPv4 mobility support. An idea to realize the routing optimization is to introduce special router with en/decapsulation function and binding cache. Technical issues for such a special router is considered to be 1) how to control its binding cache correctly and 2) how to control load balance for the routing optimization processing. This memo describes protocols to solve the technical issues and realize the special router. Okanoue and Ohsawa Expires 13 December 1996 [Page 1] draft-okanoue-mobileip-R+A-00.txt 13 June 1996 1. Introduction It is considered to be important for IP mobility support to optimize routing paths between communicating nodes. Mobile-IP WG has been discussed not only Base Mobile-IP protocols[1] but also routing optimization options[2] for IPv4 mobility support. The routing optimization mechanism described in [2] can optimize routing paths between nodes with the routing optimization option. Considering an initial phase when mobile nodes are introduced, however, it will be proper for most of the nodes to communicate with existing IPv4 nodes without any mobility supporting functionality. Hence, it is considered to be important for IPv4 mobility support to optimize routing paths between the mobile nodes and existing IPv4 nodes. The Mobile-IP WG had been discussing a concept of a cache agent to realize optimum routing paths between the mobile nodes and existing IPv4 nodes. The cache agent caches bindings of mobile nodes and encapsulates received datgrams destined to the nodes based on the cache to transfer the datagram via optimum routing paths. Through the discussions, however, the cache agent can not be reached an agreement. It is considered that the following technical issues seem to make it difficult to reach an agreement; - how to control cache entry in a cache agent without any inconsistencies and - how to control processing load for routing optimization appropriately. It is important for a cache agent to always maintain only correct bindings of mobile nodes. If the cache agent caches an incorrect binding of a mobile node, all of datagrams transferred to the node from the cache agent can not be delivered. On the other hand, a cache agent encapsulates and transfers datagrams from existing IPv4 nodes as their proxy. Then it is considered that processing loads of a cache agent will be increased when communications between existing IPv4 and mobile nodes become common. Hence, it is required to for a cache agent to control its load balance for a routing optimization processing without causing any inconsistencies to cached bindings. We believe that a concept of the cache agent is important for IPv4 mobility support in spite of above technical issues. In order to overcome the technical issues and achieve routing optimization, this document describes basic protocols to realize a router with cache agent functionality. This special router has an ability to transfer received IP datagrams to mobility functionality supporting nodes via optimum routing paths based on its binding cache. Okanoue and Ohsawa Expires 13 December 1996 [Page 2] draft-okanoue-mobileip-R+A-00.txt 13 June 1996 1.1. Terminology -Mobile Node: A node with mobility supporting functionality -Stationary Node: A node without mobility supporting functionality -Home Address: An IP address for an identification of each mobile node. The home address does not change wherever the mobile host migrates. -Care-of Address: A temporary IP address of a mobile node which depends on its location -Binding: A mapping between a home address and a care-of address of a mobile node. -Home Network: A network having a network prefix matching that of a mobile node's home address. -Home Agent: A node on a mobile node's home network which tunnels datagrams for delivery to the mobile node and maintains current location information for the mobile. -Binding Cache: A cache including bindings of other nodes. -Router with cache agent functionality(R+A): A router which maintains a binding cache and en/decapsulates received datagrams correctly to provide an optimum routing path between communication nodes. Okanoue and Ohsawa Expires 13 December 1996 [Page 3] draft-okanoue-mobileip-R+A-00.txt 13 June 1996 -Mobility Security Association: A collection of security contexts, between a home agent of a mobile node and a router with cache agent functionality, which may be applied to protocols messages exchanged between them. Mobility Security Association includes an authentication algorithm and mode, a secret (a shared key, or appropriate public/private key pair), and a style of replay protection in use and network prefix of the home agent. 2. Basic concept for a Router with Cache Agent functionality In order to overcome the technical issues for a router with cache agent functionality (R+A), following basic policies are considered to be important for protocols to handle the R+A. - A R+A can optimize routing paths for IP datagrams destined for mobile nodes of which home agent has established a mobility security association with the R+A. - Alterations in both each binding cache entry of a mobile node and the corresponding binding information of its home agent must occur in a synchronous manner. - Load balances for a routing optimization processing should be well controlled by defining messages to stop routing optimization processes for a mobile node without any inconsistency in managing bindings. This document describes protocols for realizing a R+A which can optimize routing paths between stationary and mobile nodes based on above policies. 3. Protocol Overview It is a main role for a R+A to encapsulate received IP datagrams based on its binding cache and transmit the encapsulated datagrams to a mobile nodes via optimized routing paths. In order to do this, it is important for a R+A how to maintain its binding cache entries correctly. Following subsections overview protocols for a R+A to create, update and delete its binding cache entries. 3.1. Creating binding cache entry When a R+A needs to create binding cache entry of a mobile node, the R+A sends a RA_Binding_Request Message to the mobile node's home agent to obtain its binding. The home agent replies to the R+A by sending a RA_Binding_Reply message including the required binding and its life time, if the home agent decides to control correctly the R+A's binding cache entry. Okanoue and Ohsawa Expires 13 December 1996 [Page 4] draft-okanoue-mobileip-R+A-00.txt 13 June 1996 When the R+A receives the RA_Binding_Reply message, the R+A can maintain the required binding in its binding cache based on the RA_Binding_Reply message. The home agent sending the message must have a responsibility to control correctly the binding cache entry in the R+A created by the message. 3.2. Updating binding cache entry A binding cache entry in a R+A must be updated when a mobile node corresponding to the binding cache entry migrates to another network. Whenever a mobile node migrates to another network and gets a new binding, the node must register its new binding to its home agent[1]. Then the home agent must notify the new binding to all of cache agents which caches the node's old binding. In the result, all of the cache agents can maintain the mobile node's latest binding. Whenever the home agent accepts a new registration message from a mobile node, the home agent sends a RA_Binding_Update message to all of R+As which cache the information of the node's binding. The RA_Binding_Update message includes the new binding and its life time. When a R+A receives the RA_Binding_Update message, the R+A updates its binding cache and reply to the home agent by sending a RA_Binding_Update_Ack as an acknowledgment of the message. Receiving the RA_Binding_Update_Ack, the home agent must maintain information that the R+A has the new binding for the mobile node. 3.3. Deleting binding cache entry It is considered that there exist cases where a home agent or a R+A can not continue to the routing optimization process because of shortage of its resource or high processing load and so on. Therefore, both a home agent and a R+A must have a mechanism to quite routing optimization processes with keeping consistency of information on bindings. 3.3.1. Delete binding cache entry required by HA When a home agent can not continue to process routing optimization for a mobile node, it sends RA_Binding_Delete_Request message to all of the R+A caching the binding information of the mobile node. Receiving the RA_Binding_Delete_Request message, the R+A responds to the home agent by sending a RA_Binding_Delete_Request_Ack and removes the required binding from its binding cache. 3.3.2. Delete binding cache entry required by R+A When an R+A can not continue to process routing optimization for a mobile node, the R+A sends a RA_Delete_Request message to the node's home agent. Receiving the RA_Delete_Request message, the home agent responds to the R+A by sending a RA_Delete_Request_Ack and deletes the R+A entry from a table which maintains R+As with the required binding in their binding cache. Okanoue and Ohsawa Expires 13 December 1996 [Page 5] draft-okanoue-mobileip-R+A-00.txt 13 June 1996 4. Consideration on home agent A binding of each mobile node is always maintained at its home agent correctly. In a routing optimization mechanism using a R+A, a home agent must have the following functionality to keep consistency between binding information in the home agent and a binding cache entry in R+As. 4.1. R+A List In order that a home agent correctly manages R+As which caches bindings of all of mobile nodes managed by the home agent, the home agent has a following list called R+A List (RA_list) for each mobile node managed by the home agent. The RA_list includes - mobile node's latest binding, - life time of the binding, - IP addresses of cache agents which has the binding and - Flag for each R+A to show whether the home agent has already notified the binding to the R+A or not (Notification flag). By maintaining the list, the home agent correctly grasps R+As which caches binding of mobile node managed by the home agent. The home agent must remove RA_list of which life time is over. 4.2. Receiving RA_Binding_Request message When a home agent receives a RA_Binding_Request message, the home agent must check the authentication in the RA_Binding_Request message based on the mobility security association (MSA) established between the home agent and the R+A. If the received massage can not be authenticated by the home agent, the home agent must silently discard the message. The home agent has a possibility to be required a binding for stationary nodes, mobile nodes existing in its home agent or mobile nodes visiting to another network, because the cache agent which sent the message does not have any information on the target node (target node type). The home agent discriminates the target node type by using the following mechanism. - If the home agent does not establish a MSA with the target node, the target node is a stationary node. Otherwise, the target node is a mobile node. Okanoue and Ohsawa Expires 13 December 1996 [Page 6] draft-okanoue-mobileip-R+A-00.txt 13 June 1996 - When the home agent knows that the target node is a mobile node, the home agent investigate its registration table[1]. If the target node is registered in the registration table, then the node is migrating to another network. Otherwise the node is existing in its home network. The home agent must send different information to the R+A, depending on the target node types. 4.2.1. Receiving a RA_Binding_Request for a stationary node In this case, the home agent sends a RA_Binding_Reply message which includes that the target node is a stationary node. The home agent does not update its RA_list. 4.2.2. Receiving a RA_Binding_Request for a mobile node in its home network In this case, the home agent sends a RA_Binding_Reply message which includes - binding of the target node which shows that its home address and care-of address are identical, - information that the target node is a mobile node and - infinite life time of the binding. Moreover the home agent must add the R+A to the RA_list for the target node. If the home agent decides not to continue routing optimization processing for the target node, the home agent sends a RA_Binding_Request_Reject message to the R+A. The home agent does not update the RA_list for the target node. 4.2.3. Receiving a RA_Binding_Request for a mobile node out of its home network In this case, the home agent sends a RA_Binding_Reply message which includes - binding of the target node and life time of the binding included in the home agent's registration table and - information that the target node is a mobile node. Moreover the home agent add the R+A to the RA_list for the target node. Okanoue and Ohsawa Expires 13 December 1996 [Page 7] draft-okanoue-mobileip-R+A-00.txt 13 June 1996 If the home agent decides not to continue routing optimization processing for the target node, the home agent sends a RA_Binding_Request_Reject message to the R+A. The home agent does not update the RA_list for the target node. 4.3. Receiving Registration Request[1] from a mobile node When a home agent accepts a Registration Request from a mobile node managed by the home agent, the home agent changes a notification flag for each R+A listed in its RA_list for the mobile node to NOT_NOTIFIED status. Then the home agent sends RA_Binding_Update messages to all of the R+A listed in the RA_list. 4.4. Receiving RA_Binding_Update_Ack A home agent receives a RA_Binding_Update_Ack from a R+A as an acknowledgment of a RA_Binding_Update message. When the home agent receives the acknowledgment, the home agent must check the authentication in the message based on the MSA established between the home agent and the R+A. Moreover, the home agent checks an identifier field in the message to avoid reply attacks. If the home agent can not validate the message through the authentication and identifier processes, the home agent must silently discard the message. When the home agent can validate the message, the home agent changes the notification flag for the R+A in the RA_list for the target node to NOTIFIED status. 4.5. Sending RA_Binding_Delete_Request message When a home agent decides not to continue routing optimization processes for a mobile node, the home agent must send a RA_Binding_Delete_Request message to all of the R+As listed in a RA_list for the mobile node. 4.6. Receiving RA_Binding_Delete_Request_Ack A home agent receives RA_Binding_Delete_Request_Ack messages from all of R+As as an acknowledgment, to which the home agent sent a RA_Binding_Delete_Request message. When the home agent receives a RA_Binding_Delete_Request_Ack, the home agent must check the authentication in the received message based on the MSA established between the home agent and the R+A. Moreover, the home agent check an identifier field in the message to avoid reply attacks. If the home agent can not validate the message through the authentication and identifier processes, the home agent must silently discard the message. If the home agent receives a valid RA_Binding_Delete_Request_Ack from all of the R+As listed in a RA_list, the home agent must remove the RA_list and stop a routing optimization process for the mobile node. Okanoue and Ohsawa Expires 13 December 1996 [Page 8] draft-okanoue-mobileip-R+A-00.txt 13 June 1996 4.7. Receiving RA_Delete_Request massage When a R+A decides not to continue a routing optimization process for a mobile node, its home agent receives a RA_Delete_Request message including a home address of the node. Receiving the message, the home agent must check the authentication in the received message based on the MSA established between the home agent and the R+A. If the received massage can not be validated, the home agent must silently discard the message. Otherwise, the home agent deletes the R+A from the RA_list of the mobile node. Then the home agent sends a RA_Delete_Request_Ack to the R+A. 5. Consideration on R+A A R+A has a role to provide a optimum routing path for IP datagrams sent from a stationary node to a mobile node by encapsulating the IP datagrams based on its binding cache. In order to do this, it is important for a R+A to maintain the binding cache carefully. Hence, it is considered to be reasonable that only a home agent of each mobile node can control the binding cache entry of the mobile node in R+As. Following subsections describes functionaltys required to R+As. 5.1. Binding Cache In order to transfer received IP datagram via optimum routing paths, a R+A must maintain a binding cache which stores information of destination nodes. Each entry of the binding cache has following information; - flag which shows whether the node is stationary or mobile node (node type flag), - home address of the node, - care-of address of the node, - IP address of the node's home agent and - life time for the entry. A R+A can remove the cache entry when its life time has been over without notifying the removal to the home agent of the node. Otherwise, a R+A must notify the removal of the entry to the home agent of the node. A R+A must not update the binding cache without an agreement of the home agent of the node. 5.2. Receiving IP datagram When a R+A receives a IP datagram, the R+A transfers the IP datagram by using the following algorithm. Okanoue and Ohsawa Expires 13 December 1996 [Page 9] draft-okanoue-mobileip-R+A-00.txt 13 June 1996 Step 1: The R+A checks whether it has established a MSA with a home agent of which network prefix is identical to that of the destination node or not. If it is false, the R+A transfers the IP datagram without any modifications. Otherwise go to Step 2. Step 2: The R+A checks whether its binding cache includes a care-of address of the destination. If it caches the care-of address, it encapsulates the received IP datagram and transfers the encapsulated datagram to the destination via optimum routing path. Otherwise, it must send the IP datagram without any modifications and may send a RA_Binding_Request message to the home agent of the destination to get the binding of the destination. 5.3. Receiving encapsulated datagram When a R+A receives a encapsulated datagram, the R+A must check the destination address of the outer-IP header. If the destination address is different from the R+A's address, the R+A must transfer the datagram without any modifications. Otherwise, the R+A decapsulates the received encapsulated datagram and send it to the destination in inner-IP header. There may be inconsistency between the binding of the source node in the datagram and the R+A's binding cache entry. Then the R+A should send a RA_Binding_Request message to the home agent of the source node. The R+A must not change the binding cache entry based on only the received datagram. 5.4. Receiving RA_Binding_Reply Message After sending a RA_Binding_Request massage to a home agent, a R+A will receive a RA_Binding_Reply message from the home agent. Then the R+A must check the authentication in the received message based on the MSA established between the home agent and the R+A. Moreover, the R+A must check an identifier field in the message to avoid reply attacks. If the R+A can not validate the message through the authentication and identifier processes, the R+A must silently discard the message. Otherwise, the R+A updates its binding cache based on the received RA_Binding_Reply message. The home agent may send a RA_Binding_Reject message to the R+A. Then the R+A must delete the corresponding binding cache entry if the RA_Binding_Reject message is validated. When the RA_Binding_Reject message is not validated, the R+A must silently discard the message. The validation mechanism for the message is the same as that for the RA_Binding_Reply message. Okanoue and Ohsawa Expires 13 December 1996 [Page 10] draft-okanoue-mobileip-R+A-00.txt 13 June 1996 5.5. Receiving RA_Binding_Delete_Request message When a home agent of a mobile node stops a routing optimization processing for the mobile node, the R+A receives a RA_Binding_Delete_Request message. Receiving the message, the R+A must check the authentication in the received message based on the MSA established between the home agent and the R+A. If the received massage can not be validated, the R+A must silently discard the message. Otherwise, the R+A must send a RA_Binding_Delete_Request_Ack to the home agent and delete the binding cache entry involved in the RA_Binding_Delete_Request message. 5.6. Receiving RA_Binding_Update message When a R+A receives a RA_Binding_Update message from a home agent of a mobile node involved in its binding cache, the R+A must check the authentication in the received message based on the MSA established between the home agent and the R+A. If the received massage can not be validated, the R+A must silently discard the message. Otherwise, the R+A must update its binding cache entry based on the received RA_Binding_Update message and send RA_Binding_Update_Ack to the home agent as an acknowledgment. 5.7. Procedures to delete a binding cache entry When a R+A can not continue routing optimization processes for a mobile node involved in its binding cache, the R+A must send a RA_Delete_Request message to the mobile node's home agent. As an acknowledgment, the R+A will receives a RA_Delete_Request_Ack from the home agent. Then the R+A must check the authentication in the received message based on the MSA established between the home agent and the R+A. If the received massage can be validated, the R+A can delete the binding cache entry. Otherwise, the cache agent must silently discard the message. 5.8. Receiving Binding_Warning_Message[2] A R+A may receive a Binding_Warning_Message from a previous foreign agent of the mobile node involved in its binding cache. Then the R+A should send a RA_Binding_Request message to its home agent to require the its new binding. 6. Message Format The protocol described in this document uses following 8 messages are required. Particular message format is tbd. Okanoue and Ohsawa Expires 13 December 1996 [Page 11] draft-okanoue-mobileip-R+A-00.txt 13 June 1996 - RA_Binding_Request message This message should include 1) authenticator of the message, 2) identifier of the message, 3) R+A address and 4) target node address. - RA_Binding_Reply This message should include 1) authenticator of the message, 2) identifier of the message, 3) home agent address, 4) node type of the target node, 5) binding of the target node and 6) life time of the binding. - RA_Binding_Reject This message should include 1) authenticator of the message, 2) identifier of the message, 3) home agent address, 4) node type of the target node and 5) target node address. - RA_Binding_Delete_Request This message should include 1) authenticator of the message, 2) identifier of the message, 3) home agent address, and 4) binding of target node. - RA_Binding_Delete_Request_Ack This message should include 1) authenticator of the message, 2) identifier of the message, 3) R+A address, and 4) target node address. - RA_Delete_Request_Ack This message should include 1) authenticator of the message, 2) identifier of the message, 3) R+A address and 4) target node address. Authors' Address: - Kazuhiro Okanoue NEC Corp. C&C Research Labs. Network Research Lab. 4-1-1 Miyazaki, Miyamae-ku, Kawasaki 216 Japan Phone: +81 44 856 2255 E-mail: okanoue@nwk.CL.nec.co.jp or okanoue@sics.se - Tomoki Ohsawa NEC Corp. C&C Research Labs. Network Research Lab. 4-1-1 Miyazaki, Miyamae-ku, Kawasaki 216 Japan Phone: +81 44 856 2255 E-mail: ohsawa@nwk.CL.nec.co.jp Okanoue and Ohsawa Expires 13 December 1996 [Page 12] draft-okanoue-mobileip-R+A-00.txt 13 June 1996 References [1] Charles Perkins, "IP Mobility Support", Internet draft, work in progress, April 1996 [2] David B. Johnson and Charles Perkins, "Route Optimization in Mobile IP", Internet draft, work in progress, February 1996 Okanoue and Ohsawa Expires 13 December 1996 [Page 13]