Jeroen van der Ham wrote:
I agree that George's multi-layer pathfinding seems very similar to the AutoBAHN approach.
Freek in his thesis argues that this approach can work, but does not have a way to handle incompatibilities. Freek uses an example where there are two ways to map Ethernet onto SONET, and the source and destination use different mappings. A path through the network will have to do a remapping along the way, otherwise it can't work.
I do not see how a collapsed topology can ever solve such a problem. Perhaps it can, but it will have to specifically supported by the stitching framework.
The approach that must be taken for collapsing is: - have a path find agent find multiple paths - let the stitching framework try each path in order till a valid path is found. The consequence is that in rare situations no valid path may be found, even though one might be available. If these situations are sufficiently rare, the simplification that this approach brings may outweigh the disadvantage of false negatives. So I think this may be a viable approach, even though it is different than what I have pursued so far. This is not to say I have no concerns about topology collapsing and stitching approaches. I have two concerns about the stitching framework, and one about topology collapsing. For stitching, I like to make sure there is no implicit assumption of order in network layers, or worse, that the number of network layers is fixed (e.g. as in layer 1-7 in the OSI model), or that a layer may only occur once in an adaptation stack. - layers come and go. We got rid of the ATM layer, and some people try to get rid of the SONET layer(s). However, just the same, we add (sub)layers for Ethernet and OTN. - The order can not be fixed: it is getting common to see network tunnels, e.g. Ethernet over IP over Ethernet, or simply Ethernet over Ethernet (think Q-in-Q). My concern about layer collapsing is how it handles multiplexing and inverse multiplexing. A SONET circuit in the GLIF community may carry multiple Ethernet connections. At my work, we have an immediate problem that we must describe the relations between these connections -- if the SONET circuit goes does, so will the Ethernet circuits, and our software must know this relations or we will not inform the correct customers. Therefor, we need a network description that is able to describe this relation. I have doubts that this can still work for collapsed topologies. Regards, Freek