Subject: [DMM] Elements of a DMM Solution

From: Peter McCann <[email-masked]>
Date: Tue, 30 Jul 2013 11:09:10 +0000

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.

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.

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.

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.

--
Peter J. McCann
Huawei Technologies (USA)
[email-masked]
+1 908 541 3563
Rm. C-0105, 400 Crossings Blvd. (2nd floor), Bridgewater, NJ  08807-2863  USA

---

From: Marco Liebsch <[email-masked]>
Date: Wed, 31 Jul 2013 23:05:39 +0000

Hi Pete,

I support your proposal. Please see (so far brief) feedback inline.

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf Of
>Peter McCann
>Sent: Dienstag, 30. Juli 2013 13:09
>To: [email-masked]
>Subject: [DMM] Elements of a DMM Solution
>
>"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:
>
>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
>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.

>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? 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.

>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.   

>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.
>
>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
>
>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.
>
>together into an overall system.  To the extent we need to make changes to MN
>implementation practices, we should publish advice in Informational RFCs.
>we should send requirements to other working groups and encourage the work
>to get done.

Makes sense to me. 

marco

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

---

From: <[email-masked]>
Date: Thu, 1 Aug 2013 05:47:47 +0000

Hi Peter,

I agree with the main message of your email, which I am translating into:

*) Define protocol agnostic Functional Framework to build DMM solutions around existing mobility protocols:
   o) can apply to solutions that are solely based on existing IP mobility protocols
   o) can apply to solutions which get support from non mobility protocols

Best regards,

Georgios

________________________________
Van: [email-masked] [[email-masked]] namens Peter McCann [[email-masked]]
Verzonden: dinsdag 30 juli 2013 13:09
To: [email-masked]
Onderwerp: [DMM] Elements of a DMM Solution

IV. Security