Re: Elements of a DMM Solution

Hi Pete,
please see inline.

On 01.08.2013, at 18:02, "Peter McCann" <[email protected]> wrote:

> Hi, Marco,
> 
> Marco Liebsch wrote:
>> Hi Pete,
>> 
>> I support your proposal. Please see (so far brief) feedback inline.
>> 
>>> -----Original Message-----
>>> From: [email protected] [mailto:[email protected]] On Behalf Of
>>> Peter McCann
>>> Sent: Dienstag, 30. Juli 2013 13:09
>>> To: [email protected]
>>> Subject: [DMM] Elements of a DMM Solution
>>> 
>>> I think that the DMM work can be subdivided into a small number of
>>> "modules", each of which can be implemented in a number of different
>>> ways.
>>> 
>>> 
>>> I. Limited-scope (localized) network-based mobility scheme
>>> 
>>> This is probably what most people have in mind when they think of a DMM
>>> "protocol".  This is the mechanism that gets packets to the current
>>> point of attachment.  We have seen the following proposed as options
>>> for this module:
>>> 
>>>  A. Something based on PMIP
>>>  B. Something based on GTP
>>>  C. Something based on a routing protocol (e.g., BGP)
>>>  D. Something based on SDN
>>> We should be able to "plug in" any of the above solutions to an overall
>>> DMM framework.  This module needs to be signaled when an MN attaches or
>>> changes its point of attachment.  An identifier of the MN and an
>>> identifier of the attachment point should be provided in this signal.
>>> This module needs to interact with the address allocation/management
>>> module to obtain the set of IP prefixes currently in use by the mobile
>>> node, so that redirection/tunneling of packets destined to those
>>> prefixes can be set up.  This may require a network- queryable database
>>> of prefixes that can be indexed by mobile node identifier. This
>>> database could be stored in something like an HSS or in a DNS
>>> server.
>> 
>> Yes, or an IP mobility anchor control plane function, or a registry
>> associated with an SDN controller, or.. something that can treat the
>> MN's IP address (prefix) as identifier and select an appropriate
>> routable locator IP address. I fully support that view that any DMM
>> solution should consider hooks to external (non- mobility) protocols to
>> optimize (D)MM operation and is well aligned with the methodology in our
>> framework draft.
> 
> I don't think the MN's IP address (prefix) will necessarily be the identifier
> of choice.  Perhaps an NAI or other identifier authenticated at the time of
> access is the right one to use.

In terms of routing/switching U-plane traffic to the MN's current point of attachment (aka anchor ;-) it is the IP address that is used as key for a locator lookup. These packets do not carry NAIs. In terms of authentication, you are probably right.



> 
> It's good to have this discussion; once we pin down the interface between
> Module I and the rest of the system we can work independently on the pieces.

Good.

> 
> 
>>> II. Address allocation/management
>>> 
>>> This module lives in both the MN and the network.  The MN maintains a
>>> pool of addresses, each one topologically related to the point of
>>> attachment at the time it was assigned.  The MN should be made aware of
>>> which of its addresses are currently on-link at its current attachment
>>> point, courtesy of Module I.  The MN should maintain information about
>>> how it is using each address so that unused addresses can be released
>>> and in-use addresses can have their leases renewed at the appropriate
>>> times.  Address allocation/deallocation should NOT be coupled to node
>>> mobility.  It should be possible to have a mobility event without
>>> allocating a new address (to avoid excessive numbers of addresses being
>>> allocated) and even if Module I cannot provide network-based relocation
>>> of a prefix, mobility to an attachment point where an address is not
>>> on-link SHOULD NOT trigger deallocation of the address, because the MN
>>> might have a client- based mobility scheme that enables it to continue
>>> using the address (Module III). Some mechanism to renew the lease on
>>> the address from a remote location should be provided, such as
>>> obtaining a global unicast IP address of a DHCP server.  Security
>>> considerations for such remote renewal need to be investigated and
>>> addressed.
>> 
>> So, on-link addresses are routable addresses associated with the MN's
>> current anchor, whereas other addresses (off-link?) are associated
>> with the previous anchor (or point of attachment) and considered deprecated.
>> Correct? 
> 
> I really dislike the term "anchor".  It seems to imply there is a fixed 
> point in the network through which the MN's traffic is flowing and is also
> semantically linked to tunnel-based solutions.
> 

Yes,I understood your comment during today's session.


> When I say "on-link" I mean the prefix is currently advertised in an RA
> on the current link (in IPv6 terms).  The degree to which it is topologically
> aggregateable may vary depending on how far the MN has moved.  It may or
> may not be marked as "deprecated" by the advertising AR; in any case, it 
> is available for use by ongoing sessions or possibly new sessions according
> to logic inside the MN.
> 
> Addresses that are not advertised on-link, if they are still needed, should
> be supported with a client-based tunnel.
> 
>> Dependent on the solution for DMM, this IP address is not
>> routable anymore if imported to the current anchor to enable IP
>> address continuity or remains routable through the MN's previous
>> anchor. In the latter case the MN may have multiple anchors which may
>> have to be added to the address management module, at least in case of
>> client-based mobility.
> 
> Again, don't like "anchor".  Hopefully the above explanation tells you how
> I am defining my terms.

Yes.

