[DMM] Enhanced mobility anchoring

[h chan <[e-mail]>]

The enhanced mobility anchoring draft has been revised and posted:
https://tools.ietf.org/html/draft-chan-dmm-distributed-mobility-anchoring-02

Changes include the following:

removed the words “anchoring of a session” to avoid disagreement on its meaning. Thanks to offline suggestion from Danny during IETF meeting.

Use the well defined term “flow”. (Session and flow were used interchangeably in previous version.) Thanks to offline suggestion from John.

Reference to other mobility solution drafts are explicitly made, they had been considered from the perspective of anchoring.

Security texts have been improved.

All 3 co-authors have carefully checked before we upload. We are now waiting for your feedback.

Thanks.

H Anthony Chan

From: h chan
Sent: Thursday, March 26, 2015 5:55 PM
To: [e-mail]
Subject: Enhanced mobility anchoring

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