Subject: [arch-d] Thoughts about mobility, multi-homing, and architecture

From: Pekka Nikander <[email-masked]>
Date: Thu, 23 Nov 2006 12:35:18 +0200

John Day and I have expressed our opinions that mobility and multi- 
homing are architecturally similar, implying that maybe we could  
address them in a unified way.  Some people disagreed.  I think much  
depends on your point of view, and in this message I try to clarify  
that.  In a way, I am restating much which Joel already stated, but  
from a subtly different point of view, trying both to dive still  
somewhat deeper and to expand the discussion to application-level  
aspects.

Unfortunately, in order to get to my point, I must start from quite  
far away.  Hence, for the impatient, it may be better to read this  
rather long message in the reverse order, starting from the  
discussion (search for "Discussion") and then referring back to the  
assumptions.

Starting point
==============

As a starting point, I take the following premises or assumptions:

A1. Application-level resources are the main entities we are  
interested in.  They may be named in different ways, the exact  
details of which is outside the scope of the current focus.

A2. Application-level entities are often logically aggregated due to  
different factors, including fate sharing, security privileges,  
mobility, etc.  This application-level aggregation should be kept  
distinct from network-address-level aggregation.

A3. The routing system is based on the hop-by-hop paradigm, where the  
routers have forwarding tables that use routing-level addresses as  
input for the forwarding decision.

A4. Completely flat addressing is out of scope due to practical  
constraints to the forwarding tables and the routing system.

A5. To implement A4, the routing-level addresses (locators) are  
somehow aggregateable.  That is, the addressing name space has  
internal structure (topology) that allows a larger or "more- 
aggregated" address range (e.g. one with a shorter prefix) to denote  
an area that confines a number of smaller or "less-aggregated"  
address ranges (e.g. ones with longer prefixes).  [Note that this  
definition does not mandate a tree-like addressing name space  
topology that we have today, but still allows it.]

Now, theoretically speaking, as the purpose of the aggress  
aggregation is to embed into the address some partial information  
about the location of the said address within the network graph,  
thereby relieving some burden from the forwarding tables and routing  
system, it immediately follows that the parts of the network graph  
where an address may be located at is confined by the address itself.

In more practical terms, the addresses become names of locations  
within the network graph, i.e., locators.  That is, given a specific  
address, there are only a limited number of locations within the  
network graph where the address may "be".  In a typical system, such  
as those used today for IPv4 and IPv6, that "limited number of  
locations" equals to the subnet identified by the address prefix.

Still more practically, what I mean is that due to the assumptions  
made about the forwarding parading and network layer addressing, the  
addresses in the system are names of locations (points of attachment)  
in the network, and not e.g. location-independent names of mobile hosts.

Basics of multi-homing
======================

This structure leads to a situation where we apparently must make a  
distinction between two different types of "multi-path"*:

P1. In the network graph, there may be alternative routing paths  
between two areas that are named with some given, unique address  
ranges.  In today's terms, this would be reflected by having multiple  
routing table entries for a given prefix.  This is what Joel called  
"multi-pathing" in his message (http://www1.ietf.org/mail-archive/web/ 
architecture-discuss/current/msg00682.html ).

P2. In the network graph, there may be areas (including single nodes)  
that are identified by more than one address ranges.  This is what  
Joel called "multi-homing".

Note that the underlying network graph may be identical in cases P1  
and P2.  The only difference is how we decide to name locations,  
i.e., in address assignment.  In P1 we assign only one range of  
addresses to the "multi-homed" location while in P2 we assign two or  
more.  Further note that this naming decision is apparently motivated  
by the assumptions A4 and A5, in an attempt to make the address space  
topology and the topology of the network graph match in such a way  
that the size of the routing and forwarding tables can be reduced.

[Footnote *) This is a point where I hope to be wrong.  Making the  
distinction between multi-path at the routing level vs. multi-path at  
a level above does not "feel" nice.  However, to me this seems to be  
an implication from assumptions A3-A5.  Finding alternative solutions  
would be very good, but given the constraints on the size of the  
forwarding/routing tables, propagation times, and routing  
computation, I find it unlikely that any practical alternatives exist.]

To summarise so far:  Using hop-by-hop forwarding with aggregateable  
addresses leads to a situation where "area" (subnet) multi-homing can  
be solved either by adding alternative routes into the routing table  
or assigning multiple address ranges.

