Subject: [DMM] New DMM draft: draft-bernardos-dmm-distributed-anchoring-00.txt

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Mon, 05 Mar 2012 18:39:52 +0100

Dear all,

We've just submitted a new I-D on the DMM space. The draft describes a
network-based DMM approach extending PMIPv6, and focusing on the
required extensions to effectively support simultaneously anchoring
several flows at different distributed anchors.

As usual, comments would be warmly welcomed!

More info below:

        Title           : PMIPv6-based distributed anchoring
        Author(s)       : Carlos J. Bernardos
                          Juan Carlos Zuniga
        Filename        :
draft-bernardos-dmm-distributed-anchoring-00.txt
        Pages           : 23
        Date            : 2012-03-05

   Distributed Mobility Management solutions allow for setting up
   networks so that traffic is distributed in an optimal way and does
   not rely on centralized deployed anchors to provide IP mobility
   support.

   There are many different approaches to address Distributed Mobility
   Management, as for example extending network-based mobility protocols
   (like Proxy Mobile IPv6), or client-based mobility protocols (as
   Mobile IPv6), among others.  This document follows the former
   approach, and proposes a solution based on Proxy Mobile IPv6 in which
   mobility sessions are anchored at the last IP hop router (called
   distributed gateway).  The distributed gateway is an enhanced access
   router which is also able to operate as local mobility anchor or
   mobility access gateway, on a per prefix basis.  The draft focuses on
   the required extensions to effectively support simultaneously
   anchoring several flows at different distributed gateways.

   This draft introduces the concept of distributed logical interface
   (at the distributed gateway), which is a software construct that
   allows to easily hide the change of anchor from the mobile node.
   Additionally, the draft describes how to provide session continuity
   in inter-domain scenarios in which dynamic tunneling or signaling
   between distributed gateways from different operators is not allowed.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-bernardos-dmm-distributed-anchoring-00.txt

Thanks,

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: Marco Liebsch <[email-masked]>
Date: Fri, 9 Mar 2012 11:51:01 +0000

Hi Carlos,

I have a few clarifying questions to your new draft. The draft proposes the
distributed logical interface. I don't really get the advantage of virtualizing
the previous LMA on the MN's current LMA if packets are routed through
the previous LMA anyway. Why not using the current LMA to serve simply
as MAG for forwarded traffic (which remains anchored at previous LMA)
and using the new LMA to anchor the new address/prefix? 

The draft writes that the idea hides the change of the anchor from the
mobile node. The DGW2IF on the new LMA does not pretend to be LMA1, or?
I don't see how the anchor change is kept transparent to the MN.

I somehow agree also to Pete's opinion that solving the packet routing after
anchor relocation above the anchors is a good option. It simply allows more
optimal routes.

Now I am deviating a bit, but into the direction of an important question:
That's directly related to the question of how persistent we need to be
about IP address continuity. Now, some proposals consider termination
of an IP address prefix, which is anchored at a previously used anchor point,
as soon as the IP session, which uses that address, terminates. New sessions
can use the address being anchored at the new mobility anchor. My opinion is
that we need to find a good choice about the lifetime of such an anchored IP
address, as it may also be registered with other services, e.g. IMS, messaging, etc,
and would require an updated registration after a change in the registered address.
And even if such lifetime is short, we may not accept suboptimal routing paths
via the previous anchor after anchor relocation.

What do you think?

Thanks,
marco

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Carlos Jesús Bernardos Cano
> Sent: Montag, 5. März 2012 18:40
> To: [email-masked]
> Subject: [DMM] New DMM draft: draft-bernardos-dmm-distributed-
> anchoring-00.txt
> 
> Dear all,
> 
> required extensions to effectively support simultaneously anchoring several
> flows at different distributed anchors.
> 
> Carlos Jesús Bernardos Cano  http://www.netcom.it.uc3m.es/ GPG FP: D29B
> 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67

---

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

Hi Marco,

Apologies for the late reply. Thanks for reading the draft. Please see
some answers to your questions/comments inline below.

> and using the new LMA to anchor the new address/prefix? 

