GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools

Problem, Formatting or Query -  Send Feedback

Was this page helpful?-10+1


rfc:rfc4888

Network Working Group C. Ng Request for Comments: 4888 Panasonic Singapore Labs Category: Informational P. Thubert

                                                         Cisco Systems
                                                             M. Watari
                                                         KDDI R&D Labs
                                                               F. Zhao
                                                              UC Davis
                                                             July 2007
       Network Mobility Route Optimization Problem Statement

Status of This Memo

 This memo provides information for the Internet community.  It does
 not specify an Internet standard of any kind.  Distribution of this
 memo is unlimited.

Copyright Notice

 Copyright (C) The IETF Trust (2007).

Abstract

 With current Network Mobility (NEMO) Basic Support, all
 communications to and from Mobile Network Nodes must go through the
 bi-directional tunnel established between the Mobile Router and Home
 Agent when the mobile network is away.  This sub-optimal routing
 results in various inefficiencies associated with packet delivery,
 such as increased delay and bottleneck links leading to traffic
 congestion, which can ultimately disrupt all communications to and
 from the Mobile Network Nodes.  Additionally, with nesting of Mobile
 Networks, these inefficiencies get compounded, and stalemate
 conditions may occur in specific dispositions.  This document
 investigates such problems and provides the motivation behind Route
 Optimization (RO) for NEMO.

Ng, et al. Informational [Page 1] RFC 4888 NEMO RO Problem Statement July 2007

Table of Contents

 1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
 2.  NEMO Route Optimization Problem Statement  . . . . . . . . . .  3
   2.1.  Sub-Optimality with NEMO Basic Support . . . . . . . . . .  4
   2.2.  Bottleneck in the Home Network . . . . . . . . . . . . . .  6
   2.3.  Amplified Sub-Optimality in Nested Mobile Networks . . . .  6
   2.4.  Sub-Optimality with Combined Mobile IPv6 Route
         Optimization . . . . . . . . . . . . . . . . . . . . . . .  8
   2.5.  Security Policy Prohibiting Traffic from Visiting Nodes  .  9
   2.6.  Instability of Communications within a Nested Mobile
         Network  . . . . . . . . . . . . . . . . . . . . . . . . .  9
   2.7.  Stalemate with a Home Agent Nested in a Mobile Network . . 10
 3.  Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 10
 4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
 5.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 11
 6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
   6.1.  Normative Reference  . . . . . . . . . . . . . . . . . . . 12
   6.2.  Informative Reference  . . . . . . . . . . . . . . . . . . 12
 Appendix A.  Various Configurations Involving Nested Mobile
              Networks  . . . . . . . . . . . . . . . . . . . . . . 13
   A.1.  CN Located in the Fixed Infrastructure . . . . . . . . . . 13
     A.1.1.  Case A: LFN and Standard IPv6 CN . . . . . . . . . . . 14
     A.1.2.  Case B: VMN and MIPv6 CN . . . . . . . . . . . . . . . 14
     A.1.3.  Case C: VMN and Standard IPv6 CN . . . . . . . . . . . 14
   A.2.  CN Located in Distinct Nested NEMOs  . . . . . . . . . . . 15
     A.2.1.  Case D: LFN and Standard IPv6 CN . . . . . . . . . . . 16
     A.2.2.  Case E: VMN and MIPv6 CN . . . . . . . . . . . . . . . 16
     A.2.3.  Case F: VMN and Standard IPv6 CN . . . . . . . . . . . 16
   A.3.  MNN and CN Located in the Same Nested NEMO . . . . . . . . 17
     A.3.1.  Case G: LFN and Standard IPv6 CN . . . . . . . . . . . 18
     A.3.2.  Case H: VMN and MIPv6 CN . . . . . . . . . . . . . . . 18
     A.3.3.  Case I: VMN and Standard IPv6 CN . . . . . . . . . . . 19
   A.4.  CN Located Behind the Same Nested MR . . . . . . . . . . . 19
     A.4.1.  Case J: LFN and Standard IPv6 CN . . . . . . . . . . . 20
     A.4.2.  Case K: VMN and MIPv6 CN . . . . . . . . . . . . . . . 20
     A.4.3.  Case L: VMN and Standard IPv6 CN . . . . . . . . . . . 21
 Appendix B.  Example of How a Stalemate Situation Can Occur  . . . 22

Ng, et al. Informational [Page 2] RFC 4888 NEMO RO Problem Statement July 2007

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 and
 its Home Agent (also known as the MRHA tunnel) when the mobile
 network is away.  Although such an arrangement allows Mobile Network
 Nodes to reach and be reached by any node on the Internet,
 limitations associated to the base protocol degrade overall
 performance of the network and, ultimately, can prevent all
 communications to and from the Mobile Network Nodes.
 Some of these concerns already exist with Mobile IPv6 [4] and were
 addressed by the mechanism known as Route Optimization, which is part
 of the base protocol.  With Mobile IPv6, Route Optimization mostly
 improves the end-to-end path between the Mobile Node and
 Correspondent Node, with an additional benefit of reducing the load
 of the Home Network, thus its name.
 NEMO Basic Support presents a number of additional issues, making the
 problem more complex, so it was decided to address Route Optimization
 separately.  In that case, the expected benefits are more dramatic,
 and a Route Optimization mechanism could enable connectivity that
 would be broken otherwise.  In that sense, Route Optimization is even
 more important to NEMO Basic Support than it is to Mobile IPv6.
 This document explores limitations inherent in NEMO Basic Support,
 and their effects on communications between a Mobile Network Node and
 its corresponding peer.  This is detailed in Section 2.  It is
 expected that readers are familiar with general terminologies related
 to mobility in [4][2], NEMO-related terms defined in [3], and NEMO
 goals and requirements [5].

