Re: Preparing for DMM future steps and rechartering

Hi, Sri,

Even if we agree that those services are necessary (and I would point out
once again that most of them are not beneficial to the end-user) I don't
think we should be architecting the network in such a way that we lose the
basic benefits of IP (shortest path routing and fault-tolerance).  We can
implement those services without taking all the packets to a central location;
maybe just the first packet or meta-information about the first packet can
be taken to an SDN controller that can make some decision and pass it down
to the user plane.

I really don't think this is such fantastic science-fiction. ;)

-Pete

Sri Gundavelli (sgundave) wrote:
> Hi Pete,
> 
>> As for "mobility anchor" I am not sure what is your definition of that
>> term. If you mean some router in the network that the packets for a
>> given MN's
> 
> 
> My definition of a "mobility anchor" is the traditional definition that
> we are familiar with. Its the entity that's hosting the subscriber
> session and that is HA in CDMA, HA in WiMAX, GGSN/PGW in GSM networks
> and LMA in generic PMIP-based architectures. Now, if that entity is in
> the routing path is one aspect, or relocation of the subscriber state
> between two such nodes is another aspect, but eliminating that function
> entirely from the network is interesting :). Probably, if the view that
> mobile architecture is all about IP address continuity and hence just a
> routing problem, then that may be it.
> 
> The proposals on the table fail to acknowledge the existence of the core
> service functions in mobility architecture such as Charging, LI, DPI,
> Policy Š and when such constraints are removed, sure, its a host route
> that does all the magic. The assumption that there will be a single node
> mobility architecture and that node is nothing but either a base station
> or a cell-site router is interesting, but it is fine with me.
> 
> On a lighter note, In 80's I grew up watching the old StarTrek series
> and most of my pre-teen years I lived in Star ship enterprise in
> Andromeda Galaxy. That first-hand experience with "Transporter", "Beam
> Us Up", "Phasers", "Telepresence" Š today makes me accept any new
> technology that gets beamed at me. Anchor-less mobile network is another
> in that list that I can accept and live with :) :)
> 
> 
> 
> 
> Regards
> Sri
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> On 11/11/13 1:17 PM, "Peter McCann" <[email protected]> wrote:
> 
>> Hi, Sri,
>> 
>> Sri Gundavelli (sgundave) wrote:
>>> Hi Pete,
>>> 
>>> I'm not sure, I agree with this, or understand this to be precise. I
>>> do not know know CP (in the form of PMIP, GTP or some other protocol
>>> XYZ) can be completely eliminated. There needs to be some interface
>>> between the access gateway and the mobility anchor.
>> 
>> As I said in jabber during the meeting we need to carefully define
>> these terms.
>> 
>> Let's try to use the term MAG consistently.  It means the first node
>> that can see IP packets from the MN.  In my mind this should be
>> co-located with the L2 termination point.
>> 
>> As for "mobility anchor" I am not sure what is your definition of that
>> term. If you mean some router in the network that the packets for a
>> given MN's assigned IP address are delivered, then that entity can
>> change over the period of time the address is assigned to a given MN. 
>> IMHO when the address is assigned, that node should be the MAG to which
>> the MN is attached at the time of assignment.  You can do this by
>> choosing the pool of addresses that are normally routed to the MAG. 
>> When the MN moves, the "mobility anchor" can be changed if the routing
>> tables are updated.
>> 
>>> I assumed your's, Marco's and Ryuji's goal is for eliminating the
>>> tunnel, which I don't believe it can be achieved, but still thought we
>>> can discuss this.
>> 
>> If we can change the "mobility anchor" to always be the current MAG
>> while the MN is in the same domain (or perhaps the same part of a
>> domain) then there will not be a need for tunnels during that period of
>> time.  You need a tunnel when you move outside the domain under which
>> routing protocols are scalable.  This can be a client-MIP tunnel
>> because there won't be much need to update it, assuming the new CoA is
>> managed in the same way by whatever network the MN is on at that time.
>> 
>>> IMO, its not just about inserting a RIB route and redistributing it,
>>> but even there in DP there is a state transfer needed  from the CP and
>>> the DP. Starting point appears like a simple route propagation, very
>>> soon it will end up with a bunch of state that gets moved between the
>>> two nodes.
>> 
>> MAG authenticates the MN when it attaches/moves in.  Authentication
>> gives an MN ID.  MN ID is used to lookup IP addresses currently
>> assigned. UPDATE is generated for those IPs to attract packets to the
>> current MAG. Mission accomplished.
>> 
>>> But, may
>>> be I don't understand the ideas clearly on eliminating CP and
>>> eliminating tunnels. I'm not going to oppose this, I don't see this
>>> converging, IMHO.
>> 
>> I think you mean the discussion will not converge, when Alex
>> interpreted this to mean the routing tables won't converge... anyway, I
>> hope we can consider routing protocols as one way to accomplish
>> localized mobility management.
>> 
>> -Pete
>> 
>>> 
>>> 
>>> 
>>> 
>>> Regards
>>> Sri
>>> 
>>> 
>>> 
>>> On 11/10/13 3:13 PM, "Peter McCann" <[email protected]> wrote:
>>> 
>>>> Hi, Sri,
>>>> 
>>>> I think you will agree that PMIP is a control protocol for setting up
>>>> tunnels.  A tunnel implies that we are not using the destination IP
>>>> of the inner packet for routing and by definition will lead to a
>>>> non-optimal route and a bit of state on some box that can fail and
>>>> lose that state.
>>>> 
>>>> I hope that DMM can consider other approaches such as injecting
>>>> routes from the latest L2-attachment point into the access network,
>>>> which is a truly Distributed Mobility Management protocol for getting
>>>> the packets to the mobile node.  It will lead to more optimal routes
>>>> and more robust fault-tolerant operation of the network.
>>>> 
>>>> I think we can continue to use the term MAG to apply to that first-
>>>> hop router which is hopefully co-located with the L2 termination
>>>> point (it may not be so in every technology depending on the extent
>>>> to which that technology has evolved to support truly Distributed
>>>> operation). Anything that happens below the MAG (between the MAG and
>>>> the L2 termination point) should be out of scope and we should not
>>>> define any protocol there and we should discourage any separation
>>>> between the two.
>>>> 
>>>> However, we should not require the MAG to run any form of PMIP
>>>> because tunnels should not be required in the architecture.  We
>>>> should not require an LMA, because this would imply a central point
>>>> of state maintenance and possibility of failure.
>>>> 
>>>> It is fine to consider a split between CP and DP but I thought we had
>>>> agreed that any discussion of the protocol to use on such an
>>>> interface would be out of scope for this WG.  IMHO we should leave
>>>> that to the Wireless & Mobile Working Group of ONF.
>>>> 
>>>> Now, the proponents of OpenFlow and other CP/DP splits have argued
>>>> that it is better to centralize the algorithms such as routing
>>>> protocols on a logically centralized server or servers with a
>>>> synchronized global view of the network. I have no problem with that,
>>>> in which case this centralized controller just needs to get notified
>>>> about the MN's current attachment point, so it can install the routes
>>>> (or tunnels, if an operator wishes to use them) into the DP. But, the
>>>> mechanisms for doing so are out of scope for the DMM WG because we
>>>> are not working on a CP/DP split.  I think it would be appropriate
>>>> for the DMM WG (which exists in the IETF, a standards body that has a
>>>> long history of developing distributed and fault-tolerant routing
>>>> protocols) to describe a more distributed alternative, building on
>>>> foundational Internet technologies such as I-BGP, in such a way that
>>>> will bring down the costs, reduce the latency, and increase the
>>>> robustness of wireless access networks.
>>>> 
>>>> I actually don't think we need to define any new extensions or IEs
>>>> for BGP; I would like to read more about Ryuji's proposed extensions
>>>> here. All we need is for the MAG to learn what IPs have been assigned
>>>> to the MN, decide which of those IPs are in the scope of the local
>>>> AS, and inject routes for those prefixes to itself.  We could work on
>>>> alternative mechanisms for discovering this list of addresses - the
>>>> fundamental requirement is that we use an authenticated MN ID
>>>> (probably an NAI) as an index to lookup the set of IPs in a
>>>> distributed database. I've proposed using DNS for this but there are
>>>> other alternatives. We also need a way to make sure the latest UPDATE
>>>> gets used by all the BGP peers. I've proposed putting a timestamp in
>>>> LOCAL_PREF but there are probably other alternatives.
>>>> 
>>>> It would also be nice to have a well-defined fall-back mechanism in
>>>> case the MN moves to a different AS or just too far from the original
>>>> MAG, in which case the I-BGP approach wouldn't scale.  For these
>>>> cases, I think a client MIP tunnel to an HA located in the original
>>>> AS for each assigned IP address would be ideal. The HA can behave
>>>> just like the MAGs in that domain, injecting routes when MNs
>>>> establish tunnels to it so as to attract the packets to themselves
>>>> (this would be the routing equivalent of the proxy-ARP or proxy-ND
>>>> mechanism that works on just a single home link in MIPv4 or MIPv6). 
>>>> We should work on mechanisms to enable dynamic assignment of local
>>>> HAs to MNs and dynamic establishment of security associations that
>>>> don't require AAA and associated round-trips to the home network.
>>>> Because the HA is associated with the original MAG that assigned the
>>>> address, this may involve some DHCP extensions.  There is already a
>>>> way to assign the HA IP address but we will need new extensions to
>>>> carry the HA credentials to the MN (maybe just an HA DNS name so the
>>>> MN can use DANE to retrieve a public key).
>>>> 
>>>> I think something like the path I've outlined above would make a good
>>>> work plan for the future of DMM.
>>>> 
>>>> -Pete
>>>>