What you just mention is exactly what the draft does. Additionally, the
logical interface simplifies the interface between the MN and the access
router that behaves as LMA/MAG. It does so because by interacting with
the MN as different "logical" routers (one per anchoring LMA), you can
make full use of the ND based features (e.g., RFC4191) in a very easy
way.

> I don't see how the anchor change is kept transparent to the MN.

The point is that from the point of view of the MN, it always "sees" as
directly connected (1-hop away) each of the anchor LMAs. Every time the
MN moves and attaches to a new access router, the only thing it notices
is that a new ("logical") router appears on the link, advertising a new
prefix (and, in most use cases, the others start advertising the
prefixes with lifetime=0 to deprecate them).

> anchor relocation above the anchors is a good option. It simply allows more

I have to read his draft, but unless you have control on the routing
infrastructure (and this is not always possible, and it takes time to
converge), I don't see many other options to ensure address continuity.

> via the previous anchor after anchor relocation.

Session lifetime and prefix anchoring termination is a tricky and
important issue. As I see it, DMM is compatible with a "classical"
centralized approach (at least for the solutions that are basically
extending currently standardized IP mobility protocols to operate in a
more "distributed" way). For those applications that are known in
advance to require very long address lifetime (compared to the anchoring
mobility rate), I'd say that those sessions it might make sense to keep
them centrally anchored (or to enable applications to be able to survive
to an IP address change).

Thanks,

Carlos

---

From: Marco Liebsch <[email-masked]>
Date: Fri, 16 Mar 2012 10:00:54 +0000

Carlos,
thanks for your feedback. Please see inline.

> From: Carlos Jesús Bernardos Cano [mailto:[email-masked]]
> Sent: Freitag, 16. März 2012 09:51
> To: Marco Liebsch
> Cc: [email-masked]
> Subject: RE: [DMM] New DMM draft: draft-bernardos-dmm-distributed-
> anchoring-00.txt
> 
> Hi Marco,
> 
> Apologies for the late reply. Thanks for reading the draft. Please see some
> answers to your questions/comments inline below.
> 
> > I have a few clarifying questions to your new draft. The draft
> > proposes the distributed logical interface. I don't really get the
> > advantage of virtualizing the previous LMA on the MN's current LMA if
> > packets are routed through the previous LMA anyway. Why not using the
> > current LMA to serve simply as MAG for forwarded traffic (which
> > remains anchored at previous LMA) and using the new LMA to anchor the
> new address/prefix?
> 
> What you just mention is exactly what the draft does. Additionally, the logical
> interface simplifies the interface between the MN and the access router that
> behaves as LMA/MAG. It does so because by interacting with the MN as
> different "logical" routers (one per anchoring LMA), you can make full use of
> the ND based features (e.g., RFC4191) in a very easy way.
> 
> >
> The point is that from the point of view of the MN, it always "sees" as directly
> connected (1-hop away) each of the anchor LMAs. Every time the MN moves
> and attaches to a new access router, the only thing it notices is that a new
> ("logical") router appears on the link, advertising a new prefix (and, in most
> use cases, the others start advertising the prefixes with lifetime=0 to
> deprecate them).

The LMA function should be transparent to the MN anyway, so it does not
matter whether the LMA, which serves as anchor, is on the previous AR or on
the current one. Invalidating the previous HNP and validating the new HNP
can be done independently of whether the responsible LMA instance is co-located
with the local AR or the previous AR. But I must admit that I probably have to
check that part of your draft again.

> 
> >
> > I somehow agree also to Pete's opinion that solving the packet routing
> > after anchor relocation above the anchors is a good option. It simply
> > allows more optimal routes.
> 
> infrastructure (and this is not always possible, and it takes time to converge),
> I don't see many other options to ensure address continuity.

I don't expect this to take long time, as the routing states are not to be enforced
in all routers, at least not in our proposal.  Intention is to keep the routing plane as it is
and update states only is one dedicated router per data session, which translates the
MN's IP address into a routable one to ensure that remaining routers in the network
forward the downlink packet to the MN's current anchor point. The previous anchor
point is released from any forwarding tasks. Further advantage is that routes are
potentially more optimal compared to forwarding from a previous anchor.
Which does not mean that both approaches cannot co-exist. A DMM solution
could rely on forwarding while the state in the routing plane is established.

