INTERNET DRAFT Ryuji Wakikawa Expires: 24 Apr 2005 Masafumi Watari Keio Univ./WIDE 24 Oct 2004 Optimized Route Cache Protocol (ORC) draft-wakikawa-nemo-orc-01.txt Status of This Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she become aware will be disclosed, in accordance with RFC 3668. 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. Copyright Notice Copyright (C) The Internet Society (2004). Abstract This draft proposes Optimized Route Cache Protocol (ORC) to provide route optimization for the NEMO Basic Support protocol. ORC provides a dynamic route optimization mechanism, similar to route optimization in Mobile IPv6. The ORC aims to manage binding information for when routing information of each mobile network are located at special routers called ``Correspondent Router''. Wakikawa and Watari Expires 24 Apr 2005 [Page i] Internet Draft ORC 24 Oct 2004 Contents Status of This Memo i Abstract i 1. Introduction 3 2. ORC Concept 3 3. Terminology 4 4. ORC Overview 5 4.1. Correspondent Router Discovery . . . . . . . . . . . . . 5 4.2. Binding Registration to Correspondent Router . . . . . . 5 4.3. Forwarding between Mobile Router and Correspondent Router 6 5. Extensions to Mobile IPv6 and the Basic NEMO protocol 6 5.1. Forwarding Table Data Structure . . . . . . . . . . . . . 6 5.2. Mobility Header Messages . . . . . . . . . . . . . . . . 7 5.2.1. Binding Update . . . . . . . . . . . . . . . . . 7 5.2.2. Binding Acknowledgment . . . . . . . . . . . . . 7 5.2.3. Managed Prefix Lists sub-option . . . . . . . . . 7 5.3. New ICMP Messages . . . . . . . . . . . . . . . . . . . . 8 5.3.1. Correspondent Router Discovery Request . . . . . 8 5.3.2. Correspondent Router Discovery Reply . . . . . . 9 6. Protocol Operations 11 6.1. Correspondent Router Discovery . . . . . . . . . . . . . 11 6.2. Binding Registration to Correspondent Router . . . . . . 12 6.2.1. Sending Binding Update . . . . . . . . . . . . . 12 6.2.2. Return Routability . . . . . . . . . . . . . . . 12 6.3. Intercepting Packets by Correspondent Router . . . . . . 13 6.4. Routing to Mobile Network . . . . . . . . . . . . . . . . 14 7. Security Consideration 14 8. Acknowledgements 14 References 14 Authors' Addresses 16 Appendices 17 A. Example Scenario 17 B. Correspondent Router Hierarchy 19 Wakikawa and Watari Expires 24 Apr 2005 [Page 1] Internet Draft ORC 24 Oct 2004 C. Modifications from the last version 21 Wakikawa and Watari Expires 24 Apr 2005 [Page 2] Internet Draft ORC 24 Oct 2004 1. Introduction The NEMO Basic Support protocol [4] is currently being standardized at the IETF NEMO working group. However, the NEMO Basic Support protocol does not provide route optimization, but always use a bi-directional tunnel established between a mobile router and its home agent. Optimized route cache protocol is designed as an extension to the NEMO Basic Support protocol for providing certain route optimization. ORC was proposed earlier in the paper [8]. In the NEMO Basic Support protocol, a binding of a mobile network can be treated as routing information of the mobile network. For instance, a care-of address in the binding can be treated as a next hop address in a routing table. It is against the general standard operations of the Internet for each end-node to handle route information. End nodes should be unaware of routing since managements of a binding may bother them. 2. ORC Concept In Mobile IPv6 [5] and the NEMO Basic Support protocol, a home agent is an original anchor router of a mobile network and maintains a binding of the mobile network persistently. All packets are first routed to the home agent and are tunneled to the mobile router by the home agent unless the mobile router starts route optimization. On the other hand, the optimized route cache protocol introduces correspondent routers that can be configured anywhere in the Internet to be an anchor router for the mobile network, providing certain level of route optimization. Practically, the correspondent routers should be scattered near the transit AS to allow direct forwarding to the mobile network before reaching the home agent. Because it is impossible to replace all routers on the Internet with the correspondent routers support, it is effective to place a correspondent router at places where traffic is converged like the Internet Exchange Point (IXP). The optimized routing cache protocol provides optimal route path in best effort when correspondent routers exist. However, the level of optimization can be improved depending on where the correspondent routers are placed, and the path it takes. The correspondent routers can also be dynamically discovered if necessary, to provide certain route optimization. Since the binding is processed and maintained only by the correspondent routers scattered over the Internet, mobile router does not need to handle bindings for each correspondent nodes. It is clearly redundant operations if both the mobile router and the Wakikawa and Watari Expires 24 Apr 2005 [Page 3] Internet Draft ORC 24 Oct 2004 remote network manage bindings for the same communicating network. This also allows the end-nodes to communicate in the optimized route without requiring any additional functions. This concept can be applied to Mobile IPv6 as well. In Mobile IPv6, correspondent nodes are required to extend its protocols suites for route optimization. However, it is not reasonable to assume all end-nodes to support the Mobile IPv6 protocol. Therefore, a mobile host can not initiate route optimization (i.e. return routability) to all correspondent nodes. In such case, the network of which the correspondent nodes are connected to can provides route optimization on behalf of the correspondent nodes. 3. Terminology Most of the terminology is described in [5] and [3]. This document in addition defines the following terms. Correspondent Router An edge router of correspondent nodes' network. A Correspondent Router is well defined in [7] and is also defined as ``ORC router'' in the paper [8]. A correspondent router is capable to manage a binding of any mobile router and setup forwarding for mobile network prefixes. A correspondent router can be statically configured or dynamically discovered by the mobile router. Correspondent Router Anycast address An anycast address assigned to each correspondent router. It is generated by the correspondent router's 64 bit prefix and an anycast identifier. The anycast identifier is to be defined by IANA. Managed Prefix Prefixes which are managed by each correspondent router. The Managed Prefix is often configured with administrative policy. For example, if a correspondent router is placed for an administrative domain (let's say 2001:a:b::/32), the Managed Prefix for the correspondent router is the 2001:a:b::/32. Mobile router can tunnel any packets meant for the managed prefixes to the correspondent router. The correspondent router has responsibility to route packets correctly to the destination which is in the managed prefixes. Wakikawa and Watari Expires 24 Apr 2005 [Page 4] Internet Draft ORC 24 Oct 2004 Proxy Route A proxy Route is used to intercept packets by a correspondent router at an administrative domain. A proxy route is to direct a route of a mobile network prefix to a correspondent router. Proxy route contains a mobile network prefix of a correspondent router as a destination and the correspondent router's address as a next hop. The proxy route will not be aggregated in an IGP domain, but can be distributed inside the IGP domain. Proxy Route is used to intercept packets when a correspondent router is not on the path of the traffic from the correspondent node to the Mobile Networks. (i.e. The correspondent router is neither Default Router nor Core Router. See [7]). 4. ORC Overview 4.1. Correspondent Router Discovery Each mobile router may have the list of the correspondent routers beforehand by system administrators or users. In addition, when a mobile network node starts communication with a correspondent node, a mobile router may dynamically discover a correspondent router for the correspondent node. The discovery is triggered when a mobile router receives tunneled packets from its Home Agent. The mobile router first sends a correspondent router Discovery Request to the correspondent router anycast address. The anycast address is created with the prefix address of the correspondent node and the well-known anycast identifier. The prefix length for the anycast address is always 64. When one of correspondent router receives the Correspondent Router Discovery Request, it replies back a Correspondent Router Discovery Reply including all correspondent routers of the administrative domain of which the correspondent node is located. 4.2. Binding Registration to Correspondent Router After receiving the correspondent router addresses, the mobile router can attempt Binding Registration to the correspondent router. The mobile router sends a Binding Update which is protected by IPsec to the correspondent router. The mobile router MUST set ORC flag 'O' in the Binding Update and include the Mobile Network Prefix sub-options. The Binding Update message is same as a Binding Update sent to a Home Agent except for the flag field (i.e. 'O' flag set and 'H' flag unset). Wakikawa and Watari Expires 24 Apr 2005 [Page 5] Internet Draft ORC 24 Oct 2004 After processing the Binding Update successfully, the correspondent router MUST return a Binding Acknowledgment including the managed prefix list. The managed prefix is used when the mobile router decides which packets are sent to which correspondent router. The correspondent router setup forwarding for all the mobile network prefixes notified by the mobile router. After getting successful Binding Acknowledgment, the mobile router set up forwarding for all managed prefixes. If the mobile router gets error status code in the Binding Acknowledgment or cannot get any Binding Acknowledgment, it SHOULD stop sending Binding Update to the correspondent router and SHOULD mark the correspondent router as invalid. There is alternative mechanism based on Return Routability to send secured Binding Update. The detailed operation is introduced in Appendix. 4.3. Forwarding between Mobile Router and Correspondent Router Once a mobile router registers its binding to a correspondent router, it forwards packets destined to an address which is in range of correspondent router's managed prefix. The correspondent router also intercepts packets sent to the Mobile Network and tunnels them to mobile router by IP-in-IP encapsulation. 5. Extensions to Mobile IPv6 and the Basic NEMO protocol 5.1. Forwarding Table Data Structure Forwarding table is maintained by each mobile router. It has conceptually the following fields. How to implement forwarding table is up to implementations. - Correspondent Router Address - Managed Prefix Lists The list of Managed Prefix which is notified by the correspondent router Wakikawa and Watari Expires 24 Apr 2005 [Page 6] Internet Draft ORC 24 Oct 2004 5.2. Mobility Header Messages 5.2.1. Binding Update 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|H|L|K|M|R|O| Reserved | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ORC Flag (O) The flag is used to identify a Binding Update sent for a correspondent router. 5.2.2. Binding Acknowledgment 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status |K|O| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ORC Flag (O) The flag is used to identify a Binding Acknowledgment sent from a correspondent router. 5.2.3. Managed Prefix Lists sub-option The managed prefix lists mobility header sub-option is valid only in the Binding Acknowledgment. Wakikawa and Watari Expires 24 Apr 2005 [Page 7] Internet Draft ORC 24 Oct 2004 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 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + + | | + Managed Prefix List + . . . . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type To be assigned by IANA Length The length of sub-option. Managed Prefix List The list of prefixes which are managed by a correspondent router. Lower bit after prefix length should be set zero. (ex. 2001:a:b:c::/64 is expressed by 2001:a:b:c:0:0:0:0) 5.3. New ICMP Messages Two new ICMP messages are defined for the discovery of the correspondent routers. Two messages have similar structure of home agent address discovery request and reply messages defined in Mobile IPv6 [5]. 5.3.1. Correspondent Router Discovery Request The Correspondent Router Discovery Request message is used by a mobile node to discover correspondent routers where correspondent nodes are located. The message format is as follows. Wakikawa and Watari Expires 24 Apr 2005 [Page 8] Internet Draft ORC 24 Oct 2004 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 | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type To be assigned by IANA Code 0 Checksum The ICMP Checksum Identifier The 16-bit identifier to aid in matching correspondent router Discovery Reply message. The identifier should never be set to 0 and should always be more than 1. Reserved 0 5.3.2. Correspondent Router Discovery Reply The Correspondent Router Discovery Reply message is used by a correspondent router to send lists of correspondent routers configured at the network in reply to the Correspondent Router Discovery Request message. The message format is as follows. Wakikawa and Watari Expires 24 Apr 2005 [Page 9] Internet Draft ORC 24 Oct 2004 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 | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Preference | Prefix Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Correspondent Router Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Preference | Prefix Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Correspondent Router Address + | | + + | | . . . . . . Type To be assigned by IANA Code 0 Checksum The ICMP Checksum Identifier The 16-bit identifier to aid in matching Correspondent Router Discovery Reply message. The identifier should never be set to 0 and should always be more than 1. Reserved 0 Wakikawa and Watari Expires 24 Apr 2005 [Page 10] Internet Draft ORC 24 Oct 2004 Preference The 8-bit preference value of each correspondent router. The default preference value is zero. Higher value indicate higher preference. Prefix length The length of prefix with which a correspondent router is configured and responsible for. Correspondent Router Address A global IPv6 address of a correspondent router. A correspondent router replies multiple addresses of correspondent routers that are configured in same network domain by a single Correspondent Router Discovery Reply message. 6. Protocol Operations 6.1. Correspondent Router Discovery A correspondent router is dynamically discovered with Correspondent Router Discovery and Correspondent Router Reply. The discovery mechanism is similar to the dynamic home agent discovery mechanism of Mobile IPv6 [5]. When a mobile router detects that a received packet is tunneled by its home agent, it can initiate Correspondent Router Discovery on demand by sending a Correspondent Router Discovery Request to the correspondent router anycast address. The mobile router learns the correspondent router anycast address from the correspondent node's prefix and the anycast identification. The prefix length of the correspondent node's prefix is always assumed to be 64-bit. Correspondent routers with a shorter prefix length are notified later with a Correspondent Router Discovery Reply. If no replies are received, the mobile router stops further discovery for correspondent routers to the network of which the correspondent node are located. The mobile router must then communicate through its home agent. If the mobile router receives a Correspondent Router Discovery Reply, it first verifies the message header (e.g. ICMP checksum and identifier). If all verifications are passed, it retrieves the correspondent router addresses. If more than one addresses are included, the mobile router selects one of the addresses and starts explicit binding registration described in section 6.2. The determination of which correspondent routers to select are handled Wakikawa and Watari Expires 24 Apr 2005 [Page 11] Internet Draft ORC 24 Oct 2004 with preference values and prefix length. Some examples are shown in Appendix B. 6.2. Binding Registration to Correspondent Router 6.2.1. Sending Binding Update A mobile router MAY maintain IPsec Security Association with correspondent routers. Alternatively, it MAY use Return Routability mechanism to protect Binding Update described in Section 6.2.2. A mobile router creates a Binding Update as indicated in the basic NEMO protocol. It MUST set 'O' flag in the Flag field of a Binding Update. The Binding Update MUST be always protected by IPsec or Return Routability mechanism. A mobile router also records the sent Binding Update as a Binding Update list entry for each correspondent router. 6.2.2. Return Routability In Mobile IPv6, a mobile host provides reasonable assurance with the correspondent nodes through the return routability mechanism, and securely register its binding. A correspondent router is similar to the correspondent node in terms of security relationship with a mobile router. Although IPsec provides stubborn security for binding registration, it is expensive operations for both a mobile router and a correspondent router. The ORC follows similar approach to Mobile IPv6 so that secured binding registration is performed with the return routability mechanism. It is necessary to extend the return routability procedure to register mobile network prefix information. To complete return routability for a mobile network, a mobile router is required to generate its home address from its mobile network prefix instead of its home network. In Mobile IPv6, return routability procedure plays two roles when authenticating a binding update. One is to verify if the binding between the home address and the care-of address is legit, The other role is to exchange keys for authorizing binding update. In the optimized route cache protocol, following extensions are required in addition to return routability procedure. The home agent must verify the HoTI that is securely tunneled from the mobile router. The HoTI should be checked for its source address and prefix length. Wakikawa and Watari Expires 24 Apr 2005 [Page 12] Internet Draft ORC 24 Oct 2004 HoTI will be sent with the home address as the source address, generated from the mobile network prefix. Thus, if the source address does not match the home address registered in home agent's binding, the home agent discards the HoTI. Furthermore, if the prefix length registered for the mobile router is different from the prefix sub-option sent, the home agent also discards the HoTI. On the other hand, CoTI will be sent with the care-of address as its source address. Once the mobile router receives both HoT and CoT back from the correspondent router, it is assured that the mobile router exists in topologically correct attachment point and also assures that it is the router of the network with the mobile network prefix. The mobile router can now send a binding update to the correspondent router with the keys exchanged in return routability. If the correspondent router can recompute the encryption, the binding update completes in success. When a mobile router sends a binding update, it must set the binding acknowledge flag in order for it to receive a binding acknowledgment message from the recipient. The correspondent router must return a binding acknowledgment message containing a list of managed prefixes of its IGP domain in the managed prefix mobility option. The managed prefix mobility option is defined in section 5.2.3. If the binding update is successfully processed by the correspondent router, the mobile router establishes a bi-directional tunnel with the correspondent router as in [5]. The mobile router also records the pair of the prefixes retrieved from the managed prefix mobility option and the correspondent router's address as route entries in its routing table. These routes may be used to search a correspondent router in a routing table when the mobile router sends packet to correspondent nodes described in section 6.4. 6.3. Intercepting Packets by Correspondent Router A correspondent router basically intercepts packets for a registered mobile router by IP level routing. However, there is different operations depending on correspondent router's topological location. If a correspondent router is located as a gateway router of a network, it intercepts packets by parsing all packets' destination address with registered bindings. On the other hand, if a correspondent router is located in a network, it MUST advertise a proxy route for a mobile network prefix of registered binding to its routing domain. All routers in the same routing domain forward packets meant for the mobile network prefix to the correspondent router who is advertising the prefix route. Wakikawa and Watari Expires 24 Apr 2005 [Page 13] Internet Draft ORC 24 Oct 2004 6.4. Routing to Mobile Network Whenever a correspondent router receives packets and query routing table as general router operations, it also searches for binding cache for a destination address in the IPv6 header just like any home agent. The correspondent router should select the prefix longest matched binding and route for the destination. When the correspondent router finds the prefix longest matched binding for the destination, it must search binding cache database recursively for the next hop address of the binding and must select the last matched binding for the destination. This recursive operation is aimed to support nested mobility. Once the correspondent router finds a binding instead of an IGP route for outgoing packets, it tunnels the packets directly to the care-of address of the destination according to the registered binding. For the opposite direction, the mobile router may reverse tunnel packets to the correspondent router at correspondent node's IGP domain which is found with route of the correspondent router's managed prefixes in mobile router's routing table. The correspondent router then decapsulates packets and route them to a correspondent node. The mobile router does not insert the home address option as Mobile IPv6, since falsification of mobile network node's packets on intermediate nodes like the mobile router should be avoided for security considerations. The encapsulation of packets adds additional IPv6 header, and it does not change original packets. 7. Security Consideration The optimized route cache protocol enables to manage routing information across AS boundaries. In other words, it is possible for a mobile router to alter routing table of opposite routers. Wrong binding registrations will cause opposite ASs to fall into confusion or to have black-hole of routing. The ORC employees Mobile IPv6 security mechanism [5] for protecting binding updates which are the IPsec authentication header [1] and the return routability scheme. Furthermore, recipient routers can apply their IGP domain or AS routing policies to handle each binding. 8. Acknowledgements The authors would like to thank Keisuke Uehara, Susumu Koshiba, Jun Murai, and WIDE Project for their contributions. Wakikawa and Watari Expires 24 Apr 2005 [Page 14] Internet Draft ORC 24 Oct 2004 References [1] R. Atkinson. IP Authentication Header. Request for Comments (Proposed Standard) 1826, Internet Engineering Task Force, August 1995. [2] A. Conta and S. Deering. Generic Packet Tunneling in IPv6 Specification. Request for Comments (Proposed Standard) 2473, Internet Engineering Task Force, December 1998. [3] Thierry E. et al. Network Mobility Support Terminology. Internet Draft, Internet Engineering Task Force, February 2002. [4] Vijay Devarapalli. et al. Network Mobility (NEMO) Basic Support Protocol. Internet Draft, Internet Engineering Task Force, June 2004. [5] David B. Johnson, C. Perkins, and Jari Arkko. Mobility Support in IPv6. Request For Comments 3775, Internet Engineering Task Force, June 2004. [6] Y. Rekhter and T. Li. A Border Gateway Protocol 4 (BGP-4). Request for Comments (Draft Standard) 1771, Internet Engineering Task Force, March 1995. [7] P. Thubert, M. Molteni, C. Ng, and E. Ohnishi, H. Paik. Taxonomy of Route Optimization models in the Nemo context (work in progress). Internet Draft, Internet Engineering Task Force, February 2004. [8] R. Wakikawa, S. Koshiba, K. Uehara, and J. Murai. ORC: Optimized Route Cache Management Protocol for Network Mobility. In The 10th International Conference on Telecommunication (ICT) 2003, pages 119--126, February 2003. Wakikawa and Watari Expires 24 Apr 2005 [Page 15] Internet Draft ORC 24 Oct 2004 Authors' Addresses Ryuji Wakikawa Graduate School of Media and Governance, KEIO University 5322 Endo Fujisawa Kanagawa, 252-8520 JAPAN Phone: +81-466-49-1100 EMail: ryuji@sfc.wide.ad.jp Fax: +81-466-49-1395 Masafumi Watari Graduate School of Media and Governance, KEIO University 5322 Endo Fujisawa Kanagawa, 252-8520 JAPAN Phone: +81-466-49-1100 EMail: watari@sfc.wide.ad.jp Fax: +81-466-49-1395 Wakikawa and Watari Expires 24 Apr 2005 [Page 16] Internet Draft ORC 24 Oct 2004 A. Example Scenario Figure 1 shows the configuration of the optimized route cache protocol. In the figure, there are five ASs connected to each other by Border Gateway Protocol (BGP) [6]. This can be assumed to be typical Internet BGP routing topology. In Mobile IPv6 and the NEMO Basic Support protocol, a home agent is an original anchor router of a mobile network and maintains a binding of the mobile network persistently. All packets are first routed to the home agent and are tunneled to the mobile router by the home agent unless the mobile router starts route optimization. Therefore, in the case when correspondent nodes in AS3 communicates with the mobile network nodes in AS5, packets must first be routed to the HA in AS2 via AS1, before being tunneled to the destination nodes. On the other hand, the optimized route cache protocol introduces correspondent routers that can be configured anywhere in the Internet to be an anchor router, providing route optimization. Practically, the correspondent routers should be placed on expected networks where there exist correspondent nodes for a mobile router and a | | +----+ |----| | HA | Home Agent Correspondent Router | | +----+ AS2 +----+ | +-------------------------------- | CR | | +----+ | +------------------------ AS1 +------------+ ---------+---------+ | +--------+ + CN | | | Router |----+ CN ---------+-----------+ | +--------+ + CN AS4 +----+ +----------+ AS3 | CR | | +----+------------------- +----+ | | | | +---------+------------------- +--+--+ | | AS5 CN CN CN | | +----+ Correspondent Nodes | | | MR | Mobile Router | +-+--+ | | | +---+---+- Mobile Network | MNN MNN MNN | Mobile Network Nodes Figure 1: Optimized Route Cache Protocol Overview Wakikawa and Watari Expires 24 Apr 2005 [Page 17] Internet Draft ORC 24 Oct 2004 mobile network because it is impossible to replace all routers on the Internet with the correspondent routers support. It is effective to place a correspondent router where traffic is converged like Internet Exchange Point (IXP). Whenever a mobile router moves, correspondent routers may receive a binding update notification on-demand from the mobile router and cache them. The correspondent router must authorize the mobile network to receive the binding as described in section 6.2. After creation of the binding, the correspondent router intercepts packets destined to the mobile network, and tunnels them to the care-of address which is registered in the binding. For example, as soon as one of the nodes inside AS4 communicates with the mobile network the mobile router registers its binding to the correspondent router in AS4. After the registration, any packets meant for the mobile network from AS4 are always intercepted by the correspondent router and tunneled to the mobile router. On the return path, the mobile router could tunnel packets that are sent to AS4 to the correspondent router by IP-in-IP encapsulation [2]. All correspondent routers advertise a proxy route of the mobile prefix to capture packets destined to the mobile network by routing protocols regardless of IGP or EGP. The proxy route may not be inter-exchanged by correspondent routers with any Exterior Gateway Protocol (EGP) such as BGP. The correspondent route advertises the proxy route only while the received binding is valid. After the binding expiration, the correspondent router removes the proxy route from the routing table. Thus, it may lead to frequent changes on BGP routing tables that is not desired on the Internet. Correspondent routers can intercept packets that are from transit AS. For instance, if a correspondent node in AS3 send packets to the mobile network, the packets are routed towards the home agent since there are no correspondent routers in AS3. However, on the way to the home agent, a correspondent router in AS1 which is the transit AS of AS3, can intercept the packets and tunnels them directly to the mobile router. The proxy route is not a binding, but it contains the mobile prefix as a destination and the correspondent router's address as the next hop. The proxy route will not be aggregated in correspondent router's IGP domain. The correspondent router can reject receiving a binding of any mobile network according to administrative policies, because the advertisement of unaggregatable routes may swell routing entries on routers. According to routing management policies of each AS, correspondent routers should be approved to provide services for mobile router from their affiliated IGP domain. Wakikawa and Watari Expires 24 Apr 2005 [Page 18] Internet Draft ORC 24 Oct 2004 B. Correspondent Router Hierarchy Figure 2 shows the case where the mobile router selects the correspondent router that has shorter prefix. In this case, the correspondent router advertises the proxy route(PR) for the mobile router to one router nearby. Since two routers are configured as border routers, packets sent to the mobile router are routed to one of routers according to the default route of other routers. Once the router having the proxy route intercepts the packets, it re-routes the packets to the correspondent router. Finally the correspondent router tunnels the packets to the mobile router. Figure 3 shows the case where the mobile router selects the correspondent router configured at the leaf network. The correspondent router advertises the proxy route for the mobile router to other routers in the same network domain. Otherwise, packets are silently routed to the Internet without interception of the correspondent router. Packets sent to the mobile router are routed to one of routers according to the proxy route and then routed to the Mobile Router + | +-----+-------------+ | Internet | +--+------------+---+ | | +-----+--+ +--+-----+ | CR +------+ Router | /32 network +-BC--+--+ +--+--PR-+ Binding Cache / " / " Proxy Route / " / " / " / " +------+-+ +-+----+-+ +-+------+ | Router | | Router | | Router | /48 network +--------+ +---+----+ +--------+ | +---+----+ | Router | /64 network +---+----+ | +--+--+--+--+ CN CN CN CN CN Correspondent Nodes Figure 2: Registration to Higher Router Wakikawa and Watari Expires 24 Apr 2005 [Page 19] Internet Draft ORC 24 Oct 2004 correspondent router. The correspondent router tunnels these packets to the mobile router. As a result, the route may become longer than the route between the higher route and the mobile router according to the tunnel end point. It is better to activate a correspondent router located higher in the network hierarchy in terms of proxy route advertisements and shorter bi-directional tunnel between a correspondent router and a mobile node. However, corruption of higher router causes the network separation from the Internet. Thus, higher routers administratively prohibits the correspondent router support. Increasing the number of correspondent routers caring the mobile network is an important factor to optimize routes between a mobile node and correspondent nodes as much as possible. By contrast, the optimized route cache protocol does not always force to have a number of correspondent routers. Binding registrations to all the correspondent routers bring considerable overheads to a mobile router and prevents scalability and quickness of movement processing. Mobile Router + | +-----+-------------+ | Internet | +--+------------+---+ | | +-----+--+ +--+-----+ | Router +------+ Router | /32 network +-PR--+--+ +--+--PR-+ Proxy Route / " / " Proxy Route / " / " / " / " +------+-+ +-+----+-+ +-+------+ | Router | | Router | | Router | /48 network +-PR-----+ +---+-PR-+ +-----PR-+ | +---+----+ | CR | /64 network +---+-BC-+ | Binding Cache +--+--+--+--+ CN CN CN CN CN Correspondent Nodes Figure 3: Registration to Lower Router Wakikawa and Watari Expires 24 Apr 2005 [Page 20] Internet Draft ORC 24 Oct 2004 C. Modifications from the last version - remove nested mobile networks support - fix a few typo and packet formats Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Wakikawa and Watari Expires 24 Apr 2005 [Page 21] Internet Draft ORC 24 Oct 2004 Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Wakikawa and Watari Expires 24 Apr 2005 [Page 22]