Re: [nemo] Re: I-D ACTION:draft-ietf-nemo-ro-space-analysis-01.txt
Alexandru Petrescu <alexandru.petrescu@motorola.com> Fri, 25 November 2005 13:18 UTC
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfdSy-0006BU-C9; Fri, 25 Nov 2005 08:18:16 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfdSw-00066I-DT for nemo@megatron.ietf.org; Fri, 25 Nov 2005 08:18:14 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23879 for <nemo@ietf.org>; Fri, 25 Nov 2005 08:17:31 -0500 (EST)
Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EfdmC-0006AR-Ku for nemo@ietf.org; Fri, 25 Nov 2005 08:38:09 -0500
Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id jAPDUZYj005307; Fri, 25 Nov 2005 06:30:35 -0700 (MST)
Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id jAPDQot3027568; Fri, 25 Nov 2005 07:26:50 -0600 (CST)
Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 38B52865980; Fri, 25 Nov 2005 14:17:49 +0100 (CET)
Message-ID: <43870EFC.5090100@motorola.com>
Date: Fri, 25 Nov 2005 14:17:48 +0100
From: Alexandru Petrescu <alexandru.petrescu@motorola.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803
X-Accept-Language: rs1_22c0391591b, rs2_349b8913e3d, rs3_148101cb63
MIME-Version: 1.0
To: Chan-Wah Ng <chanwah.ng@sg.panasonic.com>
Subject: Re: [nemo] Re: I-D ACTION:draft-ietf-nemo-ro-space-analysis-01.txt
References: <E1EV94t-0000KU-Af@newodin.ietf.org> <1130764060.19589.13.camel@localhost> <1130929567.7004.5.camel@acorde> <20051124203213.024ec45b.ernst@sfc.wide.ad.jp> <1132838480.11586.90.camel@localhost>
In-Reply-To: <1132838480.11586.90.camel@localhost>
X-Enigmail-Version: 0.91.0.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56
Content-Transfer-Encoding: 7bit
Cc: nemo@ietf.org, Thierry Ernst <ernst@sfc.wide.ad.jp>
X-BeenThere: nemo@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: NEMO Working Group <nemo.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/nemo>, <mailto:nemo-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:nemo@ietf.org>
List-Help: <mailto:nemo-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/nemo>, <mailto:nemo-request@ietf.org?subject=subscribe>
Sender: nemo-bounces@ietf.org
Errors-To: nemo-bounces@ietf.org
Chan-Wah Ng wrote:
> Hello Thierry,
[...]
>> o Avoid the Instability and Stalemate
>>
>> [1] described a potential stalemate situation when a Home Agent is
>> nested within a Mobile Network. Route Optimization may circumvent
>> such stalemate situations by directly forwarding traffic upstream.
>> However, it should be noted that certain Route Optimization
>> schemes may require signaling packets to be first routed via the
>> Home Agent before an optimized route can be established. In such
>> cases, a Route Optimization solution cannot avoid the stalemate.
>>
>> I'm not sure the paragraph above is clear enough.
>
> [1] is listed as "Normative". After reading [1] and if you still
> feel its not clear enough, I am open to suggestions on how to improve
> it :)
About the "stalemate" problem. [1] is the ro problem statement draft,
which in turn cites the home network models draft which cites back
the ro problem statement draft.
For example, the home network models draft says:
> But note that SFO should never attach to one of its own Cabs. This
> would create a stalemate situation, as documented in the NEMO RO
> problem statement [11].
... which leaves one wonder what exactly is the "stalemate" situation.
So one goes to the ro ps draft and reads:
> Several configurations for the Home Network are described in [9]
> [home net models]. 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 visitors traffic. The traffic from the
> parent is thus blocked from reaching the Internet and it will never
> bind to its own (grand parent) Home Agent.
This last paragraph in the ro ps draft is the essence of the "stalemate"
problem. If that paragraph is not enough for clear explanation, here's
more detailed text about how the "stalemate" situation may occur
(substitute "stalemate" for "cross-over tunnels":
Two MR-HA tunnels are "crossing over" each other when the path
between one tunnel's endpoints includes only one of the other
tunnel's endpoints.
Support of nested mobile networks is possible only when the path
from MR2 to MR1's HA does not go through MR1 (path considered when
both mobile routers are at home and no tunnels are in place).
Consider a mobility configuration depicted below. MR1 is served by
HA1/BR and MR2 is served by HA2. 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 link1 ------- | |
-----------------------| HA1/BR|---| Internet |
| ------- | |
| ----------
----- -----
| MR1 | | HA2 |
----- -----
| |
-------------mobile network 1 / home link2
|
----- -----
| MR2 | | LFN |
----- -----
| |
------------mobile network 2
In the picture above, communication between CN and LFN follows a
direct path as lons 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 the
figure below:
/-----CN
----------/
home link 1 ------- | |
---------------| HA1/BR|---| Internet |
| ------- | |
----- ----- ----------\
| MR1 | | HA2 | \
----- ----- -----
| | | AR |
------------mobile net 1 -----
home link2 |
----- -----
| MR2 | | LFN |
----- -----
| |
mobile net 2------------
Once MR2 acquires a CoA under AR, the tunnel setup procedure occurs
between MR2 and HA2. MR2 sends BU to HA2 and HA2 replies BAck 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 the figure below:
/-----CN
----------/
------- | |
| HA1/BR|---| Internet |
------- | |
----------\
\
-----
| AR |
-----
|
----- -----
| MR2 | | LFN |
----- -----
| |
mobile net 2------------
|
----- -----
| MR1 | | HA2 |
----- -----
| |
mobile net 1------------
After this movement, MR1 acquires a CoA valid in the second mobile
network. Subsequently, it sends a BU message addressed to HA1.
This BU 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, due to the fact that the tunnel between MR2 and HA2
has been previously torn down (when the mobile net 1 has moved from
home). The communication between CN and LFN stops, even though both
mobile networks are connected to the Internet.
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 the above picture,
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.
Alex
- [nemo] I-D ACTION:draft-ietf-nemo-ro-space-analys… Internet-Drafts
- [nemo] Re: I-D ACTION:draft-ietf-nemo-ro-space-an… Chan-Wah Ng
- Re: [nemo] Re: I-D ACTION:draft-ietf-nemo-ro-spac… Alexandru Petrescu
- [nemo] Next steps in RO - was :draft-ietf-nemo-ro… Thierry Ernst
- Re: [nemo] Re: I-D ACTION:draft-ietf-nemo-ro-spac… Carlos Jesús Bernardos Cano
- [nemo] Next steps in RO T.J. Kniveton
- Re: [nemo] Next steps in RO Chan-Wah NG
- Re: [nemo] Next steps in RO Carlos Jesús Bernardos Cano
- Re: [nemo] Next steps in RO T.J. Kniveton
- Re: [nemo] Next steps in RO Thierry Ernst
- Re: [nemo] Re: I-D ACTION:draft-ietf-nemo-ro-spac… Thierry Ernst
- Re: [nemo] Re: I-D ACTION:draft-ietf-nemo-ro-spac… Chan-Wah Ng
- Re: [nemo] Re: I-D ACTION:draft-ietf-nemo-ro-spac… Chan-Wah Ng
- Re: [nemo] Re: I-D ACTION:draft-ietf-nemo-ro-spac… Thierry Ernst
- [nemo] Published work for RO solutions referenced… Thierry Ernst
- Re: [nemo] Re: I-D ACTION:draft-ietf-nemo-ro-spac… Chan-Wah Ng
- Re: [nemo] Re: I-D ACTION:draft-ietf-nemo-ro-spac… Alexandru Petrescu
- Re: [nemo] Re: I-D ACTION:draft-ietf-nemo-ro-spac… Chan-Wah Ng
- RE: [nemo] Re: I-D ACTION:draft-ietf-nemo-ro-spac… Pascal Thubert (pthubert)
- Re: [nemo] Re: I-D ACTION:draft-ietf-nemo-ro-spac… Thierry Ernst
- Re: [nemo] Re: I-D ACTION:draft-ietf-nemo-ro-spac… Chan-Wah Ng
- Re: [nemo] Re: I-D ACTION:draft-ietf-nemo-ro-spac… Thierry Ernst