> > That's directly related to the question of how persistent we need to
> > be about IP address continuity. Now, some proposals consider
> > termination of an IP address prefix, which is anchored at a previously
> > used anchor point, as soon as the IP session, which uses that address,
> > terminates. New sessions can use the address being anchored at the new
> > mobility anchor. My opinion is that we need to find a good choice
> > about the lifetime of such an anchored IP address, as it may also be
> > registered with other services, e.g. IMS, messaging, etc, and would require
> an updated registration after a change in the registered address.
> > And even if such lifetime is short, we may not accept suboptimal
> > routing paths via the previous anchor after anchor relocation.
> 
> Session lifetime and prefix anchoring termination is a tricky and important
> issue. As I see it, DMM is compatible with a "classical"
> centralized approach (at least for the solutions that are basically extending
> currently standardized IP mobility protocols to operate in a more
> "distributed" way). For those applications that are known in advance to
> require very long address lifetime (compared to the anchoring mobility rate),
> I'd say that those sessions it might make sense to keep them centrally
> anchored (or to enable applications to be able to survive to an IP address
> change).

So you think that the UE should receive multiple IP addresses and treat them
differently according to the associated topological anchor point? Hmm, yes, possible.
What about real time streaming and other IP data sessions, which could have a
longer lifetime, they should be anchored than at a central point as well, right?
If the MN had such intelligence and information, it could treat the HNPs differently, true.

marco

> > > From: [email-masked] [mailto:[email-masked]] On
> Behalf
> > > Of Carlos Jesús Bernardos Cano
> > > We've just submitted a new I-D on the DMM space. The draft describes
> > > a network-based DMM approach extending PMIPv6, and focusing on the
> > > Carlos Jesús Bernardos Cano  http://www.netcom.it.uc3m.es/ GPG FP:
> > > D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67
> 
> --

---

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

Hi Marco,

Thanks for your comment. Please see inline below.

> check that part of your draft again.

If it just invalidating the prefix, this can be done, true. But the
point is that the DLIF concept enables to do more that just invalidating
a prefix. Besides, it makes easier to implement this prefix deprecation.

> could rely on forwarding while the state in the routing plane is established.

