Subject: [DMM] Enhanced mobility anchoring

From: h chan <[email-masked]>
Date: Thu, 26 Mar 2015 17:54:32 +0000

I was asked to provide more explanation about anchoring.

Distributed mobility management may have anchoring functionality in different networks so that routes do not need to traverse a centralized anchor.

Yet, the definition of "anchoring function" (AF) in RFC 7333 is in terms of route advertisement for the IP address only, and such function is available in multiple network.

So what are the rest of the functions?

Such functions may tend to cause the packets to traverse certain nodes.

Consider a typical handover scenario: MN moves from Net1 moves to Net2, and CN is in Net3

The old AR (AR1) of MN in Net1 performs RA for IP1; the new AR (AR2) of MN in Net2 performs RA for IP2; the AR (AR3) of CN in Net3 performs RA for IP3.

The additional functions at AR1 and AR2 both try to cause the packets of the flow to traverse them. If we call these additional functions part of distributed anchoring function, the question is what they are anchoring.

So according to the definition of AF, AR1 performs AF for IP1; AR2 performs AF for IP2 (not IP1); and AR3 performs AF for IP3.

One approach is to borrow the well known concept of separation of session ID (SID) from routing address. There are tons of papers addressing such separation, and the lack of such separation is considered the fundamental problem of breaking session as an IP address changes during handover.

In line with this separation, the function of anchoring of a session/flow can be separated from that of anchoring an IP address.

The separation of session ID and routing address can be considered a generalization, because the session ID can be anything. An example is HIT in the IETF protocol HIP.

The use of HoA and CoA can be considered a particular case of SID and routing address separation. In using indirection, one IP address (CoA) is used for routing, whereas another IP address (HoA) is used in the socket as part of the SID identification.

Another IETF protocol of such separation is LISP.

In one example of handover scenario the desired path can be:

packet from CN first goes to AR3, to which IP3 is anchored.

it then goes to AR1, to which IP1 is anchored.

it then goes to AR2, to which IP2 is anchored.

What causes the packets of the flow to go this way may be:

AR2 has the location information: the binding of SID of the flow (IP1) to IP address of AR2. It sends this information to AR1.

Such additional function basically tries to cause the packets of the flow (IP1) to traverse AR1 and AR2.

In another example of this same scenario, the desired path is:

packet from CN first goes to AR3, to which IP3 is anchored.

it then goes directly to AR2, to which IP2 is anchored.

What causes the packets of the flow to go this way may be:

AR3 has the location information: the binding of SID of the flow (IP1) to IP address of AR2.

Please let me know if any of these is not clear enough. Thank you.

H Anthony Chan

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 31 Mar 2015 17:07:48 +0000

Hi Anthony,

What you are describing is well addressed by AERO. AERO also addresses
some gaps listed in RFC7429 better than other approaches, and IMHO has
a much cleaner mobility architecture. Please include AERO in your list.

Thanks – Fred
[email-masked]

From: dmm [mailto:[email-masked]] On Behalf Of h chan
Sent: Thursday, March 26, 2015 10:55 AM
To: [email-masked]
Subject: [DMM] Enhanced mobility anchoring

H Anthony Chan