2. NEMO Route Optimization Problem Statement

 Given the NEMO Basic Support protocol, all data packets to and from
 Mobile Network Nodes must go through the Home Agent, even though a
 shorter path may exist between the Mobile Network Node and its
 Correspondent Node.  In addition, with the nesting of Mobile Routers,
 these data packets must go through multiple Home Agents and several
 levels of encapsulation, which may be avoided.  This results in
 various inefficiencies and problems with packet delivery, which can
 ultimately disrupt all communications to and from the Mobile Network
 Nodes.
 In the following sub-sections, we will describe the effects of a
 pinball route with NEMO Basic Support, how it may cause a bottleneck
 to be formed in the Home Network, and how these get amplified with

Ng, et al. Informational [Page 3] RFC 4888 NEMO RO Problem Statement July 2007

 nesting of mobile networks.  Closely related to nesting, we will also
 look into the sub-optimality even when Mobile IPv6 Route Optimization
 is used over NEMO Basic Support.  This is followed by a description
 of security policy in the Home Network that may forbid transit
 traffic from Visiting Mobile Nodes in mobile networks.  In addition,
 we will explore the impact of the MRHA tunnel on communications
 between two Mobile Network Nodes on different links of the same
 mobile network.  We will also provide additional motivations for
 Route Optimization by considering the potential stalemate situation
 when a Home Agent is part of a mobile network.

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 MRHA
 tunnel, resulting in a pinball route between the two nodes.  This has
 the following sub-optimal effects:
 o  Longer Route Leading to Increased Delay and Additional
    Infrastructure Load
    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 usually longer than if the packet were to go straight
    from the mobile network to the Correspondent Node.  When the
    Correspondent Node (or the mobile network) resides near the Home
    Agent, the increase in packet delay can be very small.  However,
    when the mobile network and the Correspondent Node are relatively
    near to one another but far away from the Home Agent on the
    Internet, the increase in delay is very large.  Applications such
    as real-time multimedia streaming may not be able to tolerate such
    increase in packet delay.  In general, the increase in delay may
    also impact the performance of transport protocols such as TCP,
    since the sending rate of TCP is partly determined by the round-
    trip time (RTT) perceived by the communication peers.
    Moreover, by using a longer route, the total resource utilization
    for the traffic would be much higher than if the packets were to
    follow a direct path between the Mobile Network Node and
    Correspondent Node.  This would result in additional load in the
    infrastructure.
 o  Increased Packet Overhead
    The encapsulation of packets in the MRHA tunnel results in
    increased packet size due to the addition of an outer header.
    This reduces the bandwidth efficiency, as an IPv6 header can be

Ng, et al. Informational [Page 4] RFC 4888 NEMO RO Problem Statement July 2007

    quite substantial relative to the payload for applications such as
    voice samples.  For instance, given a voice application using an 8
    kbps algorithm (e.g., G.729) and taking a voice sample every 20 ms
    (as in RFC 1889 [6]), the packet transmission rate will be 50
    packets per second.  Each additional IPv6 header is an extra 320
    bits per packet (i.e., 16 kbps), which is twice the actual
    payload!
 o  Increased Processing Delay
    The encapsulation of packets in the MRHA tunnel also results in
    increased processing delay at the points of encapsulation and
    decapsulation.  Such increased processing may include encryption/
    decryption, topological correctness verifications, MTU
    computation, fragmentation, and reassembly.
 o  Increased Chances of Packet Fragmentation
    The augmentation in packet size due to packet encapsulation may
    increase the chances of the packet being fragmented along the MRHA
    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.  Packet fragmentation will
    result in a further increase in packet delays and further
    reduction of bandwidth efficiency.
 o  Increased Susceptibility to Link Failure
    Under the assumption that each link has the same probability of
    link failure, a longer routing path would be more susceptible to
    link failure.  Thus, packets routed through the MRHA tunnel may be
    subjected to a higher probability of being lost or delayed due to
    link failure, compared to packets that traverse directly between
    the Mobile Network Node and its Correspondent Node.

Ng, et al. Informational [Page 5] RFC 4888 NEMO RO Problem Statement July 2007

2.2. Bottleneck in the Home Network

 Apart from the increase in packet delay and infrastructure load,
 forwarding packets through the Home Agent may also lead to either the
 Home Agent or the Home Link becoming a bottleneck for the aggregated
 traffic from/to all the Mobile Network Nodes.  A congestion at home
 would lead to additional packet delay, or even packet loss.  In
 addition, Home Agent operations such as security check, packet
 interception, and tunneling might not be as optimized in the Home
 Agent software as plain packet forwarding.  This could further limit
 the Home Agent capacity for data traffic.  Furthermore, with all
 traffic having to pass through the Home Link, the Home Link becomes a
 single point of failure for the mobile network.
 Data packets that are delayed or discarded due to congestion at the
 Home Network would cause additional performance degradation to
 applications.  Signaling packets, such as Binding Update messages,
 that are delayed or discarded due to congestion at the Home Network
 may affect the establishment or update of bi-directional tunnels,
 causing disruption of all traffic flow through these tunnels.
 A NEMO Route Optimization mechanism that allows the Mobile Network
 Nodes to communicate with their Correspondent Nodes via a path that
 is different from the MRHA tunneling and thereby avoiding the Home
 Agent may alleviate or even prevent the congestion at the Home Agent
 or Home Link.

