Subject: [DMM] Review of draft-bernardos-dmm-distributed-anchoring-00

From: Peter McCann <[email-masked]>
Date: Tue, 6 Mar 2012 20:55:38 +0000

Hi, Carlos, Juan-Carlos,

I have read draft-bernardos-dmm-distributed-anchoring-00, and I have a few
comments.

First, I want to bring up something that I think is common to several of
the DMM proposals, and that is sub-optimal use of the backhaul resources.
It seems that when you use an AR as an anchor point, and move to a new AR,
the traffic for that session has to traverse the backhaul 3 times in each
direction, like this:

          -----
         | Rtr |
      / ^ -----\
   1 / / 2      \ 3
    v /          v
   ----          ----
  | AR |        | AR |
   ----          ----

Although it may seem at odds with the goal of "distributing" mobility to
use the crossover router as the point of traffic redirection, it would make
for much more optimal use of the backhaul resources.   I believe it is possible
to route the traffic more optimally with a standard off-the-shelf router at
the crossover point (using mechanisms detailed in draft-mccann-dmm-flatarch-00).

Second, I like the idea of moving the prefix assigned to the MN from one AR
to another.  However, why do we need to keep the AR's MAC address the same?
IPv6 should handle the failover of a first-hop router from one instance to another
with no problems.  You see the same prefix advertised from a different MAC address;
what's the big deal?  You can just keep using the prefix as you did before, addressing
packets to the new access router.

Third, I don't like the idea of having to ship so much state around the network
through the HSS.  In your draft you talk about (out-of-scope) mechanisms to get
the prefix and the anchor gateway address to the new D-GW.  There is also the complication
of knowing which prior prefixes the MN wants to keep at its new attachment point.
It seems to me that we should avoid the behavior that a new prefix is always assigned
at each new point of attachment; rather, we should force the MN to take some sort of
affirmative action to acquire an address/prefix for its use, such as DHCP-PD.  This
would be done occasionally, not on every handover, and the MN could register its intent
to keep an address through e.g., dynamic DNS update.  Then the new D-GW could lookup
the DNS name of the MN at the time it attaches, see the list of addresses that are
currently assigned, and take steps to attract the packets for those prefixes.  This
could be a tunnel or it could be a BGP UPDATE as outlined in draft-mccann-dmm-flatarch-00.

Finally, I don't quite understand the "Local Prefixes" concept presented in the draft.
I understand how LIPA is supposed to work, but I don't understand why you need to treat
such prefixes differently from any other prefix on the D-GW1 link.  You are tunneling
all the traffic back to the D-GW1 AR, correct?  Wouldn't the traffic just naturally
follow the proper path through to the D-GW1 and from there to the local CN?

Personally, I think it might be better to use client-based Mobile IP for any scenario
where the current AR cannot attract the packets for a given prefix, such as when the
MN moves out of the domain of one operator.  That situation is very similar to the LIPA
case and could be solved with a single mechanism.

Looking forward to continued discussion,

-Pete

--
Peter J. McCann
Huawei Technologies (USA)
[email-masked]
+1 908 541 3563
Rm. C-0105, 400 Crossings Blvd. (2nd floor), Bridgewater, NJ  08807-2863  USA

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Wed, 07 Mar 2012 19:00:49 +0100

Hi Pete,

Thanks for the comments. Please see some comments inline below.

> the traffic for that session has to traverse the backhaul 3 times in each

In our draft we don't make any assumption about the backhaul and access
architecture. ARs might be also directly connected (in which case no Rtr
would be traversed) if a network deployment allows that. In any case,
the traffic redirection is supposed to happen for relatively short
periods of time (otherwise the DMM advantages might vanish and it's just
better to go for a centralized approach).

> packets to the new access router.

This is basically inherited from PMIPv6 basic operation, in which the MN
keeps "seeing" always the same router (i.e. same IPv6 link-local address
and MAC address) while moving within the PMIPv6 domain. This is so to
improve performance (there are no stale entries on the neigh cache) and
also to avoid triggering any movement detection mechanism on the MN
(changing the default router might be treated as such). We basically
follow the same approach. Besides, by using a logical interface per
anchoring router, it becomes easier to handle the prefix advertisement
on the network side.

