idnits 2.17.00 (12 Aug 2021)

/tmp/idnits45993/draft-thubert-nemo-ro-taxonomy-03.txt:

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  https://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

  ** It looks like you're using RFC 3978 boilerplate.  You should update this
     to the boilerplate described in the IETF Trust License Policy document
     (see https://trustee.ietf.org/license-info), which is required now.

  -- Found old boilerplate from RFC 3978, Section 5.1.a on line 21.

  -- Found old boilerplate from RFC 3978, Section 5.5 on line 1450.

  -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1427.

  -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1434.

  -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1440.

  ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure
     Acknowledgement. 

  ** This document has an original RFC 3978 Section 5.4 Copyright Line,
     instead of the newer IETF Trust Copyright according to RFC 4748.

  ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead
     of the newer disclaimer which includes the IETF Trust according to RFC
     4748.

  ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate
     instead of verbatim RFC 3978 boilerplate.  After 6 May 2005, submission
     of drafts without verbatim RFC 3978 boilerplate is not accepted.

     The following non-3978 patterns matched text found in the document. 
     That text should be removed or replaced:

        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
        becomes aware will be disclosed, in accordance with Section 6 of
        BCP 79.


  Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

  == No 'Intended status' indicated for this document; assuming Proposed
     Standard


  Checking nits according to https://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

  ** The document seems to lack a Security Considerations section.

  ** The document seems to lack an IANA Considerations section.  (See Section
     2.2 of https://www.ietf.org/id-info/checklist for how to handle the case
     when there are no actions for IANA.)

  ** The document seems to lack separate sections for Informative/Normative
     References.  All references will be assumed normative when checking for
     downward references.

  ** There are 3 instances of lines with control characters in the document.


  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not
     match the current year

  -- The document seems to lack a disclaimer for pre-RFC5378 work, but may
     have content which was first submitted before 10 November 2008.  If you
     have contacted all the original authors and they are all willing to grant
     the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
     this comment.  If not, you may need to add the pre-RFC5378 disclaimer. 
     (See the Legal Provisions document at
     https://trustee.ietf.org/license-info for more information.)

  -- The document date (October 25, 2004) is 6417 days in the past.  Is this
     intentional?

  -- Found something which looks like a code comment -- if you have code
     sections in the document, please surround them with '<CODE BEGINS>' and
     '<CODE ENDS>' lines.


  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

     (See RFCs 3967 and 4897 for information about using normative references
     to lower-maturity documents in RFCs)

  == Outdated reference: draft-ietf-nemo-basic-support has been published as
     RFC 3963

  ** Obsolete normative reference: RFC 3775 (ref. '2') (Obsoleted by RFC 6275)

  ** Downref: Normative reference to an Informational RFC: RFC 3753 (ref. '3')

  == Outdated reference: draft-ietf-nemo-terminology has been published as
     RFC 4885

  ** Downref: Normative reference to an Informational draft:
     draft-ietf-nemo-terminology (ref. '4')

  == Outdated reference: draft-ietf-nemo-requirements has been published as
     RFC 4886

  ** Downref: Normative reference to an Informational draft:
     draft-ietf-nemo-requirements (ref. '5')

  == Outdated reference: A later version (-01) exists of
     draft-zhao-nemo-ro-ps-00

  -- Possible downref: Normative reference to a draft: ref. '6' 

  == Outdated reference: A later version (-01) exists of
     draft-watari-nemo-nested-cn-00

  -- Possible downref: Normative reference to a draft: ref. '7' 

  -- Possible downref: Normative reference to a draft: ref. '8' 

  -- Possible downref: Normative reference to a draft: ref. '9' 

  == Outdated reference: draft-ietf-mipshop-hmipv6 has been published as RFC
     4140

  ** Downref: Normative reference to an Experimental draft:
     draft-ietf-mipshop-hmipv6 (ref. '10')

  == Outdated reference: A later version (-02) exists of
     draft-thubert-nemo-global-haha-00

  -- Possible downref: Normative reference to a draft: ref. '11' 

  -- Possible downref: Normative reference to a draft: ref. '12' 

  == Outdated reference: A later version (-07) exists of
     draft-thubert-nemo-reverse-routing-header-05

  -- Possible downref: Normative reference to a draft: ref. '13' 

  -- Possible downref: Normative reference to a draft: ref. '14' 

  -- Possible downref: Non-RFC (?) normative reference: ref. '15'

  -- Possible downref: Normative reference to a draft: ref. '16' 

  -- Possible downref: Normative reference to a draft: ref. '17' 

  == Outdated reference: A later version (-01) exists of
     draft-wakikawa-nemo-orc-00

  -- Possible downref: Normative reference to a draft: ref. '18' 

  -- Possible downref: Normative reference to a draft: ref. '19' 

  -- Possible downref: Normative reference to a draft: ref. '20' 

  -- Possible downref: Normative reference to a draft: ref. '21' 

  -- Possible downref: Normative reference to a draft: ref. '22' 

  == Outdated reference: A later version (-02) exists of
     draft-droms-nemo-dhcpv6-pd-01

  -- Possible downref: Normative reference to a draft: ref. '23' 

  -- Possible downref: Normative reference to a draft: ref. '24' 

  -- Possible downref: Normative reference to a draft: ref. '25' 

  -- Possible downref: Normative reference to a draft: ref. '26' 


     Summary: 14 errors (**), 0 flaws (~~), 12 warnings (==), 28 comments
     (--).

     Run idnits with the --verbose option for more detailed information about
     the items above.

--------------------------------------------------------------------------------

1	NEMO Working Group                                                 C. Ng
2	Internet-Draft                                  Panasonic Singapore Labs
3	Expires: April 25, 2005                                       P. Thubert
4	                                                           Cisco Systems
5	                                                              H. Ohnishi
6	                                                                     NTT
7	                                                                 E. Paik
8	                                                                      KT
9	                                                        October 25, 2004

11	       Taxonomy of Route Optimization models in the NEMO Context
12	                   draft-thubert-nemo-ro-taxonomy-03

14	Status of this Memo

16	   This document is an Internet-Draft and is subject to all provisions
17	   of section 3 of RFC 3667.  By submitting this Internet-Draft, each
18	   author represents that any applicable patent or other IPR claims of
19	   which he or she is aware have been or will be disclosed, and any of
20	   which he or she become aware will be disclosed, in accordance with
21	   RFC 3668.

23	   Internet-Drafts are working documents of the Internet Engineering
24	   Task Force (IETF), its areas, and its working groups.  Note that
25	   other groups may also distribute working documents as
26	   Internet-Drafts.

28	   Internet-Drafts are draft documents valid for a maximum of six months
29	   and may be updated, replaced, or obsoleted by other documents at any
30	   time.  It is inappropriate to use Internet-Drafts as reference
31	   material or to cite them other than as "work in progress."

33	   The list of current Internet-Drafts can be accessed at
34	   http://www.ietf.org/ietf/1id-abstracts.txt.

36	   The list of Internet-Draft Shadow Directories can be accessed at
37	   http://www.ietf.org/shadow.html.

39	   This Internet-Draft will expire on April 25, 2005.

41	Copyright Notice

43	   Copyright (C) The Internet Society (2004).

45	Abstract

47	   With current Network Mobility (NEMO) Basic Support, all
48	   communications to and from mobile network nodes must go through the
49	   MR-HA tunnel when the mobile network is away.  This results in
50	   increased length of packet route and increased packet delay.  To
51	   overcome these limitations, one might have to turn to route
52	   optimization (RO) for NEMO.  This memo documents various types of
53	   route optimization in NEMO, and explores the benefits and tradeoffs
54	   in different aspects of NEMO route optimization.

56	Table of Contents

58	   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
59	   2.  Problem Statement of NEMO Route Optimization . . . . . . . . .  4
60	     2.1   Sub-Optimality with NEMO Basic Support . . . . . . . . . .  4
61	     2.2   Nesting of Mobile Networks . . . . . . . . . . . . . . . .  5
62	     2.3   MIPv6 Host in Mobile Networks  . . . . . . . . . . . . . .  7
63	     2.4   Communications within a Mobile Networks  . . . . . . . . .  7
64	   3.  Solution Space of NEMO Route Optimization  . . . . . . . . . .  8
65	     3.1   MR-to-CN Optimization  . . . . . . . . . . . . . . . . . .  9
66	     3.2   Infrastructure Optimization  . . . . . . . . . . . . . . . 10
67	     3.3   Nested Tunnels Optimization  . . . . . . . . . . . . . . . 11
68	     3.4   MIPv6-over-NEMO Optimization . . . . . . . . . . . . . . . 12
69	     3.5   Intra-NEMO Optimization  . . . . . . . . . . . . . . . . . 13
70	   4.  Analysis of Solution Space . . . . . . . . . . . . . . . . . . 14
71	     4.1   General Considerations of RO Solution  . . . . . . . . . . 14
72	       4.1.1   Additional Signaling Overhead  . . . . . . . . . . . . 14
73	       4.1.2   Increased Protocol Complexity  . . . . . . . . . . . . 15
74	       4.1.3   Mobility Awareness . . . . . . . . . . . . . . . . . . 15
75	       4.1.4   New Functionalities  . . . . . . . . . . . . . . . . . 15
76	       4.1.5   Other Considerations . . . . . . . . . . . . . . . . . 17
77	     4.2   Specific Types of RO Solution  . . . . . . . . . . . . . . 17
78	       4.2.1   MR-to-CN Optimization  . . . . . . . . . . . . . . . . 17
79	       4.2.2   Infrastructure Optimization  . . . . . . . . . . . . . 19
80	       4.2.3   Nested Tunnels Optimization  . . . . . . . . . . . . . 20
81	       4.2.4   MIPv6-over-NEMO Optimization . . . . . . . . . . . . . 21
82	       4.2.5   Intra-NEMO Optimization  . . . . . . . . . . . . . . . 23
83	   5.  Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 24
84	   6.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 25
85	   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
86	       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 27
87	   A.  Proposed Route Optimizations . . . . . . . . . . . . . . . . . 29
88	     A.1   MR-to-CN Optimizations . . . . . . . . . . . . . . . . . . 29
89	     A.2   Infrastructure Optimizations . . . . . . . . . . . . . . . 29
90	     A.3   Nested Tunnel Optimizations  . . . . . . . . . . . . . . . 30
91	     A.4   MIPv6-over-NEMO Optimizations  . . . . . . . . . . . . . . 32
92	     A.5   Intra-NEMO Optimizations . . . . . . . . . . . . . . . . . 33
93	       Intellectual Property and Copyright Statements . . . . . . . . 34

95	1.  Introduction

97	   With current Network Mobility (NEMO) Basic Support [1], all
98	   communications to and from nodes in a mobile network must go through
99	   the bi-directional tunnel established between the mobile router (MR)
100	   and its home agent (HA) when the mobile network is away.  Although
101	   such an arrangement allows mobile network nodes (MNNs) to reach and
102	   be reached by any node on the Internet, there are associated
103	   limitations which might be unacceptable for certain applications.  To
104	   substantially ameliorate these limitations, one might have to turn to
105	   route optimization (RO) for NEMO.  Here, we use the term "route
106	   optimization" to loosely refer to any approach that optimize the
107	   route taken by packets sent between a mobile network node and
108	   correspondent node (CN).

110	   This document aims to explore limitations inherent in NEMO Basic
111	   Support, and analyze the possible approaches to route optimization
112	   with NEMO.  It is expected for readers to be familiar with general
113	   terminologies related to mobility in [2] and [3], and NEMO related
114	   terms defined in [4].  In addition, it is beneficial to keep in mind
115	   the design requirements of NEMO [5].  A point to note is that since
116	   this document discusses aspects of route optimization, the readers
117	   may assume that a mobile network or a mobile host is away when they
118	   are mentioned throughout this document, unless it is explicitly
119	   specified that they are at home.

121	   It is the objective of this document to address the need for a route
122	   optimization analysis in the NEMO Working Group.  To quote the
123	   charter of the NEMO Working group:

125	      "...  The WG will work on: ...  ...  [an] informational document
126	      which specifies a detailed problem statement for route
127	      optimization and looks at various approaches to solving this
128	      problem.  This document will look into the issues and tradeoffs
129	      involved in making the network's movement visible to some nodes,
130	      by optionally making them "NEMO aware".  The interaction between
131	      route optimization and IP routing will also be described in this
132	      document.  Furthermore, security considerations for the various
133	      approaches will also be considered.  ..."

135	   To such end, this document first describes the problem of route
136	   optimization in NEMO in Section 2.  Next, we explore into various
137	   possible approaches to solving the problem of route optimization in
138	   Section 3.  Following this, Section 4 discusses various issues that a
139	   route optimization solution might face.  Finally, Section 5 concludes
140	   this memo.  In addition, we attempt to list various proposed
141	   solutions for route optimization in Appendix A, and classify them
142	   according to the solution space described in Section 3.

144	2.  Problem Statement of NEMO Route Optimization

146	   In essence, the problem of route optimization in NEMO is to eliminate
147	   limitations, or sub-optimality, introduced by the bi-directional
148	   tunnel between a mobile router and its home agent (also known as the
149	   MR-HA tunnel).  In the following sub-sections, we will describe the
150	   effects of sub-optimal routing with NEMO-Basic Support, and how they
151	   get amplified with nesting of mobile networks.  We will also look
152	   into the nesting of a Mobile IPv6 (MIPv6) host in a mobile network.
153	   In addition, we will explore the impact of MR-HA tunnel on
154	   communications between two mobile network nodes (MNNs) on different
155	   links of the same mobile network.

157	   Readers might be interested to note the availability of [6] which
158	   also discusses the problem statement of NEMO route optimization.

160	2.1  Sub-Optimality with NEMO Basic Support

162	   With NEMO Basic Support, all packets sent between a mobile network
163	   node and its correspondent node are forwarded through the MR-HA
164	   tunnel.  This results in a sub-optimal routing, also known as
165	   "dog-leg routing", with NEMO Basic Support.  This sub-optimality has
166	   the following undesirable effects:

168	   o  Longer route leading to increased delay

170	      Because a packet must transit from a mobile network to the home
171	      agent then to the correspondent node, the transit time of the
172	      packet is always higher than if the packet were to go straight
173	      from the mobile network to the correspondent node.  In the best
174	      case, where the correspondent node resides near the home agent,
175	      the increase in packet delay is minimal.  In the worst case, where
176	      both the mobile network and the correspondent node are located at
177	      a point furthest away from the home agent on the Internet, the
178	      increase in delay is tremendous.  Applications such as real-time
179	      multimedia streaming may not be able to tolerate such increase in
180	      packet delay.

182	   o  Increased packets overhead

184	      The encapsulation of packets in the MR-HA tunnel results in
185	      increased packet size due to addition of an outer packet.  This
186	      reduces the bandwidth efficiency, as IPv6 header can be quite
187	      substantial (at least 40 bytes).

189	   o  Increased processing delay

191	      The encapsulation of packets in the MR-HA tunnel also results in
192	      increased processing delay at the points of encapsulation and
193	      decapsulation.

195	   o  Increased chances of packet fragmentation

197	      The increased in packet size due to packet encapsulation may
198	      increase the chances of the packet being fragmented along the
199	      MR-HA tunnel.  This can occur if there is no prior path MTU
200	      discovery conducted, or if the MTU discovery mechanism did not
201	      take into account the encapsulation of packets.  Packets
202	      fragmentation will result in a further increase in packet delays,
203	      and further reduction of bandwidth efficiency.

205	2.2  Nesting of Mobile Networks

207	   With nesting of mobile networks, the use of NEMO Basic Support
208	   further amplifies the sub-optimality of routing.  We call this the
209	   amplification effect of nesting, where the (undesirable) effects of
210	   sub-optimal routing with NEMO Basic Support is amplified with each
211	   level of nesting of mobile networks.  This is best illustrated by an
212	   example shown in Figure 1.

214	                                HAofMR1
215	                       +-----------|---------+
216	             HAofMR2 --|      Internet       |---CN
217	                       +---------------|-----+
218	                        /         Access Router
219	                   HAofMR3             |
220	                              ====?========
221	                                 MR1
222	                                  |
223	                    ====?===========?===========?===
224	                       MR5         MR2         MR6
225	                        |           |           |
226	                  ==|=======   ===?======    ======|==
227	                   LFN2          MR3             LFN3
228	                                  |
229	                            ==|=========?==
230	                             LFN1      MR4
231	                                        |
232	                                    =========

234	             Figure 1: An example of nested Mobile Network

236	   Using NEMO Basic Support, the flow of packets between a Local Fixed
237	   Node LFN1 and a correspondent node CN would need to go through three
238	   separate tunnels, illustrated in Figure 2 below.

240	                               ----------.
241	                      --------/         /----------.
242	             -------/        |         |          /-------
243	   CN ------( -  - | -  -  - | -  -  - | -  -  - |  -  - (------- LFN
244	      HAofMR3-------\        |         |          \-------MR3
245	               HAofMR2--------\         \----------MR2
246	                         HAofMR1---------MR1

248	              Figure 2: Nesting of Bi-Directional Tunnels

250	   This leads to the following problems:

252	   o  'Pinball' routing

254	      Both inbound and outbound packets will flow via the HAs of all the
255	      MRs on their path within the NEMO, with increased latency, less
256	      resilience and more bandwidth usage.  To illustrate this effect,
257	      Figure 3 below shows the route taken by a packet sent from LFN1 to
258	      CN:

260	                   +--> HAofMR3 ---------------------+
261	                   |                                 |
262	                   +----------------- HAofMR2 <--+   |
263	                                                 |   |
264	                                 +---------------+   |
265	                                 |                   V
266	                              HAofMR1 <------+       CN
267	                                             |
268	                                             |
269	                   LFN1 --> MR3 --> MR2 --> MR1

271	                      Figure 3: 'Pinball' Routing

273	       For more illustration of the pinball routing, see [7].

275	   o  Increased Packet Size

277	      An extra IPv6 header is added per level of nesting to all the
278	      packets.  The header compression suggested in [8] cannot be
279	      applied because both the source and destination (the intermediate
280	      MR and its HA), are different hop to hop.

282	2.3  MIPv6 Host in Mobile Networks

284	   When a MIPv6 mobile node joins a mobile network, it becomes a
285	   visiting mobile node (VMN) of the mobile network.  Packets sent to
286	   and from the visiting mobile node will have to be routed not only to
287	   the home agent of the visiting mobile node, but also to the home
288	   agent of the mobile router in the mobile network.  This suffers the
289	   same amplification effect of nested mobile router mentioned in
290	   Section 2.2.

292	   In addition, although Mobile IPv6 [2] allows a mobile host to perform
293	   route optimization with its correspondent node to avoid tunneling
294	   with its home agent, the "optimized" route is no longer optimized
295	   when the mobile host is attached to a mobile network.  This is
296	   because the route between the mobile host and its correspondent node
297	   is subjected to the sub-optimality introduced by the MR-HA tunnel.
298	   Interested readers may refer to [7] for examples of how the routes
299	   will appear with nesting of MIPv6 hosts in mobile networks.

301	2.4  Communications within a Mobile Networks

303	   The reliance on the MR-HA tunnel has its implications on MNNs in a
304	   nested mobile network communicating with each other.  Let us consider
305	   the previous example illustrated in Figure 1.  Suppose LFN1 and LFN2
306	   are communicating with each other.  With NEMO Basic Support, a packet
307	   sent from LFN1 to LFN2 will follow the path of: LFN1 -> MR3 -> MR2 ->
308	   MR1 -> HAofMR1 -> HAofMR2 -> HAofMR3 -> HAofMR5 -> HAofMR1 -> MR1 ->
309	   MR5 -> LFN2.  A round-about trip indeed where the direct path would
310	   be LFN1 -> MR3 -> MR2 -> MR5 -> LFN2.

312	   The consequences of increase packet delay and packet size have been
313	   discussed in previous sub-sections.  Here, there is an additional
314	   effect that is undesirable: should MR1 loses its connection to the
315	   global Internet, LFN1 and LFN2 can no longer communicates with each
316	   other, even though the direct path from LFN1 to LFN2 is unaffected!

318	3.  Solution Space of NEMO Route Optimization

320	   To address the problems discussed in Section 2, one can incorporate
321	   route optimization into NEMO.  This is also known as the NEMO
322	   Extended Support.  Although a standardized NEMO Extended Support has
323	   yet materialize, one can expect it to show some of the following
324	   benefits:

326	   o  Shorter Delay

328	      Route optimization involves the selection and utilization of a
329	      shorter (or faster) route to be taken for traffic between a mobile
330	      network node and correspondent node.  Hence a major benefit of
331	      route optimization should be shorter delay experiences by the data
332	      traffic between the two end nodes.  This may possibly in turn
333	      leads to better overall Quality of Services characteristics, such
334	      as reduced jitter and packet loss.

336	   o  Reduced Consumption of Overall Network Resources

338	      Through the selection of a shorter route, the total link
339	      utilization for all links used by traffic between the two end
340	      nodes should be much lower than that used if route optimization is
341	      not carried out.  This would result in a lighter network load with
342	      reduced congestion.

344	   o  Less Susceptibility to Link Failure

346	      An optimized route would conceivably utilize a lesser number of
347	      links between the two end nodes.  Hence, the probability of
348	      connectivity loss due to a single point of failure at a link
349	      should be lower as compared to the longer non-optimized route.

351	   o  Greater Data Efficiency

353	      Depending on the actual solution for NEMO Extended Support, the
354	      data packets exchanged between the two end nodes may not require
355	      as many levels of encapsulation as required by NEMO Basic Support.
356	      This would mean less packet overheads, and higher data efficiency.

358	   There are multiple proposals for providing various forms of route
359	   optimizations for NEMO (see Appendix A).  In the following
360	   sub-sections, we describe the solution space of route optimization by
361	   listing different types of approach to route optimization.  Readers
362	   might be interested to take note of a route optimization model
363	   described in [9] which describes route optimization model based on
364	   the variations of tunnel end-points.

366	3.1  MR-to-CN Optimization

368	   o  Binding Update with Network Prefix

370	      A straight-forward approach to route optimization is in NEMO is
371	      for the mobile router to attempt route optimization with
372	      correspondent node.  This can be viewed as a logical extension to
373	      NEMO Basic Support, where the mobile router would send binding
374	      updates to the correspondent node containing one or more Mobile
375	      Network Prefix option.  The correspondent node having received the
376	      binding update, can then set up a bi-directional tunnel with the
377	      mobile router at the current care-of address of the mobile router,
378	      and inject a route to its routing table so that packets destined
379	      for addresses in the mobile network prefix will be routed through
380	      the bi-directional tunnel.

382	      This approach is particularly useful when a lot of MNNs in a
383	      mobile network is communicating with a few corresponding nodes.
384	      In such cases, a single binding update can optimize the routes of
385	      many flows between the correspondent node and the MNNs.

387	   o  MR as a Proxy

389	      A somewhat similar approach is for the mobile router to act as a
390	      "proxy" for the MNNs in its mobile network.  In this case, The MR
391	      uses standard MIPv6 route optimization procedure to bind the
392	      address of a MNN to its care-of address.  This has the advantage
393	      of keeping the implementations of MNNs and correspondent nodes
394	      unchanged, and can be done by having the mobile router to perform
395	      the following steps:

397	      *  determining when to perform RO (eg.  by the flow packet count)

399	      *  sending CoTI and HoTI on behalf of the MNN

401	      *  receiving CoT (trivial, since it is addressed to the MR)

403	      *  intercepting the HoT (which requires inspection of the packets
404	         addressed to the MNN)

406	      *  sending the BU and receiving the BA on behalf of MNN

408	      *  inserting the Home Address Option in packets sent by the MNN

410	      *  removing the type 2 routing header in packets sent to the MNN

412	      *  adjusting various ICMP packets to account for the modification
413	         it performs

415	3.2  Infrastructure Optimization

417	   There are two known approaches to achieve infrastructure
418	   optimization.  The first approach involves the introduction of an
419	   entity known as a correspondent-side router (C-side Router), or
420	   sometimes known simply as a correspondent router (CR) within the
421	   routing infrastructure.  As long as the correspondent router is
422	   located "closer" to the correspondent node than the home agent of the
423	   mobile router, the route between MNN and the correspondent node can
424	   be said to have optimized.  This is illustrated in Figure 4.

426	               ************************** HAofMR
427	             *                            #*#
428	           *                            #*#     +---------------------+
429	         CN                           #*#       |       LEGEND        |
430	           o                        #*#         +---------------------+
431	            o   ###############   #*#           | #: Tunnel           |
432	             CR ooooooooooooooo MR              | *: NEMO Basic route |
433	                ###############  |              | o: Optimized route  |
434	                                MNN             +---------------------+

436	                 Figure 4: Infrastructure Optimization

438	   This form of optimization can take place independently for the 2
439	   directions of the traffic:

441	   o  From MNN to CN

443	      The mobile router locates the correspondent router, establishes a
444	      tunnel with that correspondent router and sets a route to the
445	      correspondent node via the correspondent router over the tunnel.
446	      After this, traffic to the correspondent node does not flow
447	      through the home agent anymore.

449	   o  From CN to MNN

451	      The correspondent router is on the path of the traffic from the
452	      correspondent node to the home agent.  In addition, it has an
453	      established tunnel with the current care-of address of the mobile
454	      router and is aware of the mobile network prefix(es) managed by
455	      the mobile router.  The correspondent router can thus intercept
456	      packets going to the mobile network, and forward them to the
457	      mobile router over the established tunnel.

459	   The advantage of this approach is that no additional functionality is
460	   required for the correspondent node and mobile network nodes.

462	   The second approach is to have optimizations carried out fully in
463	   infrastructure.  One example is to make use of mobile anchor points
464	   (MAP) in HMIPv6 [10] to optimize routes between themselves.  Another
465	   example is to make use of the global HAHA protocol [11].  In this
466	   case, proxy home agents are distributed in the infrastructure and
467	   mobile routers bind to the closest proxy.  The proxy performs, in
468	   turn, a primary binding with a real home agent for that mobile
469	   router.  Then, the proxy might establish secondary bindings with
470	   other home agents or proxies in the infrastructure, in order to
471	   improve the end-to-end path.  In this case, the proxies discover each
472	   other, establish a tunnel and exchange the relevant mobile network
473	   prefix information in the form of explicit prefix routes.  There is
474	   no need for return routability test or its like since the security is
475	   built in the infrastructure, one way or an other, and the proxies
476	   belong to the infrastructure.

478	3.3  Nested Tunnels Optimization

480	   Nested tunnels optimization is targeted at nested mobile networks,
481	   where there will be multiple levels of MR-HA tunnels with NEMO Basic
482	   Support.  Such a solution will seek to minimize the number of
483	   tunnels, possibly by collapsing the amount of tunnels required
484	   through dome form of signaling between the mobile routers and home
485	   agents.  This ameliorate the amplification effect of tunnel nesting,
486	   and at best, the performance of a nested mobile network will be the
487	   same as though there were no nesting of mobile networks.

489	   There have been various proposals on nested tunnels optimization, and
490	   we can model them according to:

492	   o  Sending Information of Upstream Mobile Routers

494	      This involves sending information on upstream mobile router(s) to
495	      the home agent of a nested mobile router, thereby enabling the
496	      home agent to forward tunneled packets directly to the nested
497	      mobile router via the upstream mobile router(s), skipping the home
498	      agents of upstream mobile router(s).  This usually involves the
499	      use of a routing header to route packets through the upstream
500	      mobile router(s).

502	      The information of upstream mobile router (for simplicity, we
503	      refer to it as "upstream information") may contain information on
504	      the entire chain of upstream mobile routers, or it may only
505	      contain information on the immediate parent mobile router.  For
506	      the former, the home agent can build a multihop routing header
507	      from a single transmission of the information.  For the latter,
508	      each upstream mobile router may have to send binding update to the
509	      home agent of the nested mobile router, thereby enabling the home
510	      agent of the nested mobile router to build a multihop routing
511	      header recursively.

513	   o  Prefix Delegation

515	      An alternative approach to nested tunnels optimization is to use
516	      prefix delegation.  Here, each mobile router in a nested mobile
517	      network is delegated a mobile network prefix from the access
518	      router using DHCP Prefix Delegation [12].  Each mobile router also
519	      autoconfigures its care-of address from this delegated prefix.  In
520	      this way, the care-of addresses of each mobile router are all from
521	      an aggregatable address space starting from the access router.
522	      This may be used to eliminate any nesting of tunnels.  It may also
523	      be used to achieve MIPv6-over-NEMO optimization (see Section 3.4)
524	      if MIPv6 hosts autoconfigure their care-of addresses from the
525	      prefix as well.

527	   o  Mobile Aggregation

529	      This model applies to a category of problems where the mobile
530	      networks share a same administration and consistently move
531	      together (e.g.  a fleet at sea).  In this model, there is a
532	      cascade of home agents.  The main home agent is fixed in the
533	      infrastructure, and advertises an aggregated view of all the
534	      mobile networks.  This aggregation is actually divided over a
535	      number of mobile routers, the root-MRs.  The root-MRs subdivide
536	      some of their address space to the other mobile routers forming
537	      their fleet, for which they are home agent.  As home agents, the
538	      root-MRs terminate tunnels from the inside of the mobile network.
539	      As mobile router, they also terminate their home tunnels.  As
540	      routers, they forward packets between the 2 tunnels.

542	3.4  MIPv6-over-NEMO Optimization

544	   MIPv6-over-NEMO optimization involves providing optimization for a
545	   visiting mobile node within a mobile network.  There are two aspects
546	   to MIPv6-over-NEMO optimization:

548	   o  Nested Tunnels

550	      This aims to reduce the amplification effect of nested tunnels due
551	      to the nesting of the tunnel between the visiting mobile node and
552	      its home agent within the tunnel between the mobile router of the
553	      mobile network and the home agent of the mobile router.

555	      This is very similar to "Nested Tunnels Optimization" described in
556	      Section 3.3.  Thus, a possible approach is to extend the solution
557	      for nested tunnels optimization to visiting mobile node as well.

559	   o  MIPv6 Route Optimization

561	      This aims to remove the sub-optimality of a MR-HA tunnel from the
562	      MIPv6 route optimization established between a visiting mobile
563	      node and correspondent node.  One approach is to simply extend the
564	      solution for nested tunnels optimization to correspondent node.
565	      Another (arguably "evil") approach is for the mobile router to
566	      "play some trick" to the MIPv6 route optimization, such as
567	      altering messages exchanged during the return routability
568	      procedure between the visiting mobile node and correspondent node,
569	      so that packets sent from correspondent node to the visiting
570	      mobile node will be routed to the care-of address of the mobile
571	      router once route optimization is established (see Section 3.1:
572	      "MR as a Proxy").  Alternatively, the mobile router can perform
573	      return routability procedure on behalf of the visiting mobile
574	      node.  This would most likely require some signaling protocol
575	      between the visiting mobile node and the mobile router, but may be
576	      able to keep the functionality of the correspondent node
577	      unchanged.

579	3.5  Intra-NEMO Optimization

581	   A route optimization solution may seek to improve the communications
582	   between two mobile network nodes within a nested mobile network.  An
583	   example will be the optimization of packets route taken between LFN1
584	   and LFN2 of Figure 1.

586	   One may be able to extend a well-designed solution for MR-to-CN
587	   optimization to provide Intra-NEMO optimization, where, for example
588	   in Figure 1, LFN1 is treated as a correspondent node in the view of
589	   MR5, and LFN2 is treated as a correspondent node in the view of MR3.

591	   Another possibility is for the infrastructure optimization technique
592	   to be applied here.  Using the same example of communication between
593	   LFN1 and LFN2, MR3 may treat MR5 as a correspondent router for LFN2,
594	   and MR5 treats MR3 as a correspondent router for LFN1.

596	4.  Analysis of Solution Space

598	   In this section, we present an analysis of the solution space.
599	   First, we discuss the general issues that will be faced by a NEMO
600	   Extended Support solution in Section 4.1.  Then, we explore deeper
601	   into specific types of route optimization solutions in Section 4.2.

603	4.1  General Considerations of RO Solution

605	   Although route optimization, or NEMO Extended Support, can bring
606	   benefits as described in previous section, it does so with some
607	   tradeoffs.  The actual type and degree of tradeoffs depend greatly on
608	   the solution; however, in general, one would expect the costs
609	   described in the following sub-sections to be incurred.

611	4.1.1  Additional Signaling Overhead

613	   The nodes involved in performing route optimization would be expected
614	   to exchange additional signaling information in order to establish
615	   route optimization.  The cost of such signaling may be high,
616	   depending on the actual solution.  Such a cost may scale to
617	   unacceptable height when the number of mobile network nodes and/or
618	   correspondent nodes is increased.

620	   This signaling overhead is often in the form of binding update sent
621	   to home agents or correspondent nodes.  One issue that may impact
622	   route optimization solution is known as the phenomenon of "Binding
623	   Update Storm".  This occurs when a change in point of attachment of
624	   the mobile networks is accompanied with a sudden burst of binding
625	   update messages being generated, resulting in temporary congestion,
626	   packet delays or even packet lost.

628	   There has been argument that binding update storm may not be as
629	   significant as it seems.  For instance, consider a mobile network
630	   where mobile network nodes is receiving x video stream at 25 packets
631	   per seconds.  On the average, the mobile network is handling a total
632	   traffic of 25*x packets per second.  Assuming one binding update has
633	   to be sent for each video stream server, a change in point of
634	   attachment would result in at most 6*x signaling messages (if we
635	   include the return routability procedure messages and a binding
636	   acknowledgment).  Thus the signaling overhead is small compared to
637	   the normal data traffic that the mobile network is handling, and
638	   hence the effect of binding update storm is small.  On the other
639	   hand, if the normal data rate is small, the effect of binding update
640	   storm may have a greater impact.  From this discussion, it appears
641	   that the significance of binding update storm may depend on the
642	   application type (eg.  high or low data rate, tolerance on packets
643	   delay, etc).

645	   It is also possible to further moderate the effect of Binding Update
646	   Storm by having some sort of "exponential back-off" mechanism in
647	   place for the sending of binding updates.  Such a scheme aims to
648	   spread the burst of binding update transmissions over a longer period
649	   of time, thereby reducing possibility of congestion and packet drops.

651	4.1.2  Increased Protocol Complexity

653	   Some nodes will be required to have additional functionalities in
654	   order to incorporate NEMO Extended Support.  This increases the node
655	   complexity.  It may not be feasible to implement new functionalities
656	   on legacy nodes.  If such nodes are mobile, this may prove to be a
657	   significant cost	due to the limited memory resources such devices
658	   usually have.

660	   Coupled with the increased in protocol complexity, nodes that are
661	   involved in the establishment and maintenance of route optimization
662	   will have to bear increased processing load.  If such nodes are
663	   mobile, this may prove to be a significant cost due to the limited
664	   power and processing resources such devices usually have.

666	4.1.3  Mobility Awareness

668	   One advantage of NEMO Basic Support is that the correspondent nodes
669	   and mobile network nodes need not be aware of the actual location and
670	   mobility of the mobile network.  With route optimization, it might be
671	   necessary to reveal the current care-of address and any change of
672	   point of attachment of the mobile router to other nodes, such as the
673	   mobile network nodes or correspondent node.  This may mean a tradeoff
674	   between location privacy and route optimization.  In MIPv6, the
675	   mobile node can decide whether or not to perform route optimization
676	   with a given correspondent node.  Thus, the mobile node is in control
677	   of whether to trade location privacy for an optimized route.  It will
678	   be desirable that such control is also available in a route optimized
679	   solution of NEMO should the solution contain the same tradeoff.
680	   However, for solutions where route optimization decision is made by
681	   mobile router, it will be difficult for mobile network nodes to
682	   control the decision of having this tradeoff.

684	4.1.4  New Functionalities

686	   All route optimization approaches require some sort of new
687	   functionalities be implemented on some nodes.  In general, it is
688	   desirable to keep the number of nodes that require new
689	   functionalities to be kept as small as possible.  This allows for
690	   easier adoption of the solution, and also creates less impact on the
691	   existing infrastructure.

693	   In addition, if route optimization solution requires new
694	   functionalities on the part of some other nodes other than nodes
695	   within the mobile network, a mechanism for other nodes (such as
696	   mobile router) to detect if support for the new functionalities are
697	   available should also be provided.  Furthermore, it is desirable for
698	   there to be a graceful fall back procedure the required
699	   functionalities are unavailable.

701	   Possible nodes that are required to be changed includes:

703	   o  Local Fixed Nodes

705	      It is generally undesirable to affect local fixed nodes.  However,
706	      some approaches require mobile network nodes to implement new
707	      functionalities to enjoy benefits of route optimizations.

709	   o  Visiting Mobile Nodes

711	      Visiting mobile nodes in general should already have implemented
712	      MIPv6 functionalities, and since MIPv6 is a relatively new
713	      standard, there is still a considerable window to allow mobile
714	      devices to implement new functionalities.

716	   o  Mobile Routers

718	      It is expected for mobile routers to implement new functionalities
719	      in order to enable route optimizations.

721	   o  Access Routers

723	      Some approaches require access routers, or nodes in the access
724	      network to implement some new functionalities.  A clear example
725	      will be prefix delegation approach.

727	   o  Home Agents

729	      Although it is likely that vendors and operators would not mind
730	      having new functionalities in home agents, few route optimizations
731	      approaches would impact the home agents.

733	   o  Correspondent Nodes

735	      It is generally undesirable for correspondent nodes to be required
736	      to implement new functionalities.

738	   o  Correspondent Routers

740	      Correspondent routers are new entity to be deployed in the
741	      infrastructure.  Such addition would generally cause the least
742	      disruption to the existing routing infrastructure.

744	4.1.5  Other Considerations

746	   There are other considerations when analyzing the route optimization
747	   solution space.  These may not be a 'tradeoff" so to speak, but are
748	   beneficial to keep in mind when considering a route optimization
749	   solutions.

751	   o  Compatibility with NEMO Basic Support

753	      It will be beneficial to vendors if a route optimized solution for
754	      NEMO is compatible with NEMO Basic Support.  This reduces the
755	      complexity and achieves greater reuse of existing functionalities.

757	   o  In-Plane Signaling versus Off-Plane Signaling

759	      There is also considerations of whether route optimization
760	      signaling should be done in-plane and off-plane.  In-plane
761	      signaling involves embedding signaling information into headers of
762	      data packets (a good example would be the Reverse Routing Header
763	      [13]).  Off-plane signaling involves separating the signaling
764	      packets from the data packets.  Most proposals involving sending
765	      of binding updates fall within this category.

767	4.2  Specific Types of RO Solution

769	   Many of the tradeoffs discussed previously in Section 4.2 are
770	   dependent on the actual route optimization approach.  In the
771	   following sub-sections, we will explore deeper into the issues
772	   involved in each specific type of route optimization approach.

774	4.2.1  MR-to-CN Optimization

776	   One approach of MR-to-CN optimization involves the mobile router
777	   sending binding update messages with mobile network prefix
778	   information to the correspondent node.  This raised several issues:

780	   o  Security Considerations

782	      With mobile router sending binding update containing network
783	      prefix information to correspondent node, there is a question on
784	      the additional risk imposed on the correspondent node.  Although
785	      return routability procedure allows the correspondent node to
786	      verify that the care-of and home addresses of the mobile router
787	      are indeed collocated, it does not allow the correspondent node to
788	      verify the validity of the network prefix.  If the correspondent
789	      node accepts the binding without verification, it will be exposed
790	      to a class of attacks where the attacker tricks the correspondent
791	      node into forwarding packets destined for a mobile network to the
792	      attacker.

794	      Hence, MR-to-CN optimization would most likely require an extended
795	      return routability procedure to be developed for correspondent
796	      node to authenticate the validity of the mobile network prefix.
797	      This require additional functionality on the correspondent node,
798	      and a mechanism must be provided for the mobile router to check if
799	      the correspondent node has such functionality implemented.

801	   o  Mobility Awareness

803	      By sending binding update with mobile network prefix to the
804	      correspondent node, the mobile router is effectively revealing the
805	      location and mobility of the mobile network to the correspondent
806	      node.  Hence this is a case of trading location privacy for route
807	      optimization.  However, since route optimization in this case is
808	      initiated by the mobile router, the mobile network nodes may not
809	      have an influence to the decision of whether the tradeoff should
810	      be made.

812	   o  Binding Update Storm

814	      If the mobile network nodes in a mobile network are communicating
815	      with a lot of correspondent nodes, whenever the mobile router
816	      changes its point of attachment, it needs to send out a large
817	      number of binding updates to correspondent nodes.  This is further
818	      worsen by the fact that the mobile router has to perform the
819	      return routability procedure prior to sending binding updates.

821	   Another approach involves the mobile router acting as a proxy for
822	   MNNs behind it.  This has the following issues:

824	   o  Security Considerations

826	      Having the mobile router alters packets (such as inserting home
827	      address destination option and removing type 2 routing header)
828	      raise considerable security concerns.  Such a scheme may break
829	      existing IPSec protocols, and cause packets to be dropped.

831	   o  Complexity

833	      This also greatly increases the complexity of a mobile router, as
834	      it needs to look beyond the standard IPv6 headers for
835	      ingress/egress packets, and performs hacks appropriately.  The
836	      mobile router is also required to maintain some form of state
837	      information for each pair of MNN and CN, resulting in scaling
838	      issues.  This scheme also places all processing burden on the
839	      mobile router, which may be undesirable for mobile device with
840	      limited power and processing resources.

842	   o  Binding Update Storm

844	      Whenever the mobile router changes its point of attachment, it
845	      needs to perform binding updates with every correspondent node.
846	      Some CN selection scheme may be required to moderate the effect of
847	      binding update storm and processing burden on the mobile router.

849	   o  A Hack of Existing Protocol

851	      There have been comments on the NEMO WG mailing list that such an
852	      approach is essentially a hack of the existing return routability
853	      procedure.  The disadvantages of it being a hack is that firstly a
854	      change/extension in the current return routability procedure would
855	      render this hack broken, and secondly, it might be very difficult
856	      to accommodate other protocols that are not aware of such hacks
857	      (IPSec being an excellent example).

859	   o  Nesting of Mobile Routers

861	      Should one mobile router be attached to another mobile router, it
862	      is unclear how this solution will work if both mobile routers try
863	      to perform route optimization on behalf of the same mobile network
864	      node.  Using Figure 1 as an example, if MR5 perform route
865	      optimization on behalf of LFN2, and then MR1 again tries to act as
866	      a proxy to MR5, the results might be messy without any
867	      co-ordination between these mobile routers.

869	4.2.2  Infrastructure Optimization

871	   An infrastructure optimization approach using correspondent routers
872	   may face the following issues:

874	   o  Security Considerations

876	      The first security-related issue is how do the mobile router
877	      verify the validity of a correspondent router.  In other words,
878	      the mobile router needs some mechanism to ascertain that the
879	      correspondent router is indeed a valid correspondent router
880	      capable of forwarding packets to and from the correspondent node.

882	      A second security-related issue is how can the correspondent
883	      router verify the validity of a mobile router.  In other words,
884	      the correspondent router needs some mechanism to ascertain that
885	      the mobile router is indeed managing the mobile network prefix it
886	      claims to be managing.  This is related to the issues discussed in
887	      Section 4.2.1.

889	   o  Mobility Awareness

891	      Infrastructure optimization requires the correspondent router to
892	      be informed of the location and mobility of the mobile network.
893	      Correspondent nodes and mobile network nodes remain ignorant of
894	      the mobile network's mobility.

896	   o  Discovery of Correspondent Routers

898	      How should a mobile router discover a correspondent router given a
899	      particular correspondent node?  The discovery mechanism may have
900	      impact on the security issue discussed earlier.

902	4.2.3  Nested Tunnels Optimization

904	   Nested tunnels optimization usually involves the nested mobile router
905	   sending information of upstream mobile router(s).

907	   o  Security Considerations

909	      One issue for consideration is whether the home agent should trust
910	      the upstream information supplied by the nested mobile router.  If
911	      the upstream information falsely points to a victim node, the home
912	      agent may unconsciously flood the victim with packets intended for
913	      the nested mobile network.

915	      This risk can be minimized if the upstream information is
916	      protected by security association between the nested mobile router
917	      and its home agent (e.g.  the upstream information may be
918	      transmitted in a binding update that is protected from tampering).
919	      However, this does not protect against a malicious mobile router
920	      intentionally supplying false upstream information to its home
921	      agent, with the intent of launching a flooding attack against a
922	      victim node.

924	   o  Mobility Awareness

926	      Usually, nested tunnels optimization involves the nested mobile
927	      router sending upstream information to its home agent.  This
928	      implies that the upstream mobile router will have to reveal some
929	      information to sub-mobile routers.  Such information may reveal
930	      the location and mobility of the upstream mobile router.

932	   o  Binding Update Storm

934	      Depending on the specifics of a solution for nested tunnels
935	      optimization, the upstream information may be the care-of address
936	      of the upstream mobile router.  This will leads to the a burst of
937	      binding update messages whenever an upstream mobile router changes
938	      its point of attachment, since all its sub-MRs must send binding
939	      updates to their home agents to update the new upstream
940	      information.

942	   o  Complexity

944	      Sending of upstream information for nested tunnels optimization
945	      requires the home agent to store the upstream information in order
946	      to build a routing header.  Complexity of the home agent is
947	      further increased if the upstream information is sent individually
948	      by all upstream mobile routers, requiring the home agent to
949	      recursively build a routing header.

951	   Alternatively, a prefix delegation approach may be used to achieve
952	   nested tunnel optimization by eliminating the need for nesting.  This
953	   approach may face the following issues:

955	   o  Protocol Complexity

957	      This approach requires the access router (or some other entity
958	      within the access network)	to possess prefix delegation
959	      functionality, and also maintains information on what prefix is
960	      delegated to which node.

962	   o  Binding Update Storm

964	      A change in the point of attachment of the root mobile router will
965	      require every nested mobile router (and possibly visiting mobile
966	      nodes) to change their care-of addresses and delegated prefixes.
967	      These will cause a burst of binding update and prefix delegation
968	      activities where every mobile routers and visiting mobile nodes
969	      start sending binding updates to their home agents and possibly
970	      correspondent nodes.

972	4.2.4  MIPv6-over-NEMO Optimization

974	   If MIPv6 route optimization is not used, the optimization for
975	   MIPv6-over-NEMO is very similar to nested tunnels optimization, where
976	   the MIPv6 mobile node acts like a visiting mobile router.  The
977	   analysis of such optimization is thus similar to those discussed in
978	   Section 4.2.3, and hence will not be repeated here.  In this section,
979	   we explore the issues if MIPv6 route optimization is used.

981	   As described in Section 3.4, MIPv6-over-NEMO optimization can be
982	   achieved using various approaches.  One approach involves including
983	   upstream information (see nested tunnels optimization) in the binding
984	   update sent from the visiting mobile node to the correspondent node.
985	   This approach has the following considerations:

987	   o  Security Considerations

989	      A security-related issue is how can the correspondent node verify
990	      the validity of the supplied upstream information.  See also
991	      Section 4.2.3.

993	   o  Mobility Awareness

995	      The visiting mobile node will need to acquire the upstream
996	      information, most likely including the mobility and location
997	      information of the upstream mobile routers.

999	   On the other hand, the mobile router can perform some hacks on the
1000	   return routability messages exchanged between the visiting mobile
1001	   node and correspondent node to achieve MIPv6-over-NEMO optimization.
1002	   This, is generally undesirable due to:

1004	   o  Security Considerations

1006	      Such a scheme may break existing security related protocols, as it
1007	      requires the mobile router to make changes to contents of a packet
1008	      that is not originated by the mobile router.

1010	   Alternatively, the mobile router can perform return routability
1011	   procedure on behalf of the visiting mobile node.  Here the issues
1012	   are:

1014	   o  Security Considerations

1016	      Such a scheme require the visiting mobile node to place
1017	      considerable trust on the mobile router, as the mobility
1018	      management key is now transfered to the mobile router.

1020	   o  Mobility Awareness

1022	      This approach aims to keep the functionality of the correspondent
1023	      node to be identical as those required by MIPv6 route
1024	      optimization.  The expense will be that a new form of signaling
1025	      between the visiting mobile node and mobile router would most
1026	      likely be required.

1028	   o  Processing Burden

1030	      This approach also increases the processing burden of the mobile
1031	      router, as it needs to maintain information necessary for route
1032	      optimization to work for every correspondent node that is
1033	      communicating with each visiting mobile node.  This may not scale
1034	      very well when one consider, for example, a train network, where
1035	      there are hundreds of visiting mobile nodes in one mobile network.

1037	4.2.5  Intra-NEMO Optimization

1039	   As mentioned in Section 3.5, it is likely that any MR-to-CN
1040	   optimization may be able to fulfill the role of an intra-NEMO
1041	   optimization.  Such solutions will face the same issues as described
1042	   in Section 4.2.1, as well as the following:

1044	   o  Reliance on Outside Infrastructure

1046	      Most MR-to-CN optimization rely on the operations of home agent in
1047	      one way or another.  For instance, the return routability
1048	      procedure requires a Home Test (HoT) or Home Test Init (HoTI)
1049	      messages be forwarded by the home agent.  This means that should
1050	      the path to the Internet be broken, such optimization techniques
1051	      can no longer be used (and thus LFN1 can no longer communicates
1052	      with LFN2 in the example of Figure 1).

1054	5.  Conclusion

1056	   The problem space of route optimization in the NEMO context is
1057	   multifold and can be split into several work areas.  It will be
1058	   critical, though, that the solution to a given piece of the puzzle be
1059	   compatible and integrate smoothly with the others.

1061	   This memo explored into various problems of sub-optimality of NEMO
1062	   Basic Support, and discussed different aspects of a route optimized
1063	   solution in NEMO.  The intent of this document is to trigger fruitful
1064	   discussions that in turn will enhance our common understanding of the
1065	   route optimization problem and solution space.

1067	6.  Acknowledgments

1069	   The authors wish to thank: Greg Daley, Thierry Ernst, Erik Nordmark,
1070	   T.J.  Kniveton, Alexandru Petrescu, Hesham Soliman, Ryuji Wakikawa
1071	   and Patrick Wetterwald for their various contributions.  In addition,
1072	   the authors would also like to extend their heart-felt gratitude to
1073	   Marco Molteni, who was a co-author for the earlier versions of this
1074	   document.

1076	7  References

1078	   [1]   Devarapalli, V., "Network Mobility (NEMO) Basic Support
1079	         Protocol", draft-ietf-nemo-basic-support-03 (work in progress),
1080	         June 2004.

1082	   [2]   Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in
1083	         IPv6", RFC 3775, June 2004.

1085	   [3]   Manner, J. and M. Kojo, "Mobility Related Terminology", RFC
1086	         3753, June 2004.

1088	   [4]   Ernst, T. and H. Lach, "Network Mobility Support Terminology",
1089	         draft-ietf-nemo-terminology-01 (work in progress), February
1090	         2004.

1092	   [5]   Ernst, T., "Network Mobility Support Goals and Requirements",
1093	         draft-ietf-nemo-requirements-02 (work in progress), February
1094	         2004.

1096	   [6]   Zhao, F., Wu, F. and S. Jung, "NEMO Route Optimization Problem
1097	         Statement, Requirements and Evaluation Considerations",
1098	         draft-zhao-nemo-ro-ps-00 (work in progress), October 2004.

1100	   [7]   Watari, M. and T. Ernst, "Route Optimization with Nested
1101	         Correspondent Nodes", draft-watari-nemo-nested-cn-00 (work in
1102	         progress), October 2004.

1104	   [8]   Deering, S. and B. Zill, "Redundant Address Deletion when
1105	         Encapsulating IPv6 in IPv6",
1106	         draft-deering-ipv6-encap-addr-deletion-00 (work in progress),
1107	         November 2001.

1109	   [9]   Na, J., "Generic Route Optimization Model for NEMO Extended
1110	         Support", draft-na-nemo-gen-ro-model-00 (work in progress),
1111	         July 2004.

1113	   [10]  Soliman, H., Castelluccia, C., Malki, K. and L. Bellier,
1114	         "Hierarchical Mobile IPv6 mobility management (HMIPv6)",
1115	         draft-ietf-mipshop-hmipv6-02 (work in progress), June 2004.

1117	   [11]  Thubert, P., "Global HA to HA protocol",
1118	         draft-thubert-nemo-global-haha-00 (work in progress), October
1119	         2004.

1121	   [12]  Droms, R. and O. Troan, "IPv6 Prefix Options for DHCPv6",
1122	         draft-troan-dhcpv6-opt-prefix-delegation-01 (work in progress),
1123	         May 2002.

1125	   [13]  Thubert, P. and M. Molteni, "IPv6 Reverse Routing Header and
1126	         its application to Mobile Networks",
1127	         draft-thubert-nemo-reverse-routing-header-05 (work in
1128	         progress), June 2004.

1130	   [14]  Ng, C. and J. Hirano, "Extending Return Routability Procedure
1131	         for Network Prefix (RRNP)", draft-ng-nemo-rrnp-00 (work in
1132	         progress), October 2004.

1134	   [15]  Bernardos, C., Bagnulo, M. and M. Calderon, "MIRON: MIPv6 Route
1135	         Optimization for NEMO", ASWN 2004, Online:
1136	         http://www.it.uc3m.es/cjbc/papers/miron_aswn2004.pdf.

1138	   [16]  Ng, C. and T. Tanaka, "Securing Nested Tunnels Optimization
1139	         with Access Router Option",
1140	         draft-ng-nemo-access-router-option-01 (work in progress), July
1141	         2004.

1143	   [17]  Na, J., "Route Optimization Scheme based on Path Control
1144	         Header", draft-na-nemo-path-control-header-00 (work in
1145	         progress), April 2004.

1147	   [18]  Wakikawa, R., "Optimized Route Cache Protocol (ORC)",
1148	         draft-wakikawa-nemo-orc-00 (work in progress), July 2004.

1150	   [19]  Na, J., "Secure Nested Tunnels Optimization using Nested Path
1151	         Information", draft-na-nemo-nested-path-info-00 (work in
1152	         progress), September 2003.

