Subject: RE: [netlmm] Re: [Mipshop] comments on Mobile IPv6 Fast Handovers over IEEE 802.16eNetworks draft

From: Gerardo Giaretta <[email-masked]>
Date: Fri, 15 Jul 2005 18:08:24 +0200

Hi James and Daniel,

one comment below..

> 
> (cc'ing to netlmm mailing list)
> 
> Daniel,
> 
> -----
> > I am CCing James and Phil as a chair of  *netlmm* BoF...
> >
> > >1. The draft is not talking about the network initiated L3 
> handover.
> > >
> > >    I think, it is possible in the following scenario
> > >
> > >a)      BS and AR are collocated (as in Figure 3), and
> > >
> > >b)      BS is sending MOB_BSHO-REQ
> > >
> > >
> > >Then AR can send PrRtAdv to MN, so that MN can start
> > >handoff immediately (with out exchanging RtSolPr, PrRtAdv).
> > >To accomplish this, a new trigger from L2 to L3 (similar to the
> > >three primitives namely Link_Going_Down, Link_Up and Link_Switch
> > >defined in the draft for interaction between FMIPv6 and 802.16e)
> > >in BS may be required.
> >
> > sounds interesting, but I am not sure it is in scope of FMIPv6
> > operation. Rather, it seems like network based mobility
> > support. During this meeting, *netlmm* BoF will be scheduled
> > to discuss network based localized mobility management,
> > and 802.16 will be presented at that time. If acceped, we will
> > be able to show this document...
> >
> > James, Phil, could you let us know your view on the above ?
> >
> >
> 
> I have not read this draft yet, I have a long plane ride 
> coming up next week
> when I'm intending to read it, so I'll refrain from making 
> any detailed
> comment on the technical content.
> 
> In general, my technical view (and it is just my personal 
> view, some others
> involved with NETLMM might not share it) is that NETLMM and FMIP have
> different roles. NETLMM is used for localized mobility 
> management within an
> lmm domain, and is responsible for taking care of updating 
> the routing on
> handover within the lmm domain. When moving between lmm 
> domains, however,
> MIP should be used to change the care of address and  FMIP 
> can be used to
> smooth handover. So I don't see any real conflict between the two.
> 

I agree with James (this is my personal view too).  

Depending on the scalability properties of NETLMM protocol, an edge
domain can be a hotspot or can be up to a wide part of the operator
network. So, depending on that, movements between edge domains can be a
rare or a frequent event but need to be handled. IMO, FMIP is needed to
handle seamless mobility for these movements.

--Gerardo

> If we manage to get a WG formed, I think one topic of 
> discussion might be
> how to handle transition between NETLMM domains, though I 
> don't see this as
> being necesarily part of the base protocol.
> 
> 
>             jak
> 
> 
> _______________________________________________
> netlmm mailing list
> [email-masked]
> https://vesuvio.ipv6.cselt.it/mailman/listinfo/netlmm
> 

Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia S.p.A.

====================================================================
CONFIDENTIALITY NOTICE
This message and its attachments are addressed solely to the persons
above and may contain confidential information. If you have received
the message in error, be informed that any use of the content hereof
is prohibited. Please return it immediately to the sender and delete
the message. Should you have any questions, please send an e_mail to 
[email-masked]. Thank you
====================================================================

_______________________________________________
Mipshop mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mipshop

---

From: Rajeev Koodli <[email-masked]>
Date: Fri, 15 Jul 2005 10:34:54 -0700

Hello folks,

I have not read the netlmm protocol :-)

>handle seamless mobility for these movements.
is there _any_ interaction between access routers in a "netlmm domain"?
For instance, to reduce  re-authentication latency? If so, setting up 
routing
between access routers is a minor incremental step.

And, security for signaling: I have two comments. First, when MN 
signaling is involved
(which is outside of the scope of netlmm I guess) - I believe this was 
mentioned in the
problem statement draft, if there is any access control at all (AAA, 
SEND?), the same
mechanism ca be re-used for securing any signaling between the MN and AR.

Second, when there is no MN signaling involved, and there is inter-AR 
communication,
security defaults to whatever is assumed between the routers.

-Rajeev

--Gerardo

---

From: "James Kempf" <[email-masked]>
Date: Fri, 15 Jul 2005 10:57:31 -0700

Rajeev,

> I have not read the netlmm protocol :-)

Not suprising, since there is no protocol document yet. :-) We so far have a
problem statement and requirements + gap analysis.

> between access routers is a minor incremental step.

I don't think interaction has been ruled out. For example, I've talked to
some people who are interested in context transfer for routing treatments
such as QoS, to speed getting the same routing properties up on the new AR
as on the old. And, with regard to re-authentication, I think that's a bit
of a tricky issue, because some link protocols do that at the link layer,
since the NAS is on the AP/BS. So specifying interaction for one wayt to do
that might be difficult.

However, in the architectural outline we've written into the charter, the
primary interface of interest is between the ARs and the mobility anchor.
That's where the primary protocol design task lies, I think.

> mechanism ca be re-used for securing any signaling between the MN and AR.

MN signaling that is explicitly involved in handover management is out of
scope, but, like I said in an earlier email, opinions vary about what amount
of signaling is necessary for movement detection (aka network attachment
detection). Security on network attachment and movement detection should be
whatever the underlying protocol uses, i.e. if it is an L2 mechanism, then
whatever is provided by that, if it is something like DNA, then SEND, etc.

> security defaults to whatever is assumed between the routers.

