[multrans] Architecture as part of the analysis in section 4 of the Problem Statement

[Tom Taylor <[e-mail]>]

Could I suggest that we present a basic architecture for each of the 
three functions (acquisition, control signalling, distribution) in our 
analysis. For instance (to use an example I'm not really sure of, so 
I'll be happy to be corrected), address acquisition begins with the 
receiver and the channel list server, I think. The receiver uses some 
sort of signalling to the channel list server to acquire the <S, G> pair 
for the desired channel. First thing we have to do is identify the 
functions along the way that carry the request from the receiver to the 
channel list server.

Next problem: does the <S, G> supplied by the channel list server match 
the IP version supported by the receiver? If so, no problem. If not, 
some function has to translate the addresses. Where should that function 
be located, and where does it get the new addresses from? This gets 
nuanced by whether the access network is running the same IP version as 
the receiver. If it is, the original <S, G> version has to be recovered 
somewhere in the middle of the path in the control signalling stage. How 
is that going to happen?

Lots of fruitful lines of enquiry there, all shaped about a basic 
architecture that starts with two entities and ends up needing more.

One thing the present version of the Problem Statement is missing is 
what could be a mapping/translation function (in some possible 
solutions) or a coordination function (e.g. the one used in Dr. Xu's 
draft for directing ASM traffic through the transit network) in other 
possible solutions. Perhaps you assumed it was part of the interworking 
functions that have been identified, but you really need it for address 
acquisition and content distribution too.

If you want me to send detailed text to show what I'm talking about, let 
me know.

Tom Taylor