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

[NJEDJOU Eric FTRD/DMR/REN <eric.njedjou@francetelecom.com>]

> -----Message d'origine-----
> De : owner-dna@ecselists.eng.monash.edu.au 
> [mailto:owner-dna@ecselists.eng.monash.edu.au] De la part de 
> James Kempf
> Envoyé : mardi 2 mars 2004 01:02
> Ŕ : Gregory Daley; NJEDJOU Eric FTRD/DMR/REN
> Cc : Pekka Nikander; Stefan Aust; basavaraj.patil@nokia.com; 
> Carmelita Görg; Niko A. Fikouras; Cornel Pampu; Dna; Greg 
> Daley; mip6@ietf.org
> Objet : Re: [Mip6] Re: RE : [DNA] Current IETF-Draft version 
> - POLIMAND
> 
> 
> 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. 

Well these protocols (CARD, CTP, FMIP, HMIP) could not and can not be ready for deployment as they essentially assume that IPv6, then Mobile IPv6 be deployed, at least partially, as the aforementionned protocols rely on IPv6 and mobile IPv6. Mobile IPv6 products are now coming out from vendors shelves. We can avoid to wait for (CARD, CTP, FMIP, HMIP) before providing optimisation for MIPv6 handover by bringing "simple" additions to the base specification that would already provide smoother handover as a sort of "work around". Then when we would get enough feedback from MIPv6 deployment issues we would be able to rethink at the way CARD,... Could be adapted. 


>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.
> 
It already the case, at least for ours.

>            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
> >
> 
>