Yes, that sound right.

            jak

---

From: Rajeev Koodli <[email-masked]>
Date: Fri, 15 Jul 2005 11:12:45 -0700

> since the NAS is on the AP/BS. So specifying interaction for one wayt to do

Ok. QoS is good enough. I only used re-auth as an example.

> That's where the primary protocol design task lies, I think.

You would not disallow route set up between access routers, right?

> whatever is provided by that, if it is something like DNA, then SEND, etc.

IMO, the distinction between L3 network attachment detection (NAD) and
handover signaling is very blurry. For instance FNA in FMIP is a form
of NAD hook.
If you are restricting the scope to L2, that should be made explicit.

-Rajeev

---

From: "James Kempf" <[email-masked]>
Date: Fri, 15 Jul 2005 11:34:52 -0700

> You would not disallow route set up between access routers, right?

The basic idea is to limit the number of routers that need to deal with
disaggregated routes. In a mobility anchor-type solution, only the mobility
anchor and the access routers need to do this. The access routers do it
because they disaggregate routes anyway, to do last hop routing inbound. The
mobility anchors disaggregate to find the right AR, then reaggregate into
the tunnel.

If what you mean is whether the ARs can disaggregate and do host routing
outbound on handover, essentially like FMIP does, it's possible that it
might be helpful in some lmm domain topologies, but I think it needs to be
carefully examined. For example, for an lmm topology where the mobility
anchor is the aggregation router and signaling times between the mobility
anchor and ARs is short, it might make more sense to have a short, sliding
buffer on the mobility anchor (like Charlie P's work with regional
registration and forwarding from previous care of address in MIPv4 some
years back) and just send buffered packets to the new AR. This avoids the
dogleg route from the mobility anchor to the AR and back. On mesh
topologies, however, it might make more sense to set up host routes on
handover. It's something that the WG will need to discuss as part of the
protocol design.

> If you are restricting the scope to L2, that should be made explicit.

What is the relation between FNA and DNA? If a MN supports DNA, does it need
to do FNA as well?

            jak

---

From: Rajeev Koodli <[email-masked]>
Date: Fri, 15 Jul 2005 14:19:55 -0700

James Kempf wrote:

> This avoids the

Still trying to catch up with the terminology.. Sounds like the issue
(dogleg routing) is topology-specific. And, Mesh can work with host 
routes on the access link only (i.e., FA-CoA operation). So, access 
routers do not need per-CoA tunnel, but a pre-set tunnel between them 
can be used during handover (and the MN keeps the same CoA).
BTW, FMIPv4 looked into this, where the tunnel end point is always
the NAR/NFA.

> What is the relation between FNA and DNA? If a MN supports DNA, does it need

We only need an unsolicited announcement to NAR in FMIP, nothing else.

-Rajeev

---

From: "James Kempf" <[email-masked]>
Date: Fri, 15 Jul 2005 14:39:37 -0700

> BTW, FMIPv4 looked into this, where the tunnel end point is always

Yes, a pre-set tunnel can be used between the AR and mobility anchor as
well. In general, I would expect that an operator would want to integrate
NETLMM into their traffic management scheme for the lmm domain.

> We only need an unsolicited announcement to NAR in FMIP, nothing else.

DNA delivers the new subnet information to the MN and provides fast movement
detection, unless the link layer has some specialized support (like it
delivers the nAR link address and prefixes to the MN) or the host has some
prehandover information (like the MN has done PrxyRtXXX or CARD and knows
whether the AP/BS is in a new subnet, what the nAR link address is, and what
the new prefixes are).

Once the DNA RA comes back, the MN knows that it is on a new subnet and can
configure a new address, then do the FBU using oDAD for the src addr and the
pAR for dest addr, it need not even go through nAR except to route.

Even if DNA isn't used, the MN can use oDAD for the src addr and the pAR for
the dest addr. In this case, the MN would have had to configure the new CoA
using prehandover prefix information or prefix information derived from the
specialized link support.

So, I wonder, is FNA really needed anymore for FMIP? Seems like it could
really simplify the protocol to have it concentrate on FBU.

            jak

---

From: Rajeev Koodli <[email-masked]>
Date: Fri, 15 Jul 2005 15:35:08 -0700

> specialized link support.

I think we are digressing from the main thread..

FYI: there is a draft specifying FMIP and DNA interaction that should
appear soon.

draft-koodli-dna-fmip-00.txt

A protocol (FMIP) should be able to work on its own, while also being 
able to work well when some other protocol is available.

The FBU can be constructed as above. But we still need a way to inform
NAR to flush the buffer.

> really simplify the protocol to have it concentrate on FBU.

See above. In cases where we can assume that an announcement that makes
the NAR's ND state REACHABLE (for NCoA) is available, we can make do 
without it.

-Rajeev

---

From: "James Kempf" <[email-masked]>
Date: Fri, 15 Jul 2005 15:40:56 -0700

Great, I'll wait for the draft! Thanx.

            jak

----- Original Message -----
From: "Rajeev Koodli" <[email-masked]>
To: "James Kempf" <[email-masked]>
Cc: "Gerardo Giaretta" <[email-masked]>;
<[email-masked]>; <[email-masked]>; "Heejin Jang"
<[email-masked]>; <[email-masked]>
Sent: Friday, July 15, 2005 3:35 PM
Subject: Re: Interaction between ARs in lmm domain (was Re: [netlmm] Re:
[Mipshop] comments on Mobile IPv6 Fast Handovers over IEEE 802.16eNetworks
draft)