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