2.3. Amplified Sub-Optimality in Nested Mobile Networks

 By allowing other mobile nodes to join a mobile network, and in
 particular mobile routers, it is possible to form arbitrary levels of
 nesting of mobile networks.  With such nesting, 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 a pinball route with NEMO Basic Support are amplified with
 each level of nesting of mobile networks.  This is best illustrated
 by an example shown in Figure 1.

Ng, et al. Informational [Page 6] RFC 4888 NEMO RO Problem Statement July 2007

             +--------+  +--------+  +--------+  +--------+
             | MR2_HA |  | MR3_HA |  | MR4_HA |  | MR5_HA |
             +------+-+  +---+----+  +---+----+  +-+------+
                     \       |           |        /
      +--------+    +------------------------------+
      | MR1_HA |----|         Internet             |-----CN1
      +--------+    +------------------------------+
                                  |
                              +---+---+
                    root-MR   |  MR1  |
                              +-------+
                               |     |
                        +-------+   +-------+
               sub-MR   |  MR2  |   |  MR4  |
                        +---+---+   +---+---+
                            |           |
                        +---+---+   +---+---+
               sub-MR   |  MR3  |   |  MR5  |
                        +---+---+   +---+---+
                            |           |
                        ----+----   ----+----
                           MNN         CN2
            Figure 1: An Example of a Nested Mobile Network
 Using NEMO Basic Support, the flow of packets between a Mobile
 Network Node, MNN, and a Correspondent Node, CN1, would need to go
 through three separate tunnels, illustrated in Figure 2 below.
  1. ———.
  2. ——–/ /———-.
  3. ——/ | | /——-

