Subject: Re: [nemo] Design Team draft for NEMO Basic Solution

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 01 Jul 2003 14:38:52 +0200

Vijay Devarapalli wrote:
> Chan-Wah Ng wrote:
> 
>> Should HA respond to RS on behalf of MR if the R-bit was set in the
>>  BU? Regardless of the answer, this need to be explained in the 
>> Draft, IMHO.
> 
> 
> RS is typically sent to the all routers multicast address. it is not
>  sent to a particular address.

I was thinking that a neighbour on the home link might target a RS to a
specific IP address (not multicast), sometimes.

> so there is no question of HA responding to an RS on MR's behalf.

Maybe it is worth considering that HA joins the multicast groups at home
to which the MR joined prior to movement.  That means that HA replies to
  neighbours requesting info about the MR.  One might consider "Reachable
Time" as a value in the RA sent by HA on behalf of MR in order to
gracefully indicate the neighbouring nodes on the home link that MR is
gone and that HA takes its place.

> and anyway this information is useless.

One might also want to consider what are the interactions of HA sending
RA on behalf of MR, and the Mobile Prefix Solicitation mechanisms of
Mobile IPv6.

Alex
GBU

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 01 Jul 2003 14:38:52 +0200

Alex
GBU

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 27 Jun 2003 10:20:53 -0700

Chan-Wah Ng wrote:
> 
> Should HA respond to RS on behalf of MR if the R-bit was set in the BU?
> Regardless of the answer, this need to be explained in the Draft, IMHO.

RS is typically sent to the all routers multicast address.
it is not sent to a particular address. so there is no 
question of HA responding to an RS on MR's behalf. and
anyway this information is useless.

> Should the HA broadcast a RA on behalf of MR if the R-bit was set in the
> BU? 

no. the MR is not on the home link. there is no point.

> Or should the MR send RA broadcast to the home link via the MRHA
> tunnel? 

it could. but the information is useless again. the HA 
cant do anything with it.

> I think it was suggested in the Draft that MR may do so,
> provided the Lifetime field is set to 0.

this is when the MR is at home and sends a RA on the link
with which it is connected to the home link. the router
lifetime is set to 0, so that no other node configures the
MR as a default router.

Vijay

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 01 Jul 2003 14:29:29 +0200

Vijay Devarapalli wrote:
>> In [Section 4.4, page 13], the explanation of Prefix Length field
>> seems to be questionable.  It says "length of the IPv6 prefix
>> contained in the option", but there is no prefix in this option.
>> Also, a full-stop punctuation is missing.
> 
> 
> changed it to
> 
> 8 bit unsigned integer indicating the prefix length of the IPv6
> prefix from which the Home Address included in the Binding Update was
> configured from.

Typo, redundant double occurence of "from".  Could be:

         8 bit unsigned integer indicating the length of the IPv6
         prefix derived from the Home Address appearing in the Binding
         Update.

Alex
GBU

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 01 Jul 2003 14:29:29 +0200

Alex
GBU

---

From: William D Ivancic <[email-masked]>
Date: Wed, 02 Jul 2003 13:35:35 -0400

Very nice work on the Basic Support.

Sorry, I cannot make it out to Vienna, but I should be at the next 
meeting.   Also,  I have a draft completed on issues related to mobile-ip 
and routing protocols when using encryption devices.  I could not get it in 
before closeout of Internet Drafts.  However I will as soon as IETF opens 
for new submissions.

Here are a few questions and some minor corrections:

1)  Question regarding section 8. Support for Dynamic Routing Protocols
"In the solution described so far, forwarding to the Mobile Network at the 
Home Agent is set up when the Home Agent receives a Binding Update from the 
Mobile Router. An alternative to this is for the Home Agent and the Mobile 
Router to run a intra-doamin routing protocol like RIPng [6] and OSPF [7] 
through the bi-directional tunnel."

I believe the hop limit is usually set to 1 for routing 
protocols.   Encapsulation will decrement by 1.  Do we need to state 
anything here regarding the need to not decrement the Hop Limit field here 
or is this obvious?  ( I am wary of this as it is definitely an issue with 
encryption devices.)

1.1)  Has anyone given some though to policy base routing over tunnels that 
are coming up and going down?   The aeronautics community still has this on 
their wish list.

2)  Many places in  the document is state "MUST not."   Should those be 
changed to "MUST NOT"?

Typographic and Spelling Mistakes
=========================
Page 17.
home link. At this point, Mobile Router MAY try try to obtain and own a 
prefix by the same means that it initially got attributed the Invalid 
Prefix in question. Alternatively, Mobile Router MAY send Binding Updates 
in another mode (e.g. implicit mode) to a Home Agent on the same home link.

MAY try try  >>>   MAY try

The bi-directional tunnel between Mobile Router and Home Agent allows 
packets to flow in both directions between these entities, while the Mobile 
Router is connected to a Visisted Link.

Visisted Link. >>> Visited Link

Page 18

A Mobile Router MAY use the received Router Advertisements on the interface 
connected to the home link, but only for logging and administrative 
purposes. Only when that interface is connected to a A Mobile Router MAY 
use the received Router Advertisements on the interface connected to the 
home link, but only for logging and administrative purposes. Only when that 
interface is connected to a visisted link,