Nothing new.  Just dissecting the background assumptions.

Generalisation I, or Application Multi-homing
=============================================

So far we have only considered the network graph and the addressing  
name space.  Let us now consider application-level entities.

An application-level entity (resource) may be distributed, or be  
available through multiple points at the network graph.  For example,  
the underlying server host may be multi-homed, the application entity  
may be location-dependent and implemented at several distinct server  
hosts, or the entity may be genuinely distributed and implemented by  
a distributed server farm.

Now we seem to have even more choices than in the case of network- 
graph-level multi-homing.  I'll describe these as chains of identifiers.

C1. Top-most entity name -> One "multi-pathed" address (P1) ->  
Alternative routes

C2. Top-most entity name -> Multiple alternative addresses (P2) ->  
One route

C3. Top-most entity name -> Multiple alternative intermediate entity  
names (e.g. host names) -> P1 -> One Route

Of course, if supported by the underlying system, these levels of  
flexibility can be combined:

C4. Top-most entity name -> Alternative super-entity names -> P2 ->  
Alternative routes

[Of course, intermediate indirections (C3) may be recursive.]

To summarise and generalise the discussion so far, we can state that  
from a high-level architectural point of view, multi-homing is  
nothing more one-to-many mappings as one resolves higher-layer  
identifiers into lower-layer identifiers.  The differences lie when  
there are one-to-many mappings and when simple one-to-one mappings.

Considering a single indirection step, the most important design  
choice then is when, exactly, one of the alternative lower-layer  
identifiers is chosen for the purposes of delivery.  To summarise the  
more-than-two-decades old wisdom: Be lazy, bind late.

Mobility
========

Consider now mobility.  From the present point of view, we can state  
that mobility is nothing more than dynamic mappings as one resolves  
higher-layer identifiers into lower layer identifiers.

Analogous to the multi-homing chains C1-C4 above, we can present  
mobility chains:

M1. Stable entity name -> Stable address -> Dynamic route updates  
(host routing)

M2. Stable entity name -> Dynamic, updateable address -> Stable routes

M3. Stable entity name -> Dynamic, updateable intermediate entity  
name -> Stable address -> Stable routes

M4. Stable entity name -> Dynamic super-entity name -> Dynamic  
address -> Dynamic route

I will skip the longer discussion here, as it would be isomorphic to  
the multi-homing discussion above, merely replacing mapping  
alternatives with temporal dynamics.

MANETs are prototypical examples of M1.  NetLMM can be also  
considered as a peculiar example of M1.

MIP, NEMO, HIP (and potentially SHIM6 based mobility) are all  
examples of M2, with just different choices for the name spaces.

I am not aware of any major examples of M3, but I could imagine they  
could be found in various middleware frameworks.  And I think SIP  
could also offer such examples.

Discussion
==========

By now, the structural (architectural?) parallels between multi- 
homing and mobility should be clear:

Layer          Multi-homing                  Mobility

Routing        Traditional, routing-         Micro mobility
                based site multi-homing       e.g. MANETs

Routing-       (GSE?)                        So called edge mobility,
Addressing                                   e.g. NetLMM
boundary

Addressing     Multi-address multi-homing,   Most node mobility  
protocols,
                e.g. SHIM6, GSE               e.g. MIP and HIP

                                              Tunnelling-based  
solutions,
                                              e.g. NEMO and MOBIKE

Application-   Multiple A/AAAA RRs           DynDNS
Addressing
boundary                                     Renumbering,
                                              (but on a different  
time scale)

Application    Distributed applications,     Application mobility,
                e.g. location dependent ones  e.g. process migration

[Footnote: I am not sure about the "right" positioning of GSE.  The  
position of NetLMM could also be discussed; I'd be tempted to  
classify it as a "routing" solution, but others apparently disagree.]

Hence, it is this point of view that I say that mobility and multi- 
homing are architecturally quite similar.

There is one thing that I haven't considered at all, on purpose: Time  
scales, including make-before-break vs. break-before-make.  They make  
a difference.  But that's one level down towards the details, in my  
opinion.  They are still architectural, but not the highest point of  
view.  Anyway, this message is long enough already now; the  
differences would warrant a separate message.

The big question is whether the similarities and co-occurring usage  
scenarios are plausible enough so that mobility and multi-homing  
should be handled in an architecturally unified way, or whether the  
differences are so big and the phenomena so separate that the added  
minor complexity does not pay off.

