DVB, DAVIC and MPEG stuff

[hakulinh@research.nokia.com (Hakulinen Harri NRC/Tre)]

Hi

Sorry that I have had no time to join this list before.

In montreal I promised to make some kind of informational RFC about DVB's 
"IP encapsulation over MPEG TS" -method. That plan is still valid, but some 
clarifications are needed concerning current DVB actions.

In Montreal I said, that DVB had already specified this method, but it was 
not exactly true. It was specified about a week after that (I was not very 
well syncronized with our DVB representatives at that time).

The method had been specified in MPEG/DSM-CC and in DAVIC before Montreal, 
so the error was not so huge.

The encapsulation is based on MPEG TS Private Sections and LLC/SNAP 
 -encapsulation. Private Sections work very much like AAL5 -packets in ATM, 
so the overall method is about the same as in Classic IP over ATM.

There is also major differencies when compared to ATM:

 - Link is unidirectional
 - Link has broadcast nature
 - Addressing method is different

In MPEG TS addressing is based on PID, Table_ID and Table_ID_extension 
fields. Those can be used as hardware filtering parameters in most 
DEMUX-chicps in STB-like devices. And hardware filtering is desirable, 
because the stream speed is usually about 40 Mbits.

(Table and Section are about the same thing in MPEG TS).

Conditional Access(CA) system in DVB is based on PID values, so it is the 
main "address" in MPEG TS -stream.

Problem is, that PID field consist of only 13 bits. It is certainly too 
small to be the only "mac" address, so it must be expanded by using 
Table_ID_extension. Table_ID_extension gives 16 bits more to be used as a 
kind of "mac"-layer address (with PID). Table_ID is also one filtering 
parameter, but its use has been defined in a silly way in MPEG, so it is 
almoust unusable.

General problem with current MPEG/DSM-CC spec is, that it is not designed 
from the beginning to transport IP -packets. So if we want (DVB want's) to 
be compatible with current DEMUX-chips (and those currently in desing), we 
must accept these limitations.

The actual mechanism how "mac" layer works is NOT defined in DVB currently 
and it is NOT completely defined in DAVIC either.

There is at least two models how DVB-link could be utilized to transport IP. 


 - Unidirectional link (as has been disscussed here)
 - broadcast only IP (multicast IP) "stream"

Broadcast only IP "stream" could mean, that there is some kind of "static 
set" of multicast addresses that are send to given DVB link at the time. 
This set is defined by droadcast operator (maybe with some application level 
interaction from the user).

In this case some sort of "routing table" can be broadcasted in the same 
stream (and/or in other streams also). DVB Service Information (SI) 
mechanism can be used to tell receivers (STB like devices) what IP-multicast 
address(or address space) is related to certain PID/Table_ID_extension pair.

This is maybe not very usable as such, but if it is used with some much 
higher layer protocol(maybe not routing protocol), there might be some 
usefull application possibilities. Of course, this kind of system with its 
limitations can be used without any return path to DVB-link router.

I continue with unidirectional link case tomorrow, because it seems that 
today its almoust first sunny day in Finland in this summer ...

 - Harri