1154	   [20]  Kang, H., "Route Optimization for Mobile Network by Using
1155	         Bi-directional Between Home  Agent and Top Level Mobile
1156	         Router", draft-hkang-nemo-ro-tlmr-00 (work in progress), June
1157	         2003.

1159	   [21]  Ohnishi, H., "HMIP based Route optimization method in a mobile
1160	         network", draft-ohnishi-nemo-ro-hmip-00 (work in progress),
1161	         October 2003.

1163	   [22]  Paakkonen, P. and J. Latvakoski, "Mobile Network Prefix
1164	         Delegation extension for Mobile IPv6",
1165	         draft-paakkonen-nemo-prefix-delegation-00 (work in progress),
1166	         March 2003.

1168	   [23]  Droms, R. and P. Thubert, "DHCPv6 Prefix Delegation for NEMO",
1169	         draft-droms-nemo-dhcpv6-pd-01 (work in progress), February
1170	         2004.

1172	   [24]  Lee, K., "Route Optimization for Mobile Nodes in Mobile Network
1173	         based on Prefix  Delegation", draft-leekj-nemo-ro-pd-02 (work
1174	         in progress), February 2004.

1176	   [25]  Jeong, J., "ND-Proxy based Route Optimization for Mobile Nodes
1177	         in Mobile Network", draft-jeong-nemo-ro-ndproxy-02 (work in
1178	         progress), February 2004.