> could be a tunnel or it could be a BGP UPDATE as outlined in draft-mccann-dmm-flatarch-00.

I haven't had time to check your draft yet. Apologies for that, I'll do
it shortly. In any case, our draft does not specify how the info about
the active prefixes is obtained, and from where the require state is
retrieved. A centralized entity (such as the HSS, or a centralized LMA)
is just an example. Our draft also includes some PMIPv6 protocol
extensions to obtain that info from the previous router visited by the
MN (we call that D-GW), if the current router knows it. So basically the
defined mechanisms are not incompatible, IMHO, with the ones you
mentioned above.

> follow the proper path through to the D-GW1 and from there to the local CN?

We are considering here prefixes that because of security or other
reasons are not normally reachable from the Internet, but only from
nodes directly attached to D-GW1 (e.g., in an enterprise network). For
that case, it might be useful to keep being able to reach those while
being attached to a different D-GW. This is the LIPA use case considered
by 3GPP.

> case and could be solved with a single mechanism.

Client-based DMM is a topic that deserves additional attention. In our
draft we have started to look at a network-based solution, but we can
discuss the implications of a client-based solution as well.

> Looking forward to continued discussion,

So do we. Thanks for the good comments.

Carlos

-- 
Carlos Jesús Bernardos Cano  http://www.netcom.it.uc3m.es/
GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67

---

From: Peter McCann <[email-masked]>
Date: Wed, 7 Mar 2012 18:58:59 +0000

Hi, Carlos,

Just a couple of response points below...

Carlos Jesús Bernardos Cano wrote:
>> I have read draft-bernardos-dmm-distributed-anchoring-00, and I have a
>> few comments.
>> 
>> First, I want to bring up something that I think is common to several
>> of the DMM proposals, and that is sub-optimal use of the backhaul
>> resources. It seems that when you use an AR as an anchor point, and
>> move to a new AR, the traffic for that session has to traverse the
>> backhaul 3 times in each direction, like this:
>> 
>> 
>>           -----
>>          | Rtr |
>>       / ^ -----\
>>    1 / / 2      \ 3
>>     v /          v
>>    ----          ---- 
>>   | AR |        | AR | 
>>    ----          ----
>> Although it may seem at odds with the goal of "distributing" mobility
>> to use the crossover router as the point of traffic redirection, it
>> would make for much more optimal use of the backhaul resources.   I
>> believe it is possible to route the traffic more optimally with a
>> standard off-the-shelf router at the crossover point (using mechanisms
>> detailed in draft-mccann-dmm-
> flatarch-00).
> 

I suppose I have a different view of how long one might keep an address
that has been assigned by a first access router.  There might be quite
a bit of overhead involved with getting an address assigned, and you 
might want to delay getting a new address until, say, every 4th AR
that you encounter.  While I think it might be reasonable in some
environments for neighboring ARs to have a direct IP hop between them,
I think it is less likely that the 4th neighbor over will have a direct
connection.  And even direct neighbors I think are likely to be connected
in a star topology via expensive and slow backhaul links to a router
one layer up in the aggregation hierarchy.

>> Second, I like the idea of moving the prefix assigned to the MN from
>> one AR to another.  However, why do we need to keep the AR's MAC
>> address the same? IPv6 should handle the failover of a first-hop router
>> from one instance to another with no problems.  You see the same prefix
>> advertised from a different MAC address; what's the big deal?  You can
>> just keep using the prefix as you did before, addressing packets to the
>> new access router.
>> 
> 

At some layer of the stack the MN will know that it changed ARs.  I don't
see any particular reason why we have to hide the movement from the 
MAC layer.  Besides, most wide-area cellular technologies will use 
P2P links and won't have MAC addresses visible to the upper layers 
directly.