I have to admit I haven't checked your proposal yet. What you mention
seems like a NAT-based approach, is it true? and if there is a dedicated
router, isn't it a centralized entity? if the point is that that entity
is closer to the MN (not deep in the operator's core), then I see that
as a kind-of hierarchical-alike solution.

> If the MN had such intelligence and information, it could treat the HNPs differently, true.

I think thank kind of approaches make sense.

Carlos

---

From: jouni korhonen <[email-masked]>
Date: Sun, 18 Mar 2012 22:47:08 +0200

> I think thank kind of approaches make sense.

There are a couple proposals on table that go into this direction. We put those
under "addressing enhancements" slot. Basically piggybacking anchoring properties
of a prefix along with address configuration.

- Jouni

---

From: [email-masked]
Date: Mon, 19 Mar 2012 15:44:07 +0800

Hi Carlos and Marco,

As Marco said 

***********************************************************************
So you think that the UE should receive multiple IP addresses and treat 
them
differently according to the associated topological anchor point? Hmm, 
yes, possible.
What about real time streaming and other IP data sessions, which could 
have a
longer lifetime, they should be anchored than at a central point as well, 
right?
If the MN had such intelligence and information, it could treat the HNPs 
differently, true.
*******************************************************************************

I also think it is possible to let UE treat those multiple IP addresses 
differently. Some modification may be needed to let mobile node to have 
such intelligence.
But the question is, one of principles of PMIP is not to touch mobile 
node. And you know, MIP already supports distinguishing between HoA and 
CoA in mobile node.
Since we will touch mobile node anyway, why don't we use MIP directly?

BR
Luowen

Marco Liebsch <[email-masked]> 
发件人:  [email-masked]
2012/03/16 18:00

收件人
"[email-masked]" <[email-masked]>
抄送
"[email-masked]" <[email-masked]>
主题
Re: [DMM] New DMM draft: draft-bernardos-dmm-distributed-anchoring-00.txt

Carlos,

> Apologies for the late reply. Thanks for reading the draft. Please see 
some
> What you just mention is exactly what the draft does. Additionally, the 
logical
> The point is that from the point of view of the MN, it always "sees" as 
directly

The LMA function should be transparent to the MN anyway, so it does not
matter whether the LMA, which serves as anchor, is on the previous AR or 
on
the current one. Invalidating the previous HNP and validating the new HNP
can be done independently of whether the responsible LMA instance is 
co-located
with the local AR or the previous AR. But I must admit that I probably 
have to
check that part of your draft again.

> infrastructure (and this is not always possible, and it takes time to 
converge),
> I don't see many other options to ensure address continuity.

I don't expect this to take long time, as the routing states are not to be 
enforced
in all routers, at least not in our proposal.  Intention is to keep the 
routing plane as it is
and update states only is one dedicated router per data session, which 
translates the
MN's IP address into a routable one to ensure that remaining routers in 
the network
forward the downlink packet to the MN's current anchor point. The previous 
anchor
point is released from any forwarding tasks. Further advantage is that 
routes are
potentially more optimal compared to forwarding from a previous anchor.
Which does not mean that both approaches cannot co-exist. A DMM solution
could rely on forwarding while the state in the routing plane is 
established.

> Session lifetime and prefix anchoring termination is a tricky and 
important
> centralized approach (at least for the solutions that are basically 
extending
> anchored (or to enable applications to be able to survive to an IP 
address

So you think that the UE should receive multiple IP addresses and treat 
them
differently according to the associated topological anchor point? Hmm, 
yes, possible.
What about real time streaming and other IP data sessions, which could 
have a
longer lifetime, they should be anchored than at a central point as well, 
right?
If the MN had such intelligence and information, it could treat the HNPs 
differently, true.

marco

> > > http://www.ietf.org/internet-drafts/draft-bernardos-dmm-distributed-

_______________________________________________
dmm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dmm

---

From: Marco Liebsch <[email-masked]>
Date: Mon, 19 Mar 2012 08:58:34 +0000

Carlos, please see inline.

> Sent: Sonntag, 18. März 2012 20:59
> To: Marco Liebsch
> Cc: [email-masked]
> > > Apologies for the late reply. Thanks for reading the draft. Please
> > > see some answers to your questions/comments inline below.
> > >
> > > > advantage of virtualizing the previous LMA on the MN's current LMA
> > > > if packets are routed through the previous LMA anyway. Why not
> > > > using the current LMA to serve simply as MAG for forwarded traffic
> > > > (which remains anchored at previous LMA) and using the new LMA to
> > > > anchor the
> > > new address/prefix?
> > >
> > > What you just mention is exactly what the draft does. Additionally,
> > > the logical interface simplifies the interface between the MN and
> > > the access router that behaves as LMA/MAG. It does so because by
> > > interacting with the MN as different "logical" routers (one per
> > > anchoring LMA), you can make full use of the ND based features (e.g.,
> RFC4191) in a very easy way.
> > >
> > > >
> > > > The draft writes that the idea hides the change of the anchor from
> > > > the mobile node. The DGW2IF on the new LMA does not pretend to be
> > > > LMA1,
> > > or?
> > > The point is that from the point of view of the MN, it always "sees"
> > > as directly connected (1-hop away) each of the anchor LMAs. Every
> > > time the MN moves and attaches to a new access router, the only
> > > thing it notices is that a new
> > > ("logical") router appears on the link, advertising a new prefix
> > > (and, in most use cases, the others start advertising the prefixes
> > > with lifetime=0 to deprecate them).
> >
> > The LMA function should be transparent to the MN anyway, so it does
> > not matter whether the LMA, which serves as anchor, is on the previous
> > AR or on the current one. Invalidating the previous HNP and validating
> > the new HNP can be done independently of whether the responsible LMA
> > instance is co-located with the local AR or the previous AR. But I
> > must admit that I probably have to check that part of your draft again.
> 
> If it just invalidating the prefix, this can be done, true. But the point is that
> the DLIF concept enables to do more that just invalidating a prefix. Besides, it
> makes easier to implement this prefix deprecation.

Ok, I'll check the description to better understand the DLIF function.

> 
> >
> >
> > >
> > > >
> > > > I somehow agree also to Pete's opinion that solving the packet
> > > > routing after anchor relocation above the anchors is a good
> > > > option. It simply allows more optimal routes.
> > >
> > > infrastructure (and this is not always possible, and it takes time
> > > to converge), I don't see many other options to ensure address
> continuity.
> >
> > I don't expect this to take long time, as the routing states are not
> > to be enforced in all routers, at least not in our proposal.
> > Intention is to keep the routing plane as it is and update states only
> > is one dedicated router per data session, which translates the MN's IP
> > address into a routable one to ensure that remaining routers in the
> > network forward the downlink packet to the MN's current anchor point.
> > The previous anchor point is released from any forwarding tasks. Further
> advantage is that routes are potentially more optimal compared to
> forwarding from a previous anchor.
> > Which does not mean that both approaches cannot co-exist. A DMM
> > solution could rely on forwarding while the state in the routing plane is
> established.
> 
> I have to admit I haven't checked your proposal yet.

No problem ;-)

> What you mention
> seems like a NAT-based approach, is it true?

We propose NAT to save per-packet overhead and use the prefix/IP address
being assigned and anchored at the new anchor as locator, which intrinsically
has identifier information. So, reverse NAT on the new anchor is easily possible.
But that's not the key of the approach, as NAT can be easily replaced by IP tunnels.
The key approach is to solve DMM in the routing plane above anchors while using
the existing routing plane.

> and if there is a dedicated
> router, isn't it a centralized entity?

It's exactly the opposite. No additional hierarchy level for mobility. Forwarding is being
done by standard routers which build the routing plane in the core, metro and aggregation
network. They can setup a transient per-host state after the MN's anchor has been relocated
and perform a longest prefix match. These routers are distributed throughout the routing plane.
After NAT or encapsulation, remaining routers on the path to the MN's current anchor
perform routing according to their existing entries, as the used IP address represents
a routable address and locator, which is anchored at the MN#s current mobility anchor. 

>if the point is that that entity is closer to
> the MN (not deep in the operator's core), then I see that as a kind-of
> hierarchical-alike solution.

Mobility anchors are distributed and located closer to the MN. No additional hierarchy
level is introduced, as there is no additional anchor above the distributed mobility anchors.

marco

> > > > That's directly related to the question of how persistent we need
> > > > to be about IP address continuity. Now, some proposals consider
> > > > termination of an IP address prefix, which is anchored at a
> > > > previously used anchor point, as soon as the IP session, which
> > > > uses that address, terminates. New sessions can use the address
> > > > being anchored at the new mobility anchor. My opinion is that we
> > > > need to find a good choice about the lifetime of such an anchored
> > > > IP address, as it may also be registered with other services, e.g.
> > > > IMS, messaging, etc, and would require
> > > extending currently standardized IP mobility protocols to operate in
> > > a more "distributed" way). For those applications that are known in
> > > advance to require very long address lifetime (compared to the
> > > anchoring mobility rate), I'd say that those sessions it might make
> > > sense to keep them centrally anchored (or to enable applications to
> > > be able to survive to an IP address change).
> >
> > So you think that the UE should receive multiple IP addresses and
> > treat them differently according to the associated topological anchor point?
> Hmm, yes, possible.
> > have a longer lifetime, they should be anchored than at a central point as
> well, right?
> > > > > We've just submitted a new I-D on the DMM space. The draft
> > > > > describes a network-based DMM approach extending PMIPv6, and
> > > > > focusing on the required extensions to effectively support
> > > > > simultaneously anchoring several flows at different distributed
> anchors.
> > > > >
> > > > > http://www.ietf.org/internet-drafts/draft-bernardos-dmm-distribu
> > > > > ted-
> > > > > anchoring-00.txt
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Carlos
> > > > >
> > > > > --

---

From: <[email-masked]>
Date: Mon, 19 Mar 2012 11:16:56 +0100

I think it is worth to work on solution providing more information on the type of address. IMHO, it is a requirement for the UE to play with more than one IP address and select the more appropriate source address according the topological anchor point. DMM is clearly one use-case but, this feature is also required for offload purpose in current centralized network based mobility. The ongoing proposals for RA extensions, that allow to distinguish anchored from local prefix, are interesting. Now, the UE shall have the intelligence to make the source address selection according to prefix properties; at least extensions to RFC3484 may be defined but more sophisticated selection behavior may be required, typically, policies based selection, e.g. offload policies.

Pierrick

> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] De la part de
> jouni korhonen
> Envoyé : dimanche 18 mars 2012 21:47
> À : Carlos Jesús Bernardos Cano; Marco Liebsch
> Cc : [email-masked]
> Objet : Re: [DMM] New DMM draft:draft-bernardos-dmm-distributed-
> anchoring-00.txt
> 
> 
> >>
> treat them

---

From: Marco Liebsch <[email-masked]>
Date: Mon, 19 Mar 2012 10:53:23 +0000

Hi Pierrick,

I agree that this is an interesting approach from research point of view. The question
is how practical this is. Intelligence on the MN is ok, but to take a decision about which
IP address to use, the MN needs information. If information is solely a binding between the prefix
and the level of the associated anchor in a hierarchy of anchors, then the
MN may select a prefix/address according to the expected IP session duration to avoid
a change in the topological anchor of the used IP address. Taking such decision requires also
some information about the topology, which I doubt operators will reveal. Important
here is the location of the anchor and the location of the used serving point. Latter could
be a public Internet service, hence knowledge of the operator's IX peering points may
be relevant. If the serving point is operator CDN-like, typically the MN is served
by transparent caching, hence, the location of the cache is not known to the MN.

A different and pragmatic approach is to select the closest anchor point to serve any IP session
of the UE and to provide a good solution to handle routing after anchor relocation plus
renewal of the MN's IP address from time to time. IMO, such approach enables short
routing paths between any source and the MN while offloading traffic from the core
network as its best.

marco

> From: [email-masked] [mailto:[email-masked]]
> Sent: Montag, 19. März 2012 11:17
> To: [email-masked]; [email-masked]; Marco Liebsch
> Cc: [email-masked]
> Subject: RE: [DMM] New DMM draft:draft-bernardos-dmm-distributed-
> anchoring-00.txt
> 
> I think it is worth to work on solution providing more information on the type
> of address. IMHO, it is a requirement for the UE to play with more than one
> IP address and select the more appropriate source address according the
> topological anchor point. DMM is clearly one use-case but, this feature is also
> required for offload purpose in current centralized network based mobility.
> The ongoing proposals for RA extensions, that allow to distinguish anchored
> from local prefix, are interesting. Now, the UE shall have the intelligence to
> make the source address selection according to prefix properties; at least
> extensions to RFC3484 may be defined but more sophisticated selection
> behavior may be required, typically, policies based selection, e.g. offload
> policies.
> 
> Pierrick
> 
> > jouni korhonen Envoyé : dimanche 18 mars 2012 21:47 À : Carlos Jesús
> > Bernardos Cano; Marco Liebsch Cc : [email-masked] Objet : Re: [DMM] New
> > DMM draft:draft-bernardos-dmm-distributed-
> > anchoring-00.txt
> >
> >
> > >>
> > There are a couple proposals on table that go into this direction. We
> > put those under "addressing enhancements" slot. Basically piggybacking
> > anchoring properties of a prefix along with address configuration.
> >
> > - Jouni
> >
> >
> >
> > >
> > > Carlos
> > >
> > >>
> > >> marco
> >

---

From: jouni korhonen <[email-masked]>
Date: Mon, 19 Mar 2012 12:59:22 +0200

Pierrick,

On Mar 19, 2012, at 12:16 PM, <[email-masked]> <[email-masked]> wrote:

> I think it is worth to work on solution providing more information on the type of address. IMHO, it is a requirement for the UE to play with more than one IP address and select the more appropriate source address according the topological anchor point. DMM is clearly one use-case but, this feature is also required for offload purpose in current centralized network based mobility. The ongoing proposals for RA extensions, that allow to distinguish anchored from local prefix, are interesting. Now, the UE shall have the intelligence to make the source address selection according to prefix

To me offloading and DMM go hand in hand, since how the current charter is described emphasizes the use of CoAs (could be the "local prefix"). With some care, solutions developed in DMM space apply to both. At least this is what I want to see to happen.

>  properties; at least extensions to RFC3484 may be defined but more sophisticated selection behavior may be required, typically, policies based selection, e.g. offload policies.

For example, draft-korhonen-dmm-prefix-properties discuss briefly how to hook into RFC3484bis (and even to RFC3484). The text superseding source address selection Rule 8:

   Rule 8 may be superseded if the implementation has other means of
   choosing among source addresses.  For example, if the implementation
   somehow knows which source address will result in the "best"
   communications performance.

is especially a good fit here.

- Jouni

>> put those

---

From: <[email-masked]>
Date: Mon, 19 Mar 2012 13:06:30 +0100

> De : jouni korhonen [mailto:[email-masked]]
> Envoyé : lundi 19 mars 2012 11:59
> À : SEITE Pierrick RD-RESA-REN
> Cc : [email-masked]; [email-masked]; [email-masked]
> > I think it is worth to work on solution providing more information on
> the type of address. IMHO, it is a requirement for the UE to play with
> more than one IP address and select the more appropriate source address
> according the topological anchor point. DMM is clearly one use-case
> but, this feature is also required for offload purpose in current
> centralized network based mobility. The ongoing proposals for RA
> extensions, that allow to distinguish anchored from local prefix, are
> interesting. Now, the UE shall have the intelligence to make the source
> address selection according to prefix
> 
> To me offloading and DMM go hand in hand, since how the current charter
> is described emphasizes the use of CoAs (could be the "local prefix").
> With some care, solutions developed in DMM space apply to both. At
> least this is what I want to see to happen.
> 

I couldn't agree more. 

Pierrick

> >  properties; at least extensions to RFC3484 may be defined but more
> sophisticated selection behavior may be required, typically, policies
> based selection, e.g. offload policies.
> 
> For example, draft-korhonen-dmm-prefix-properties discuss briefly how
> to hook into RFC3484bis (and even to RFC3484). The text superseding
> source address selection Rule 8:
> 
> >>>> longer lifetime, they should be anchored than at a central point
> as
> >> well, right?
> >>>> If the MN had such intelligence and information, it could treat
> the
> >> HNPs differently, true.
> >>>
> >> under "addressing enhancements" slot. Basically piggybacking
> anchoring
> >> properties

---

From: <[email-masked]>
Date: Mon, 19 Mar 2012 13:22:21 +0100

> De : Marco Liebsch [mailto:[email-masked]]
> Envoyé : lundi 19 mars 2012 11:53
> À : SEITE Pierrick RD-RESA-REN; [email-masked]; [email-masked]
> Cc : [email-masked]
> Objet : RE: [DMM] New DMM draft:draft-bernardos-dmm-distributed-
> anchoring-00.txt
> 
> Hi Pierrick,
> 
> some information about the topology, which I doubt operators will
> reveal. 

I confirm :-)