1180	   [26]  Perera, E., "Extended Network Mobility Support",
1181	         draft-perera-nemo-extended-00 (work in progress), July 2003.

1183	Authors' Addresses

1185	   Chan-Wah Ng
1186	   Panasonic Singapore Laboratories Pte Ltd
1187	   Blk 1022 Tai Seng Ave #06-3530
1188	   Tai Seng Industrial Estate
1189	   Singapore  534415
1190	   SG

1192	   Phone: +65 65505420
1193	   EMail: cwng@psl.com.sg

1195	   Pascal Thubert
1196	   Cisco Systems Technology Center
1197	   Village d'Entreprises Green Side
1198	   400, Avenue Roumanille
1199	   Biot - Sophia Antipolis  06410
1200	   FRANCE

1202	   EMail: pthubert@cisco.com
1203	   Hiroyuki Ohnishi
1204	   NTT network service systems laboratories, NTT cooperation
1205	   9-11, Midori-Cho 3-Chome
1206	   Musashino-shi
1207	   Tokyo  180-8585
1208	   JAPAN

1210	   EMail: ohnishi.hiroyuki@lab.ntt.co.jp

1212	   Paik, Eun Kyoung
1213	   KT
1214	   Portable Internet Team, Convergence Lab., KT
1215	   17 Woomyeon-dong, Seocho-gu
1216	   Seoul  137-792
1217	   Korea

