>
> James Kempf wrote:
> > If the AR uses a default route, it can simply
forward the
> packets to
> > the LMA as the default router. The AR can also use
tunnels
> of various
> > types configured as the default route. So the LMA
doesn't
> really have
> > to remember the AR, the routing within the LM
domain needs
> to be set
> > up with the LMA as the default router for the ARs.
Packets
> coming in
> > from the wireless interface are forwarded back
through the
> default route.
>
> this assume that the ARs are connected to the LMA
directly.
> IMHO, a wrong assumption to make.
>
Fully agree. Making such assumptions will make it very tough
for the protocol to be adopted for real deployment.
Vidya
> Vijay
>
> >
> > jak
> >
> >
> > ----- Original Message ----- From:
"Narayanan, Vidya"
> > <vidyan qualcomm.com>
> > To: "James Kempf" <kempfdocomolabs-usa.com>; "Pete McCann"
> > <mccaplucent.com>
> > Cc: "Von-Hugo, Dirk" <Dirk.Hugot-systems.com>;
> > <alexandru.petrescumotorola.com>;
<wanghuiresearch.nec.com.cn>;
> > <netlmmngnet.it>
> > Sent: Friday, May 12, 2006 2:13 PM
> > Subject: RE: Make-before-break Background (was RE:
AW:
> [netlmm] Issue
> > #44: Add goal to support make before break
handover)
> >
> >
> > Ok. In the direction of AR to LMA, this can be
allowed by the LMA
> > simply remembering the old AR (by the MPLS label
or IP address) to
> > accept packets from it. For routing purposes
itself, it may
> only point
> > to the new AR.
> >
> > Does that make sense?
> >
> > Vidya
> >
> >> -----Original Message-----
> >> From: James Kempf [mailto:kempfdocomolabs-usa.com]
> >> Sent: Friday, May 12, 2006 1:35 PM
> >> To: Narayanan, Vidya; Pete McCann
> >> Cc: Von-Hugo, Dirk; alexandru.petrescumotorola.com;
> >> wanghuiresearch.nec.com.cn; netlmmngnet.it
> >> Subject: Re: Make-before-break Background (was
RE: AW:
> >> [netlmm] Issue #44: Add goal to support make
before break handover)
> >>
> >> Right, but that doesn't mean that the two
routes need to
> be installed
> >> on the LMA.
> >>
> >> jak
> >>
> >> ----- Original Message -----
> >> From: "Narayanan, Vidya"
<vidyanqualcomm.com>
> >> To: "Pete McCann" <mccaplucent.com>; "James Kempf"
> >> <kempfdocomolabs-usa.com>
> >> Cc: "Von-Hugo, Dirk"
<Dirk.Hugot-systems.com>;
> >> <alexandru.petrescumotorola.com>;
> >> <wanghuiresearch.nec.com.cn>;
<netlmmngnet.it>
> >> Sent: Friday, May 12, 2006 1:30 PM
> >> Subject: RE: Make-before-break Background (was
RE: AW:
> >> [netlmm] Issue #44:
> >> Add goal to support make before break
handover)
> >>
> >>
> >> Pete's description is exactly right. The
whole idea is to allow
> >> reception of packets corresponding to the MN
from two different
> >> routes for a short period of time.
> >>
> >> Vidya
> >>
> >> > -----Original Message-----
> >> > From: Pete McCann [mailto:mccaplucent.com]
> >> > Sent: Friday, May 12, 2006 12:40 PM
> >> > To: James Kempf
> >> > Cc: Narayanan, Vidya; Von-Hugo, Dirk;
> >> > alexandru.petrescumotorola.com; wanghuiresearch.nec.com.cn;
> >> > netlmmngnet.it
> >> > Subject: Re: Make-before-break Background
(was RE: AW:
> >> > [netlmm] Issue #44: Add goal to support
make before
> break handover)
> >> >
> >> > Hi, James,
> >> >
> >> > Maybe what is needed isn't the use of
multiple routes at
> the LMA in
> >> > the forward direction, but just the
ability to receive
> >> packets on the
> >> > old route for a short period of time
after the new route is
> >> installed.
> >> > You can imagine implementing a short
"hang time"
> >> > for the old route before packets from the
MN to the LMA
> are dropped.
> >> >
> >> > My understanding of the EVDO multi-route
capability is
> that the MS
> >> > uses the old route until it receives the
first packet on the new
> >> > route, at which point it switches over to
sending on the
> >> new route as
> >> > well. Thus, there isn't a need for
special drivers to
> access the
> >> > multi-route feature, it just happens as a
natural result of
> >> following
> >> > the network-directed handoff. If you
picture the
> situation you can
> >> > see that there is a race condition
between the arrival of the
> >> > registration message on the LMA and the
arrival of packets
> >> on the old
> >> > route. This is especially true if the MS
continues to
> use the old
> >> > route until positive acknowledgment
(receipt of
> >> > packets) is received on the new route.
> >> >
> >> > -Pete
> >> >
> >> > James Kempf wrote:
> >> > > NETLMM is only analgous to MIPv4 if
you accept that
> tunnels will
> >> > > always involve an IP address as an
endpoint.
> >> > >
> >> > > Suppose that the LMA is configured
to use MPLS tunnels.
> >> The routing
> >> > > then consists of mapping the mobile
node's address to an
> >> > LSP. Then the
> >> > > packet is forwarded through the LSP
to the other
> >> endpoint. If there
> >> > > are two possible routes for one
mobile node address, as
> >> is the case
> >> > > with multiple bindings, then there
needs to be some
> >> distinguishing
> >> > > characteristic in the packet by
which the LSA can
> determine which
> >> > > forwarding path to use, for example,
the DSCP. The
> mobile node's
> >> > > address is not a distinguishing
characteristic, because it
> >> > will be the
> >> > > same in every packet. The key issue
here is that MPLS
> >> separates out
> >> > > routing from forwarding at the LMA*.
> >> > >
> >> > > Also, I looked at Section 5.3.2 and
5.4.1 of
> >> > draft-vidya-netlmm-netmob.
> >> > > Neither of these sections provides
any guidance about
> how the LMA
> >> > > should route incoming packets when
there are two routes for
> >> > the same
> >> > > unicast address.
> >> > >
> >> > > In your description below, you say
that "it is not the same
> >> > IP address
> >> > > that is routed along different
paths". My original point
> >> > was that if
> >> > > there are paths from the LMA to
different ARs for one
> >> *mobile node*
> >> > > address in the LMA, then there will
be two routes. You then
> >> > say that
> >> > > "by default, it (the LMA)
should tunnel that packet to
> the new AR
> >> > > unless specific bi-casting is
requested". So this then
> >> seems to be
> >> > > your criterion by which the LMA
decides which path to use:
> >> > use the new
> >> > > AR path unless bicast is in force. I
find this particular
> >> decision
> >> > > criterion technically questionable,
and I have never seen much
> >> > > technical merit in bicasting, due to
negative interaction with
> >> > > transport protocols (it really only
works well if you
> >> > assume that an
> >> > > IPR-ed version of TCP, Eiffel if I
recall correctly,
> will become
> >> > > widely used). In addition, as far as
I know, most traffic
> >> > engineering
> >> > > schemes don't have such criteria as
"new AR v.s. old
> AR". They're
> >> > > concerned with other critera, such
as available
> >> bandwidth, latency,
> >> > > and such. So this would require some
major changes in the
> >> > way wireless ISPs do traffic engineering.
> >> > >
> >> > > However, I have some additional
problems with this proposal.
> >> > >
> >> > > 1) It is very L2 specific. As has
been pointed out,
> the charter
> >> > > specifically rules out design
features in the protocol
> >> that support
> >> > > particular L2s. Near as I can
determine, the only widely
> >> > used protocol
> >> > > which has MBB handover is EV-DO.
Even with EV-DO, my
> >> > understanding is
> >> > > that MBB handover is only supported
on the downlink.
> >> > > 2) I don't even think this feature
would be used with a
> >> > protocol that
> >> > > does supports MBB hanodver. Here's
why. Suppose we don't
> >> > have multiple
> >> > > routes and the new AR sends the
route update to the LMA
> >> > (I'm making an
> >> > > assumption about this, the old AR
might do it instead,
> >> depending on
> >> > > what the DT decides, but if so, the
case becomes even
> >> > easier). In that
> >> > > case, there will be some latency,
equivalent to 1/2*RTT
> >> between the
> >> > > new AR and the LMA during which the
LMA will continue
> to forward
> >> > > packets to the old AR while the
mobile node is *also*
> >> > reachable via L2
> >> > > on the new AR (it is reachable on
both because we have
> >> assumed MBB
> >> > > handover). These packets will be
delivered to the MN
> without any
> >> > > problem because of the backward
handover leg, with no
> >> > involvement by the LMA because they are
in flight.
> >> > > Meanwhile, the LMA gets the route
update and modifies the
> >> > route to the
> >> > > new AR. Incoming packets are now
forwarded to the new AR
> >> > which sends
> >> > > them to the mobile node. Multiple
routes at the LMA
> are therefore
> >> > > unnecessary for incoming packets. On
the mobile node side,
> >> > the mobile
> >> > > node can send packets through the
new AR because the new AR
> >> > will have
> >> > > the route for the mobile node's
address. It could also
> >> potentially
> >> > > send packets through the old AR on
the backward leg
> >> (supposing that
> >> > > MBB handover is even available for
the mobile node to
> >> send packets
> >> > > uplink), if the L2 driver on the
mobile node provides some
> >> > way to cut
> >> > > over when the backward leg is no
longer usable. This could be
> >> > > supported if the old AR tells the
mobile node's driver (at
> >> > L2) that it
> >> > > is shutting down the backward leg
when the LMA tells the
> >> old AR to
> >> > > delete the route for the mobile
node's address. Multiple
> >> > routes at the
> >> > > LMA are therefore unnecessary for
outgoing packets.
> >> > >
> >> > > In summary, there really is no need
for having two routes
> >> > at the LMA
> >> > > for the mobile node's address on
the downlink even with MBB
> >> > handover.
> >> > > For routing from the mobile node to
the LMA, there is also
> >> > no need for
> >> > > having two routes at the LMA. L2
support is required in
> >> the mobile
> >> > > node's driver (which is an L2
specific piece of code,
> not an IP
> >> > > specific
> >> > > piece) if the mobile node wants to
send packets via the
> >> old AR, in
> >> > > order for the mobile node's driver
to know when to cut over
> >> > to the the
> >> > > new AR, but that is an L2 specific
feature, which some
> >> > others have pointed out.
> >> > >
> >> > > jak
> >> > >
> >> > > *Suggested reading material:
> >> > >
> >> > > "MPLS and VPN
Architectures" by Ivan Pepelnjak and Jim
> >> > Guichard. This
> >> > > is from Ciscopress. It is a little
heavy on CLI
> printouts but it
> >> > > provides a good description about
how routing and
> forwarding is
> >> > > separated in MPLS networks and how
to use this for traffic
> >> > engineering.
> >> > >
> >> > > ----- Original Message ----- From:
"Narayanan, Vidya"
> >> > > <vidyanqualcomm.com>
> >> > > To: "James Kempf"
<kempfdocomolabs-usa.com>; "Von-Hugo, Dirk"
> >> > > <Dirk.Hugot-systems.com>;
<alexandru.petrescumotorola.com>
> >> > > Cc: <wanghuiresearch.nec.com.cn>; <netlmmngnet.it>
> >> > > Sent: Thursday, May 11, 2006 7:01 PM
> >> > > Subject: RE: Make-before-break
Background (was RE: AW:
> >> > [netlmm] Issue
> >> > > #44: Add goal to support make before
break handover)
> >> > >
> >> > >
> >> > >
> >> > > Hi James,
> >> > > The operation here is identical to
the way MIP4 works - the
> >> > MN has one
> >> > > IP address in the NETLMM domain
(analogous to the home
> >> address); it
> >> > > has reachability to two different
ARs (analogous to two foreign
> >> > > agents) - when the LMA receives a
packet for an MN, it needs to
> >> > > *tunnel* it to one AR or the other -
so, it is not the same
> >> > IP address
> >> > > that is routed along different
paths; the tunnel endpoint
> >> is the AR
> >> > > and it will be routed to the
appropriate AR by the routing
> >> > topology.
> >> > > By default, it should tunnel that
packet to the new AR
> >> > unless specific bi-casting is requested.
> >> > > However, when the MN sends a packet
out, either AR will
> >> > forward it to
> >> > > the LMA and the LMA must accept it.
> >> > >
> >> > > Please see sections 5.3.2. and
5.4.1. in
> >> > draft-vidya-netlmm-netmob-00
> >> > > for further details on how this
would work.
> >> > >
> >> > > So, there is no ambiguity in either
direction - this has
> >> > nothing to do
> >> > > with the MN not having multiple IP
addresses - simultaneous
> >> > bindings
> >> > > in
> >> > > MIPv4 works just fine in FA CoA mode
and there is a
> very strong
> >> > > analogy here.
> >> > >
> >> > > Regards,
> >> > > Vidya
> >> > >
> >> > >> -----Original Message-----
> >> > >> From: netlmm-adminngnet.it
[mailto:netlmm-adminngnet.it]
> >> > On Behalf
> >> > >> Of James Kempf
> >> > >> Sent: Thursday, May 11, 2006
6:24 PM
> >> > >> To: Narayanan, Vidya; Von-Hugo,
Dirk;
> >> > alexandru.petrescumotorola.com
> >> > >> Cc: wanghuiresearch.nec.com.cn; netlmmngnet.it
> >> > >> Subject: Re: Make-before-break
Background (was RE: AW:
> >> > >> [netlmm] Issue #44: Add goal to
support make before
> >> break handover)
> >> > >>
> >> > >> I have a somewhat different
perspective on this. Let me
> >> > take off my
> >> > >> editor and WG chair hats and put
on my technical
> contributor hat.
> >> > >>
> >> > >> Suppose there are two routes
(note the use of the word
> >> > "routes" here,
> >> > >> not
> >> > >> bindings) registered at the LMA
for a particular MN. What
> >> > does this
> >> > >> mean?
> >> > >>
> >> > >> Well, there is only one address
in NETLMM, say the MN's
> >> > address is A.
> >> > >> It is not like MIP where there
are different CoAs on
> >> both routers.
> >> > >> That means that one IP address
can be routed to two different
> >> > >> routers.
> >> > >>
> >> > >> A packet comes into the LMA for
address A. How shall the
> >> > LMA decide
> >> > >> which router to send the packet
to? Flip a coin?
> >> > >>
> >> > >> In summary, I cannot see how
this could possibly work.
> >> > >>
> >> > >> jak
> >> > >>
> >> > >>
> >> > >> ----- Original Message -----
> >> > >> From: "Narayanan,
Vidya" <vidyanqualcomm.com>
> >> > >> To: "Von-Hugo, Dirk"
<Dirk.Hugot-systems.com>;
> >> > >> <alexandru.petrescumotorola.com>
> >> > >> Cc: <wanghuiresearch.nec.com.cn>;
> <kempfdocomolabs-usa.com>;
> >> > >> <netlmmngnet.it>
> >> > >> Sent: Wednesday, May 10, 2006
3:53 PM
> >> > >> Subject: Make-before-break
Background (was RE: AW: [netlmm]
> >> > >> Issue
> >> > >> #44: Add goal to support make
before break handover)
> >> > >>
> >> > >>
> >> > >>
> >> > >> Folks,
> >> > >> Here is some background that
will help understand the
> need for
> >> > >> make-before-break support in the
NETLMM protocol.
> >> > >>
> >> > >> Make-before-break at L2 happens
below IP. However, the MAP
> >> > (or HA in
> >> > >> the case of MIP) needs to be
able to continue to receive
> >> > packets from
> >> > >> the old and new points of
attachment (or CoA in MIP) at
> >> > the IP level,
> >> > >> for which multiple bindings are
required. Note that this
> >> > is different
> >> > >> from bi-casting - there is no
need to send duplicate
> >> packets down
> >> > >> multiple interfaces (that could
be an option, but
> certainly not
> >> > >> required).
> >> > >>
> >> > >> As an example, EV-DO works this
way - for a period of
> time, the
> >> > >> mobile is attached to both the
old and new BS (base
> >> > >> station) and it may send packets
to either one. When the
> >> > BS passes it
> >> > >> up to the corresponding ARs, in
the case of NETLMM, the
> >> > MAP must be
> >> > >> able to accept packets from
either AR. If multiple
> >> > bindings are not
> >> > >> supported, the new binding will
replace the old one and
> >> > the MAP would
> >> > >> have to throw away packets
related to the MS coming from
> >> > the old AR.
> >> > >> This is true for MIP as well -
MIP6 would have done much
> >> better to
> >> > >> have included this in the base
protocol itself; however,
> >> there is
> >> > >> work underway in Monami6 to
provide this functionality in
> >> > MIP6. It is
> >> > >> quite trivial to support the
basic functionality for this
> >> > and it is
> >> > >> very critical for certain L2s.
> >> > >>
> >> > >> In a nutshell, the MAP should be
able to store multiple
> >> > bindings for
> >> > >> an MN and accept packets from
all active bindings at a
> >> > given point of
> >> > >> time - it may be for ingress
filtering purposes or
> other policy
> >> > >> reasons. As for packet
duplication, it may not be
> >> important at the
> >> > >> moment (when we get into
multi-homing and flow
> >> > steering/control, it
> >> > >> may become important) - packet
duplication can
> potentially be an
> >> > >> option, but certainly should not
be mandatory. The default
> >> > behavior
> >> > >> would just be that the MAP will
accept packets from
> all active
> >> > >> bindings and the old binding
will be kept active for
> >> some default
> >> > >> time (say, 3 seconds). This is
the bare minimum needed
> >> to support
> >> > >> make-before-break.
> >> > >>
> >> > >> Hope this helps.
> >> > >>
> >> > >> Regards,
> >> > >> Vidya
> >> > >>
> >> > >>
> >> > >> > -----Original Message-----
> >> > >> > From: Von-Hugo, Dirk
[mailto irk.Hugo
t-systems.com]
> >> > >> > Sent: Wednesday, May 10,
2006 6:19 AM
> >> > >> > To: alexandru.petrescumotorola.com
> >> > >> > Cc: Narayanan, Vidya;
wanghuiresearch.nec.com.cn;
> >> > >> > kempfdocomolabs-usa.com;
netlmmngnet.it
> >> > >> > Subject: AW: AW: [netlmm]
Issue #44: Add goal to support
> >> > >> make before
> >> > >> > break han dover
> >> > >> >
> >> > >> > Hi,
> >> > >> > 802.16e in IEEE Std
802.16e-2005 defines a
> >> > >> make-before-break HO as a
> >> > >> > HO where service with the
target BS starts before
> >> > >> disconnection of the
> >> > >> > service with the previous
serving BS.
> >> > >> > In this standard different
HO options are specified
> >> > including macro
> >> > >> > diversity handover (MDHO)
which should allow for the
> >> > >> make-before-break
> >> > >> > feature as during HO in the
downlink two or more BSs are
> >> > >> transmitting
> >> > >> > the same MAC/PHY protocol
data unit
> >> > >> > (PDU) and in the uplink
(UL) two or more BSs are
> >> > receiving the same
> >> > >> > PDU from the MS, such that
diversity combining of the
> >> > >> received PDU can
> >> > >> > be performed as well at the
MS as among the BSs.
> >> > >> > W-CDMA in 3GPP also enables
similarly Soft HO such
> that these
> >> > >> > technologies should support
Make Before Break.
> >> > >> >
> >> > >> > With regard to Seamlessness
you are right, I just
> looked for a
> >> > >> > mnemonic letter as M is
already occupied ... 
> >> > >> >
> >> > >> > Regards
> >> > >> > Dirk
> >> > >> >
> >> > >> > -----Ursprüngliche
Nachricht-----
> >> > >> > Von: Alexandru Petrescu
> >> [mailto:alexandru.petrescumotorola.com]
> >> > >> > Gesendet: Mittwoch, 10. Mai
2006 13:53
> >> > >> > An: von-Hugo, Dirk
> >> > >> > Cc: vidyanqualcomm.com; wanghuiresearch.nec.com.cn;
> >> > >> > kempfdocomolabs-usa.com;
netlmmngnet.it
> >> > >> > Betreff: Re: AW: [netlmm]
Issue #44: Add goal to support
> >> > >> make before
> >> > >> > break han dover
> >> > >> >
> >> > >> > Von-Hugo, Dirk wrote:
> >> > >> > >
> >> > >> > > Dear all, I also would
appreciate to have the optional
> >> > >> > support of MBB
> >> > >> > > HO within NETLMM
goals.
> >> > >> >
> >> > >> > Is MBB make-before-break?
What wireless
> technologies do MBB?
> >> > >> > 802.11 type don't.
802.11 scans channels and during
> >> > this scan it
> >> > >> > can't receive anything.
> >> > >> >
> >> > >> > MBB may happen when two
802.11 interfaces of same mobile.
> >> > >> > While one interface is
scanning the other one transmits app
> >> > >> data. Is
> >> > >> > this the kind of MBB?
> >> > >> >
> >> > >> > MIMO (multiple-input
multiple-output) or 802.11n has
> >> > >> multiple antennas
> >> > >> > but for the goal of
enhancing bandwidth and from a
> >> > longer distance
> >> > >> > from AP. MIMO happens at
PHY layer.
> >> > >> >
> >> > >> > What's more exactly MBB?
> >> > >> >
> >> > >> > > Perhaps one could even
state that the protocol should
> >> > as far as
> >> > >> > > possible exploit
capabilities and performance improvement
> >> > >> > > feasibilities of
underlying L2 technology.
> >> > >> >
> >> > >> > I agree with this.
> >> > >> >
> >> > >> > > Seeing LMM as
complementary to GMM (e.g. MIP) also support
> >> > >> > of multiple
> >> > >> > > binding for
inter-access system (inter
> technology) handover
> >> > >> > > - even if this can
only be realised by the global protocol
> >> > >> > - could be
> >> > >> > > provided by
introducing a corresponding flag (H for
> >> > >> > Handover or S for
> >> > >> > > Seamless?).
> >> > >> >
> >> > >> > "Seamless"
handovers can't be obtained by just adding
> >> a bit in a
> >> > >> > message. The seamless user
experience during handovers is
> >> > >> obtained by
> >> > >> > a combination of factors on
L2 implementation, IP
> >> > >> implementations and
> >> > >> > app-level implementation.
Seamless can't be really
> >> > defined, but a
> >> > >> > user easily recognizes a
seamless experience.
> >> > >> >
> >> > >> > Alex
> >> > >> >
_______________________________________________
> >> > >> > 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
> >> >
> >>
> >>
> >>
> >
> >
> > _______________________________________________
> > 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
|