NEMO Working Group Jongkeun Na Internet Draft Seongho Cho Expires: January 2005 Chongkwon Kim Seoul National University Changhoi Koo Samsung Electronics July 2004 Generic Route Optimization Model for NEMO Extended Support draft-na-nemo-gen-ro-model-00 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 In this memo, we introduce the generic Route Optimization (RO) model that can be used as a framework to evaluate the existing RO models. Then, we analyze typical RO problems by virtue of that. And, we discuss on the feasibility of achieving a unified RO in NEMO, Na, et al. Expires - January 2005 [Page 1] Internet Draft Generic RO Model July 2004 and enumerate the issues that should be cleared for the purpose of that. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119. Table of Contents 1. Introduction.................................................3 2. Generic Route Optimization Model.............................3 3. The Analysis of RO Problems in NEMO..........................5 3.1 RO in the infrastructure................................6 3.2 Nested Tunnels Optimization (NTO).......................7 4. Toward to a unified route optimization in NEMO...............8 5. Open Issues..................................................9 6. Security Considerations......................................9 References......................................................10 Acknowledgments.................................................11 Authors' Addresses..............................................11 Na, et al. Expires - January 2005 [Page 2] Internet Draft Generic RO Model July 2004 1. Introduction NEMO Basic Support Protocol [15] would suppose to support the transparent mobility to mobile network nodes (MNNs) in mobile networks by using MR-HA bi-directional tunnel. However, inherently due to the use of the bi-directional tunnel, there are some types of route optimization problem [14] that need our attention. RO problems have a common property that there is an optimized path, but it cannot be used due to support the transparent mobility to the IP terminals. While preserving the goals of Mobile IP [1] and NEMO Basic [15], it is impossible to realize RO without introducing the tunnel-based virtual path over IP routing through some extensions or new functionalities of routing facilities. This is the reason why the existing proposed solutions for RO at least use tunnel-based packet redirection or re-routing mechanism in the extended routing facilities such as Correspondent Router (CR). As a requirement about RO, we argue that RO in NEMO should be provided by a unified solution which can solve most of RO problems by applying the same principle to the routing facilities such as HA, MR, CR. If each different RO solution is used to solve each RO problem, it will produce the protocol redundancy and complexity in the routing facilities. In this memo, we introduce the generic RO model that can be used as a framework to evaluate the existing RO models. Then, we analyze typical RO problems by virtue of the generic RO model. And, we discuss on the feasibility of achieving a unified RO in NEMO, and enumerate the issues that should be cleared for the purpose of that. 2. Generic Route Optimization Model Route Optimization in NEMO means that one routing entity uses an IP tunnel to redirect the original packets to the other routing entity that is most closely located from the destination. To enable such a route optimization, two routing entities must recognize each other, in other words, anyone among them should feel the need of RO tunnel and initiate the signaling procedure to make an IP tunnel between them. We can define such an IP tunnel as `RO Tunnel (ROT)` in NEMO context because it is established for the purpose of route optimization in NEMO. This is like the basic principle of Mobile IP. In Mobile IP, MN detects its movement and initiates BU to HA. Such an analogy can be extended to RO problem in NEMO. In this point of view, we can extract some of statements characterizing how to achieve RO tunnel. For example, which routing facilities can initiate RO tunnel? What information does trigger such a RO tunnel? Na, et al. Expires - January 2005 [Page 3] Internet Draft Generic RO Model July 2004 How can the trigger information be delivered to the initiator of RO tunnel? And so on. The answer to those of questions depends on the problem spaces [14] and the proposed solutions [4][5][19][20] in each problem space. The attributes of RO tunnel can concretely well express the RO context including the purpose of RO, the operation of RO, and the effectiveness of RO. TE[1] TS[0..n] TR[0..n] TE[1] +--+---------+--+--------+--+--------+--+ ====|XX|=========|XX|========|==|========|XX|==== +--+---------+--+--------+--+--------+--+ XX: Tunnel Processing (Encap./Decap.) TE: Tunnel Endpoint TS: Tunnel Switcher TR: Tunnel Relay Fig.1 Generic RO Tunnel (ROT) Model Fig.1 shows the generalized ROT model. ROT can be made of at least two TEs. In here, TE is a router or host which is allowed to initiate or terminate the RO tunnel in the view of route optimization. According to the type of ROT, ROT can include zero or more TS for switching an incoming tunnel to an outgoing tunnel at that point, zero or more TR for relaying the tunneled packets to next intermediate point. As of TR, The difference is that it operates a routing mechanism, such as Source Routing using RH0 header [10], based on the packet header information without the knowledge of the end-to-end tunneling, while TS processes the tunnel switching based on a given tunnel mapping information that consistently maintained in that point by interacting with other tunnel endpoints. From the general ROT model, we can drive the following attributes which can be exploited to characterize a specific RO model. RO Initiator (ROI) We need to identify which TE among two TEs can be the initiator in making a RO tunnel. This parameter depends on the applied RO scheme. In one RO scheme, MR is only the initiator, on the other hand, HA and CR can be the initiator in the other RO scheme. RO Responder (ROR) Na, et al. Expires - January 2005 [Page 4] Internet Draft Generic RO Model July 2004 We need to identify which routing facilities can be the responder in making a RO tunnel. This parameter also depends on the applied RO scheme. RO Trigger Source (ROTS) The RO initiator (ROI) is recognized for the need of RO from this information. For example, an explicit RO bit in the packet header can be used to force the receiver to start the RO. RO Responder Information (RORI) This information is used for the RO initiator (ROI) to identify the RO responder (ROR). It would include the address information of the moving entity such as MR, or the address information of the correspondent nodes. RO Discovery Mechanism (RODM) This mechanism describes that how RORI can be delivered to the RO initiator (ROI). In other words, ROI can get RORI by using this discovery mechanism. For example, if ROI itself try to find its ROR using IPv6 anycast address, RORI becomes an address of ROR and we can say that RODM is IPv6 anycasting mechanism. RO Tunnel Type (ROTT) ROTT can be classified as the followings: Simple ROT (SiROT), Switched ROT (SwROT), Releyed ROT (ReROT). SiROT consists of only two TEs. SwROT consists of one or more TS between two TEs. ReROT consists of one or more TR between two TEs. For example, we can say that RRH [4] uses ReROT as RO Tunnel Type, HMIPv6 uses SwROT. More attributes to be defined. 3. The Analysis of RO Problems in NEMO In this section, we analyze typical RO problems in NEMO using the generic ROT model. Na, et al. Expires - January 2005 [Page 5] Internet Draft Generic RO Model July 2004 3.1 RO in the infrastructure TE[1] TE[1] +--+---------------------------------+--+ ====|XX|=================================|XX|==== +--+---------------------------------+--+ Fig.2 SiROT based RO in the infrastructure Fig.2 shows the simple RO in the infrastructure. This RO model was used in ORC [19]. According to the generic ROT model, the following formulation is possible. TE: Mobile Router (MR), Optimized Route Cache (ORC) Router ROI: MR ROR: ORC Router ROTS: the packet sent from any CN via MR-HA default tunnel RORI: the global IPv6 address of ORC Router RODM: IPv6 anycast addressing ROTT: SiROT Above attributes compactly describes that this RO implements ROT between MR and ORC Router, and MR initiates the signaling procedure for ROT to ORC Router after getting the global IPv6 address of ORC Router through IPv6 anycast addressing. This RO model also includes some RO approaches, such as C-Side Router or Correspondent Router (CR), mentioned in RO-Taxonomy [14]. To include those of RO approaches, we can loosely redefine above attributes as follows: TE: Mobile Router (MR), Optimized Route Cache (ORC) Router, C-Side Router, Correspondent Router (CR) ROI: MR ROR: ORC Router, C-Side Router, CR ROTS: the packet sent from any CN via MR-HA default tunnel RORI: the global IPv6 address of ROR RODM: IPv6 anycast addressing ROTT: SiROT TE[1] TS[1] TE[1] +--+---------------------+--+--------+--+ ====|XX|=====================|XX|========|XX|==== +--+---------------------+--+--------+--+ Fig.3 SwROT based RO in the infrastructure Na, et al. Expires - January 2005 [Page 6] Internet Draft Generic RO Model July 2004 Fig.3 shows extended RO in the infrastructure. This RO model includes one TS entity and two TEs. Distributed Anchor Routers described in RO-Taxonomy [14] can be expressed as this model like below. TE: Mobile Router (MR), C-Side Anchor Router TS: M-Side Anchor Router (a.k.a Mobility Anchor Point in HMIPv6) ROI: Not mentioned ROR: Not mentioned ROTS: Not mentioned RORI: Not mentioned RODM: Not mentioned ROTT: SwROT In this case, most of attributes in the ROT model are not determined, so it is required to deeply understand this RO problem and derive its viable solution. 3.2 Nested Tunnels Optimization (NTO) NTO can be modeled like Fig.4 by using the ROT model. For example, the attributes of RRH [4] model are as follows: TE[1] TR[1..n] TE[1] +--+---------------------+--+--------+--+ ====|XX|=====================|==|========|XX|==== +--+---------------------+--+--------+--+ Fig.4 ReROT based NTO TE: Mobile Router (MR), Home Agent (HA) TR: MR (via Source Routing) ROI: MR ROR: HA ROTS: TIO option in RA [14] RORI: Nested Path Information like MR3->MR2->MR1->HA3 RODM: Using Reverse Routing Header (RRH) ROTT: ReROT Similarly, ARO [5] can be expressed as follows: TE: Mobile Router (MR), Home Agent (HA) TR: MR (via Source Routing) ROI: MR Na, et al. Expires - January 2005 [Page 7] Internet Draft Generic RO Model July 2004 ROR: HA ROTS: BU with ARO option, Recursive Binding Update by ancestor MRs RORI: Nested Path Information like MR3->MR2->MR1->HA3 RODM: Using Access Router Option (ARO) & Recursive BU ROTT: ReROT 4. Toward to a unified route optimization in NEMO There are some efforts for Route Optimization (RO). For RO in the routing infrastructure, some approaches such as VIP [17], ORC [19] require a special router or the extension of the existing router which can handle the packet redirection to gain RO effect. The RO schemes belong to this category can be applied to both Mobile IP and NEMO in IP routing infrastructure. On the other hand, There are other kinds of the NEMO-specific RO problem. [14] well defines RO problem spaces of NEMO and briefly analyzes the proposed interim solutions. Typically, one of NEMO-specific RO problem is a nested tunneling problem that can be formed due to the network mobility. Most of proposed solutions are for solving that problem. As of now, it's not easy to say how RO problems in NEMO can be best solved in the reasonable manner. However, the sure thing is that current proposed solutions can be applied only to one problem space of RO. That is an uncomfortable and unnatural facet in supporting coherent network mobility. We need a simple and effective, unified route optimization scheme for network mobility. With the help of the ROT model, we can evaluate whether or not there is the feasibility of achieving a unified route optimization in NEMO, and enumerate the issues that should be cleared for the purpose of that. As a unified RO model, let us illustrate one example as Fig.5. In here, TR can be zero. That is only difference in comparing with Fig.4. However, this trivial difference in the model implies that this model can support SiROT based RO in the infrastructure as well as ReROT based NTO. PCH [20] approach belongs to this model. TE[1] TR[0..n] TE[1] +--+---------------------+--+--------+--+ ====|XX|=====================|==|========|XX|==== +--+---------------------+--+--------+--+ Fig.5 A unified RO supporting ReROT as well as SiROT As an instance of a unified RO, The attributes of PCH [20] model can be summarized as follows: Na, et al. Expires - January 2005 [Page 8] Internet Draft Generic RO Model July 2004 TE: Mobile Router (MR), Home Agent (HA), Correspondent Router (CR) TR: MR (via Source Routing) ROI: CR, HA ROR: MR ROTS: Receiving the packet with Path Control Header (PCH) RORI: Nested Path Information like MR1-MR2-MR3, contained in PCH RODM: PCH Piggybacking by HA ROTT: SiROT+ReROT 5. Open Issues ? Functional entities involving in RO ? Source routing in the inside of nested mobile network ? Considerations on RO in multi-homed mobile networks ? Performance / Evaluation Metric for RO TBD 6. Security Considerations TBD Na, et al. Expires - January 2005 [Page 9] Internet Draft Generic RO Model July 2004 References [1] Perkins, C., Johnson, D. and J. Arkko, "Mobility Support in IPv6", draft-ietf-mobileip-ipv6-18 (work in progress), July 2002. [2] Ernst, T. and H. Lach, "Network Mobility Support Terminology", draft-ietf-nemo-terminology-00 (work in progress), May 2003. [3] Ernst, T., Castelluccia, C., Bellier, L., Lach, H. and A. Olivereau, "Mobile Networks Support in Mobile IPv6 (Prefix Scope Binding Updates)", draft-ernst-mobileip-v6-network-03 (work in progress), March 2002. [4] Thubert, P., and Molteni, M., "IPv6 Reverse Routing Header and Its Application to Mobile Networks", Internet Draft: draft-thubert-nemo-reverse-routing-header-01 (work in progress), Oct 2002. [5] Chan-Wah Ng, and Takeshi Tanaka, "Securing Nested Tunnels Optimization with Access Router Option", Internet Draft:draft -ng-nemo-access-router-option-00(work in progress), Oct 2002. [7] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [8] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998. [9] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998. [10] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [11] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [12] Conta, A. and S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 2463, December 1998. [13] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by an On-line Database", RFC 3232, January 2002. [14] Thubert, P., and Molteni, M., "Taxonomy of Route Optimization Models in the NEMO Context", Internet Draft: draft-thubert- nemo-ro-taxonomy-00(work in progress), Oct 2002. Na, et al. Expires - January 2005 [Page 10] Internet Draft Generic RO Model July 2004 [15] vijay, D., Ryuji, W., Alexandru, P., Pascal, T., "NEMO Basic Support Protocol", draft-ietf-nemo-basic-support-00(work in process), June 2003. [16] A. Conta, S. Deering, "Generic Packet Tunneling in IPv6 Specificiation", RFC2473, December 1998. [17] Fumio Teraoka, Keisuke Uehara, Hideki Sunahara, and Jun Murai, ``VIP : A Protocol Providing Host Mobility,`` Aug. 1994 [18] Weidong Chen, Eric Lin, ``Route Optimization and Location Updates for Mobile Hosts,`` International Conference on Distributed Computing Systems,1996 [19] Ryuji Wakikawa, Susumu Koshiba, Keisuke Uehara, Jun Murai, ``ORC: Optimized Route Cache Management Protocol for Network Mobility,`` Proc. of ICT2003, Nov 2003. [20] Jongkeun Na, et.al. ``Route Optimization Scheme based on Path Control Header,`` draft-na-nemo-path-control-header-00(work in process), April 2004. Acknowledgments Authors' Addresses Jongkeun Na Information Networking & Computing Lab. School of Computer Science and Engineering, Seoul National University, Seoul Korea EMail: jkna@popeye.snu.ac.kr Sungho Cho Information Networking & Computing Lab. School of Computer Science and Engineering, Seoul National University, Seoul Korea EMail: shcho@popeye.snu.ac.kr Chongkwon Kim Information Networking & Computing Lab. School of Computer Science and Engineering, Seoul National University, Seoul Korea EMail: ckim@popeye.snu.ac.kr Changhoi Koo Na, et al. Expires - January 2005 [Page 11] Internet Draft Generic RO Model July 2004 Global Standards & Research Team Telecommunication R&D Center, Samsung Electronics, KOREA Email : chkoo@samsung.com Copyright (C) The Internet Society (year). 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. 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. Na, et al. Expires - January 2005 [Page 12]