1219	   Phone: +82-2-526-5233
1220	   Fax:   +82-2-526-5200
1221	   EMail: euna@kt.co.kr
1222	   URI:   http://mmlab.snu.ac.kr/~eun/

1224	Appendix A.  Proposed Route Optimizations

1226	   Here, we attempt to list the numerous proposed solutions according to
1227	   the solution space defined in Section 3.  Although we made effort in
1228	   listing all possible solutions, sincere apology is extended to
1229	   authors of solutions that we might have missed out.

1231	A.1  MR-to-CN Optimizations

1233	   Most MR-to-CN optimizations proposals are implicitly achieved by
1234	   sending mobile network prefixes to correspondent nodes.  The Return
1235	   Routability procedure with Network Prefix (RRNP) [14] proposed an
1236	   extension to return routability procedure for verifying the validity
1237	   of mobile network prefixes.

1239	   One approach that uses the mobile router as a proxy for establishing
1240	   route optimization on behalf of mobile network nodes can be found in
1241	   [15].

1243	   In addition, various nested tunnel optimizations proposals (see
1244	   Appendix A.3) can also be extended to correspondent node, thus
1245	   enabling the MR-to-CN optimizations.  Example includes the Reverse
1246	   Routing Header (RRH) [13], Access Router Option (ARO) [16].