>> Third, I don't like the idea of having to ship so much state around the
>> network through the HSS.  In your draft you talk about (out-of-scope)
>> mechanisms to get the prefix and the anchor gateway address to the new
>> D-GW.  There is also the complication of knowing which prior prefixes
>> the MN wants to keep at its new attachment point. It seems to me that
>> we should avoid the behavior that a new prefix is always assigned at
>> each new point of attachment; rather, we should force the MN to take
>> some sort of affirmative action to acquire an address/prefix for its
>> use, such as DHCP-PD.  This would be done occasionally, not on every
>> handover, and the MN could register its intent to keep an address
>> through e.g., dynamic DNS update.  Then the new D- GW could lookup the
>> DNS name of the MN at the time it attaches, see the list of addresses
>> that are currently assigned, and take steps to attract the packets for
>> those prefixes.  This could be a tunnel or it could be a BGP UPDATE as
>> outlined in draft-
> mccann-dmm-flatarch-00.
> 
> it shortly. 

Great, would be glad to have your comments.

> In any case, our draft does not specify how the info about

Sure.  I guess it is necessary to get the old prefix that was assigned
somehow; it just seems that the additional effort to map this to an anchoring
D-GW might be too much.

>> Finally, I don't quite understand the "Local Prefixes" concept
>> presented in the draft. I understand how LIPA is supposed to work, but
>> I don't understand why you need to treat such prefixes differently from
>> any other prefix on the D-GW1 link. You are tunneling all the traffic
>> back to the D-GW1 AR, correct?  Wouldn't the traffic just naturally

I understand the motivation, but wouldn't this use case be solved because
of the fact you have a tunnel from the old D-GW to the new D-GW?  Why 
does the new D-GW need to know that a particular prefix was local to the
previous D-GW?  Aren't you proposing to always use reverse tunneling back
to the old D-GW for those packets that use the old logical interface?

>> Personally, I think it might be better to use client-based Mobile IP
>> for any scenario where the current AR cannot attract the packets for a
>> given prefix, such as when the MN moves out of the domain of one
>> operator.  That situation is very similar to the LIPA case and could be
>> solved with a single mechanism.
> 

I think the network based solution is a good match for the frequent,
localized mobility within a given autonomous system.  However, once you
cross a boundary outside of which the network can't re-route your traffic,
client MIP seems to be required.

-Pete

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Fri, 16 Mar 2012 09:46:07 +0100

Hi Pete,

Sorry for the late reply. Please see inline below.

> one layer up in the aggregation hierarchy.

I guess this very much depends on the operator's architecture and the
mobility pattern of the MN.

> MAC layer.  Besides, most wide-area cellular technologies will use 

The change is not hidden from the MAC layer, but from the IP layer.

> P2P links and won't have MAC addresses visible to the upper layers 

Well, in this case the L2 change is "by default" hidden from the IP
stack (if the new MAG shares the IP address from the old one).

> somehow; it just seems that the additional effort to map this to an anchoring

Not sure I follow what you said here...

> to the old D-GW for those packets that use the old logical interface?

The tunnel is only used while you have ongoing sessions active. But you
might want to still being able to start new sessions to that local
prefix via the D-GW connected to it (because it is the only way to get
connectivity to it).

> client MIP seems to be required.

For that case, seems to me that both PMIP and CMIP-based solutions could
be appropriate, but it depends on the specific assumptions. I guess we
would need to look further into the details.

Thanks,

Carlos

---

From: Peter McCann <[email-masked]>
Date: Fri, 16 Mar 2012 14:38:29 +0000

Hi, Carlos,