Important
> here is the location of the anchor and the location of the used serving
> point. 
Latter could
> by transparent caching, hence, the location of the cache is not known

You're right but, actually, we may not need a so smart selection. I was not talking about a so sophisticated selection; actually, IMHO, the requirement, is just that the UE can distinguish anchored prefix/address to be used by the application which need mobility support. Today, with network based mobility management, there is no way for the UE to know the type of address.

> routing paths between any source and the MN while offloading traffic

I agree, IMO, this is basic requirement of DMM; but I do not see this approach as different, it is complementary.

BR,
Pierrick

> the type
> > > >> differently according to the associated topological anchor
> point?
> > > Hmm, yes, possible.

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 21 Mar 2012 15:59:33 -0700

Hi Pierrick,

Catching up on DMM threads, have been sleeping for a while, some comments
woke me up :)

I agree with you. IMO, to achieve DMM we need:

1.) Localized Gateway Selection. The ability for the network to assign a
anchor point closer to the UE location. Ex: Geo-location, RNC ID ... Most
already got in Rel-10.

2.) Once the session is created and the UE moves to a new location. There
should be a new gateway assignment.  The network should continue to
advertise both the prefixes, but the advertised prefixes should have the
proper color to distinguish between those prefixes.

3.) Network should set up tunneling for the old prefixes, to the prev
anchor. It should deprecate the older prefixes.