1248	A.2  Infrastructure Optimizations

1250	   All known infrastructure optimization proposals defines the entity
1251	   known as correspondent router capable of terminating bi-directional
1252	   tunnels from mobile routers on behalf of correspondent nodes, thereby
1253	   achieving route optimization.  The difference between these proposals
1254	   is mainly the way correspondent routers are discovered.  Proposals
1255	   include:

1257	   o  Path Control Header (PCH) [17]

1259	      The PCH approach requires the home agent to piggyback a Path
1260	      Control Header on the packet when forwarding packets arriving from
1261	      a bi-directional tunnel to a correspondent node.  Because PCH is a
1262	      hop-by-hop option header, all intermediate routers lying between
1263	      the home agent and the correspondent node will inspect the PCH.
1264	      If a correspondent router exists among these intermediate router,
1265	      it can contact the mobile router (identified in the PCH) and
1266	      establish a optimized tunnel with the mobile router.

1268	   o  Optimized Routing Cache (ORC) [18]

1270	      The ORC approach defines the functionality of a correspondent
1271	      router able to terminate bi-directional tunnels from mobile
1272	      routers.  Mobile routers discover correspondent routers by sending
1273	      a query message to a multicast address corresponding to "all
1274	      correspondent router" address.  The query message contains the
1275	      address of the correspondent node for which the mobile router
1276	      wishes to send packets to.  The correspondent router managing the
1277	      network within which the correspondent node resides will responds
1278	      to this query.  The proposal also suggest correspondent router to
1279	      inform mobile routers the prefix information of the network it is
1280	      capable of managing, so that any other traffic flows that
1281	      originate and end at the mobile network and the network the
1282	      correspondent router is managing can also enjoy route
1283	      optimization.