> 
>>> Module I must be provided with a list of prefixes currently allocated
>>> to the MN. The database storing this information could be updated by
>>> the network element that allocates the address (e.g., DHCP server) or
>>> could be updated by the MN.  A network element initiated update may be
>>> more appropriate for an HSS-stored database, whereas an MN-initiated
>>> update may be more appropriate for a DNS- based database.
>> 
>> Well, in general this is about a dynamic binding in a database between
>> one or more IP addresses of the MN and associated locator(s).
>> Important is that this can be something else than what is provided by
>> Mobile IP protocols. And this makes sense, as it applies to the
>> routing space above mobility anchor level (southbound to MM U-Plane
>> function, or attachment point according to your terminology).
>> Who updates the database is up to a particular solution.
> 
> Again, I think the binding is from some other identifier (like NAI) to
> a set of currently allocated/assigned IP addresses.  While there are 
> mechanisms to allocate IP addresses using Mobile IP, I don't think they
> necessarily will be used by DMM because most addresses should be 
> topologically correct a the time they are assigned instead of being
> routed through a home agent.
> 

Sure the NAI can be associated with the binding. I was referring to a binding between a continued address after relocation of a Point of attachment and a locator or other routing info to deliver a downlink packet to the MN's current point of attachment. Example BGP resolves the MN's address into a per-host route and associated next hop.

> Agree that database update details are a property of individual 

Ok.

Marco


> 
>>> III. An optional global, client-based mobility scheme
>>> 
>>> Any network-based mobility scheme will necessarily have a limited
>>> scope.  This is especially true in the DMM case because the Internet
>>> attachment points are by definition close to the MN in the access
>>> (visited) network.  Consider a roaming mobile node with home network H
>>> that attaches to visited network V1. It obtains DMM service from V1,
>>> obtaining an IP address topologically routed from the Internet directly
>>> to V1.  Now consider this MN performing a handoff from V1 to another
>>> visited network V2.  V2 has a roaming agreement with H (otherwise the
>>> MN would not be able to get service) but has absolutely no business
>>> arrangement with V1. Therefore, it is impossible for the network-based
>>> mobility scheme to support re-routing or tunneling the packets destined
>>> to the original V1 address to network V2.  We must therefore support
>>> fall-back to a client-based OTT global mobility scheme, using the fact
>>> that both V1 and V2 offer connectivity to the same Internet, if the MN
>>> wants to keep using the address it got while connected to V1.
>>> 
>>> Allocation of a global mobility anchor should be coupled to allocation
>>> of the address for which global mobility is needed.  There are already
>>> DHCP extensions to carry HA IP addresses which could be used for this
>>> purpose.  The MN-HA security association should also be bootstrapped at
>>> this time, so that the establishment of security does not add latency
>>> at the time the global mobility service is invoked.  We need to
>>> investigate whether the current DHCP extension provides the right kind
>>> of HA identifier to the MN or whether a DNS name would be more helpful
>>> in bootstrapping security.
>>> 
>>> The global mobility anchor may invoke Module I to get the HoA-
>>> addressed packets delivered to itself before tunneling them to the MN's
>>> CoA. The MN should make use of Module I for its CoA in its new visited
>>> network to minimize the number of global mobility location update
>>> messages it needs to send to the anchor point.
>>> 
>>> 
>>> IV. Security
>>> 
>>> Module I depends on a secure network access control protocol to provide
>>> an authenticated MN identity.  Similarly, Module III requires
>>> bootstrapping a security association between MN and HA.  So far, the
>>> AAA suite of protocols have been used for this purpose.  However, it
>>> may be possible to further optimize this process and unify the
>>> credentials used by the various nodes if new solutions are
>>> investigated.  Eliminating the round-trip to the home AAA server would
>>> dramatically improve the performance of network attachment and MN- HA
>>> SA establishment.  Making use of DNS-based public key credentials that
>>> can be locally cached may allow the elimination of this round-trip and
>>> improve the scalability of home network infrastructure.
>>> 
>>> These enhancements to security can be decoupled from the rest of the
>>> architecture and investigated separately.
>>> 
>>> 
>>> 
>>> 
>>> I think it's important for the DMM working group to investigate all 4
>>> of the above solution components, even though most people in the group
>>> are probably focused on Module I for now.  We need to understand how
>>> the pieces will fit together into an overall system. To the extent we
>>> need to make changes to MN implementation practices, we should publish
>>> advice in Informational RFCs. To the extent we need to modify protocols
>>> that are outside the scope of DMM, we should send requirements to other
>>> working groups and encourage the work to get done.
>> 
>> 
>> Makes sense to me.
> 
> Ok, good.  Maybe if we can get agreement on the various pieces we can
> arrive at an updated framework document.
> 
> -Pete
> 
>> 
>> marco
>> 
>>> 
>>> 
>>> --
>>> Peter J. McCann
>>> Huawei Technologies (USA)
>>> [email protected]
>>> +1 908 541 3563
>>> Rm. C-0105, 400 Crossings Blvd. (2nd floor), Bridgewater, NJ
>>> 08807-2863  USA
>>> 
>>> 
>>> _______________________________________________
>>> dmm mailing list
>>> [email protected]
>>> https://www.ietf.org/mailman/listinfo/dmm
>> _______________________________________________
>> dmm mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/dmm
> 
> 
>