NEMO Working Group S. Baek Internet-Draft J. Yoo Expires: April 20, 2006 T. Kwon Seoul National University E. Paik M. Nam KT October 17, 2005 Routing Optimization in the same nested mobile network draft-baek-nemo-nested-ro-00.txt Status of this Memo 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 becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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. This Internet-Draft will expire on April 20, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document describes a nested NEMO Route Opimization (NNRO) protocol for the communications between any two nodes in the same nested mobile network. A nested NEMO Route Opimization message is used to exchange the routing information between two mobile network Baek, et al. Expires April 20, 2006 [Page 1] Internet-Draft RO in the same nested mobile network October 2005 nodes in the same nested mobile network. The protocol is designed in a way such that the mobility of the entire nested mobile network is transparent to the nodes therein. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Overview of NNRO Operation . . . . . . . . . . . . . . . . . . 4 4. Changes to Existing Protocol . . . . . . . . . . . . . . . . . 4 4.1 IPv6 Neighbor Discovery . . . . . . . . . . . . . . . . . 4 4.2 Conceptual Data Sturctures in Mobile Router . . . . . . . 5 5. Message Formats for Route Optimization . . . . . . . . . . . . 6 5.1 Nested NEMO Route Optimization Message . . . . . . . . . . 6 6. Operations of Mobile Routers . . . . . . . . . . . . . . . . . 8 6.1 Sending NNRO Messages . . . . . . . . . . . . . . . . . . 8 6.2 Updating Forwading Table . . . . . . . . . . . . . . . . . 8 6.3 Forwarding Packets . . . . . . . . . . . . . . . . . . . . 9 7. Design Considerations . . . . . . . . . . . . . . . . . . . . 9 7.1 Compatability with VMN . . . . . . . . . . . . . . . . . . 9 7.2 Mobility Considerations . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . 12 Baek, et al. Expires April 20, 2006 [Page 2] Internet-Draft RO in the same nested mobile network October 2005 1. Introduction A mobile network (NEMO) is a network whose point of attachment to the Internet varies as it moves about [1, 2]. A mobile network consists of mobile routers (MRs) and mobile network nodes (MNNs). When the mobile network changes its point of attachment, the MNNs can communicate with corresponding nodes without need to know about the movements. To do this, all traffic to and from MNNs is forwarded through the bi-directional tunnel between the MR and MR's home agent (HA). Therefore, sub-optimality occurs in the path between the two nodes [3]. When the mobile network is nested, this sub-optimality is amplified as all the traffic between two nodes should be routed through the HAs of the nested MRs. Especially, when the two nodes are within a nested mobile network, the sub-optimality is notable although the two nodes are located within the same nested mobile network. Besides, this sub-optimality causes the tunneling overhead. This document proposes a nested NEMO routing optimization (NNRO) protocol to improve the communication overhead between two MNNs within the same nested mobile network. This protocol makes the traffic between two MNNs in the same nested NEMO to be routed directly without a traversing HAs of the nested MRs. 2. Terminology MR mobile router. HA home agent. MNN mobile network node. MNNs such as VMN and LFN are nodes in a mobile network. VMN visiting mobile node. A VMN is temporarily attached to the MR's subnet by obtaining its CoA from the mobile network prefix. Baek, et al. Expires April 20, 2006 [Page 3] Internet-Draft RO in the same nested mobile network October 2005 LFN visiting mobile node. local fixed node. This belongs to the mobile network and is unable to change its point of attachment. 3. Overview of NNRO Operation An MR multicasts route optimization messages that contain reachable destinations and their path metrics to the MR's one hop neighbor MRs. The route optimization messages are transmitted by an IPv6 Link Local Multicast to the MR's lower MRs in ingress interface and by an unicast to the MR's upper MR in egress interface. After the neighbor (lower and upper) MRs receive these route optimization messages, they transmit not only their own information of reachable destinations but also the received information from their neighbors. Consquently, the information of mobile network prefixes is delivered to all of the MRs in the nested mobile network. Based on this information, the MRs in the nested mobile network construct forwarding tables for the mobile network prefixes in the nested mobile network. Each forwarding table has entries, each of which contains the mobile network prefix, the path metric of the destination, the next hop, and the life time of the entry. Before the MR forwards packets through the bi-directional tunnel, it searches the forwarding table. If the MR finds out an entry that matches the destination of the packet, it forwards the packet to the next hop MR, not performing the bi-directional tunneling with its HA. Otherwise, the MR acts as specified in NEMO basic support protocol [2]. 4. Changes to Existing Protocol The proposed NNRO protocol requires some modifications for NEMO basic support protocol [2] and IPv6 Neighbor Discovery protocol [5]. 4.1 IPv6 Neighbor Discovery A new flag (N) is included in the Router Advertisement Message to indicate to the MRs in the ingress interface whether the MR supports NNRO protocol in the same nested NEMO or not [5]. Baek, et al. Expires April 20, 2006 [Page 4] Internet-Draft RO in the same nested mobile network October 2005 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cur Hop Limit |M|O|N| Reserved| Router Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reachable Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Retrans Timer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+-+-+-+-+-+-+-+- Route Optimization in the same nested NEMO flag (N) The N flag is set to indicate to the MRs in the egress interface whether the sending MR supports the Route Opimization in the same neseted NEMO. For descriptions of the other fields in the message, see [5]. 4.2 Conceptual Data Sturctures in Mobile Router An MR maintains a Forwarding Table, described in section 3. The Forwarding Table is a data structure that records the reachability to the MNNs in the same nested mobile network. There is one entry per each Mobile Network Prefix. Each Forwarding Table Entry (FTE) conceptually contains the following fields: o The Mobile Network Prefix of the MRs in the same nested mobile network. This field is used as the key for searching the Forwarding Table for the destination address of a packet being forwarded. o The metric field is the cost at which the next hop MR can deliver packets to the destination. o The next hop field is the address of the MR to which packets are forwarded. Baek, et al. Expires April 20, 2006 [Page 5] Internet-Draft RO in the same nested mobile network October 2005 o A lifetime value, indicating the remaining lifetime for this FTE. The lifetime value is updated whenever NNRO messages are received. 5. Message Formats for Route Optimization 5.1 Nested NEMO Route Optimization Message The Nested NEMO Route Optimization (NNRO) message is used by an MR to notify other MRs in the same nested NEMO of a recheability for the entries. Each MR that supports nested NEMO Route Optimization has a process that sends and receives this NNRO message. The NNRO message will use a new MH Type value (say 11). The format of the Message Data field in the Mobility Header is as follows [4]: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |D|R|P| | # of entries | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Forwarding Table Entry 1 (20) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ ... ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Forwarding Table Entry N (20) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where each Forwarding Table Entry (FTE) has the following format: Baek, et al. Expires April 20, 2006 [Page 6] Internet-Draft RO in the same nested mobile network October 2005 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Mobile Network Prefix ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix Length | Metric | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Default (D) The Default (D) bit is set by the sending MR when it sends NNRO messages periodically. Request (R) The Request (R) bit is set by the sending MR to request that one hop neighbor MRs should send its whole FTE. Response (P) The Response (P) bit is set when the MR responds to the NNRO message with the R bit set. # of entries The number of entries indicates the number of entries in the NNRO message. Mobile Network Prefix A sixteen-byte field containing the Mobile Network Prefix. Prefix Length Eight-bit unsigned integer indicating the prefix length of the IPv6 prefix contained in the FTE. Baek, et al. Expires April 20, 2006 [Page 7] Internet-Draft RO in the same nested mobile network October 2005 Metric Eight-bit unsigned integer indicating the cost to reach that destination. 6. Operations of Mobile Routers 6.1 Sending NNRO Messages The MR sends the NNRO messages to its ingress interface and its egress interface periodically. When the MR sends NNRO messages to its ingress interface and its egress interface, the source IP address field of that packet is set to the HoA and the CoA of the MR, respectively. When an MR starts its operation, there is only one entry in the Forwarding Table, which contains its own mobile network prefix. As the NNRO messages from other MRs propagates, the number of entries FTE will be incremented. An MR updates its Forwarding Table as described in Section 6.2. When the Forwarding Table is updated, the MR sends the NNRO message containing the updated FTEs immediately. 6.2 Updating Forwading Table Initially, an MR has an entry about its Mobile Network Prefix in the Forwarding Table. This entry has the minimum Metric value. When an MR receives the NNRO messages from its neighbor MRs, it updates its Forwarding Table based on the following criterion. New FTE: When an MR receives the FTE that is not in the its Forwarding Table, it inserts a new entry for that destination. Better Metric FTE : When an MR receives an entry with a better metric, it modifies the Metric and the Next Hop values of the existing entry. Otherwise : Otherwise, an MR ignores the FTE. When inserting the new entries or modifying the exsting entries, the MR sets the Next Hop to the source IPv6 address of the NNRO messages. Baek, et al. Expires April 20, 2006 [Page 8] Internet-Draft RO in the same nested mobile network October 2005 6.3 Forwarding Packets When the MR receives a data packet, it searches the Forwarding Table to find out entries that matches the destination IPv6 address of the packet before the MR forwards the packet through the bi-directional tunnel. If the MR finds out the matched entry, it forwards the packet to the MR Next Hop in the Forwarding Table without tunneling. Otherwise, the MR forwards the packet through the bi-directional tunnel based on the NEMO basic support protocol [2]. 7. Design Considerations 7.1 Compatability with VMN Besides communication between an LFN and another LFN in the same nested mobile network, the proposed NNRO protocol supports route opimization between an LFN and a VMN or between a VMN and another VMN. VMNs conforms to Mobile IPv6 protocol [4]. According to Moble IPv6 protocol, a mobile node can establish optimal route through binding uptate directly to the correspondent node. After the procedure of binding update to the correspondent node, the destination address of the packet is the CoA of the VMN using type 2 routing header when the LFN sends packets to the VMN in the same nested mobile network. Therefore, the MR used by the VMN can forward the packet to the VMN by searching the Forwarding Table. 7.2 Mobility Considerations If the entire nested mobile network moves together and changes its point of attachment, the additional operations in the nested mobile network are not needed. The MRs in the nested mobile network are transparent to this movement. However, if an MR in the nested mobile network goes away, the topology of the nested mobile network is changed, and the Forwarding Table Entry of the MR in the other MRs will be deleted. 8. References [1] Ernst, T. and H. Lach, "Network Mobility Support Terminology", draft-ietf-nemo-terminology-03 (work in progress), February 2005. [2] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005. [3] Ng, C., "Network Mobility Route Optimization Problem Statement", draft-ietf-nemo-ro-problem-statement-01 (work in progress), Baek, et al. Expires April 20, 2006 [Page 9] Internet-Draft RO in the same nested mobile network October 2005 October 2005. [4] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [5] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. Authors' Addresses Sungmin baek Seoul National University Multimedia and Mobile Communications Lab., Seoul National Univ. Shillim-dong, Kwanak-gu Seoul 151-744 Korea Phone: +82-2-880-9147 Fax: +82-872-2045 Email: smbaek@mmlab.snu.ac.kr URI: http://mmlab.snu.ac.kr/~smbaek/ Jinkyu Yoo Seoul National University Multimedia and Mobile Communications Lab., Seoul National Univ. Shillim-dong, Kwanak-gu Seoul 151-744 Korea Phone: +82-2-880-9147 Fax: +82-872-2045 Email: jkyoo@mmlab.snu.ac.kr URI: http://mmlab.snu.ac.kr/~jkyoo/ Baek, et al. Expires April 20, 2006 [Page 10] Internet-Draft RO in the same nested mobile network October 2005 Taekyoung Kwon Seoul National University Multimedia and Mobile Communications Lab., Seoul National Univ. Shillim-dong, Kwanak-gu Seoul 151-744 Korea Phone: +82-2-880-9105 Fax: +82-872-2045 Email: tkkwon@snu.ac.kr URI: http://mmlab.snu.ac.kr/~tk/ Eunkyoung Paik KT Portable Internet Team, Convergence Business Unit, KT 17 Woomyeon-dong, Seocho-gu Seoul 137-792 Korea Phone: +82-2-526-5233 Fax: +82-2-526-5200 Email: euna@kt.co.kr URI: http://mmlab.snu.ac.kr/~eun/ Minji Nam KT Portable Internet Team, Convergence Business Unit, KT 17 Woomyeon-dong, Seocho-gu Seoul 137-792 Korea Phone: +82-2-526-6121 Fax: +82-2-526-5200 Email: mjnam@kt.co.kr URI: http://mmlab.snu.ac.kr/~mjnam/ Baek, et al. Expires April 20, 2006 [Page 11] Internet-Draft RO in the same nested mobile network October 2005 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 (2005). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Baek, et al. Expires April 20, 2006 [Page 12]