4.) UE should use enhanced SAS schemes to use the new prefix for the new
flows.

5.) Over time, once the old flow die, the tunnel to the prev home is gone
and the UE has optimized traffic flows.

This introduces simple changes into the mobility architecture and most
semantics are already there in one form, or the other. The missing aspect is
the type of Address and how we enable the UE to leverage that aspect and
make Source Address selection and also for the network to manage those
prefixes in a proper way. To that affect, I agree this is one important
requirement.

-- 
Regards
Sri

On 3/19/12 3:16 AM, "[email-masked]" <[email-masked]>
wrote:

> of address. IMHO, it is a requirement for the UE to play with more than one IP
> address and select the more appropriate source address according the
> topological anchor point. DMM is clearly one use-case but, this feature is
> also required for offload purpose in current centralized network based
> mobility. The ongoing proposals for RA extensions, that allow to distinguish
> anchored from local prefix, are interesting. Now, the UE shall have the
> intelligence to make the source address selection according to prefix
> sophisticated selection behavior may be required, typically, policies based
> selection, e.g. offload policies.
> 
> Pierrick

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 21 Mar 2012 16:07:03 -0700

Hi Luowen,

Address selection is not the property of a MIP client. An host can obtain IP
addresses from different prefixes, each prefix has certain properties,
exactly as what IPv6 already has, link-local, global .. Now there additional
properties, local prefix/home network/CoA/HoA which are mobility specific.
So, this has nothing to do with PMIP or CMIP client, but rather about
coloring of prefixes and about evolving source address selection rules.