1285	A.3  Nested Tunnel Optimizations

1287	   Many proposed solutions for NEMO Extended Support targets the nested
1288	   tunnel optimization.  Most of these involves sending of upstream
1289	   information to the home agent of a nested mobile router, including

1291	   o  Reverse Routing Header (RRH) [13]

1293	      The RRH approach avoids the multiple encapsulation of the traffic
1294	      but maintains the home tunnel of the first mobile router on the
1295	      egress path.  The first mobile router on the way out (egress
1296	      direction) encapsulates the packet over its reverse tunnel, using
1297	      a form of Record Route header, the RRH.

1299	      The upstream mobile routers simply swap their care-of address and
1300	      the source of the packet, saving the original source in the RRH.
1301	      The home agent transforms the RRH in a Routing Header to perform
1302	      source routing across the nested mobile network, along the ingress
1303	      path to the target mobile router.

1305	   o  Access Router Option (ARO) [16]

1307	      The ARO approach is somewhat similar to the RRH in that only the
1308	      home tunnel of the first nested mobile router in the egress path
1309	      is maintained.  This is done by having the nested mobile router to
1310	      send an ARO	in Binding Update to inform its home agent the address
1311	      of its access router (i.e.  an upstream mobile router).  Using
1312	      this information, the home agent can build a Routing Header to
1313	      source-route a packet to the nested mobile router within in a
1314	      nested mobile network.  Upstream mobile routers can also send
1315	      binding update messages to the home agent of the nested mobile
1316	      router, thus allowing a complete routing header be built
1317	      recursively by the home agent.

