NIT vs INT .. RE: PIDs vs flow IDs

[<harri.hakulinen@nokia.com>]

Marie-Jose & all,

as small addition to very comprehensive posting from Rod.

( I am not sure, if you were originally talkin about INT or
  NIT, but keep reading, maybe this mail reduces the confusion)

In my humble understanding, PID's were never designed to
be e-to-e identifiers. Instead, they were designed to work
like ATM vpi/vci fields, but now in unidirectional case.

NIT table is actually (part of )a substitute of ATM signaling, 
and is designed to communicate the e-to-e identifiers to receivers
(as Rod explained). PMT (in the "middle") is designed to
make life easier for muxes

I belive (but I am not sure) that Rod actually explained how
NIT works, but in the original posting Marie-Jose was refering
to INT, that is little bit different story.

GBS sub group of DVB has recently worked on IP/PID/MAC mapping 
issue from DVB perspective, and i belive that the result is 
published at ETSI EN 301 192 [V1.3.1 (2003-05)]. From that 
document, look for Multiprotocol Encapsulation section and 
IP/MAC Notification Table (INT).

[ Go to www.etsi.org and select Dowload Now ! 
  Then use the document number (301 192) as search criteria ]

Figure 3 on page 23 is supposed to explain the relations bethween 
tables mentioned here (and few others..) but I am not sure if I
understood it either. 

Have fun,

//Harri

ps. For more info, I guess you should contact _TM-GBS 
    Generic Data Broadcasting & Service Information Protocols
    people directly  http://www.dvb.org/index.php?id=64


> -----Original Message-----
> From: owner-ip-dvb@erg.abdn.ac.uk 
> [mailto:owner-ip-dvb@erg.abdn.ac.uk]On
> Behalf Of ext alain.ritoux@6wind.com
> Sent: 21 November, 2003 16:41
> 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
> 
>