RE: NIT vs INT .. RE: PIDs vs flow IDs

[<Rod.Walsh@nokia.com>]

Hi All

Good points by Harri.

Just to clarify, I did mean INT (there's 4 more permutations of those 3 letter that we could use at some point to make things even more confusing - TIN, TNI, ITN, NTI :)

Cheers, Rod.


> -----Original Message-----
> From: owner-ip-dvb@erg.abdn.ac.uk 
> [mailto:owner-ip-dvb@erg.abdn.ac.uk]On
> Behalf Of ext 
> Sent: Monday, November 24, 2003 11:47 AM
> To: ip-dvb@erg.abdn.ac.uk
> Subject: NIT vs INT .. RE: PIDs vs flow IDs
> 
> 
> 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
> > 
> > 
> 
>