1319	   o  Nested Path Info (NPI) [19]

1321	      The NPI approach is somewhat similar to the ARO approach, except
1322	      that instead of sending only the home address of the upstream
1323	      mobile router to its home agent, a nested mobile router send a
1324	      nested information on the care-of addresses of all upstream mobile
1325	      routers.  Using this information, the home agent can build a
1326	      Routing Header to source-route a packet to the nested mobile
1327	      router within in a nested mobile network.

1329	   o  Top Level Mobile Router (TLMR) [20]

1331	      In TLMR, each visiting mobile router obtains the address of the
1332	      root-MR through router advertisement messages.  This information
1333	      is passed to its home agent in a binding update message.  The
1334	      visiting mobile router also registers with the root-MR.  With
1335	      these registrations, the root-MR maintains a topology of the
1336	      mobile network.  In addition, the root MR also establish tunnels
1337	      with the home agents of every visiting mobile router.  This way,
1338	      packet to and from each nested mobile network will be relayed
1339	      through the root-MR, through an additional tunnel between the
1340	      root-MR and the home agent of the nested mobile network.

1342	   o  Hierarchical Mobile IP (HMIP) [21]

1344	      This approach proposes an adaptation of HMIPv6 [10] for NEMO.
1345	      Here, information on the root-MR (acting as a Mobile Anchor Point,
1346	      MAP) is passed to nested mobile routers in the MAP option of a
1347	      router advertisement.  Nested mobile routers then register their
1348	      regional and local care-of address with the root-MR.  Packets are
1349	      then transfered to and from a nested mobile router through two
1350	      separate tunnels: one between the nested mobile router and the
1351	      root-MR, the other between the root-MR and the home agent of the
1352	      nested mobile router.