By now you should be able to guess my current opinion.

--Pekka Nikander

_______________________________________________
Architecture-discuss mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/architecture-discuss

---

From: "Bound, Jim" <[email-masked]>
Date: Thu, 23 Nov 2006 22:02:45 -0500

Pekka,

Good analysis thanks I will think about this for some time now not input
to take lightly.

/jim 

> -----Original Message-----
> From: Pekka Nikander [mailto:[email-masked]] 
> Sent: Thursday, November 23, 2006 5:35 AM
> To: [email-masked]
> Subject: [arch-d] Thoughts about mobility, multi-homing, and 
> architecture
> 
> John Day and I have expressed our opinions that mobility and 
> multi- homing are architecturally similar, implying that 
> maybe we could address them in a unified way.  Some people 
> disagreed.  I think much depends on your point of view, and 
> in this message I try to clarify that.  In a way, I am 
> restating much which Joel already stated, but from a subtly 
> different point of view, trying both to dive still somewhat 
> deeper and to expand the discussion to application-level aspects.
> 
> Unfortunately, in order to get to my point, I must start from 
> quite far away.  Hence, for the impatient, it may be better 
> to read this rather long message in the reverse order, 
> starting from the discussion (search for "Discussion") and 
> then referring back to the assumptions.
> 
> 
> Starting point
> ==============
> 
> interested in.  They may be named in different ways, the 
> exact details of which is outside the scope of the current focus.
> 
> A2. Application-level entities are often logically aggregated 
> due to different factors, including fate sharing, security 
> privileges, mobility, etc.  This application-level 
> aggregation should be kept distinct from 
> network-address-level aggregation.
> 
> A3. The routing system is based on the hop-by-hop paradigm, 
> where the routers have forwarding tables that use 
> routing-level addresses as input for the forwarding decision.
> 
> A4. Completely flat addressing is out of scope due to 
> practical constraints to the forwarding tables and the routing system.
> 
> A5. To implement A4, the routing-level addresses (locators) 
> are somehow aggregateable.  That is, the addressing name 
> space has internal structure (topology) that allows a larger 
> or "more- aggregated" address range (e.g. one with a shorter 
> prefix) to denote an area that confines a number of smaller 
> or "less-aggregated"  
> address ranges (e.g. ones with longer prefixes).  [Note that 
> this definition does not mandate a tree-like addressing name 
> space topology that we have today, but still allows it.]
> 
> aggregation is to embed into the address some partial 
> information about the location of the said address within the 
> network graph, thereby relieving some burden from the 
> forwarding tables and routing system, it immediately follows 
> that the parts of the network graph where an address may be 
> located at is confined by the address itself.
> 
> In more practical terms, the addresses become names of 
> locations within the network graph, i.e., locators.  That is, 
> given a specific address, there are only a limited number of 
> locations within the network graph where the address may 
> "be".  In a typical system, such as those used today for IPv4 
> and IPv6, that "limited number of locations" equals to the 
> subnet identified by the address prefix.
> 
> Still more practically, what I mean is that due to the 
> assumptions made about the forwarding parading and network 
> layer addressing, the addresses in the system are names of 
> locations (points of attachment) in the network, and not e.g. 
> location-independent names of mobile hosts.
> 
> Basics of multi-homing
> ======================
> 
> This structure leads to a situation where we apparently must 
> make a distinction between two different types of "multi-path"*:
> 
> P1. In the network graph, there may be alternative routing 
> paths between two areas that are named with some given, 
> unique address ranges.  In today's terms, this would be 
> reflected by having multiple routing table entries for a 
> given prefix.  This is what Joel called "multi-pathing" in 
> his message (http://www1.ietf.org/mail-archive/web/
> P2. In the network graph, there may be areas (including 
> single nodes) that are identified by more than one address 
> ranges.  This is what Joel called "multi-homing".
> 
> Note that the underlying network graph may be identical in 
> cases P1 and P2.  The only difference is how we decide to 
> name locations, i.e., in address assignment.  In P1 we assign 
> only one range of addresses to the "multi-homed" location 
> while in P2 we assign two or more.  Further note that this 
> naming decision is apparently motivated by the assumptions A4 
> and A5, in an attempt to make the address space topology and 
> the topology of the network graph match in such a way that 
> the size of the routing and forwarding tables can be reduced.
> 
> [Footnote *) This is a point where I hope to be wrong.  
> Making the distinction between multi-path at the routing 
> level vs. multi-path at a level above does not "feel" nice.  
> However, to me this seems to be an implication from 
> assumptions A3-A5.  Finding alternative solutions would be 
> very good, but given the constraints on the size of the 
> To summarise so far:  Using hop-by-hop forwarding with 
> aggregateable addresses leads to a situation where "area" 
> (subnet) multi-homing can be solved either by adding 
> alternative routes into the routing table or assigning 
> multiple address ranges.
> 
> So far we have only considered the network graph and the 
> addressing name space.  Let us now consider application-level 
> entities.
> 
> An application-level entity (resource) may be distributed, or 
> be available through multiple points at the network graph.  
> For example, the underlying server host may be multi-homed, 
> the application entity may be location-dependent and 
> implemented at several distinct server hosts, or the entity 
> may be genuinely distributed and implemented by a distributed 
> server farm.
> 
> Now we seem to have even more choices than in the case of 
> network- graph-level multi-homing.  I'll describe these as 
> chains of identifiers.
> 
> C1. Top-most entity name -> One "multi-pathed" address (P1) 
> -> Alternative routes
> 
> C2. Top-most entity name -> Multiple alternative addresses 
> (P2) -> One route
> 
> C3. Top-most entity name -> Multiple alternative intermediate 
> entity names (e.g. host names) -> P1 -> One Route
> 
> Of course, if supported by the underlying system, these 
> levels of flexibility can be combined:
> 
> C4. Top-most entity name -> Alternative super-entity names -> 
> P2 -> Alternative routes
> 
> To summarise and generalise the discussion so far, we can 
> state that from a high-level architectural point of view, 
> multi-homing is nothing more one-to-many mappings as one 
> resolves higher-layer identifiers into lower-layer 
> identifiers.  The differences lie when there are one-to-many 
> mappings and when simple one-to-one mappings.
> 
> Considering a single indirection step, the most important 
> design choice then is when, exactly, one of the alternative 
> lower-layer identifiers is chosen for the purposes of 
> delivery.  To summarise the more-than-two-decades old wisdom: 
> Be lazy, bind late.
> 
> Mobility
> ========
> 
> Consider now mobility.  From the present point of view, we 
> can state that mobility is nothing more than dynamic mappings 
> as one resolves higher-layer identifiers into lower layer identifiers.
> 
> Analogous to the multi-homing chains C1-C4 above, we can 
> present mobility chains:
> 
> M1. Stable entity name -> Stable address -> Dynamic route 
> updates (host routing)
> 
> M3. Stable entity name -> Dynamic, updateable intermediate 
> entity name -> Stable address -> Stable routes
> 
> M4. Stable entity name -> Dynamic super-entity name -> 
> Dynamic address -> Dynamic route
> 
> I will skip the longer discussion here, as it would be 
> isomorphic to the multi-homing discussion above, merely 
> replacing mapping alternatives with temporal dynamics.
> 
> I am not aware of any major examples of M3, but I could 
> imagine they could be found in various middleware frameworks. 
>  And I think SIP could also offer such examples.
> 
> Discussion
> ==========
> 
> By now, the structural (architectural?) parallels between 
> multi- homing and mobility should be clear:
> 
> Tunnelling-based solutions,
>                                               e.g. NEMO and MOBIKE
> 
>                                               (but on a 
> different time scale)
> [Footnote: I am not sure about the "right" positioning of 
> GSE.  The position of NetLMM could also be discussed; I'd be 
> tempted to classify it as a "routing" solution, but others 
> apparently disagree.]
> 
> Hence, it is this point of view that I say that mobility and 
> multi- homing are architecturally quite similar.
> 
> There is one thing that I haven't considered at all, on 
> purpose: Time scales, including make-before-break vs. 
> break-before-make.  They make a difference.  But that's one 
> level down towards the details, in my opinion.  They are 
> still architectural, but not the highest point of view.  
> Anyway, this message is long enough already now; the 
> The big question is whether the similarities and co-occurring 
> usage scenarios are plausible enough so that mobility and 
> multi-homing should be handled in an architecturally unified 
> way, or whether the differences are so big and the phenomena 
> so separate that the added minor complexity does not pay off.
>

---

From: "Bound, Jim" <[email-masked]>
Date: Thu, 23 Nov 2006 22:02:45 -0500

Pekka,

/jim