visisted link >>>  visited link

Page 26
8. Support for Dynamic Routing Protocols In the solution described so far, 
forwarding to the Mobile Network at the Home Agent is set up when the Home 
Agent receives a Binding Update from the Mobile Router. An alternative to 
this is for the Home Agent and the Mobile Router to run a intra-doamin routing

intra-doamin  >>> intra-domain

Will Ivancic

---

From: William D Ivancic <[email-masked]>
Date: Wed, 02 Jul 2003 13:35:35 -0400

MAY try try  >>>   MAY try

Page 18

Page 26

Will Ivancic

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 02 Jul 2003 11:08:06 -0700

> or is this obvious?  ( I am wary of this as it is definitely an issue with

the way I see it is, both the HA and MR run a routing protocol
through the bi-directional tunnel. this tunnel is treated as 
a singe hop link. both MR and HA use link local addresses for
routing protocol messages inside the tunnel. these messages
are processed at each end and are not forwarded onto the other
links.

forwarding packets with link local address raises a lot of 
issues and also makes the HA implementation difficult.

> are coming up and going down?   The aeronautics community still has this on

I am not sure I read any previous mails on this. can you tell
me more?

> 2)  Many places in  the document is state "MUST not."   Should those be

fixed

> Typographic and Spelling Mistakes

thanks.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 02 Jul 2003 11:08:06 -0700

fixed

thanks.

Vijay

---

From: William D Ivancic <[email-masked]>
Date: Thu, 03 Jul 2003 10:22:34 -0400

> > Router to run a intra-domain routing protocol like RIPng [6] and OSPF [7]

Hello Vijay,

let me try and give the aeronautic example.

The aero community (FAA, ICAO and other multinational political 
organizations) has an air/ground link called VDL (VHF Data Link) which 
comes in four flavors.  This link is robust and used throughout the 
world.  Ten years in the future, the aero community hopes to get everybody 
to use  packetized communication at roughly 8 kbps per link shared among a 
number of users.