1354	   Other approaches that does not really require the sending of upstream
1355	   information to home agent includes:

1357	   o  Prefix Delegation [22][23][24]

1359	      The prefix delegation approach is somewhat to HMIPv6 what NEMO is
1360	      to MIPv6.  The Access Router of the nested structure is both a
1361	      NEMO home agent and a DHCP-PD server, for an aggregation that it
1362	      owns and advertises to the infrastructure.  When visiting the
1363	      nested structure, each mobile router is delegated a mobile network
1364	      prefix from the access router using DHCP-Prefix Delegation.  The
1365	      mobile router registers this delegated prefix to the access router
1366	      that is acting as a NEMO home agent.  The mobile router also
1367	      autoconfigures an address from the delegated prefix and uses it as
1368	      a care-of address to register its own mobile network prefix(es) to
1369	      its own home agent using NEMO Basic Support.  It is possible for a
1370	      mobile router to protect its own mobile network prefixes while
1371	      advertising in the clear the local prefix for other mobile routers
1372	      to roam into.  This allows a strict privacy of visited and
1373	      visitors, and enables some specific policies in each mobile
1374	      router.

1376	   o  Neighbor Discovery Proxy (ND-Proxy) [25]

1378	      The ND-Proxy approach achieves route optimization by having mobile
1379	      routers to act as neighbor discovery proxy.  Mobile router will
1380	      configure a care-of address from the network prefix advertised by
1381	      its access router, and also relay this prefix to its subnets.  As
1382	      ND-Proxy, mobile routers will also handle neighbor discovery on
1383	      behalf of visiting mobile nodes in its subnets.  As such, the
1384	      entire mobile network and its access network forms a logical
1385	      multilink subnet, thus eliminating any nesting.  This solution
1386	      also lends itself well to achieve MIPv6-over-NEMO optimization.

1388	A.4  MIPv6-over-NEMO Optimizations

1390	   Some solutions proposed for nested tunnels optimization can be
1391	   extended for MIPv6-over-NEMO optimization, including Access Router
1392	   Option (ARO) [16], Top Level Mobile Router (TLMR) [20], Prefix
1393	   Delegation approaches [22][23][24], and Neighbor Discovery Proxy
1394	   (ND-Proxy) [25].  One solution that caters specifically for
1395	   MIPv6-over-NEMO optimization is:

1397	   o  Extended Network Mobility Support [26]

1399	      This approach is somewhat similar to the Prefix Delegation in
1400	      which the mobile router would obtain a prefix from its access
1401	      network, and allows visiting mobile network nodes to autoconfigure
1402	      their care-of addresses from this prefix.  By doing so, packets
1403	      destined to any MIPv6 node within the mobile network will not go
1404	      through the home agent of the mobile router, thereby achieving
1405	      MIPv6-over-NEMO optimization.  This solution also allows the
1406	      mobile router to act as home agent for local fixed nodes and local
1407	      mobile nodes within the mobile network in an attempt to allow
1408	      these nodes to achieve route optimization (using standard MIPv6
1409	      techniques).

1411	A.5  Intra-NEMO Optimizations

1413	   Currently, there are no proposals that specifically target intra-NEMO
1414	   optimization, though as explained previously, most solutions that
1415	   achieves MN-to-CN optimizations can also achieve intra-NEMO
1416	   optimization.

1418	Intellectual Property Statement

1420	   The IETF takes no position regarding the validity or scope of any
1421	   Intellectual Property Rights or other rights that might be claimed to
1422	   pertain to the implementation or use of the technology described in
1423	   this document or the extent to which any license under such rights
1424	   might or might not be available; nor does it represent that it has
1425	   made any independent effort to identify any such rights.  Information
1426	   on the procedures with respect to rights in RFC documents can be
1427	   found in BCP 78 and BCP 79.

1429	   Copies of IPR disclosures made to the IETF Secretariat and any
1430	   assurances of licenses to be made available, or the result of an
1431	   attempt made to obtain a general license or permission for the use of
1432	   such proprietary rights by implementers or users of this
1433	   specification can be obtained from the IETF on-line IPR repository at
1434	   http://www.ietf.org/ipr.

1436	   The IETF invites any interested party to bring to its attention any
1437	   copyrights, patents or patent applications, or other proprietary
1438	   rights that may cover technology that may be required to implement
1439	   this standard.  Please address the information to the IETF at
1440	   ietf-ipr@ietf.org.

1442	Disclaimer of Validity

1444	   This document and the information contained herein are provided on an
1445	   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1446	   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
1447	   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
1448	   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
1449	   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1450	   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

1452	Copyright Statement

1454	   Copyright (C) The Internet Society (2004).  This document is subject
1455	   to the rights, licenses and restrictions contained in BCP 78, and
1456	   except as set forth therein, the authors retain all their rights.

1458	Acknowledgment

1460	   Funding for the RFC Editor function is currently provided by the
1461	   Internet Society.