RE: PIDs vs flow IDs

["Allison, Art" <AAllison@nab.org>]

I may not have proper context as I have not been following closely. Changing
PID values is normally a routine multiplexer function. 

Because each elementary stream or set of table sections is not generally
constrained to use certain PIDs (there are some dedicated PID values), any
MPEG-2 re-mux operation must be able to rewrite PID values to get rid of
duplications. One can only have static PIDs if the stream is (a) separately
encapsulated (or contained/scoped via some means); or (b) is authored with
external control of PID uniqueness and never goes through a TS multiplex
operation.  In MPEG-2 Transport streams the scope of PID values is the
entire multiplex, and the identifier is the TSID.

Different multiplexes with different TSIDs (and usually different physical
delivery layers) can reuse PID values, of course. For this delivery means,
it would seem a logically similar scoping means would be needed to enable
static PID values.
 
Art
::{)
Art Allison
Director Advanced Engineering
NAB
1771 N St NW
Washington DC 20036
202 429 5418


-----Original Message-----
From: alain.ritoux@6wind.com [mailto:alain.ritoux@6wind.com]
Sent: Friday, November 21, 2003 9:41 AM
To: IPDVB
Subject: Re: PIDs vs flow IDs


Marie-Jose Montpetit wrote:
> I'm working on a new version of the AR draft and something has come up: 
> how PIDs are not really flow IDs and can change. As far as I know in 
> broadcast TV networks when you use INT with PID, a (re)MUX may re-mark 
> the PID, and then could remark the
> INT. This is a standard MUX function. However in a data network I think 
> it is assumed that PIDs are to be used end-to-end (as unidirectional 
> flows), and Muxes should not re-mark. If that is the case it's ok. If 
> it's not the case then we may have to find a way to easily identify 
> flows and map them appropriately.

My understanding is that  PID should really be end-to-end, because
what MUX seem to be able to do is a sort of NAT-like behaviour : it
changes the packets, AND it performs some ALG (i.e. by re-writing INT).

If we think about some possible dynamic mapping (sort of ARP/NDP)
using whatever return link may be available (SCPC, UDLR, ...) then
the MUX re-writing of PID will be catastrophic ! andI think a quite
dynamic mechanism would be REALLY usefull, for static tables such as
INT may not be enough for "automatically" numbered networks (with some
Prefix Delegation in IPv6, ...).


One other question : the Adress Resolution should not only provide
(addr) --> (mac, PID) mapping, but ALSO some precision about the
encapsulation used, i.e. (PID) --> (method) mapping to be able to swtch
between MPE and ULE for exemple.

Regards.
Alain.
-- 
Alain RITOUX
Tel +33-1-39-30-92-32
Fax +33-1-39-30-92-11
visit our web http://www.6wind.com