Re: [Mip6] Re: RE : [DNA] Current IETF-Draft version - POLIMAND

[James Kempf <kempf@docomolabs-usa.com>]

I hesitate to even bring this up, but there's a long history in the IETF
of
trying to figure out where to do this kind of work. We've been working
on
multiple interface (vertical) handover, handover optimization, and such
in
MIP and Seamoby for over three years. There are some experimental
protocols
(CARD, CTP, FMIP, HMIP) approaching publication, but they still need a
lot
of work before they are ready for deployment. The effort has been
hampered
by a lack of impending product or deployment pressure. IETF does not
function well when a particular technology does not have a group of
vendors
and network operators behind it who need interoperability for their
product
or deployment, and that has been the case for this particular
technology.

The result is that the work has been moved to the IRTF MOBOPTS research
group, and I would advise that any proposals be taken there.

           jak

----- Original Message ----- 
From: "Gregory Daley" <Greg.Daley@eng.monash.edu.au>
To: "NJEDJOU Eric FTRD/DMR/REN" <eric.njedjou@francetelecom.com>
Cc: "Pekka Nikander" <pekka.nikander@nomadiclab.com>; "Stefan Aust"
<aust@comnets.uni-bremen.de>; <basavaraj.patil@nokia.com>; "Carmelita
Görg"
<cg@comnets.uni-bremen.de>; "Niko A. Fikouras"
<niko@comnets.uni-bremen.de>;
"Cornel Pampu" <cornel.pampu@siemens.com>; "Dna"
<dna@eng.monash.edu.au>;
"Greg Daley" <greg.daley@eng.monash.edu.au>; <mip6@ietf.org>
Sent: Monday, March 01, 2004 7:19 AM
Subject: [Mip6] Re: RE : [DNA] Current IETF-Draft version - POLIMAND


> Hi,
>
> I know that this has been cross posted, so I'll
> respond to both lists, but perhaps we can talk about
> specific issues in the individual mailing lists
> subsequently.  I'd suggest DNA, unless the MIP6
> chairs wish to respond.
>
> If we need to discuss needs more generally for
> multiple interface configuration procedures or
> vertical handoff, it may be useful to take it up
> with the chairs of either or both WGs (depending
> on the circumstances).
>
> Please see my take below.
> ----- Original Message -----
> From: NJEDJOU Eric FTRD/DMR/REN <eric.njedjou@francetelecom.com>
> Date: Monday, March 1, 2004 9:51 pm
> Subject: RE : [DNA] Current IETF-Draft version - POLIMAND
>
> > Pekka,
> > The problem with MIP6 movement detection handover optimizations
> > (see http://www.ietf.ord/I-D/draft-daniel-mip6-optimized-vertical-
> > handover-00.txt for another draft) is that it is being considered
> > out of scope for DNA because of the mobile IPv6 issue raised and
> > out of scope for MIP6 because of the link triggers that has to be
> > taken into account. Actually, it is within the scope of both as
>
> I'd guess while this is frustrating, it's largely a statement
> of fact.
>
> Please inform me of any incorrect statements I make, since
> there may be subtlties I miss in the drafts.
>
> While the drafts being discussed are principally interested in
> handling multiple connectivity scenarios associated with
> wireless networks, neither MIPv6 (regarding Link hints) or
> DNA (Discussing global signalling) are currently chartered to
> work on these topics.
>
> It is indeed possible that the combination of the techniques
> is seen as the stumbling block by both groups.
>
> For example, if indeed it is necessary to provide vertical
> handover support for MIPv6, is it strictly necessary to talk
> about link layer interactions (polimand may talk about policy instead,
> Of course, it is always hard to standardize policy).
>
> Whether a document looking at multiple interface connectivity
> for MIPv6 would be useful or not (or whether there's much difference
> except the movement detection algorithm) I don't know.
>
> Particularly for DNA, we can't really discuss handovers,
> considering that this term principally refers to session
> restoration or continuation using mobility protocols.
>
> DNA is looking basically at signalling using mechanisms
> within the local link only.  Any reference to other
> protocols (except in a confined way) can make documents
> look like they're (for example) MIP specific.
>
> If there's a difference in the configuration detection
> procedures when a host has multiple interfaces, that may be
> different.
>
> For example, a host may wish to wait passively for router
> advertisements on the GPRS interface (testing reachability
> when the host switches connections to that interface), and
> probes fairly aggressively on a WLAN interface.
>
> Any decision or action based on this the configuration detection
> is starting to push into uncomfortable areas as far as DNA's tight
> charter  is concerned.  Perhaps this is analogous to the reasoning
> used in MIP6?
>
> > DNA -link triggers/hints that will be catalogued/standardized
> > within DNA will also be used for Mobile IPv6 optimised movement
> > detection. Other ones may be needed for this specific purpose.
> > Better detecting network attchment/detachment is a requirement for
> > Mobile IPv6 better performance movement detection and handover.
> > These issues are therefore strongly linked.
>
> I think we have to be particularly careful about the word
> standardized in the previous paragraph.
> There's already been some out-of-band feedback to DNA that we
> should avoid delving into standardization of L2 oriented
> mechanisms.
>
> > MIP6 -Optimized movement detection an handover schemes are
> > essenttial for base Mobile IPv6 Operation, which means, the
> > protocol operation needs exploiting L2 triggers/hints. And  MIPv6
> > implementors use L2 triggers/hints in a confusing way, if not at
all.
>
> While the usage of hints may be unavoidable in some DNA schemes,
> there will still be some systems where it is not possible to
> the the kind of hints you desire.  It would be short-sighted to
> design systems which only work if information from the link-layer
> is reliable and available.
>
> > We could be ping-ponging betwwen these two groups for years.
>
> I really hope not, but MOBOPTS isn't necessarily a place for
> killing ideas off to (no matter what some people say!).
> Our research team has (voluntarily!) submitted some ideas there
> for further discussion recently and gotten useful feedback.
>
> I don't even mind if people winnow their existing work down to
> a problem statement which is DNA centric.
> It may be that there's a chance that we'd think it out-of-scope
> anyway, but that's because the WG scope is very narrow.
>
> If the work is clear input into one of the documents on the DNA
> charter, that may change things.
>
> We're only likely to produce 4 documents this year (optimistically).
> so focussing on how the vertical handover/polimand work can
> directly help those is more immediately useful.
>
> As Pekka said, this may mean leaving MIPv6 specific parts to
> MIP6WG or MOBOPTS.
>
> Greg
>
>
> _______________________________________________
> Mip6 mailing list
> Mip6@ietf.org
> https://www.ietf.org/mailman/listinfo/mip6
>