Carlos Jesús Bernardos Cano wrote:
>>>> I have read draft-bernardos-dmm-distributed-anchoring-00, and I 
>>>> have a few comments.
>>>> 
>>>> First, I want to bring up something that I think is common to 
>>>> several of the DMM proposals, and that is sub-optimal use of the 
>>>> backhaul resources. It seems that when you use an AR as an anchor 
>>>> point, and move to a new AR, the traffic for that session has to 
>>>> traverse the backhaul 3 times in each direction, like this:
>>>> 
>>>> 
>>>>           -----
>>>>          | Rtr |
>>>>       / ^ -----\
>>>>    1 / / 2      \ 3
>>>>     v /          v
>>>>    ----          ---- 
>>>>   | AR |        | AR | 
>>>>    ----          ----
>>>> Although it may seem at odds with the goal of "distributing" 
>>>> mobility to use the crossover router as the point of traffic 
>>>> redirection, it would make for much more optimal use of the 
>>>> backhaul resources. I believe it is possible to route the traffic 
>>>> more optimally with a standard off-the-shelf router at the 
>>>> crossover point (using mechanisms detailed in draft-mccann-dmm-
>>> flatarch-00).
>>> 
>>> In our draft we don't make any assumption about the backhaul and 
>>> access architecture. ARs might be also directly connected (in which 
>>> case no Rtr would be traversed) if a network deployment allows that.
>>> In any case, the traffic redirection is supposed to happen for 
>>> relatively short periods of time (otherwise the DMM advantages might 
>>> vanish and it's just better to go for a centralized approach).
>> 
>> I suppose I have a different view of how long one might keep an 
>> address that has been assigned by a first access router.  There might 
>> be quite a bit of overhead involved with getting an address assigned, 
>> and you might want to delay getting a new address until, say, every 
>> 4th AR that you encounter.  While I think it might be reasonable in 
>> some environments for neighboring ARs to have a direct IP hop between 
>> them, I think it is less likely that the 4th neighbor over will have 
>> a direct connection.  And even direct neighbors I think are likely to 
>> be connected in a star topology via expensive and slow backhaul links 
>> to a router one layer up in the aggregation hierarchy.
> 

Indeed it does, but I do not think we should require the MN to get 
a new IP address upon every attachment to an AR.  Address allocation
should be decoupled from mobility management.

>>>> Second, I like the idea of moving the prefix assigned to the MN 
>>>> from one AR to another.  However, why do we need to keep the AR's 
>>>> MAC address the same? IPv6 should handle the failover of a 
>>>> first-hop router from one instance to another with no problems. You 
>>>> see the same prefix advertised from a different MAC address; what's 
>>>> the big deal?  You can just keep using the prefix as you did 
>>>> before, addressing packets to the new access router.
>>>> 
>>> 
>>> This is basically inherited from PMIPv6 basic operation, in which 
>>> the MN keeps "seeing" always the same router (i.e. same IPv6 
>>> link-local address and MAC address) while moving within the PMIPv6 
>>> domain. This is so to improve performance (there are no stale 
>>> entries on the neigh cache) and also to avoid triggering any 
>>> movement detection mechanism on the MN (changing the default router 
>>> might be treated as such). We basically follow the same approach.
>>> Besides, by using a logical interface per anchoring router, it 
>>> becomes easier to handle the prefix advertisement on the network
> side.
>> 
>> At some layer of the stack the MN will know that it changed ARs.  I 
>> don't see any particular reason why we have to hide the movement from 
>> the MAC layer.  Besides, most wide-area cellular technologies will
>> use
> 

Ok, I guess the MAC layer sees the link change below it even though
the MAC address of the AR is preserved.

> stack (if the new MAG shares the IP address from the old one).

Right, I guess I am wondering why we can't just see the new router
with a new IP address still advertising the old prefix.  IPv6 stacks
should be able to handle this.

>>>> Third, I don't like the idea of having to ship so much state around 
>>>> the network through the HSS.  In your draft you talk about
>>>> (out-of-scope) mechanisms to get the prefix and the anchor gateway 
>>>> address to the new D-GW.  There is also the complication of knowing 
>>>> which prior prefixes the MN wants to keep at its new attachment 
>>>> point. It seems to me that we should avoid the behavior that a new 
>>>> prefix is always assigned at each new point of attachment; rather, 
>>>> we should force the MN to take some sort of affirmative action to 
>>>> acquire an address/prefix for its use, such as DHCP-PD. This would 
>>>> be done occasionally, not on every handover, and the MN could 
>>>> register its intent to keep an address through e.g., dynamic DNS 
>>>> update.  Then the new D- GW could lookup the DNS name of the MN at 
>>>> the time it attaches, see the list of addresses that are currently 
>>>> assigned, and take steps to attract the packets for those prefixes. 
>>>> This could be a tunnel or it could be a BGP UPDATE as outlined in 
>>>> draft-mccann-dmm-flatarch-00.
>>> 
>>> I haven't had time to check your draft yet. Apologies for that, I'll 
>>> do it shortly.
>> 
>>> In any case, our draft does not specify how the info about the 
>>> active prefixes is obtained, and from where the require state is 
>>> retrieved. A centralized entity (such as the HSS, or a centralized
>>> LMA) is just an example. Our draft also includes some PMIPv6 
>>> protocol extensions to obtain that info from the previous router 
>>> visited by the MN (we call that D-GW), if the current router knows 
>>> it. So basically the defined mechanisms are not incompatible, IMHO, 
>>> with the ones you mentioned above.
>> 
>> Sure.  I guess it is necessary to get the old prefix that was 
>> assigned somehow; it just seems that the additional effort to map 
>> this to an anchoring D-GW might be too much.
> 

You need to find the anchoring D-GW in order to establish a tunnel
to it and find out its MAC address.  Assuming you found the assigned
prefix, it is an extra step to map this to an anchor D-GW.  Certain
other proposals don't need to actually find the D-GW (for example, 
they can just send a BGP UPDATE to a route reflector).

