Subject: [nemo] New draft: Failover for multiple mobile routers

From: 류지호 <[email-masked]>
Date: Mon, 11 Jul 2005 16:07:51 +0900

Hi all,

We have submitted a new draft on the failover for multiple mobile

routers in a mobile network. Your comments are appreciated.

http://www.ietf.org/internet-drafts/draft-ryu-nemo-mr-failover-00.txt

Abstract:

This draft proposed the use of multiple mobile routers in a single

NEMO. Failed mobile router is replaced by another mobile router

using "prefix peer" relationship among mobile routers in a NEMO.

"prefix peer" relationship enables a mobile router's prefix to be

handled by another mobile router.

Regards

Jiho Ryu.

---

From: Romain KUNTZ <[email-masked]>
Date: Thu, 14 Jul 2005 15:13:46 +0900

Hi,

I have several questions and comments about your draft
draft-ryu-nemo-mr-failover-00.

First, it could be a good idea to follow the spirit of
draft-ietf-nemo-multihoming-issues to describe on which topology you are
working on, and which issue you try to solve.

> 3.4.3  Binding Update Acknowledgment

It should be "Binding Acknowledgement".

> A new flag (P) is included in the binding update

It should also be "binding acknowledgement" here.

> 4.2.1  Interface Failure and Recovery
> 
> Any PMR detects an egress (ingress) interface failure of an original 
> MR by receiving a failure notify message from the failed MR, the PMR 
> sends a PPBU message to the HA of the failed MR.

My concern here is that the PMR can have problem to register with the HA
of the failed MR.

First, you may have some access control mechanisms on the HA to prevent
a MR it does not know to register.

Then, for the PMR to register at the HA of the failed MR, the PMR must
use the Home Address of the failed MR. So, first the PMR has to know it,
and then, it must be able to use it.

Maybe you should also say that the PPBU has to include the MNP of the
failed Mobile Router.

What about the value of the BID in the BID option? A 0 value must not be
used (according to MCoA specification), and some other values may have
already been taken by the failed MR for one of its CoA.

BTW, I don't understand why you use the BID option here if you do not
use the BID itself. In your examples at the end of the draft (Figure 2
and 3), all BIDs are set to 0.

> The backup flag of the Binding Update Identifier sub-option in this 
> PPBU message is set to 0.

Shouldn't it be set to 1?
As you say in the terminology section, it should be set to 1 for a PMR
registration:

> Prefix Peer Binding Update
> 
> Prefix peer binding update means this binding update message is sent
> by PMRs.  Prefix peer binding update (PPBU) has different meaning
> depending on the backup flag in Binding Unique Identifier sub-option.
> If the backup flag is set to 1, it means that a PMR sends this
> binding update message for PMR registration. Otherwise, this binding
> update message is sent by a PMR to change a CoA in binding cache of a
> HA.

> Finally, the PMR replies a Recovery Notify Acknowledge
> message to the HA of the failed MR.  Then, the original MR restarts
> to advertise its MNP.

You do not say when the original MR should stop to advertise its prefix.
I guess it should stop as soon as it detects a failure on its egress
interface.

> 4.2.2  MR Failure and Recovery
> 
> When the original MR fails, the failed MR cannot send a failure 
> notify message to inform its PMRs of the MRr failure and the HA 
> address of the failed MR to perform PPBU.  Therefore, any PMR detects
> failure of the original MR, it first performs a dynamic home agent 
> address discovery (DHAAD) [1] to know the HA address of the failed 
> MR.

To perform such a DHAAD request, the PMR must at least know the prefix
of the Home Link of the failed MR. Then some access control policies on
the HA of the home link can prevent the PMR from being successful in
such request.

> The backup flag of the Binding Update Identifier sub-option in this 
> PPBU message is set to 0.

Same here: it think it should be set to 1. Or did I miss something?

> 4.3.1  ICMP Mobile Router Failure Notify

Some of your ICMP messages uses the Home Addresses of the MR as
destination address. How the MR can know it? Or do you refer to the
solution proposed by draft-cho-nemo-mr-registration-00 ?

