Re: Self routing

["Thomas 'Dent' Mirlacher" <dent@cosy.sbg.ac.at>]

--snip/snip

> I don't think we want to change MPE but come up with an alternative, more
> efficient and more flexible solution.

which set of requirements in mind? MPE probably is not the best solution,
but it works.
it is layer2+layer3, and your proposal would be layer3 - which is fine, 
if you have a specific set of services you'd like to support, but you'll
have troubles supporting a different set of services in an efficient way.

> I agree with Gorry and Harri concerning header compression - we should keep
> this in mind and come up with a design that fully supports it, but we should
> not include it in the encapsulation.

right. - shouldn't the encapsulation just encapsulate the upper layers
(e.g. IP - which is know to work, and cannot be the layer we'd like to
change here), and do it in an efficient way (not only bandwith/troughput-wise,
but also in respect for possible other QoS requirements)

--snip/snip
> one more point: you said that you only use 4 bits of the 13 bits of the PID
> since your hardware can scan only a maximum of 20 PIDs - who or what is
> scanning your 24 bits of the link_sat field? I suppose this is a separate
> box - i.e. one protocol layer up.

one problem is the misuse of the PID here - well or probably i simply don't
understand the usage of the PID in your case.
the PID is used for segmenting the physical channel into several logical
ones, and if you reassign the meaning of the PID for beeing part of your
label thats fine for you, but on a transponder where video and data is
mixed, you run into a strange ituation where the PID is used in two
different ways at once. 

	++Thomas

-- 
in some way i do, and in some way i don't.