>>>> presented in the draft. I understand how LIPA is supposed to work, 
>>>> but I don't understand why you need to treat such prefixes 
>>>> differently from any other prefix on the D-GW1 link. You are 
>>>> tunneling all the traffic back to the D-GW1 AR, correct?
>>>> Wouldn't the traffic just naturally follow the proper path through 
>>>> to the
>>>> D-GW1 and from there to the local CN?
>>> 
>>> nodes directly attached to D-GW1 (e.g., in an enterprise network).
>>> For that case, it might be useful to keep being able to reach those 
>>> while being attached to a different D-GW. This is the LIPA use case 
>>> considered by 3GPP.
>> 
>> I understand the motivation, but wouldn't this use case be solved 
>> because of the fact you have a tunnel from the old D-GW to the new 
>> D-GW?  Why does the new D-GW need to know that a particular prefix 
>> was local to the previous D-GW?  Aren't you proposing to always use 
>> reverse tunneling back to the old D-GW for those packets that use the
>> old logical interface?
> 
> The tunnel is only used while you have ongoing sessions active. But 
> you might want to still being able to start new sessions to that local 

Sure, but wouldn't you always do this for sessions that use the old
prefix (whether they were established before or after the handover)?
Regardless of whether the prefix was "Local" or not?

>>>> Personally, I think it might be better to use client-based Mobile 
>>>> IP for any scenario where the current AR cannot attract the packets 
>>>> for a given prefix, such as when the MN moves out of the domain of 
>>>> one operator.  That situation is very similar to the LIPA case and 
>>>> could be solved with a single mechanism.
>>> 
>>> Client-based DMM is a topic that deserves additional attention. In 
>>> our draft we have started to look at a network-based solution, but 
>>> we can discuss the implications of a client-based solution as well.
>> 
>> localized mobility within a given autonomous system.  However, once 
>> you cross a boundary outside of which the network can't re-route your 
>> traffic, client MIP seems to be required.
> 
> For that case, seems to me that both PMIP and CMIP-based solutions 
> could be appropriate, but it depends on the specific assumptions. I 
> guess we would need to look further into the details.

Ok.

-Pete

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Sun, 18 Mar 2012 20:59:21 +0100

Hi Pete,

Comments inline below...

> should be decoupled from mobility management.

Well, we are talking about IP mobility management, that comes exactly
because the MN changes its attachment point at L3. This usually implies
a change of IP address, unless you instruct the L3 routing
infrastructure to follow the MN location (e.g., PMIPv6 is one way of
doing that, but having the entity anchoring the address -- the LMA --
keep a tunnel with the entity the MN is attached to; routing would be
another way).

> should be able to handle this.

This is usually understood as L3 mobility by IPv6 stacks (it will
trigger movement detection if the MN is MIPv6-enabled). One of the goals
of PMIPv6 is to hide that.

> they can just send a BGP UPDATE to a route reflector).

OK, if you are considering routing-based approaches, this is a
completely different thing. IMO, the problem then is the converge and
reaction time of the solution.

> Regardless of whether the prefix was "Local" or not?

No, if you can reach a certain network using any IP source address, you
will always prefer to use the source address that is anchored closer to
your current location.

Thanks,

Carlos