Regards
Sri

On 3/19/12 12:44 AM, "[email-masked]" <[email-masked]> wrote:

> differently. Some modification may be needed to let mobile node to have such
> intelligence. 
> But the question is, one of principles of PMIP is not to touch mobile node.
> And you know, MIP already supports distinguishing between HoA and CoA in
> mobile node.

---

From: [email-masked]
Date: Thu, 22 Mar 2012 09:29:46 +0800

Hi Sri:

Thank you for your response. Yes, I agree with you, coloring of prefixes 
can be used this way, of course. I am just considering address selection 
from DMM's point of view and a MIP client can distinguish a home prefix or 
a local prefix already. Another question, supporting prefixes coloring is 
a mandatory requirement for all IPv6 client?

BR
Luowen

Sri Gundavelli <[email-masked]> 
2012/03/22 07:07

收件人
<[email-masked]>, Marco Liebsch <[email-masked]>, 
"[email-masked]" <[email-masked]>
抄送
<[email-masked]>, "[email-masked]" <[email-masked]>
主题
Re: [DMM] 答复: Re:  New DMM draft: 
draft-bernardos-dmm-distributed-anchoring-00.txt

Hi Luowen,

Address selection is not the property of a MIP client. An host can obtain 
IP addresses from different prefixes, each prefix has certain properties, 
exactly as what IPv6 already has, link-local, global .. Now there 
additional properties, local prefix/home network/CoA/HoA which are 
mobility specific. So, this has nothing to do with PMIP or CMIP client, 
but rather about coloring of prefixes and about evolving source address 
selection rules.

Regards
Sri

Hi Carlos and Marco, 

As Marco said 

BR 
Luowen

---

From: jouni korhonen <[email-masked]>
Date: Thu, 22 Mar 2012 08:20:27 +0200

Sri,

> should be a new gateway assignment.  The network should continue to

Assuming most of the applications/communication would be happy with
addresses that come and go within a limited but not too small area..
say a L2 segment that contains multiple access points. How important
it is then to reassign the "wide area mobility providing" anchor for
the remaining flows?

I would also keep the minimizing tunneling setup and amount of tunnel
state in the network as one design criteria.

> proper color to distinguish between those prefixes.

Agree.

> anchor. It should deprecate the older prefixes.

See above about tunnels. These tunnels are essentially per prefix (or
even per address?) and a MN might soon be dragging quite few of those
along when it moves. I am a bit worried that the excess tunneling is
what we easily end up with..

> 4.) UE should use enhanced SAS schemes to use the new prefix for the new

If you manage to deprecate an old prefix in 3) then new prefixes in 4) are
preferred automatically.. assuming the end host does existing RFC3484 to
any decent level.

- Jouni