MNN —–( - - | - - - | - - - | - - - | - - (—— CN1

         MR3-------\        |         |          \-------MR3_HA
                  MR2--------\         \----------MR2_HA
                            MR1---------MR1_HA
              Figure 2: Nesting of Bi-Directional Tunnels

Ng, et al. Informational [Page 7] RFC 4888 NEMO RO Problem Statement July 2007

 This leads to the following problems:
 o  Pinball Route
    Both inbound and outbound packets will flow via the Home Agents of
    all the Mobile Routers on their paths within the mobile network,
    with increased latency, less resilience, and more bandwidth usage.
    Appendix A illustrates in detail the packets' routes under
    different nesting configurations of the Mobile Network Nodes.
 o  Increased Packet Size
    An extra IPv6 header is added per level of nesting to all the
    packets.  The header compression suggested in [7] cannot be
    applied because both the source and destination (the intermediate
    Mobile Router and its Home Agent) are different hop to hop.
 Nesting also amplifies the probability of congestion at the Home
 Networks of the upstream Mobile Routers.  In addition, the Home Link
 of each upstream Mobile Router will also be a single point of failure
 for the nested Mobile Router.

2.4. Sub-Optimality with Combined Mobile IPv6 Route Optimization

 When a Mobile IPv6 host joins a mobile network, it becomes a Visiting
 Mobile Node of the mobile network.  Packets sent to and from the
 Visiting Mobile Node will have to be routed not only via the Home
 Agent of the Visiting Mobile Node, but also via the Home Agent of the
 Mobile Router in the mobile network.  This suffers the same
 amplification effect of nested mobile network mentioned in
 Section 2.3.
 In addition, although Mobile IPv6 [4] allows a mobile host to perform
 Route Optimization with its Correspondent Node in order 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 MRHA
 tunnel.  Interested readers may refer to Appendix A for examples of
 how the routes will appear with nesting of Mobile IPv6 hosts in
 mobile networks.
 The readers should also note that the same sub-optimality would apply
 when the mobile host is outside the mobile network and its
 Correspondent Node is in the mobile network.

Ng, et al. Informational [Page 8] RFC 4888 NEMO RO Problem Statement July 2007

2.5. Security Policy Prohibiting Traffic from Visiting Nodes

 NEMO Basic Support requires all traffic from visitors to be tunneled
 to the Mobile Router's Home Agent.  This might represent a breach in
 the security of the Home Network (some specific attacks against the
 Mobile Router's binding by rogue visitors have been documented in
 [8][9]).  Administrators might thus fear that malicious packets will
 be routed into the Home Network via the bi-directional tunnel.  As a
 consequence, it can be expected that in many deployment scenarios,
 policies will be put in place to prevent unauthorized Visiting Mobile
 Nodes from attaching to the Mobile Router.
 However, there are deployment scenarios where allowing unauthorized
 Visiting Mobile Nodes is actually desirable.  For instance, when
 Mobile Routers attach to other Mobile Routers and form a nested NEMO,
 they depend on each other to reach the Internet.  When Mobile Routers
 have no prior knowledge of one another (no security association,
 Authentication, Authorization, and Accounting (AAA), Public-Key
 Infrastructure (PKI), etc.), it could still be acceptable to forward
 packets, provided that the packets are not tunneled back to the Home
 Networks.
 A Route Optimization mechanism that allows traffic from Mobile
 Network Nodes to bypass the bi-directional tunnel between a Mobile
 Router and its Home Agent would be a necessary first step towards a
 Tit for Tat model, where MRs would benefit from a reciprocal
 altruism, based on anonymity and innocuousness, to extend the
 Internet infrastructure dynamically.

2.6. Instability of Communications within a Nested Mobile Network

 Within a nested mobile network, two Mobile Network Nodes may
 communicate with each other.  Let us consider the previous example
 illustrated in Figure 1 where MNN and CN2 are sharing a communication
 session.  With NEMO Basic Support, a packet sent from MNN to CN2 will
 need to be forwarded to the Home Agent of each Mobile Router before
 reaching CN2, whereas, a packet following the direct path between
 them need not even leave the mobile network.  Readers are referred to
 Appendix A.3 for detailed illustration of the resulting routing
 paths.
 Apart from the consequences of increased packet delay and packet
 size, which are discussed in previous sub-sections, there are two
 additional effects that are undesirable:
 o  when the nested mobile network is disconnected from the Internet
    (e.g., MR1 loses its egress connectivity), MNN and CN2 can no

Ng, et al. Informational [Page 9] RFC 4888 NEMO RO Problem Statement July 2007

    longer communicate with each other, even though the direct path
    from MNN to CN2 is unaffected;
 o  the egress link(s) of the root Mobile Router (i.e., MR1) becomes a
    bottleneck for all the traffic that is coming in and out of the
    nested mobile network.
 A Route Optimization mechanism could allow traffic between two Mobile
 Network Nodes nested within the same mobile network to follow a
 direct path between them, without being routed out of the mobile
 network.  This may also off-load the processing burden of the
 upstream Mobile Routers when the direct path between the two Mobile
 Network Nodes does not traverse these Mobile Routers.

2.7. Stalemate with a Home Agent Nested in a Mobile Network

 Several configurations for the Home Network are described in [10].
 In particular, there is a mobile home scenario where a (parent)
 Mobile Router is also a Home Agent for its mobile network.  In other
 words, the mobile network is itself an aggregation of Mobile Network
 Prefixes assigned to (children) Mobile Routers.
 A stalemate situation exists in the case where the parent Mobile
 Router visits one of its children.  The child Mobile Router cannot
 find its Home Agent in the Internet and thus cannot establish its
 MRHA tunnel and forward the visitor's traffic.  The traffic from the
 parent is thus blocked from reaching the Internet, and it will never
 bind to its own (grandparent) Home Agent.  Appendix B gives a
 detailed illustration of how such a situation can occur.
 Then again, a Route Optimization mechanism that bypasses the nested
 tunnel might enable the parent traffic to reach the Internet and let
 it bind.  At that point, the child Mobile Router would be able to
 reach its parent and bind in turn.  Additional nested Route
 Optimization solutions might also enable the child to locate its Home
 Agent in the nested structure and bind regardless of whether or not
 the Internet is reachable.

3. Conclusion

 With current NEMO Basic Support, all communications to and from
 Mobile Network Nodes must go through the MRHA tunnel when the mobile
 network is away.  This results in various inefficiencies associated
 with packet delivery.  This document investigates such inefficiencies
 and provides the motivation behind Route Optimization for NEMO.

Ng, et al. Informational [Page 10] RFC 4888 NEMO RO Problem Statement July 2007

 We have described the sub-optimal effects of pinball routes with NEMO
 Basic Support, how they may cause a bottleneck to be formed in the
 Home Network, and how they get amplified with nesting of mobile
 networks.  These effects will also be seen even when Mobile IPv6
 Route Optimization is used over NEMO Basic Support.  In addition,
 other issues concerning the nesting of mobile networks that might
 provide additional motivation for a NEMO Route Optimization mechanism
 were also explored, such as the prohibition of forwarding traffic
 from a Visiting Mobile Node through an MRHA tunnel due to security
 concerns, the impact of the MRHA tunnel on communications between two
 Mobile Network Nodes on different links of the same mobile network,
 and the possibility of a stalemate situation when Home Agents are
 nested within a mobile network.

4. Security Considerations

 This document highlights some limitations of NEMO Basic Support.  In
 particular, some security concerns could prevent interesting
 applications of the protocol, as detailed in Section 2.5.
 Route Optimization for RFC 3963 [1] might introduce new threats, just
 as it might alleviate existing ones.  This aspect will certainly be a
 key criterion in the evaluation of the proposed solutions.

5. Acknowledgments

 The authors wish to thank the co-authors of previous versions from
 which this document is derived: Marco Molteni, Paik Eun-Kyoung,
 Hiroyuki Ohnishi, Thierry Ernst, Felix Wu, and Souhwan Jung.  Early
 work by Masafumi Watari on the extracted appendix was written while
 still at Keio University.  In addition, sincere appreciation is also
 extended to Jari Arkko, Carlos Bernardos, Greg Daley, T.J. Kniveton,
 Henrik Levkowetz, Erik Nordmark, Alexandru Petrescu, Hesham Soliman,
 Ryuji Wakikawa, and Patrick Wetterwald for their various
 contributions.

Ng, et al. Informational [Page 11] RFC 4888 NEMO RO Problem Statement July 2007

6. References

6.1. Normative Reference

 [1]   Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert,
       "Network Mobility (NEMO) Basic Support Protocol", RFC 3963,
       January 2005.
 [2]   Manner, J. and M. Kojo, "Mobility Related Terminology",
       RFC 3753, June 2004.
 [3]   Ernst, T. and H. Lach, "Network Mobility Support Terminology",
       RFC 4885, July 2007.

6.2. Informative Reference

 [4]   Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
       IPv6", RFC 3775, June 2004.
 [5]   Ernst, T., "Network Mobility Support Goals and Requirements",
       RFC 4886, July 2007.
 [6]   Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
       "RTP: A Transport Protocol for Real-Time Applications",
       RFC 1889, January 1996.
 [7]   Deering, S. and B. Zill, "Redundant Address Deletion when
       Encapsulating IPv6 in IPv6", Work in Progress, November 2001.
 [8]   Petrescu, A., Olivereau, A., Janneteau, C., and H-Y. Lach,
       "Threats for Basic Network Mobility Support (NEMO threats)",
       Work in Progress, January 2004.
 [9]   Jung, S., Zhao, F., Wu, S., Kim, H-G., and S-W. Sohn, "Threat
       Analysis on NEMO Basic Operations", Work in Progress,
       July 2004.
 [10]  Thubert, P., Wakikawa, R., and V. Devarapalli, "Network
       Mobility Home Network Models", RFC RFC4887, July 2007.
 [11]  Draves, R., "Default Address Selection for Internet Protocol
       version 6 (IPv6)", RFC 3484, February 2003.

Ng, et al. Informational [Page 12] RFC 4888 NEMO RO Problem Statement July 2007

Appendix A. Various Configurations Involving Nested Mobile Networks

 In the following sections, we try to describe different communication
 models that involve a nested mobile network and to clarify the issues
 for each case.  We illustrate the path followed by packets if we
 assume nodes only use Mobile IPv6 and NEMO Basic Support mechanisms.
 Different cases are considered where a Correspondent Node is located
 in the fixed infrastructure, in a distinct nested mobile network as
 the Mobile Network Node, or in the same nested mobile network as the
 Mobile Network Node.  Additionally, cases where Correspondent Nodes
 and Mobile Network Nodes are either standard IPv6 nodes or Mobile
 IPv6 nodes are considered.  As defined in [3], standard IPv6 nodes
 are nodes with no mobility functions whatsoever, i.e., they are not
 Mobile IPv6 or NEMO enabled.  This means that they cannot move around
 keeping open connections and that they cannot process Binding Updates
 sent by peers.

A.1. CN Located in the Fixed Infrastructure

 The most typical configuration is the case where a Mobile Network
 Node communicates with a Correspondent Node attached in the fixed
 infrastructure.  Figure 3 below shows an example of such topology.
                  +--------+  +--------+  +--------+
                  | MR1_HA |  | MR2_HA |  | MR3_HA |
                  +---+----+  +---+----+  +---+----+
                      |           |           |
                     +-------------------------+
                     |        Internet         |----+ CN
                     +-------------------------+
                             |               |
                         +---+---+        +--+-----+
               root-MR   |  MR1  |        | VMN_HA |
                         +---+---+        +--------+
                             |
                         +---+---+
                sub-MR   |  MR2  |
                         +---+---+
                             |
                         +---+---+
                sub-MR   |  MR3  |
                         +---+---+
                             |
                         ----+----
                            MNN
              Figure 3: CN Located at the Infrastructure

Ng, et al. Informational [Page 13] RFC 4888 NEMO RO Problem Statement July 2007

A.1.1. Case A: LFN and Standard IPv6 CN

 The simplest case is where both MNN and CN are fixed nodes with no
 mobility functions.  That is, MNN is a Local Fixed Node, and CN is a
 standard IPv6 node.  Packets are encapsulated between each Mobile
 Router and its respective Home Agent (HA).  As shown in Figure 4, in
 such a case, the path between the two nodes would go through:
      1       2       3       4          3          2          1
 MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA --- CN
 LFN                                                         IPv6 Node
           The digits represent the number of IPv6 headers.
             Figure 4: MNN and CN Are Standard IPv6 Nodes

A.1.2. Case B: VMN and MIPv6 CN

 In this second case, both end nodes are Mobile IPv6-enabled mobile
 nodes, that is, MNN is a Visiting Mobile Node.  Mobile IPv6 Route
 Optimization may thus be initiated between the two and packets would
 not go through the Home Agent of the Visiting Mobile Node or the Home
 Agent of the Correspondent Node (not shown in the figure).  However,
 packets will still be tunneled between each Mobile Router and its
 respective Home Agent, in both directions.  As shown in Figure 5, the
 path between MNN and CN would go through:
      1       2       3       4          3          2          1
 MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA --- CN
 VMN                                                             MIPv6
              Figure 5: MNN and CN Are MIPv6 Mobile Nodes

A.1.3. Case C: VMN and Standard IPv6 CN

 When the communication involves a Mobile IPv6 node either as a
 Visiting Mobile Node or as a Correspondent Node, Mobile IPv6 Route
 Optimization cannot be performed because the standard IPv6
 Correspondent Node cannot process Mobile IPv6 signaling.  Therefore,
 MNN would establish a bi-directional tunnel with its HA, which causes
 the flow to go out the nested NEMO.  Packets between MNN and CN would
 thus go through MNN's own Home Agent (VMN_HA).  The path would
 therefore be as shown in Figure 6:

Ng, et al. Informational [Page 14] RFC 4888 NEMO RO Problem Statement July 2007

             2       3       4       5          4
        MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA
        VMN                                           |
                                                      | 3
                                     1          2     |
                                 CN --- VMN_HA --- MR3_HA
                              IPv6 Node
 Figure 6: MNN is an MIPv6 Mobile Node and CN is a Standard IPv6 Node
 Providing Route Optimization involving a Mobile IPv6 node may require
 optimization among the Mobile Routers and the Mobile IPv6 node.

A.2. CN Located in Distinct Nested NEMOs

 The Correspondent Node may be located in another nested mobile
 network, different from the one MNN is attached to, as shown in
 Figure 7.  We define such configuration as "distinct nested mobile
 networks".
            +--------+  +--------+  +--------+  +--------+
            | MR2_HA |  | MR3_HA |  | MR4_HA |  | MR5_HA |
            +------+-+  +---+----+  +---+----+  +-+------+
                    \       |           |        /
       +--------+    +-------------------------+    +--------+
       | MR1_HA |----|        Internet         |----| VMN_HA |
       +--------+    +-------------------------+    +--------+
                        |                   |
                    +---+---+           +---+---+
          root-MR   |  MR1  |           |  MR4  |
                    +---+---+           +---+---+
                        |                   |
                    +---+---+           +---+---+
           sub-MR   |  MR2  |           |  MR5  |
                    +---+---+           +---+---+
                        |                   |
                    +---+---+           ----+----
           sub-MR   |  MR3  |              CN
                    +---+---+
                        |
                    ----+----
                       MNN
         Figure 7: MNN and CN Located in Distinct Nested NEMOs

Ng, et al. Informational [Page 15] RFC 4888 NEMO RO Problem Statement July 2007

A.2.1. Case D: LFN and Standard IPv6 CN

 Similar to Case A, we start off with the case where both end nodes do
 not have any mobility functions.  Packets are encapsulated at every
 Mobile Router on the way out of the nested mobile network,
 decapsulated by the Home Agents, and then encapsulated again on their
 way down the nested mobile network.
          1       2       3       4          3          2
     MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA
     LFN                                                      |
                                                              | 1
                             1       2       3          2     |
                         CN --- MR5 --- MR4 --- MR4_HA --- MR5_HA
                      IPv6 Node
             Figure 8: MNN and CN Are Standard IPv6 Nodes

A.2.2. Case E: VMN and MIPv6 CN

 Similar to Case B, when both end nodes are Mobile IPv6 nodes, the two
 nodes may initiate Mobile IPv6 Route Optimization.  Again, packets
 will not go through the Home Agent of the MNN or the Home Agent of
 the Mobile IPv6 Correspondent Node (not shown in the figure).
 However, packets will still be tunneled for each Mobile Router to its
 Home Agent and vice versa.  Therefore, the path between MNN and CN
 would go through:
          1       2       3       4          3          2
     MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA
     VMN                                                      |
                                                              | 1
                             1       2       3          2     |
                         CN --- MR5 --- MR4 --- MR4_HA --- MR5_HA
                     MIPv6 Node
              Figure 9: MNN and CN Are MIPv6 Mobile Nodes

A.2.3. Case F: VMN and Standard IPv6 CN

 Similar to Case C, when the communication involves a Mobile IPv6 node
 either as a Visiting Mobile Node or as a Correspondent Node, MIPv6
 Route Optimization cannot be performed because the standard IPv6
 Correspondent Node cannot process Mobile IPv6 signaling.  MNN would

Ng, et al. Informational [Page 16] RFC 4888 NEMO RO Problem Statement July 2007

 therefore establish a bi-directional tunnel with its Home Agent.
 Packets between MNN and CN would thus go through MNN's own Home Agent
 as shown in Figure 10:
          2       3       4       5          4          3
     MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA
     VMN                                                      |
                                                              | 2
                 1       2       3           2          1     |
             CN --- MR5 --- MR4 --- MR4_HA  --- MR5_HA --- VMN_HA
          IPv6 Node
 Figure 10: MNN is an MIPv6 Mobile Node and CN is a Standard IPv6 Node

A.3. MNN and CN Located in the Same Nested NEMO

 Figure 11 below shows the case where the two communicating nodes are
 connected behind different Mobile Routers that are connected in the
 same nested mobile network, and thus behind the same root Mobile
 Router.  Route Optimization can avoid packets being tunneled outside
 the nested mobile network.
            +--------+  +--------+  +--------+  +--------+
            | MR2_HA |  | MR3_HA |  | MR4_HA |  | MR5_HA |
            +------+-+  +---+----+  +---+----+  +-+------+
                    \       |           |        /
       +--------+    +-------------------------+    +--------+
       | MR1_HA |----|        Internet         |----| VMN_HA |
       +--------+    +-------------------------+    +--------+
                                  |
                              +---+---+
                    root-MR   |  MR1  |
                              +-------+
                               |     |
                        +-------+   +-------+
               sub-MR   |  MR2  |   |  MR4  |
                        +---+---+   +---+---+
                            |           |
                        +---+---+   +---+---+
               sub-MR   |  MR3  |   |  MR5  |
                        +---+---+   +---+---+
                            |           |
                        ----+----   ----+----
                           MNN          CN

Ng, et al. Informational [Page 17] RFC 4888 NEMO RO Problem Statement July 2007

         Figure 11: MNN and CN Located in the Same Nested NEMO

A.3.1. Case G: LFN and Standard IPv6 CN

 Again, we start off with the case where both end nodes do not have
 any mobility functions.  Packets are encapsulated at every Mobile
 Router on the way out of the nested mobile network via the root
 Mobile Router, decapsulated and encapsulated by the Home Agents, and
 then make their way back to the nested mobile network through the
 same root Mobile Router.  Therefore, the path between MNN and CN
 would go through:
          1       2       3       4          3          2
     MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA
     LFN                                                      |
                                                              | 1
          1       2       3       4          3          2     |
      CN --- MR5 --- MR4 --- MR1 --- MR1_HA --- MR4_HA --- MR5_HA
   IPv6 Node
             Figure 12: MNN and CN Are Standard IPv6 nodes

A.3.2. Case H: VMN and MIPv6 CN

 Similar to Case B and Case E, when both end nodes are Mobile IPv6
 nodes, the two nodes may initiate Mobile IPv6 Route Optimization,
 which will avoid the packets going through the Home Agent of MNN or
 the Home Agent of the Mobile IPv6 CN (not shown in the figure).
 However, packets will still be tunneled between each Mobile Router
 and its respective Home Agent in both directions.  Therefore, the
 path would be the same as with Case G and go through:
           1       2       3       4          3          2
      MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA
      LFN                                                      |
                                                               | 1
           1       2       3       4          3          2     |
       CN --- MR5 --- MR4 --- MR1 --- MR1_HA --- MR4_HA --- MR5_HA
   MIPv6 Node
             Figure 13: MNN and CN Are MIPv6 Mobile Nodes

Ng, et al. Informational [Page 18] RFC 4888 NEMO RO Problem Statement July 2007

A.3.3. Case I: VMN and Standard IPv6 CN

 As for Case C and Case F, when the communication involves a Mobile
 IPv6 node either as a Visiting Mobile Node or as a Correspondent
 Node, Mobile IPv6 Route Optimization cannot be performed.  Therefore,
 MNN will establish a bi-directional tunnel with its Home Agent.
 Packets between MNN and CN would thus go through MNN's own Home
 Agent.  The path would therefore be as shown in Figure 14:
          2       3       4       5          4          3
     MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA
     VMN                                                      |
                                                              | 2
                                                              |
                                                           VMN_HA
                                                              |
                                                              | 1
           1       2       3       4          3          2    |
       CN --- MR5 --- MR4 --- MR1 --- MR1_HA --- MR4_HA --- MR5_HA
    IPv6 Node
 Figure 14: MNN is an MIPv6 Mobile Node and CN is a Standard IPv6 Node

A.4. CN Located Behind the Same Nested MR

 Figure 15 below shows the case where the two communicating nodes are
 connected behind the same nested Mobile Router.  The optimization is
 required when the communication involves MIPv6-enabled nodes.

Ng, et al. Informational [Page 19] RFC 4888 NEMO RO Problem Statement July 2007

            +--------+  +--------+  +--------+  +--------+
            | MR2_HA |  | MR3_HA |  | MR4_HA |  | MR5_HA |
            +------+-+  +---+----+  +---+----+  +-+------+
                    \       |           |        /
       +--------+    +-------------------------+    +--------+
       | MR1_HA |----|        Internet         |----| VMN_HA |
       +--------+    +-------------------------+    +--------+
                                  |
                              +---+---+
                    root-MR   |  MR1  |
                              +---+---+
                                  |
                              +-------+
                     sub-MR   |  MR2  |
                              +---+---+
                                  |
                              +---+---+
                     sub-MR   |  MR3  |
                              +---+---+
                                  |
                              -+--+--+-
                              MNN    CN
        Figure 15: MNN and CN Located Behind the Same Nested MR

A.4.1. Case J: LFN and Standard IPv6 CN

 If both end nodes are Local Fixed Nodes, no special function is
 necessary for optimization of their communications.  The path between
 the two nodes would go through:
                                1
                           MNN --- CN
                           LFN   IPv6 Node
             Figure 16: MNN and CN Are Standard IPv6 Nodes

A.4.2. Case K: VMN and MIPv6 CN

 Similar to Case H, when both end nodes are Mobile IPv6 nodes, the two
 nodes may initiate Mobile IPv6 Route Optimization.  Although few
 packets would go out the nested mobile network for the Return
 Routability initialization, however, unlike Case B and Case E,
 packets will not get tunneled outside the nested mobile network.
 Therefore, packets between MNN and CN would eventually go through:

Ng, et al. Informational [Page 20] RFC 4888 NEMO RO Problem Statement July 2007

                                1
                           MNN --- CN
                           VMN   MIPv6 Node
             Figure 17: MNN and CN are MIPv6 Mobile Nodes
 If the root Mobile Router is disconnected while the nodes exchange
 keys for the Return Routability procedure, they may not communicate
 even though they are connected on the same link.

A.4.3. Case L: VMN and Standard IPv6 CN

 When the communication involves a Mobile IPv6 node either as a
 Visiting Mobile Network Node or as a Correspondent Node, Mobile IPv6
 Route Optimization cannot be performed.  Therefore, even though the
 two nodes are on the same link, MNN will establish a bi-directional
 tunnel with its Home Agent, which causes the flow to go out the
 nested mobile network.  The path between MNN and CN would require
 another Home Agent (VMN_HA) to go through for this Mobile IPv6 node:
          2       3       4       5          4          3
     MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA
     VMN                                                      |
                                                              | 2
                                                              |
                                                           VMN_HA
                                                              |
                                                              | 1
           1       2       3       4          3          2    |
       CN --- MR5 --- MR4 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA
    IPv6 Node
 Figure 18: MNN is an MIPv6 Mobile Node and CN is a Standard IPv6 Node
 However, MNN may also decide to use its Care-of Address (CoA) as the
 source address of the packets, thus avoiding the tunneling with the
 MNN's Home Agent.  This is particularly useful for a short-term
 communications that may easily be retried if it fails.  Default
 Address Selection [11] provides some mechanisms for controlling the
 choice of the source address.

Ng, et al. Informational [Page 21] RFC 4888 NEMO RO Problem Statement July 2007

Appendix B. Example of How a Stalemate Situation Can Occur

 Section 2.7 describes the occurrence of a stalemate situation where a
 Home Agent of a Mobile Router is nested behind the Mobile Router.
 Here, we illustrate a simple example where such a situation can
 occur.
 Consider a mobility configuration depicted in Figure 19 below.  MR1
 is served by HA1/BR and MR2 is served by HA2.  The 'BR' designation
 indicates that HA1 is a border router.  Both MR1 and MR2 are at home
 in the initial step.  HA2 is placed inside the first mobile network,
 thus representing a "mobile" Home Agent.
                                                   /-----CN
                                       +----------+
      home link 1         +--------+   |          |
    ----+-----------------| HA1/BR |---| Internet |
        |                 +--------+   |          |
        |                              +----------+
     +--+--+  +-----+
     | MR1 |  | HA2 |
     +--+--+  +--+--+
        |        |
       -+--------+-- mobile net 1 / home link 2
        |
     +--+--+  +--+--+
     | MR2 |  | LFN |
     +--+--+  +--+--+
         |        |
        -+--------+- mobile net 2
                     Figure 19: Initial Deployment
 In Figure 19 above, communications between CN and LFN follow a direct
 path as long as both MR1 and MR2 are positioned at home.  No
 encapsulation intervenes.
 In the next step, consider that the MR2's mobile network leaves home
 and visits a foreign network, under Access Router (AR) like in
 Figure 20 below.

Ng, et al. Informational [Page 22] RFC 4888 NEMO RO Problem Statement July 2007

                                             /-----CN
                                 +----------+
      home link 1   +--------+   |          |
      --+-----------| HA1/BR |---| Internet |
        |           +--------+   |          |
     +--+--+  +-----+            +----------+
     | MR1 |  | HA2 |                        \
     +--+--+  +--+--+                        +-----+
        |        |                           | AR  |
       -+--------+- mobile net 1             +--+--+
                    home link 2                 |
                                             +--+--+  +-----+
                                             | MR2 |  | LFN |
                                             +--+--+  +--+--+
                                                |        |
                                  mobile net 2 -+--------+-
                Figure 20: Mobile Network 2 Leaves Home
 Once MR2 acquires a Care-of Address under AR, the tunnel setup
 procedure occurs between MR2 and HA2.  MR2 sends a Binding Update to
 HA2 and HA2 replies with a Binding Acknowledgement to MR2.  The bi-
 directional tunnel has MR2 and HA2 as tunnel endpoints.  After the
 tunnel MR2HA2 has been set up, the path taken by a packet from CN
 towards LFN can be summarized as:
     CN->BR->MR1->HA2=>MR1=>BR=>AR=>MR2->LFN.
 Non-encapsulated packets are marked "->" while encapsulated packets
 are marked "=>".
 Consider next the attachment of the first mobile network under the
 second mobile network, like in Figure 21 below.
 After this movement, MR1 acquires a Care-of Address valid in the
 second mobile network.  Subsequently, it sends a Binding Update (BU)
 message addressed to HA1.  This Binding Update is encapsulated by MR2
 and sent towards HA2, which is expected to be placed in mobile net 1
 and expected to be at home.  Once HA1/BR receives this encapsulated
 BU, it tries to deliver to MR1.  Since MR1 is not at home, and a
 tunnel has not yet been set up between MR1 and HA1, HA1 is not able
 to route this packet and drops it.  Thus, the tunnel establishment
 procedure between MR1 and HA1 is not possible, because the tunnel
 between MR2 and HA2 had been previously torn down (when the mobile
 net 1 moved from home).  The communications between CN and LFN stops,
 even though both mobile networks are connected to the Internet.

Ng, et al. Informational [Page 23] RFC 4888 NEMO RO Problem Statement July 2007

                                    /-----CN
                        +----------+
           +--------+   |          |
           | HA1/BR |---| Internet |
           +--------+   |          |
                        +----------+
                                    \
                                    +-----+
                                    | AR  |
                                    +--+--+
                                       |
                                    +--+--+  +-----+
                                    | MR2 |  | LFN |
                                    +--+--+  +--+--+
                                       |        |
                         mobile net 2 -+--------+-
                                       |
                                    +--+--+  +-----+
                                    | MR1 |  | HA2 |
                                    +--+--+  +--+--+
                                       |        |
                         mobile net 1 -+--------+-
                 Figure 21: Stalemate Situation Occurs
 If both tunnels between MR1 and HA1, and between MR2 and HA2, were up
 simultaneously, they would have "crossed over" each other.  If the
 tunnels MR1-HA1 and MR2-HA2 were drawn in Figure 21, it could be
 noticed that the path of the tunnel MR1-HA1 includes only one
 endpoint of the tunnel MR2-HA2 (the MR2 endpoint).  Two MR-HA tunnels
 are crossing over each other if the IP path between two endpoints of
 one tunnel includes one and only one endpoint of the other tunnel
 (assuming that both tunnels are up).  When both endpoints of one
 tunnel are included in the path of the other tunnel, then tunnels are
 simply encapsulating each other.

Ng, et al. Informational [Page 24] RFC 4888 NEMO RO Problem Statement July 2007

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: chanwah.ng@sg.panasonic.com
 Pascal Thubert
 Cisco Systems
 Village d'Entreprises Green Side
 400, Avenue de Roumanille
 Batiment T3, Biot - Sophia Antipolis  06410
 FRANCE
 EMail: pthubert@cisco.com
 Masafumi Watari
 KDDI R&D Laboratories Inc.
 2-1-15 Ohara
 Fujimino, Saitama  356-8502
 JAPAN
 EMail: watari@kddilabs.jp
 Fan Zhao
 UC Davis
 One Shields Avenue
 Davis, CA  95616
 US
 Phone: +1 530 752 3128
 EMail: fanzhao@ucdavis.edu

Ng, et al. Informational [Page 25] RFC 4888 NEMO RO Problem Statement July 2007

Full Copyright Statement

 Copyright (C) The IETF Trust (2007).
 This document is subject to the rights, licenses and restrictions
 contained in BCP 78, and except as set forth therein, the authors
 retain all their rights.
 This document and the information contained herein are provided on an
 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST 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.

Intellectual Property

 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.

Acknowledgement

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

Ng, et al. Informational [Page 26]

/data/webs/external/dokuwiki/data/pages/rfc/rfc4888.txt · Last modified: 2007/07/17 01:12 (external edit)