> 4.3.2  ICMP Mobile Router Failure Notify Acknowledgment

Why do you add the HA address of the failed MR in the Acknowledgement?

Regards,

-- 
Romain KUNTZ
[email-masked]

---

From: Jiho Ryu <[email-masked]>
Date: Fri, 15 Jul 2005 17:04:40 +0900

Hi,

Thank you for your coments.

First, this draft focused on "Failover for Multiple Mobile Routers"
after succesful PMR authentication and registration.
At this point, we also degined PMR authentication and registration
mechasnism but need more verification.
A next version may include our PMR authentication and registration
mechasnism :-)

Please, read in-line.

>It should be "Binding Acknowledgement".
You're right.
Yes, it's "binding acknowledgement"

>Maybe you should also say that the PPBU has to include the MNP of the
We can utilize an MR authentication and registration mechanism proposed
by Mr. Cho[draft-cho-nemo-mr-registration-00] after a few modifications,
or a new mechanism can be developed. (We have already developed our PMR
authentication and registration mechanism as mentioned above.)
After successful PMR authentication and registration via one of such
mechanisms, the HA of the original MR may have the list/cache of PMRs.
So, the HA can determine whether the PMR's PPBU is permitted or not by
referring the list/cache of PMRs.

>and 3), all BIDs are set to 0.
We are also considering a MR that has multiple egress interfaces.
Because the MCoA mechanism can handle the case, we adapted and extended
it for multi-homed NEMOs.
So, we think that the BID is necessary.

And about the zero value of BID, you're right. Thanks.

>As you say in the terminology section, it should be set to 1 for a PMR
In section 3.4.1, we explain backup flag of Binding Update Identifier
sub-option.

Backup Flag (B)

The backup flag is set to indicate to the HA whether the CoA in
the binding update is a peer CoA or not. If the flag is set to 0,
the CoA is an active CoA.

In here(PPBU), this CoA is an active CoA to backup the failed MR.

and in section 3.2

- Backup flag: MUST be set if the CoA is a peer CoA.

I think the "peer CoA" make you confusion. Sorry about this.

>I guess it should stop as soon as it detects a failure on its egress
You're right.

>the HA of the home link can prevent the PMR from being successful in
After successful PMR authenticationand registration, the PMR maintains
the list of orginal MRs.
The format of the list can be (MR Addr, NMPs) or (MR Addr, MNPs, HA Addr).
If we use the second format, the DHAAD process in the case of MR
failures and the HA addr field in FN messages in ingress/egress
interface failures can be omitted because the PMR already knows the HA
addr.
We think that it is an optimization to our proposal :-)

>Same here: it think it should be set to 1. Or did I miss something?
I mentioned above.

>solution proposed by draft-cho-nemo-mr-registration-00 ?
The MR can maintain the list of PMRs via the PMR authentication and
registration as we mention above, so it is possible.

>Why do you add the HA address of the failed MR in the Acknowledgement?
You're right, it is not needed.

Thanks,
Jiho.

-- 
Ryu, Jiho
Master Course
Multimedia and Mobile Communications Lab.,
School of Computer Science and Engineering
Seoul National University

---

From: Jiho Ryu <[email-masked]>
Date: Tue, 26 Jul 2005 18:01:38 +0900

Hi,

I forget to answer one thing in my previous mail. :-)

>working on, and which issue you try to solve.
Our draft is focussing on the scenario (n,*,n) .
We are assuming that a mobile router can hear RA messages from other
mobile routers in the same NEMO.
Here is an example.

+-----+ +-----+
| HA1 | | HA2 |
+--+--+ +--+--+
| |
| |
+---+----------+----+ MR1 +-----+
| Internet |------| MR1 |
+---+----------+----+ CoA1+--+--+
| |MNP1
MR2|CoA2 |
+-----+ |
| MR2 | |
+--+--+ |
|MNP2 |
| |
+--+-------------+--+
| NEMO |
+-------------------+

Figure 1. Multi-homed NEMO

We try to solve the failure and recovery issues of multiple mobile
router in NEMO.

For more information, please refer the appendices section of our draft.

Regards,
Jiho.