INTERNET DRAFT Ryuji Wakikawa 10 July 2004 Masafumi Watari Keio Univ./WIDE Optimized Route Cache Protocol (ORC) draft-wakikawa-nemo-orc-00.txt Status of This Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I 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. 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 as if routing information of each mobile network are located at special routers called ``Correspondent Router''. Contents Status of This Memo i Abstract i R. Wakikawa et.al. Expires 10 January 2005 [Page i] Internet Draft ORC 10 July 2004 1. Introduction 2 2. ORC Concept 2 3. Terminology 3 4. ORC Overview 4 4.1. Correspondent Router Discovery . . . . . . . . . . . . . 4 4.2. Binding Registration to Correspondent Router . . . . . . 4 4.3. Forwarding between Mobile Router and Correspondent Router 5 5. Extensions to Mobile IPv6 and the Basic NEMO protocol 5 5.1. Forwarding Table Data Structure . . . . . . . . . . . . . 5 5.2. Mobility Header Messages . . . . . . . . . . . . . . . . 6 5.2.1. Binding Update . . . . . . . . . . . . . . . . . 6 5.2.2. Binding Acknowledgment . . . . . . . . . . . . . 6 5.2.3. Managed Prefix Lists sub-option . . . . . . . . . 6 5.3. New ICMP Messages . . . . . . . . . . . . . . . . . . . . 7 5.3.1. Correspondent Router Discovery Request . . . . . 7 5.3.2. Correspondent Router Discovery Reply . . . . . . 8 6. Protocol Operations 10 6.1. Correspondent Router Discovery . . . . . . . . . . . . . 10 6.2. Binding Registration to Correspondent Router . . . . . . 11 6.2.1. Sending Binding Update . . . . . . . . . . . . . 11 6.2.2. Return Routability . . . . . . . . . . . . . . . 11 6.3. Intercepting Packets by Correspondent Router . . . . . . 12 6.4. Routing to Mobile Network . . . . . . . . . . . . . . . . 13 7. Support for Nested Mobile Networks 13 8. Security Consideration 14 9. Acknowledgements 14 References 14 Authors' Addresses 15 Appendices 16 A. Example Scenario 16 B. Correspondent Router Hierarchy 18 C. Route Optimization in Nested Mobile Network 20 R. Wakikawa et.al. Expires 10 January 2005 [Page 1] Internet Draft ORC 10 July 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 is kind of a best effect routing protocol, where the path is only optimized where 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 R. Wakikawa et.al. Expires 10 January 2005 [Page 2] Internet Draft ORC 10 July 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 forward 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. R. Wakikawa et.al. Expires 10 January 2005 [Page 3] Internet Draft ORC 10 July 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). R. Wakikawa et.al. Expires 10 January 2005 [Page 4] Internet Draft ORC 10 July 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 Home Agent 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 R. Wakikawa et.al. Expires 10 January 2005 [Page 5] Internet Draft ORC 10 July 2004 5.2. Mobility Header Messages 5.2.1. Binding Update +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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. R. Wakikawa et.al. Expires 10 January 2005 [Page 6] Internet Draft ORC 10 July 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. R. Wakikawa et.al. Expires 10 January 2005 [Page 7] Internet Draft ORC 10 July 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. R. Wakikawa et.al. Expires 10 January 2005 [Page 8] Internet Draft ORC 10 July 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 R. Wakikawa et.al. Expires 10 January 2005 [Page 9] Internet Draft ORC 10 July 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 R. Wakikawa et.al. Expires 10 January 2005 [Page 10] Internet Draft ORC 10 July 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. R. Wakikawa et.al. Expires 10 January 2005 [Page 11] Internet Draft ORC 10 July 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. R. Wakikawa et.al. Expires 10 January 2005 [Page 12] Internet Draft ORC 10 July 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 hope 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. Support for Nested Mobile Networks The optimized route cache protocol allows route optimization in nested mobile networks. The route optimization in optimized route cache protocol allows bypassing of all HAs which are serving the mobile routers in the nested mobile network, and create a direct path from the mobile network node to the correspondent node. The concept of route optimization in optimized route cache protocol is to achieve optimized route between the correspondent router and the nested mobile network with only a single tunnel encapsulation, together with routing headers, if necssary. The routes for each mobile network in the nest are assumed to be exchanged among the each mobile routers. This can be done by using a kind of an ad-hoc routing protocol, or extending router advertisement messages, as described in Appendix C. The route optimization is fully controlled and triggered by the sub mobile routers for which it's carrying the mobile network, and is independent from the root mobile router. In other words, the root mobile routers does not need to maintain information of the mobile R. Wakikawa et.al. Expires 10 January 2005 [Page 13] Internet Draft ORC 10 July 2004 routers attached behind them, for example maintaining binding update lists and sending binding update messages on behalf of them. 8. 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. 9. Acknowledgements The authors would like to thank Keisuke Uehara, Susumu Koshiba, Jun Murai, and WIDE Project for their contributions. 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. R. Wakikawa et.al. Expires 10 January 2005 [Page 14] Internet Draft ORC 10 July 2004 [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. 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 R. Wakikawa et.al. Expires 10 January 2005 [Page 15] Internet Draft ORC 10 July 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 R. Wakikawa et.al. Expires 10 January 2005 [Page 16] Internet Draft ORC 10 July 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. R. Wakikawa et.al. Expires 10 January 2005 [Page 17] Internet Draft ORC 10 July 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 Correspondent Node + | +-----+-------------+ | 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 R. Wakikawa et.al. Expires 10 January 2005 [Page 18] Internet Draft ORC 10 July 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. Correspondent Node + | +-----+-------------+ | 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 R. Wakikawa et.al. Expires 10 January 2005 [Page 19] Internet Draft ORC 10 July 2004 C. Route Optimization in Nested Mobile Network The optimized route cache protocol allows route optimization in nested mobile networks. The route optimization in optimized route cache protocol allows bypassing of all HAs which are serving the mobile routers in the nested mobile network, and create a direct path from the mobile network node to the correspondent node. In providing such optimized route, we introduce a new mechanism called, ``a reflective binding update'', which is sent by the correspondent router in reflect to a request for a route optimization sent by the sub mobile router. The reflective binding update is used to maintain bindings at the correspondent router for the nested mobile network. Figure 4 shows a simple case where the nested level is two, and the correspondent node is located behind the correspondent router. The route optimization is fully controlled and triggered by the sub-MR, and is independent from the root-MR. Therefore, the root-MR does not need to maintain information of the mobile routers attached behind them. The correspondent router in the figure can also be a mobile router with another mobile router behind it. Even if both communicating sides are nested mobile networks, the optimized route cache protocol can create an optimized route. +-----+ +-----+ | HA1 | | HA2 | Home Agents +--+--+ +--+--+ | | +--+-------------+--+ | Internet | +-+---------------+-+ | | +----+---+ +--+-----+ root-MR | MR1 | | CR | Correspondent Router +-+------+ +------+-+ | | +------+-+ +--+--+--+--+ sub-MR | MR2 | CN CN CN CN CN +----+---+ Correspondent Nodes | +---+---+---+ MNN MNN MNN MNN Mobile Network Nodes Figure 4: Route Optimization in Nested Mobile Networks R. Wakikawa et.al. Expires 10 January 2005 [Page 20] Internet Draft ORC 10 July 2004 The route optimization is first initialized by the sub-MR when receiving a forwarded packet from its home agent. If the sub-MR in the nested mobile network decides that route optimization is needed, it sends a correspondent router discovery request to the correspondent network if necessary, as described in section 4.1. The decision can be based on protocols, port numbers, or the amount of tunneled packets received from a specific source address. After receiving a valid correspondent router discovery reply, the sub-MR sends a binding update to the correspondent router, indicating a request for a route optimization in the nested mobile network. The indication is done with a corresponding flag in the binding update message, together with the care of address of the root-MR in the binding update message sub-option. The care of address of the root-MR is originally notified to the sub-MR by extending the router advertisement message sent from the root-MR. When the correspondent router receives the binding update message, it returns a binding acknowledgment to the sending mobile router, and retrieves the care of address of the root-MR. The correspondent router then sends a binding update message to the root-MR for the network claimed by the correspondent router. This binding update messages is called, ``a reflective binding update''. After a successful creation of the bindings between the correspondent router and the root-MR, packets meant for the mobile network under the sub-MR are directly tunneled to the sub-MR at the correspondent router, together with the routing header for the root-MR. Likewise, packets meant for the correspondent network are directly tunneled to the correspondent router with the routing header for the root-MR. The router advertisement message sent by the mobile routers should be extended to support route optimization. Precisely, the router advertisement should include the care of address of the mobile router's egress interface. If incase the care of address of the mobile router changes due to movements, the new care of address should be advertised with the router advertisement message. When the sub-MR detects the change of the care of address in the router advertisement message, it should then send a new binding update message to the correspondent router. Since invalid binding at the correspondent router will only cause the packets to go via the home agent, it is not critical for operation. R. Wakikawa et.al. Expires 10 January 2005 [Page 21] Internet Draft ORC 10 July 2004 Full Copyright Statement Copyright (C) The Internet Society (2003). 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 implementation 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 languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. R. Wakikawa et.al. Expires 10 January 2005 [Page 22]