Actually, IETF standards are protocol standards. They never
specify
implementation. Implementors need to be free to innovate.
So if there are no protocol interoperability issues, there
is no need for a
goal.
jak
----- Original Message -----
From: "Narayanan, Vidya" <vidyan qualcomm.com>
To: "Genadi Velev" <Genadi.Veleveu.panasonic.com>; "James Kempf"
<kempfdocomolabs-usa.com>; <netlmmngnet.it>
Cc: "Kent Leung (kleung)" <kleungcisco.com>
Sent: Tuesday, May 16, 2006 7:08 PM
Subject: RE: [netlmm] Conclusion of discussion on Issue #44:
Add goal to
support make before break handover
Hi Genadi, Kent,
Your understanding is correct that we are not talking about
the multiple
downstream paths to the ARs and only referring to the
upstream paths
towards the LMA.
While it is an implementation issue, it still needs to be
specified in
the standard for interoperable impelmentation.
Thanks,
Vidya
> -----Original Message-----
> From: netlmm-adminngnet.it [mailto:netlmm-adminngnet.it]
On
> Behalf Of Genadi Velev
> Sent: Tuesday, May 16, 2006 8:56 AM
> To: Narayanan, Vidya; James Kempf; netlmmngnet.it
> Cc: Kent Leung (kleung)
> Subject: RE: [netlmm] Conclusion of discussion on Issue
#44:
> Add goal to support make before break handover
>
> James, Vidya, all,
>
> if the question is: does the LMA need to maintain the
> reception of MN's uplink packets coming from old and
new ARs
> simultaneously for a short period during handover, then
I
> agree with this. I also agree with Kent that this is an
> implementation issue for the LMA. I think there should
be no
> impact on the NETLMM protocol.
>
> The reason to agree on this is that the following
situation
> might be possible even if L2 performs hard handover:
since
> the signalling packets normally have higher priority
than
> data packets, the update NETLMM signalling message
(sent by
> new/old AR) may arrive at LMA before MN's uplink data
> packet(s) from old AR.
>
> However, the Issue #44 ("Add goal to support make
before break
> handover") describes more general problem and
needs a few
> more considerations especially for the downlink
traffic. I
> would abstain to include this general issue as a goal
in the
> *basic* protocol design in order to fulfill the WG
schedule,
> but rather to resume on it again when we come to work
on
> NETLMM protocol extensions.
>
> Just my 2 pence on this,
> Genadi
>
>
>
> > -----Original Message-----
> > From: netlmm-adminngnet.it
[mailto:netlmm-adminngnet.it]
> On Behalf
> > Of Kent Leung (kleung)
> > Sent: Tuesday, May 16, 2006 1:26 AM
> > To: Narayanan, Vidya; James Kempf; netlmmngnet.it
> > Subject: RE: [netlmm] Conclusion of discussion on
Issue #44:
> > Add goal to support make before break handover
> >
> > Hi James/Vidya. This is my understanding of the
issue based on
> > reading a few exchanges. In general, I agree with
Vidya and Pete.
> >
> > There is a request for MAP to maintain a brief
lingering binding to
> > receive packets (which may be in transit during
handover) from
> > previous AR. This is only for reverse traffic
from the MN.
> Actually,
> > I think this topic is an implementation issue that
reduces upstream
> > packet loss during handover. Generally, a good
feature to have and
> > "can be done" on the MAP. Not sure if
it is mandatory or
> optional.
> > BTW, the idea applies to MIP HA.
> >
> > I believe we are not talking about multiple
downstream paths to
> > different ARs. So the request is not for
simultaneous bindings for
> > traffic between ARs and MAP for duration of the
session.
> >
> > This sounds reasonable to me. BTW, sorry for
jumping in late.
> > Thought this would have worked itself out. 
> >
> > Kent
> >
> > _______________________________________________
> > netlmm mailing list
> > netlmmngnet.it
> > https://vesuvio.ipv6.cselt.it/mailman/listinfo/netlmm
> >
> >
>
>
> _______________________________________________
> netlmm mailing list
> netlmmngnet.it
> https://vesuvio.ipv6.cselt.it/mailman/listinfo/netlmm
>
_______________________________________________
netlmm mailing list
netlmmngnet.it
https://vesuvio.ipv6.cselt.it/mailman/listinfo/netlmm
|