Current requirement ALL COMMAND and CONTROL is required to use VDL links or 
INMARSAT.  (IMHO a very poor and foolish requirement, but this community is 
used to circuit-base communication system, not networks and packet-based 
communications nor open systems.

Two specific things that the aero community has written as requirements is 
Load Sharing and Policy Based Routing.

If I have two 8 kbps links available, I would like to load share (assume 
these links are already paid for and free to the user - poor assumption, 
but one that is used).  OK, so maybe it makes some sense to load share 
between the two 8 kbps links.   Now let's add two more satellite 
links:  INMARSAT swift 64 (64 kbps) and Connexion by Boeing (4 Mbps on, 
100s of kbps off).  Does load sharing make sense here?  Why not use the 
Connexion link as the entertainment services are already paying for the 
link.  Command and Control will not even be noticed and can be give highest 
priority.   Remember, if I load share the Swift 64, I have to pay that bill 
and it is quite high.  Pay per packet or per connect time.  Try budgeting 
that.    >>>>  Regarding multi-homing, I believe in the vast majority of 
the cases, one would rather pick the best link and not load share because 
of cost.  Now, if I already had flat-rate billing and a GRPS and CDMA 
service paid for and both links active, I may wish to load share. <<<<<

Given these same four links, Policy states I must send command and control 
over VDL or INMARSAT.  Thus the policy based routing requirement.  Now, 
when I fly over the oceans, I loose VDL so policy says route via INMARSAT 
if available.  If VDL is active route through VDL.  Never route Command and 
Control through Connexion.    So, interfaces and tunnels are coming up and 
down on the mobile unit.  How does one write policy?   Better yet, they 
also would like to write policy on the ground that directs traffic to take 
particular routes through the ground network.  Not to easy if everything 
resides in tunnels - of course we haven't even considered secure tunnels to 
hide things.

Now let me add some more reality to the mess.   (This is my current 
understanding as explained to me by various pilots.  I am open to 
correction.)  Commercial aircraft today generally only have one active VDL 
circuit that is performing packetized communication.  The other is used for 
voice.  They are not combined (i.e. VOIP).  Because the satellite time 
costs so much, the INMARSAT system generally is not powered on unless the 
VDL link is lost.    So in reality, only one link is active.   The question 
I keep raising to this community is why policy-based routing and load 
sharing when in reality only one link is active.    I also suspect that I 
could obtain much higher QoS if I used the Connexion link ( or 
similar)  for command and control when available and could sufficiently 
secure those messages with today's technologies.  IMHO, What is really 
needed is some type of quality of service requirement such that command and 
control is highest priority.

Will

---

From: William D Ivancic <[email-masked]>
Date: Thu, 03 Jul 2003 10:22:34 -0400

Hello Vijay,

Will

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 03 Jul 2003 15:03:41 -0700

> resides in tunnels - of course we haven't even considered secure tunnels to

I got it. there are two problems here

1. there are multiple intefaces available, and the MR
   should pick the best available interface. IMO, this
   is not necessarily a NEMO problem. you need something
   like a "roaming manager" (there are many synonyms for
   this), which figures out which interface is up and 
   decides which interface should be used and when. as
   far as the NEMO protocol is concerned, it needs an
   uplink to the visited network, through which the MR
   can reach its Home Agent. I think there is nothing to
   standardize here. the "roaming manager" would be
   implementation specific.

2. in your experiment, you said you were required to send
   control traffic through a VDL or INMARSAT link and data 
   traffic through a Connexion link. isnt this again 
   implementation specific? the forwarding code on the 
   MR has to figure out the outgoing interface based on the 
   message contents. do you see a need to standardize 
   something here? do we need an API between the NEMO 
   module and the "roaming manager"?

a list of requirements in the form of an internet draft 
would be nice. then we can figure out what exactly needs 
to be specified.

> control is highest priority.

I agree with you here.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 03 Jul 2003 15:03:41 -0700

I agree with you here.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 11 Jul 2003 12:37:14 -0700

Chan-Wah Ng wrote:
> 
> > if the Mobile Router set the R bit to 0 in the Binding
> > Update, it means it is going to behave as a mobile host.
> >
> > > So, does this means that for a static route configuration
> > > where the next hop for the Mobile Network Prefix is the Mobile Router,
> > > the Home Agent should discard packets sent to the Mobile Network Prefix
> > > if it receives a BU from Mobile Router with R=0?  Perhaps the response
> > > of the Home Agent in this case can be specified?
> >
> > even in static route configuartion, the HA must
> > consult the binding cache for the MR's current CoA.
> > if there is no binding cache entry, then the packets
> > are sent on link. if there is a binding cache entry
> > and the R bit set to 0, the HA must not forward the
> > packets.
> >
> > is this an acceptable solution?
> >
> Yes, it is.  I just thought that this should be reflected in the draft.

okay. I am changing the following

    The Mobile Router Flag is set to indicate to the Home Agent
    that the Binding Update is from a Mobile Router.  If the flag
    is set to 0, the Home Agent assumes that the Mobile Router is
    just behaving as a Mobile Node, and should not forward packets
    destined for the mobile network to the Mobile Router.

to 

    The Mobile Router Flag is set to indicate to the Home Agent
    that the Binding Update is from a Mobile Router.  If the flag
    is set to 0, the Home Agent assumes that the Mobile Router is
    just behaving as a Mobile Node, and MUST NOT forward packets
    destined for the mobile network to the Mobile Router.

MUST NOT should make it clear that if the R flag is set 
to 0, the HA does not forward packets meant for the 
mobile network to the mobile router under all 
circumstances.

> > >
> > > Nothing is said about the Data Structure of the Home Agent. Shouldn't
> > > there be changes to the Binding Cache as well?
> >
> > yes. you are right. the HA should store the prefixes
> > that was sent in the Binding Update. it needs this list
> > of prefixes later on to delete all the routes, if the
> > binding cache entry expires. I will add some text.
> >
> OK.

here is some text (to be added to Section 6.1)

   The Home Agent SHOULD store the list of Mobile Network Prefixes owned
   by a Mobile Router in the corresponding Binding Cache entry.  This
   list of prefixes should include only those for which the Home Agent
   currently has routes pointing to the Mobile Router's current Care-of
   address.  This information is later used to delete the routes when
   the Binding Cache entry for the Mobile Router is deleted.

   The Home Agent also stores the status of the Mobile Router Flag 'R'
   in the Binding Cache entry.

> 
> > > Nothing is mentioned in the operation of Mobile Router about checks on
> > > received tunnelled packets from Home Agent.  Shouldn't the Mobile Router
> > > verify that the inner packet has a destination address that is within
> > > its Mobile Network Prefix?
> >
> > it should perform all the necessary checks when
> > decapsulating and forwarding packets. we will add some
> > text.
> >
> OK

here is some text. in section 3.

after 

   The Mobile Router
   decapsulates the packet and forwards it onto the link where the
   Mobile Network is connected.

add

   The Mobile Router before decapsulating
   the tunneled packet, has to check if the Source address on the outer
   IPv6 header is the Home Agent's address.  It also has to make sure
   the destination address on the inner IPv6 header belongs to one of
   its Mobile Network Prefixes before forwarding the packet to the
   Mobile Network.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 11 Jul 2003 12:37:14 -0700

to 

after 

   The Mobile Router

add

Vijay

---

From: Chan-Wah Ng <[email-masked]>
Date: 14 Jul 2003 00:00:36 +0800

> mobile network to the mobile router under all 

Looks okay to me.

>    the Binding Cache entry for the Mobile Router is deleted.
Sounds ok to me ... just one thing, perhaps the last sentence might be
changed to "This information can be later used ..." to suggest that this
is more of an implementation issue? Just a suggestion, the original
sentence is also alright to me.

>    its Mobile Network Prefixes before forwarding the packet to the
Sounds good.

Thanks for the effort.
/cwng

---

From: Chan-Wah Ng <[email-masked]>
Date: 14 Jul 2003 00:00:36 +0800

Looks okay to me.

Sounds good.

Thanks for the effort.
/cwng