Subject: Re: [DMM] Elements of a DMM Solution

From: Peter McCann <[email-masked]>
Date: Thu, 1 Aug 2013 16:02:19 +0000

Hi, Marco,

Marco Liebsch wrote:
> 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
>> 
>> 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.

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.

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

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.

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

Agree that database update details are a property of individual solutions.

>> 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-masked]
>> +1 908 541 3563
>> Rm. C-0105, 400 Crossings Blvd. (2nd floor), Bridgewater, NJ
>> 08807-2863  USA
>> 
>> 
>> _______________________________________________
>> dmm mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/dmm
> _______________________________________________
> dmm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmm

---

From: Peter McCann <[email-masked]>
Date: Thu, 1 Aug 2013 16:07:47 +0000

Hi, Georgios,

Essentially, yes.  And we can talk separately about the solution
for each module.  And different operators might make different
choices for which solution(s) to deploy in their network.

-Pete

[email-masked] wrote:
> 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
> 
> 
> 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:
> 
> 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.
> prefixes can be set up.  This may require a network-queryable database
> database could be stored in something like an HSS or in a DNS server.
> 
> 
> 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.
> 
> 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.
> 
> 
> 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.
> 
> 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
> dramatically improve the performance of network attachment and MN-HA
> 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.
> 
>

---

From: Marco Liebsch <[email-masked]>
Date: Thu, 1 Aug 2013 16:42:05 +0000

Hi Pete,
please see inline.

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

> Module I and the rest of the system we can work independently on the pieces.

Good.

> semantically linked to tunnel-based solutions.

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

> Again, don't like "anchor".  Hopefully the above explanation tells you how

Yes.

> 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

---

From: Peter McCann <[email-masked]>
Date: Thu, 1 Aug 2013 16:55:32 +0000

Hi, Marco,

Marco Liebsch wrote:
>>>> From: [email-masked] [mailto:[email-masked]] On Behalf
>>>> Of Peter McCann
>>>> options for this module:
>>>>  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.
>>> 
>>> 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.

Ah, but the lookup from one IP address to another that you refer to
only happens when there is a tunnel or NAT binding.  Routing-based
solutions don't need this.

The mapping I am talking about is from the authenticated MN identifier
at the time it attaches or moves to an access router, to a set of IPs
currently assigned to that MN.  The Module I needs to find the set of
addresses that the MN owns, and then decide which of those addresses it
can serve with a network-based DMM by making them on-link, and setting
up forwarding/tunnel/NAT/whatever state in the network to make that
happen.

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

Do you think we can come up with a different term?  It needs to refer to
the point in the network that a given address would route to, if there were
no special DMM state in the network modifying this forwarding.  It shouldn't
be semantically coupled to the path that packets take when the MN has moved
away from this point and the retained address is no longer completely
topologically aggregateable.

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

Ok.  Maybe you can suggest a better term.

>>>> 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.
>>> 
>>> function, or attachment point according to your terminology). Who
>>> updates the database is up to a particular solution.
>> 
> 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.

Again, such a binding is only needed for NAT and tunnel-based redirection.
A routing solution would just route the addresses according to its forwarding
tables.

The part that is common to all solutions is figuring out which addresses are
owned by the MN and setting up state in the network to get the packets addressed
to those addresses to the current point of attachment.

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