NEMO Working Group C. Ng Internet-Draft Panasonic Singapore Labs Expires: April 25, 2005 P. Thubert Cisco Systems H. Ohnishi NTT E. Paik KT October 25, 2004 Taxonomy of Route Optimization models in the NEMO Context draft-thubert-nemo-ro-taxonomy-03 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. This Internet-Draft will expire on April 25, 2005. Copyright Notice Copyright (C) The Internet Society (2004). Abstract With current Network Mobility (NEMO) Basic Support, all communications to and from mobile network nodes must go through the Ng, et al. Expires April 25, 2005 [Page 1] Internet-Draft RO-Taxonomy October 2004 MR-HA tunnel when the mobile network is away. This results in increased length of packet route and increased packet delay. To overcome these limitations, one might have to turn to route optimization (RO) for NEMO. This memo documents various types of route optimization in NEMO, and explores the benefits and tradeoffs in different aspects of NEMO route optimization. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Problem Statement of NEMO Route Optimization . . . . . . . . . 4 2.1 Sub-Optimality with NEMO Basic Support . . . . . . . . . . 4 2.2 Nesting of Mobile Networks . . . . . . . . . . . . . . . . 5 2.3 MIPv6 Host in Mobile Networks . . . . . . . . . . . . . . 7 2.4 Communications within a Mobile Networks . . . . . . . . . 7 3. Solution Space of NEMO Route Optimization . . . . . . . . . . 8 3.1 MR-to-CN Optimization . . . . . . . . . . . . . . . . . . 9 3.2 Infrastructure Optimization . . . . . . . . . . . . . . . 10 3.3 Nested Tunnels Optimization . . . . . . . . . . . . . . . 11 3.4 MIPv6-over-NEMO Optimization . . . . . . . . . . . . . . . 12 3.5 Intra-NEMO Optimization . . . . . . . . . . . . . . . . . 13 4. Analysis of Solution Space . . . . . . . . . . . . . . . . . . 14 4.1 General Considerations of RO Solution . . . . . . . . . . 14 4.1.1 Additional Signaling Overhead . . . . . . . . . . . . 14 4.1.2 Increased Protocol Complexity . . . . . . . . . . . . 15 4.1.3 Mobility Awareness . . . . . . . . . . . . . . . . . . 15 4.1.4 New Functionalities . . . . . . . . . . . . . . . . . 15 4.1.5 Other Considerations . . . . . . . . . . . . . . . . . 17 4.2 Specific Types of RO Solution . . . . . . . . . . . . . . 17 4.2.1 MR-to-CN Optimization . . . . . . . . . . . . . . . . 17 4.2.2 Infrastructure Optimization . . . . . . . . . . . . . 19 4.2.3 Nested Tunnels Optimization . . . . . . . . . . . . . 20 4.2.4 MIPv6-over-NEMO Optimization . . . . . . . . . . . . . 21 4.2.5 Intra-NEMO Optimization . . . . . . . . . . . . . . . 23 5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 24 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 27 A. Proposed Route Optimizations . . . . . . . . . . . . . . . . . 29 A.1 MR-to-CN Optimizations . . . . . . . . . . . . . . . . . . 29 A.2 Infrastructure Optimizations . . . . . . . . . . . . . . . 29 A.3 Nested Tunnel Optimizations . . . . . . . . . . . . . . . 30 A.4 MIPv6-over-NEMO Optimizations . . . . . . . . . . . . . . 32 A.5 Intra-NEMO Optimizations . . . . . . . . . . . . . . . . . 33 Intellectual Property and Copyright Statements . . . . . . . . 34 Ng, et al. Expires April 25, 2005 [Page 2] Internet-Draft RO-Taxonomy October 2004 1. Introduction With current Network Mobility (NEMO) Basic Support [1], all communications to and from nodes in a mobile network must go through the bi-directional tunnel established between the mobile router (MR) and its home agent (HA) when the mobile network is away. Although such an arrangement allows mobile network nodes (MNNs) to reach and be reached by any node on the Internet, there are associated limitations which might be unacceptable for certain applications. To substantially ameliorate these limitations, one might have to turn to route optimization (RO) for NEMO. Here, we use the term "route optimization" to loosely refer to any approach that optimize the route taken by packets sent between a mobile network node and correspondent node (CN). This document aims to explore limitations inherent in NEMO Basic Support, and analyze the possible approaches to route optimization with NEMO. It is expected for readers to be familiar with general terminologies related to mobility in [2] and [3], and NEMO related terms defined in [4]. In addition, it is beneficial to keep in mind the design requirements of NEMO [5]. A point to note is that since this document discusses aspects of route optimization, the readers may assume that a mobile network or a mobile host is away when they are mentioned throughout this document, unless it is explicitly specified that they are at home. It is the objective of this document to address the need for a route optimization analysis in the NEMO Working Group. To quote the charter of the NEMO Working group: "... The WG will work on: ... ... [an] informational document which specifies a detailed problem statement for route optimization and looks at various approaches to solving this problem. This document will look into the issues and tradeoffs involved in making the network's movement visible to some nodes, by optionally making them "NEMO aware". The interaction between route optimization and IP routing will also be described in this document. Furthermore, security considerations for the various approaches will also be considered. ..." To such end, this document first describes the problem of route optimization in NEMO in Section 2. Next, we explore into various possible approaches to solving the problem of route optimization in Section 3. Following this, Section 4 discusses various issues that a route optimization solution might face. Finally, Section 5 concludes this memo. In addition, we attempt to list various proposed solutions for route optimization in Appendix A, and classify them according to the solution space described in Section 3. Ng, et al. Expires April 25, 2005 [Page 3] Internet-Draft RO-Taxonomy October 2004 2. Problem Statement of NEMO Route Optimization In essence, the problem of route optimization in NEMO is to eliminate limitations, or sub-optimality, introduced by the bi-directional tunnel between a mobile router and its home agent (also known as the MR-HA tunnel). In the following sub-sections, we will describe the effects of sub-optimal routing with NEMO-Basic Support, and how they get amplified with nesting of mobile networks. We will also look into the nesting of a Mobile IPv6 (MIPv6) host in a mobile network. In addition, we will explore the impact of MR-HA tunnel on communications between two mobile network nodes (MNNs) on different links of the same mobile network. Readers might be interested to note the availability of [6] which also discusses the problem statement of NEMO route optimization. 2.1 Sub-Optimality with NEMO Basic Support With NEMO Basic Support, all packets sent between a mobile network node and its correspondent node are forwarded through the MR-HA tunnel. This results in a sub-optimal routing, also known as "dog-leg routing", with NEMO Basic Support. This sub-optimality has the following undesirable effects: o Longer route leading to increased delay Because a packet must transit from a mobile network to the home agent then to the correspondent node, the transit time of the packet is always higher than if the packet were to go straight from the mobile network to the correspondent node. In the best case, where the correspondent node resides near the home agent, the increase in packet delay is minimal. In the worst case, where both the mobile network and the correspondent node are located at a point furthest away from the home agent on the Internet, the increase in delay is tremendous. Applications such as real-time multimedia streaming may not be able to tolerate such increase in packet delay. o Increased packets overhead The encapsulation of packets in the MR-HA tunnel results in increased packet size due to addition of an outer packet. This reduces the bandwidth efficiency, as IPv6 header can be quite substantial (at least 40 bytes). o Increased processing delay The encapsulation of packets in the MR-HA tunnel also results in Ng, et al. Expires April 25, 2005 [Page 4] Internet-Draft RO-Taxonomy October 2004 increased processing delay at the points of encapsulation and decapsulation. o Increased chances of packet fragmentation The increased in packet size due to packet encapsulation may increase the chances of the packet being fragmented along the MR-HA tunnel. This can occur if there is no prior path MTU discovery conducted, or if the MTU discovery mechanism did not take into account the encapsulation of packets. Packets fragmentation will result in a further increase in packet delays, and further reduction of bandwidth efficiency. 2.2 Nesting of Mobile Networks With nesting of mobile networks, the use of NEMO Basic Support further amplifies the sub-optimality of routing. We call this the amplification effect of nesting, where the (undesirable) effects of sub-optimal routing with NEMO Basic Support is amplified with each level of nesting of mobile networks. This is best illustrated by an example shown in Figure 1. HAofMR1 +-----------|---------+ HAofMR2 --| Internet |---CN +---------------|-----+ / Access Router HAofMR3 | ====?======== MR1 | ====?===========?===========?=== MR5 MR2 MR6 | | | ==|======= ===?====== ======|== LFN2 MR3 LFN3 | ==|=========?== LFN1 MR4 | ========= Figure 1: An example of nested Mobile Network Using NEMO Basic Support, the flow of packets between a Local Fixed Node LFN1 and a correspondent node CN would need to go through three separate tunnels, illustrated in Figure 2 below. Ng, et al. Expires April 25, 2005 [Page 5] Internet-Draft RO-Taxonomy October 2004 ----------. --------/ /----------. -------/ | | /------- CN ------( - - | - - - | - - - | - - - | - - (------- LFN HAofMR3-------\ | | \-------MR3 HAofMR2--------\ \----------MR2 HAofMR1---------MR1 Figure 2: Nesting of Bi-Directional Tunnels This leads to the following problems: o 'Pinball' routing Both inbound and outbound packets will flow via the HAs of all the MRs on their path within the NEMO, with increased latency, less resilience and more bandwidth usage. To illustrate this effect, Figure 3 below shows the route taken by a packet sent from LFN1 to CN: +--> HAofMR3 ---------------------+ | | +----------------- HAofMR2 <--+ | | | +---------------+ | | V HAofMR1 <------+ CN | | LFN1 --> MR3 --> MR2 --> MR1 Figure 3: 'Pinball' Routing For more illustration of the pinball routing, see [7]. o Increased Packet Size An extra IPv6 header is added per level of nesting to all the packets. The header compression suggested in [8] cannot be applied because both the source and destination (the intermediate MR and its HA), are different hop to hop. Ng, et al. Expires April 25, 2005 [Page 6] Internet-Draft RO-Taxonomy October 2004 2.3 MIPv6 Host in Mobile Networks When a MIPv6 mobile node joins a mobile network, it becomes a visiting mobile node (VMN) of the mobile network. Packets sent to and from the visiting mobile node will have to be routed not only to the home agent of the visiting mobile node, but also to the home agent of the mobile router in the mobile network. This suffers the same amplification effect of nested mobile router mentioned in Section 2.2. In addition, although Mobile IPv6 [2] allows a mobile host to perform route optimization with its correspondent node to avoid tunneling with its home agent, the "optimized" route is no longer optimized when the mobile host is attached to a mobile network. This is because the route between the mobile host and its correspondent node is subjected to the sub-optimality introduced by the MR-HA tunnel. Interested readers may refer to [7] for examples of how the routes will appear with nesting of MIPv6 hosts in mobile networks. 2.4 Communications within a Mobile Networks The reliance on the MR-HA tunnel has its implications on MNNs in a nested mobile network communicating with each other. Let us consider the previous example illustrated in Figure 1. Suppose LFN1 and LFN2 are communicating with each other. With NEMO Basic Support, a packet sent from LFN1 to LFN2 will follow the path of: LFN1 -> MR3 -> MR2 -> MR1 -> HAofMR1 -> HAofMR2 -> HAofMR3 -> HAofMR5 -> HAofMR1 -> MR1 -> MR5 -> LFN2. A round-about trip indeed where the direct path would be LFN1 -> MR3 -> MR2 -> MR5 -> LFN2. The consequences of increase packet delay and packet size have been discussed in previous sub-sections. Here, there is an additional effect that is undesirable: should MR1 loses its connection to the global Internet, LFN1 and LFN2 can no longer communicates with each other, even though the direct path from LFN1 to LFN2 is unaffected! Ng, et al. Expires April 25, 2005 [Page 7] Internet-Draft RO-Taxonomy October 2004 3. Solution Space of NEMO Route Optimization To address the problems discussed in Section 2, one can incorporate route optimization into NEMO. This is also known as the NEMO Extended Support. Although a standardized NEMO Extended Support has yet materialize, one can expect it to show some of the following benefits: o Shorter Delay Route optimization involves the selection and utilization of a shorter (or faster) route to be taken for traffic between a mobile network node and correspondent node. Hence a major benefit of route optimization should be shorter delay experiences by the data traffic between the two end nodes. This may possibly in turn leads to better overall Quality of Services characteristics, such as reduced jitter and packet loss. o Reduced Consumption of Overall Network Resources Through the selection of a shorter route, the total link utilization for all links used by traffic between the two end nodes should be much lower than that used if route optimization is not carried out. This would result in a lighter network load with reduced congestion. o Less Susceptibility to Link Failure An optimized route would conceivably utilize a lesser number of links between the two end nodes. Hence, the probability of connectivity loss due to a single point of failure at a link should be lower as compared to the longer non-optimized route. o Greater Data Efficiency Depending on the actual solution for NEMO Extended Support, the data packets exchanged between the two end nodes may not require as many levels of encapsulation as required by NEMO Basic Support. This would mean less packet overheads, and higher data efficiency. There are multiple proposals for providing various forms of route optimizations for NEMO (see Appendix A). In the following sub-sections, we describe the solution space of route optimization by listing different types of approach to route optimization. Readers might be interested to take note of a route optimization model described in [9] which describes route optimization model based on the variations of tunnel end-points. Ng, et al. Expires April 25, 2005 [Page 8] Internet-Draft RO-Taxonomy October 2004 3.1 MR-to-CN Optimization o Binding Update with Network Prefix A straight-forward approach to route optimization is in NEMO is for the mobile router to attempt route optimization with correspondent node. This can be viewed as a logical extension to NEMO Basic Support, where the mobile router would send binding updates to the correspondent node containing one or more Mobile Network Prefix option. The correspondent node having received the binding update, can then set up a bi-directional tunnel with the mobile router at the current care-of address of the mobile router, and inject a route to its routing table so that packets destined for addresses in the mobile network prefix will be routed through the bi-directional tunnel. This approach is particularly useful when a lot of MNNs in a mobile network is communicating with a few corresponding nodes. In such cases, a single binding update can optimize the routes of many flows between the correspondent node and the MNNs. o MR as a Proxy A somewhat similar approach is for the mobile router to act as a "proxy" for the MNNs in its mobile network. In this case, The MR uses standard MIPv6 route optimization procedure to bind the address of a MNN to its care-of address. This has the advantage of keeping the implementations of MNNs and correspondent nodes unchanged, and can be done by having the mobile router to perform the following steps: * determining when to perform RO (eg. by the flow packet count) * sending CoTI and HoTI on behalf of the MNN * receiving CoT (trivial, since it is addressed to the MR) * intercepting the HoT (which requires inspection of the packets addressed to the MNN) * sending the BU and receiving the BA on behalf of MNN * inserting the Home Address Option in packets sent by the MNN * removing the type 2 routing header in packets sent to the MNN * adjusting various ICMP packets to account for the modification it performs Ng, et al. Expires April 25, 2005 [Page 9] Internet-Draft RO-Taxonomy October 2004 3.2 Infrastructure Optimization There are two known approaches to achieve infrastructure optimization. The first approach involves the introduction of an entity known as a correspondent-side router (C-side Router), or sometimes known simply as a correspondent router (CR) within the routing infrastructure. As long as the correspondent router is located "closer" to the correspondent node than the home agent of the mobile router, the route between MNN and the correspondent node can be said to have optimized. This is illustrated in Figure 4. ************************** HAofMR * #*# * #*# +---------------------+ CN #*# | LEGEND | o #*# +---------------------+ o ############### #*# | #: Tunnel | CR ooooooooooooooo MR | *: NEMO Basic route | ############### | | o: Optimized route | MNN +---------------------+ Figure 4: Infrastructure Optimization This form of optimization can take place independently for the 2 directions of the traffic: o From MNN to CN The mobile router locates the correspondent router, establishes a tunnel with that correspondent router and sets a route to the correspondent node via the correspondent router over the tunnel. After this, traffic to the correspondent node does not flow through the home agent anymore. o From CN to MNN The correspondent router is on the path of the traffic from the correspondent node to the home agent. In addition, it has an established tunnel with the current care-of address of the mobile router and is aware of the mobile network prefix(es) managed by the mobile router. The correspondent router can thus intercept packets going to the mobile network, and forward them to the mobile router over the established tunnel. The advantage of this approach is that no additional functionality is required for the correspondent node and mobile network nodes. The second approach is to have optimizations carried out fully in Ng, et al. Expires April 25, 2005 [Page 10] Internet-Draft RO-Taxonomy October 2004 infrastructure. One example is to make use of mobile anchor points (MAP) in HMIPv6 [10] to optimize routes between themselves. Another example is to make use of the global HAHA protocol [11]. In this case, proxy home agents are distributed in the infrastructure and mobile routers bind to the closest proxy. The proxy performs, in turn, a primary binding with a real home agent for that mobile router. Then, the proxy might establish secondary bindings with other home agents or proxies in the infrastructure, in order to improve the end-to-end path. In this case, the proxies discover each other, establish a tunnel and exchange the relevant mobile network prefix information in the form of explicit prefix routes. There is no need for return routability test or its like since the security is built in the infrastructure, one way or an other, and the proxies belong to the infrastructure. 3.3 Nested Tunnels Optimization Nested tunnels optimization is targeted at nested mobile networks, where there will be multiple levels of MR-HA tunnels with NEMO Basic Support. Such a solution will seek to minimize the number of tunnels, possibly by collapsing the amount of tunnels required through dome form of signaling between the mobile routers and home agents. This ameliorate the amplification effect of tunnel nesting, and at best, the performance of a nested mobile network will be the same as though there were no nesting of mobile networks. There have been various proposals on nested tunnels optimization, and we can model them according to: o Sending Information of Upstream Mobile Routers This involves sending information on upstream mobile router(s) to the home agent of a nested mobile router, thereby enabling the home agent to forward tunneled packets directly to the nested mobile router via the upstream mobile router(s), skipping the home agents of upstream mobile router(s). This usually involves the use of a routing header to route packets through the upstream mobile router(s). The information of upstream mobile router (for simplicity, we refer to it as "upstream information") may contain information on the entire chain of upstream mobile routers, or it may only contain information on the immediate parent mobile router. For the former, the home agent can build a multihop routing header from a single transmission of the information. For the latter, each upstream mobile router may have to send binding update to the home agent of the nested mobile router, thereby enabling the home agent of the nested mobile router to build a multihop routing Ng, et al. Expires April 25, 2005 [Page 11] Internet-Draft RO-Taxonomy October 2004 header recursively. o Prefix Delegation An alternative approach to nested tunnels optimization is to use prefix delegation. Here, each mobile router in a nested mobile network is delegated a mobile network prefix from the access router using DHCP Prefix Delegation [12]. Each mobile router also autoconfigures its care-of address from this delegated prefix. In this way, the care-of addresses of each mobile router are all from an aggregatable address space starting from the access router. This may be used to eliminate any nesting of tunnels. It may also be used to achieve MIPv6-over-NEMO optimization (see Section 3.4) if MIPv6 hosts autoconfigure their care-of addresses from the prefix as well. o Mobile Aggregation This model applies to a category of problems where the mobile networks share a same administration and consistently move together (e.g. a fleet at sea). In this model, there is a cascade of home agents. The main home agent is fixed in the infrastructure, and advertises an aggregated view of all the mobile networks. This aggregation is actually divided over a number of mobile routers, the root-MRs. The root-MRs subdivide some of their address space to the other mobile routers forming their fleet, for which they are home agent. As home agents, the root-MRs terminate tunnels from the inside of the mobile network. As mobile router, they also terminate their home tunnels. As routers, they forward packets between the 2 tunnels. 3.4 MIPv6-over-NEMO Optimization MIPv6-over-NEMO optimization involves providing optimization for a visiting mobile node within a mobile network. There are two aspects to MIPv6-over-NEMO optimization: o Nested Tunnels This aims to reduce the amplification effect of nested tunnels due to the nesting of the tunnel between the visiting mobile node and its home agent within the tunnel between the mobile router of the mobile network and the home agent of the mobile router. This is very similar to "Nested Tunnels Optimization" described in Section 3.3. Thus, a possible approach is to extend the solution for nested tunnels optimization to visiting mobile node as well. Ng, et al. Expires April 25, 2005 [Page 12] Internet-Draft RO-Taxonomy October 2004 o MIPv6 Route Optimization This aims to remove the sub-optimality of a MR-HA tunnel from the MIPv6 route optimization established between a visiting mobile node and correspondent node. One approach is to simply extend the solution for nested tunnels optimization to correspondent node. Another (arguably "evil") approach is for the mobile router to "play some trick" to the MIPv6 route optimization, such as altering messages exchanged during the return routability procedure between the visiting mobile node and correspondent node, so that packets sent from correspondent node to the visiting mobile node will be routed to the care-of address of the mobile router once route optimization is established (see Section 3.1: "MR as a Proxy"). Alternatively, the mobile router can perform return routability procedure on behalf of the visiting mobile node. This would most likely require some signaling protocol between the visiting mobile node and the mobile router, but may be able to keep the functionality of the correspondent node unchanged. 3.5 Intra-NEMO Optimization A route optimization solution may seek to improve the communications between two mobile network nodes within a nested mobile network. An example will be the optimization of packets route taken between LFN1 and LFN2 of Figure 1. One may be able to extend a well-designed solution for MR-to-CN optimization to provide Intra-NEMO optimization, where, for example in Figure 1, LFN1 is treated as a correspondent node in the view of MR5, and LFN2 is treated as a correspondent node in the view of MR3. Another possibility is for the infrastructure optimization technique to be applied here. Using the same example of communication between LFN1 and LFN2, MR3 may treat MR5 as a correspondent router for LFN2, and MR5 treats MR3 as a correspondent router for LFN1. Ng, et al. Expires April 25, 2005 [Page 13] Internet-Draft RO-Taxonomy October 2004 4. Analysis of Solution Space In this section, we present an analysis of the solution space. First, we discuss the general issues that will be faced by a NEMO Extended Support solution in Section 4.1. Then, we explore deeper into specific types of route optimization solutions in Section 4.2. 4.1 General Considerations of RO Solution Although route optimization, or NEMO Extended Support, can bring benefits as described in previous section, it does so with some tradeoffs. The actual type and degree of tradeoffs depend greatly on the solution; however, in general, one would expect the costs described in the following sub-sections to be incurred. 4.1.1 Additional Signaling Overhead The nodes involved in performing route optimization would be expected to exchange additional signaling information in order to establish route optimization. The cost of such signaling may be high, depending on the actual solution. Such a cost may scale to unacceptable height when the number of mobile network nodes and/or correspondent nodes is increased. This signaling overhead is often in the form of binding update sent to home agents or correspondent nodes. One issue that may impact route optimization solution is known as the phenomenon of "Binding Update Storm". This occurs when a change in point of attachment of the mobile networks is accompanied with a sudden burst of binding update messages being generated, resulting in temporary congestion, packet delays or even packet lost. There has been argument that binding update storm may not be as significant as it seems. For instance, consider a mobile network where mobile network nodes is receiving x video stream at 25 packets per seconds. On the average, the mobile network is handling a total traffic of 25*x packets per second. Assuming one binding update has to be sent for each video stream server, a change in point of attachment would result in at most 6*x signaling messages (if we include the return routability procedure messages and a binding acknowledgment). Thus the signaling overhead is small compared to the normal data traffic that the mobile network is handling, and hence the effect of binding update storm is small. On the other hand, if the normal data rate is small, the effect of binding update storm may have a greater impact. From this discussion, it appears that the significance of binding update storm may depend on the application type (eg. high or low data rate, tolerance on packets delay, etc). Ng, et al. Expires April 25, 2005 [Page 14] Internet-Draft RO-Taxonomy October 2004 It is also possible to further moderate the effect of Binding Update Storm by having some sort of "exponential back-off" mechanism in place for the sending of binding updates. Such a scheme aims to spread the burst of binding update transmissions over a longer period of time, thereby reducing possibility of congestion and packet drops. 4.1.2 Increased Protocol Complexity Some nodes will be required to have additional functionalities in order to incorporate NEMO Extended Support. This increases the node complexity. It may not be feasible to implement new functionalities on legacy nodes. If such nodes are mobile, this may prove to be a significant cost due to the limited memory resources such devices usually have. Coupled with the increased in protocol complexity, nodes that are involved in the establishment and maintenance of route optimization will have to bear increased processing load. If such nodes are mobile, this may prove to be a significant cost due to the limited power and processing resources such devices usually have. 4.1.3 Mobility Awareness One advantage of NEMO Basic Support is that the correspondent nodes and mobile network nodes need not be aware of the actual location and mobility of the mobile network. With route optimization, it might be necessary to reveal the current care-of address and any change of point of attachment of the mobile router to other nodes, such as the mobile network nodes or correspondent node. This may mean a tradeoff between location privacy and route optimization. In MIPv6, the mobile node can decide whether or not to perform route optimization with a given correspondent node. Thus, the mobile node is in control of whether to trade location privacy for an optimized route. It will be desirable that such control is also available in a route optimized solution of NEMO should the solution contain the same tradeoff. However, for solutions where route optimization decision is made by mobile router, it will be difficult for mobile network nodes to control the decision of having this tradeoff. 4.1.4 New Functionalities All route optimization approaches require some sort of new functionalities be implemented on some nodes. In general, it is desirable to keep the number of nodes that require new functionalities to be kept as small as possible. This allows for easier adoption of the solution, and also creates less impact on the existing infrastructure. Ng, et al. Expires April 25, 2005 [Page 15] Internet-Draft RO-Taxonomy October 2004 In addition, if route optimization solution requires new functionalities on the part of some other nodes other than nodes within the mobile network, a mechanism for other nodes (such as mobile router) to detect if support for the new functionalities are available should also be provided. Furthermore, it is desirable for there to be a graceful fall back procedure the required functionalities are unavailable. Possible nodes that are required to be changed includes: o Local Fixed Nodes It is generally undesirable to affect local fixed nodes. However, some approaches require mobile network nodes to implement new functionalities to enjoy benefits of route optimizations. o Visiting Mobile Nodes Visiting mobile nodes in general should already have implemented MIPv6 functionalities, and since MIPv6 is a relatively new standard, there is still a considerable window to allow mobile devices to implement new functionalities. o Mobile Routers It is expected for mobile routers to implement new functionalities in order to enable route optimizations. o Access Routers Some approaches require access routers, or nodes in the access network to implement some new functionalities. A clear example will be prefix delegation approach. o Home Agents Although it is likely that vendors and operators would not mind having new functionalities in home agents, few route optimizations approaches would impact the home agents. o Correspondent Nodes It is generally undesirable for correspondent nodes to be required to implement new functionalities. o Correspondent Routers Correspondent routers are new entity to be deployed in the Ng, et al. Expires April 25, 2005 [Page 16] Internet-Draft RO-Taxonomy October 2004 infrastructure. Such addition would generally cause the least disruption to the existing routing infrastructure. 4.1.5 Other Considerations There are other considerations when analyzing the route optimization solution space. These may not be a 'tradeoff" so to speak, but are beneficial to keep in mind when considering a route optimization solutions. o Compatibility with NEMO Basic Support It will be beneficial to vendors if a route optimized solution for NEMO is compatible with NEMO Basic Support. This reduces the complexity and achieves greater reuse of existing functionalities. o In-Plane Signaling versus Off-Plane Signaling There is also considerations of whether route optimization signaling should be done in-plane and off-plane. In-plane signaling involves embedding signaling information into headers of data packets (a good example would be the Reverse Routing Header [13]). Off-plane signaling involves separating the signaling packets from the data packets. Most proposals involving sending of binding updates fall within this category. 4.2 Specific Types of RO Solution Many of the tradeoffs discussed previously in Section 4.2 are dependent on the actual route optimization approach. In the following sub-sections, we will explore deeper into the issues involved in each specific type of route optimization approach. 4.2.1 MR-to-CN Optimization One approach of MR-to-CN optimization involves the mobile router sending binding update messages with mobile network prefix information to the correspondent node. This raised several issues: o Security Considerations With mobile router sending binding update containing network prefix information to correspondent node, there is a question on the additional risk imposed on the correspondent node. Although return routability procedure allows the correspondent node to Ng, et al. Expires April 25, 2005 [Page 17] Internet-Draft RO-Taxonomy October 2004 verify that the care-of and home addresses of the mobile router are indeed collocated, it does not allow the correspondent node to verify the validity of the network prefix. If the correspondent node accepts the binding without verification, it will be exposed to a class of attacks where the attacker tricks the correspondent node into forwarding packets destined for a mobile network to the attacker. Hence, MR-to-CN optimization would most likely require an extended return routability procedure to be developed for correspondent node to authenticate the validity of the mobile network prefix. This require additional functionality on the correspondent node, and a mechanism must be provided for the mobile router to check if the correspondent node has such functionality implemented. o Mobility Awareness By sending binding update with mobile network prefix to the correspondent node, the mobile router is effectively revealing the location and mobility of the mobile network to the correspondent node. Hence this is a case of trading location privacy for route optimization. However, since route optimization in this case is initiated by the mobile router, the mobile network nodes may not have an influence to the decision of whether the tradeoff should be made. o Binding Update Storm If the mobile network nodes in a mobile network are communicating with a lot of correspondent nodes, whenever the mobile router changes its point of attachment, it needs to send out a large number of binding updates to correspondent nodes. This is further worsen by the fact that the mobile router has to perform the return routability procedure prior to sending binding updates. Another approach involves the mobile router acting as a proxy for MNNs behind it. This has the following issues: o Security Considerations Having the mobile router alters packets (such as inserting home address destination option and removing type 2 routing header) raise considerable security concerns. Such a scheme may break existing IPSec protocols, and cause packets to be dropped. o Complexity This also greatly increases the complexity of a mobile router, as Ng, et al. Expires April 25, 2005 [Page 18] Internet-Draft RO-Taxonomy October 2004 it needs to look beyond the standard IPv6 headers for ingress/egress packets, and performs hacks appropriately. The mobile router is also required to maintain some form of state information for each pair of MNN and CN, resulting in scaling issues. This scheme also places all processing burden on the mobile router, which may be undesirable for mobile device with limited power and processing resources. o Binding Update Storm Whenever the mobile router changes its point of attachment, it needs to perform binding updates with every correspondent node. Some CN selection scheme may be required to moderate the effect of binding update storm and processing burden on the mobile router. o A Hack of Existing Protocol There have been comments on the NEMO WG mailing list that such an approach is essentially a hack of the existing return routability procedure. The disadvantages of it being a hack is that firstly a change/extension in the current return routability procedure would render this hack broken, and secondly, it might be very difficult to accommodate other protocols that are not aware of such hacks (IPSec being an excellent example). o Nesting of Mobile Routers Should one mobile router be attached to another mobile router, it is unclear how this solution will work if both mobile routers try to perform route optimization on behalf of the same mobile network node. Using Figure 1 as an example, if MR5 perform route optimization on behalf of LFN2, and then MR1 again tries to act as a proxy to MR5, the results might be messy without any co-ordination between these mobile routers. 4.2.2 Infrastructure Optimization An infrastructure optimization approach using correspondent routers may face the following issues: o Security Considerations The first security-related issue is how do the mobile router verify the validity of a correspondent router. In other words, the mobile router needs some mechanism to ascertain that the correspondent router is indeed a valid correspondent router capable of forwarding packets to and from the correspondent node. Ng, et al. Expires April 25, 2005 [Page 19] A second security-related issue is how can the correspondent router verify the validity of a mobile router. In other words, the correspondent router needs some mechanism to ascertain that the mobile router is indeed managing the mobile network prefix it claims to be managing. This is related to the issues discussed in Section 4.2.1. o Mobility Awareness Infrastructure optimization requires the correspondent router to be informed of the location and mobility of the mobile network. Correspondent nodes and mobile network nodes remain ignorant of the mobile network's mobility. o Discovery of Correspondent Routers How should a mobile router discover a correspondent router given a particular correspondent node? The discovery mechanism may have impact on the security issue discussed earlier. 4.2.3 Nested Tunnels Optimization Nested tunnels optimization usually involves the nested mobile router sending information of upstream mobile router(s). o Security Considerations One issue for consideration is whether the home agent should trust the upstream information supplied by the nested mobile router. If the upstream information falsely points to a victim node, the home agent may unconsciously flood the victim with packets intended for the nested mobile network. This risk can be minimized if the upstream information is protected by security association between the nested mobile router and its home agent (e.g. the upstream information may be transmitted in a binding update that is protected from tampering). However, this does not protect against a malicious mobile router intentionally supplying false upstream information to its home agent, with the intent of launching a flooding attack against a victim node. o Mobility Awareness Usually, nested tunnels optimization involves the nested mobile router sending upstream information to its home agent. This implies that the upstream mobile router will have to reveal some information to sub-mobile routers. Such information may reveal the location and mobility of the upstream mobile router. Ng, et al. Expires April 25, 2005 [Page 20] Internet-Draft RO-Taxonomy October 2004 o Binding Update Storm Depending on the specifics of a solution for nested tunnels optimization, the upstream information may be the care-of address of the upstream mobile router. This will leads to the a burst of binding update messages whenever an upstream mobile router changes its point of attachment, since all its sub-MRs must send binding updates to their home agents to update the new upstream information. o Complexity Sending of upstream information for nested tunnels optimization requires the home agent to store the upstream information in order to build a routing header. Complexity of the home agent is further increased if the upstream information is sent individually by all upstream mobile routers, requiring the home agent to recursively build a routing header. Alternatively, a prefix delegation approach may be used to achieve nested tunnel optimization by eliminating the need for nesting. This approach may face the following issues: o Protocol Complexity This approach requires the access router (or some other entity within the access network) to possess prefix delegation functionality, and also maintains information on what prefix is delegated to which node. o Binding Update Storm A change in the point of attachment of the root mobile router will require every nested mobile router (and possibly visiting mobile nodes) to change their care-of addresses and delegated prefixes. These will cause a burst of binding update and prefix delegation activities where every mobile routers and visiting mobile nodes start sending binding updates to their home agents and possibly correspondent nodes. 4.2.4 MIPv6-over-NEMO Optimization If MIPv6 route optimization is not used, the optimization for MIPv6-over-NEMO is very similar to nested tunnels optimization, where the MIPv6 mobile node acts like a visiting mobile router. The analysis of such optimization is thus similar to those discussed in Section 4.2.3, and hence will not be repeated here. In this section, Ng, et al. Expires April 25, 2005 [Page 21] Internet-Draft RO-Taxonomy October 2004 we explore the issues if MIPv6 route optimization is used. As described in Section 3.4, MIPv6-over-NEMO optimization can be achieved using various approaches. One approach involves including upstream information (see nested tunnels optimization) in the binding update sent from the visiting mobile node to the correspondent node. This approach has the following considerations: o Security Considerations A security-related issue is how can the correspondent node verify the validity of the supplied upstream information. See also Section 4.2.3. o Mobility Awareness The visiting mobile node will need to acquire the upstream information, most likely including the mobility and location information of the upstream mobile routers. On the other hand, the mobile router can perform some hacks on the return routability messages exchanged between the visiting mobile node and correspondent node to achieve MIPv6-over-NEMO optimization. This, is generally undesirable due to: o Security Considerations Such a scheme may break existing security related protocols, as it requires the mobile router to make changes to contents of a packet that is not originated by the mobile router. Alternatively, the mobile router can perform return routability procedure on behalf of the visiting mobile node. Here the issues are: o Security Considerations Such a scheme require the visiting mobile node to place considerable trust on the mobile router, as the mobility management key is now transfered to the mobile router. o Mobility Awareness This approach aims to keep the functionality of the correspondent node to be identical as those required by MIPv6 route optimization. The expense will be that a new form of signaling between the visiting mobile node and mobile router would most likely be required. Ng, et al. Expires April 25, 2005 [Page 22] Internet-Draft RO-Taxonomy October 2004 o Processing Burden This approach also increases the processing burden of the mobile router, as it needs to maintain information necessary for route optimization to work for every correspondent node that is communicating with each visiting mobile node. This may not scale very well when one consider, for example, a train network, where there are hundreds of visiting mobile nodes in one mobile network. 4.2.5 Intra-NEMO Optimization As mentioned in Section 3.5, it is likely that any MR-to-CN optimization may be able to fulfill the role of an intra-NEMO optimization. Such solutions will face the same issues as described in Section 4.2.1, as well as the following: o Reliance on Outside Infrastructure Most MR-to-CN optimization rely on the operations of home agent in one way or another. For instance, the return routability procedure requires a Home Test (HoT) or Home Test Init (HoTI) messages be forwarded by the home agent. This means that should the path to the Internet be broken, such optimization techniques can no longer be used (and thus LFN1 can no longer communicates with LFN2 in the example of Figure 1). Ng, et al. Expires April 25, 2005 [Page 23] Internet-Draft RO-Taxonomy October 2004 5. Conclusion The problem space of route optimization in the NEMO context is multifold and can be split into several work areas. It will be critical, though, that the solution to a given piece of the puzzle be compatible and integrate smoothly with the others. This memo explored into various problems of sub-optimality of NEMO Basic Support, and discussed different aspects of a route optimized solution in NEMO. The intent of this document is to trigger fruitful discussions that in turn will enhance our common understanding of the route optimization problem and solution space. Ng, et al. Expires April 25, 2005 [Page 24] Internet-Draft RO-Taxonomy October 2004 6. Acknowledgments The authors wish to thank: Greg Daley, Thierry Ernst, Erik Nordmark, T.J. Kniveton, Alexandru Petrescu, Hesham Soliman, Ryuji Wakikawa and Patrick Wetterwald for their various contributions. In addition, the authors would also like to extend their heart-felt gratitude to Marco Molteni, who was a co-author for the earlier versions of this document. 7 References [1] Devarapalli, V., "Network Mobility (NEMO) Basic Support Protocol", draft-ietf-nemo-basic-support-03 (work in progress), June 2004. [2] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [3] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004. [4] Ernst, T. and H. Lach, "Network Mobility Support Terminology", draft-ietf-nemo-terminology-01 (work in progress), February 2004. [5] Ernst, T., "Network Mobility Support Goals and Requirements", draft-ietf-nemo-requirements-02 (work in progress), February 2004. [6] Zhao, F., Wu, F. and S. Jung, "NEMO Route Optimization Problem Statement, Requirements and Evaluation Considerations", draft-zhao-nemo-ro-ps-00 (work in progress), October 2004. [7] Watari, M. and T. Ernst, "Route Optimization with Nested Correspondent Nodes", draft-watari-nemo-nested-cn-00 (work in progress), October 2004. [8] Deering, S. and B. Zill, "Redundant Address Deletion when Encapsulating IPv6 in IPv6", draft-deering-ipv6-encap-addr-deletion-00 (work in progress), November 2001. [9] Na, J., "Generic Route Optimization Model for NEMO Extended Support", draft-na-nemo-gen-ro-model-00 (work in progress), July 2004. [10] Soliman, H., Castelluccia, C., Malki, K. and L. Bellier, "Hierarchical Mobile IPv6 mobility management (HMIPv6)", Ng, et al. Expires April 25, 2005 [Page 25] Internet-Draft RO-Taxonomy October 2004 draft-ietf-mipshop-hmipv6-02 (work in progress), June 2004. [11] Thubert, P., "Global HA to HA protocol", draft-thubert-nemo-global-haha-00 (work in progress), October 2004. [12] Droms, R. and O. Troan, "IPv6 Prefix Options for DHCPv6", draft-troan-dhcpv6-opt-prefix-delegation-01 (work in progress), May 2002. [13] Thubert, P. and M. Molteni, "IPv6 Reverse Routing Header and its application to Mobile Networks", draft-thubert-nemo-reverse-routing-header-05 (work in progress), June 2004. [14] Ng, C. and J. Hirano, "Extending Return Routability Procedure for Network Prefix (RRNP)", draft-ng-nemo-rrnp-00 (work in progress), October 2004. [15] Bernardos, C., Bagnulo, M. and M. Calderon, "MIRON: MIPv6 Route Optimization for NEMO", ASWN 2004, Online: http://www.it.uc3m.es/cjbc/papers/miron_aswn2004.pdf. [16] Ng, C. and T. Tanaka, "Securing Nested Tunnels Optimization with Access Router Option", draft-ng-nemo-access-router-option-01 (work in progress), July 2004. [17] Na, J., "Route Optimization Scheme based on Path Control Header", draft-na-nemo-path-control-header-00 (work in progress), April 2004. [18] Wakikawa, R., "Optimized Route Cache Protocol (ORC)", draft-wakikawa-nemo-orc-00 (work in progress), July 2004. [19] Na, J., "Secure Nested Tunnels Optimization using Nested Path Information", draft-na-nemo-nested-path-info-00 (work in progress), September 2003. [20] Kang, H., "Route Optimization for Mobile Network by Using Bi-directional Between Home Agent and Top Level Mobile Router", draft-hkang-nemo-ro-tlmr-00 (work in progress), June 2003. [21] Ohnishi, H., "HMIP based Route optimization method in a mobile network", draft-ohnishi-nemo-ro-hmip-00 (work in progress), October 2003. Ng, et al. Expires April 25, 2005 [Page 26] Internet-Draft RO-Taxonomy October 2004 [22] Paakkonen, P. and J. Latvakoski, "Mobile Network Prefix Delegation extension for Mobile IPv6", draft-paakkonen-nemo-prefix-delegation-00 (work in progress), March 2003. [23] Droms, R. and P. Thubert, "DHCPv6 Prefix Delegation for NEMO", draft-droms-nemo-dhcpv6-pd-01 (work in progress), February 2004. [24] Lee, K., "Route Optimization for Mobile Nodes in Mobile Network based on Prefix Delegation", draft-leekj-nemo-ro-pd-02 (work in progress), February 2004. [25] Jeong, J., "ND-Proxy based Route Optimization for Mobile Nodes in Mobile Network", draft-jeong-nemo-ro-ndproxy-02 (work in progress), February 2004. [26] Perera, E., "Extended Network Mobility Support", draft-perera-nemo-extended-00 (work in progress), July 2003. Authors' Addresses Chan-Wah Ng Panasonic Singapore Laboratories Pte Ltd Blk 1022 Tai Seng Ave #06-3530 Tai Seng Industrial Estate Singapore 534415 SG Phone: +65 65505420 EMail: cwng@psl.com.sg Pascal Thubert Cisco Systems Technology Center Village d'Entreprises Green Side 400, Avenue Roumanille Biot - Sophia Antipolis 06410 FRANCE EMail: pthubert@cisco.com Ng, et al. Expires April 25, 2005 [Page 27] Internet-Draft RO-Taxonomy October 2004 Hiroyuki Ohnishi NTT network service systems laboratories, NTT cooperation 9-11, Midori-Cho 3-Chome Musashino-shi Tokyo 180-8585 JAPAN EMail: ohnishi.hiroyuki@lab.ntt.co.jp Paik, Eun Kyoung KT Portable Internet Team, Convergence Lab., 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/ Ng, et al. Expires April 25, 2005 [Page 28] Internet-Draft RO-Taxonomy October 2004 Appendix A. Proposed Route Optimizations Here, we attempt to list the numerous proposed solutions according to the solution space defined in Section 3. Although we made effort in listing all possible solutions, sincere apology is extended to authors of solutions that we might have missed out. A.1 MR-to-CN Optimizations Most MR-to-CN optimizations proposals are implicitly achieved by sending mobile network prefixes to correspondent nodes. The Return Routability procedure with Network Prefix (RRNP) [14] proposed an extension to return routability procedure for verifying the validity of mobile network prefixes. One approach that uses the mobile router as a proxy for establishing route optimization on behalf of mobile network nodes can be found in [15]. In addition, various nested tunnel optimizations proposals (see Appendix A.3) can also be extended to correspondent node, thus enabling the MR-to-CN optimizations. Example includes the Reverse Routing Header (RRH) [13], Access Router Option (ARO) [16]. A.2 Infrastructure Optimizations All known infrastructure optimization proposals defines the entity known as correspondent router capable of terminating bi-directional tunnels from mobile routers on behalf of correspondent nodes, thereby achieving route optimization. The difference between these proposals is mainly the way correspondent routers are discovered. Proposals include: o Path Control Header (PCH) [17] The PCH approach requires the home agent to piggyback a Path Control Header on the packet when forwarding packets arriving from a bi-directional tunnel to a correspondent node. Because PCH is a hop-by-hop option header, all intermediate routers lying between the home agent and the correspondent node will inspect the PCH. If a correspondent router exists among these intermediate router, it can contact the mobile router (identified in the PCH) and establish a optimized tunnel with the mobile router. o Optimized Routing Cache (ORC) [18] The ORC approach defines the functionality of a correspondent router able to terminate bi-directional tunnels from mobile Ng, et al. Expires April 25, 2005 [Page 29] Internet-Draft RO-Taxonomy October 2004 routers. Mobile routers discover correspondent routers by sending a query message to a multicast address corresponding to "all correspondent router" address. The query message contains the address of the correspondent node for which the mobile router wishes to send packets to. The correspondent router managing the network within which the correspondent node resides will responds to this query. The proposal also suggest correspondent router to inform mobile routers the prefix information of the network it is capable of managing, so that any other traffic flows that originate and end at the mobile network and the network the correspondent router is managing can also enjoy route optimization. A.3 Nested Tunnel Optimizations Many proposed solutions for NEMO Extended Support targets the nested tunnel optimization. Most of these involves sending of upstream information to the home agent of a nested mobile router, including o Reverse Routing Header (RRH) [13] The RRH approach avoids the multiple encapsulation of the traffic but maintains the home tunnel of the first mobile router on the egress path. The first mobile router on the way out (egress direction) encapsulates the packet over its reverse tunnel, using a form of Record Route header, the RRH. The upstream mobile routers simply swap their care-of address and the source of the packet, saving the original source in the RRH. The home agent transforms the RRH in a Routing Header to perform source routing across the nested mobile network, along the ingress path to the target mobile router. o Access Router Option (ARO) [16] The ARO approach is somewhat similar to the RRH in that only the home tunnel of the first nested mobile router in the egress path is maintained. This is done by having the nested mobile router to send an ARO in Binding Update to inform its home agent the address of its access router (i.e. an upstream mobile router). Using this information, the home agent can build a Routing Header to source-route a packet to the nested mobile router within in a nested mobile network. Upstream mobile routers can also send binding update messages to the home agent of the nested mobile router, thus allowing a complete routing header be built recursively by the home agent. Ng, et al. Expires April 25, 2005 [Page 30] Internet-Draft RO-Taxonomy October 2004 o Nested Path Info (NPI) [19] The NPI approach is somewhat similar to the ARO approach, except that instead of sending only the home address of the upstream mobile router to its home agent, a nested mobile router send a nested information on the care-of addresses of all upstream mobile routers. Using this information, the home agent can build a Routing Header to source-route a packet to the nested mobile router within in a nested mobile network. o Top Level Mobile Router (TLMR) [20] In TLMR, each visiting mobile router obtains the address of the root-MR through router advertisement messages. This information is passed to its home agent in a binding update message. The visiting mobile router also registers with the root-MR. With these registrations, the root-MR maintains a topology of the mobile network. In addition, the root MR also establish tunnels with the home agents of every visiting mobile router. This way, packet to and from each nested mobile network will be relayed through the root-MR, through an additional tunnel between the root-MR and the home agent of the nested mobile network. o Hierarchical Mobile IP (HMIP) [21] This approach proposes an adaptation of HMIPv6 [10] for NEMO. Here, information on the root-MR (acting as a Mobile Anchor Point, MAP) is passed to nested mobile routers in the MAP option of a router advertisement. Nested mobile routers then register their regional and local care-of address with the root-MR. Packets are then transfered to and from a nested mobile router through two separate tunnels: one between the nested mobile router and the root-MR, the other between the root-MR and the home agent of the nested mobile router. Other approaches that does not really require the sending of upstream information to home agent includes: o Prefix Delegation [22][23][24] The prefix delegation approach is somewhat to HMIPv6 what NEMO is to MIPv6. The Access Router of the nested structure is both a NEMO home agent and a DHCP-PD server, for an aggregation that it owns and advertises to the infrastructure. When visiting the nested structure, each mobile router is delegated a mobile network prefix from the access router using DHCP-Prefix Delegation. The mobile router registers this delegated prefix to the access router that is acting as a NEMO home agent. The mobile router also Ng, et al. Expires April 25, 2005 [Page 31] Internet-Draft RO-Taxonomy October 2004 autoconfigures an address from the delegated prefix and uses it as a care-of address to register its own mobile network prefix(es) to its own home agent using NEMO Basic Support. It is possible for a mobile router to protect its own mobile network prefixes while advertising in the clear the local prefix for other mobile routers to roam into. This allows a strict privacy of visited and visitors, and enables some specific policies in each mobile router. o Neighbor Discovery Proxy (ND-Proxy) [25] The ND-Proxy approach achieves route optimization by having mobile routers to act as neighbor discovery proxy. Mobile router will configure a care-of address from the network prefix advertised by its access router, and also relay this prefix to its subnets. As ND-Proxy, mobile routers will also handle neighbor discovery on behalf of visiting mobile nodes in its subnets. As such, the entire mobile network and its access network forms a logical multilink subnet, thus eliminating any nesting. This solution also lends itself well to achieve MIPv6-over-NEMO optimization. A.4 MIPv6-over-NEMO Optimizations Some solutions proposed for nested tunnels optimization can be extended for MIPv6-over-NEMO optimization, including Access Router Option (ARO) [16], Top Level Mobile Router (TLMR) [20], Prefix Delegation approaches [22][23][24], and Neighbor Discovery Proxy (ND-Proxy) [25]. One solution that caters specifically for MIPv6-over-NEMO optimization is: o Extended Network Mobility Support [26] This approach is somewhat similar to the Prefix Delegation in which the mobile router would obtain a prefix from its access network, and allows visiting mobile network nodes to autoconfigure their care-of addresses from this prefix. By doing so, packets destined to any MIPv6 node within the mobile network will not go through the home agent of the mobile router, thereby achieving MIPv6-over-NEMO optimization. This solution also allows the mobile router to act as home agent for local fixed nodes and local mobile nodes within the mobile network in an attempt to allow these nodes to achieve route optimization (using standard MIPv6 techniques). Ng, et al. Expires April 25, 2005 [Page 32] Internet-Draft RO-Taxonomy October 2004 A.5 Intra-NEMO Optimizations Currently, there are no proposals that specifically target intra-NEMO optimization, though as explained previously, most solutions that achieves MN-to-CN optimizations can also achieve intra-NEMO optimization. Ng, et al. Expires April 25, 2005 [Page 33] Internet-Draft RO-Taxonomy October 2004 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Ng, et al. Expires April 25, 2005 [Page 34]