DSM-CC object and data carousels allow broadcasters to transport data to receivers using MPEG-2 sections. For some types of data such as files, this is fine, but it’s not suitable for all kinds of data that may be transmitted to a set top box. If there’s some connection to the Internet world in particular, then using carousels isn’t really practical.
This is where DSM-CC multi-protocol encapsulation comes in. Multi-protocol encapsulation allows a broadcaster to carry IP data in MPEG-2 sections, effectively giving the box a simple one-way internet connection. There are limits, of course – as we’ve just said, this is purely a one-way connection for UDP datagram packets, rather than a complete two-way TCP connection (although in theory it would be possible to use the return channel to provide the missing part of the connection.
Although IP data is probably the most common form of data that is carried, other protocols are supported. In this tutorial, however, we’ll look at multi-protocol encapsulation purely from a perspective of carrying IP packets because that is the only functionality offered by MHP, OCAP, and ACAP.
Addressing a receiver
IP uses a combination of IP addresses and hardware MAC addresses to identify a receiver, with MAC addresses being used at the lower levels. Since this works pretty well and is well-understood, DSM-CC uses the same approach. Each receiver is given a 48-bit MAC address (the same length as an Ethernet MAC address) and this is used to identify which receiver (or receivers) is the destination for a specific packet. DSM-CC says nothing about how a receiver gets its MAC address or how this is assigned, however.
Obviously, a MAC address alone isn’t very useful – IP datagrams use IP addresses, and there has to be some way of routing an IP address to the right receiver, and mapping that to a MAC address. In fact, there are a couple of ways. Old versions of the DVB data broadcasting specification described the routing descriptor that is carried in the service information and describes this. Unfortunately, this was not quite enough, and so the most recent version of the data broadcasting spec uses a new mechanism called the IP/MAC Notification Table (INT). This is an additional SI table that carries information used by multi-protocol encapsulation, and we will discuss it in more detail below.
Transporting IP packets
In order to carry IP packets in the MPEG-2 stream, DSM-CC defines a type of section called the datagram section. This is compatible with the normal DSM-CC private section format, but it extends it to make it easier for receivers to filter packets based on the MAC address using hardware section filters.
Datagram sections can support any kind of OSI layer 3 networking protocol, but DVB has optimized the section format to make it easier to use multi-protocol encapsulation with IP datagrams. This optimized section format looks like this:
| Syntax | No. of bits | Mnemonic |
|---|---|---|
| datagram section { | ||
| table_id | 8 | uimsbf |
| section_syntax_indicator | 1 | bslbf |
| private_indicator | 1 | bslbf |
| reserved | 2 | bslbf |
| section_length | 12 | uimsbf |
| MAC_address_6 | 8 | uimsbf |
| MAC_address_5 | 8 | uimsbf |
| reserved | 2 | bslbf |
| payload_scrambling_control | 2 | bslbf |
| address_scrambling_control | 2 | bslbf |
| LLC_SNAP_flag | 1 | bslbf |
| current_next_indicator | 1 | bslbf |
| section_number | 8 | uimsbf |
| last_section_number | 8 | uimsbf |
| MAC_address_4 | 8 | uimsbf |
| MAC_address_3 | 8 | uimsbf |
| MAC_address_2 | 8 | uimsbf |
| MAC_address_1 | 8 | uimsbf |
| if (LLC_SNAP_flag == "1") { | ||
| LLC_SNAP() | ||
| } else { | ||
| for (i = 0; i < N1; i++) { | ||
| IP_datagram _data_byte |
8 | bslbf |
| } | ||
| } | ||
| if (section_number == last_section_number) { | ||
| for (j = 0; j < N2; j++) { | ||
| stuffing_byte | 8 | bslbf |
| } | ||
| } | ||
| if (section_syntax_indicator == "0") { | ||
| checksum | 32 | uimsbf |
| } else { | ||
| CRC_32 | 32 | rpchof |
| } | ||
| } |
As you can see, the MAC address is split into two groups: the two least significant bytes (bytes 5 and 6) are stored early in the section, with the others following later. The reason for this is to allow hardware section filters (which can often only filter on the first part of a section’s payload) to help filter out datagrams for other MAC addresses that a receiver would not care about.
Each section carries a single datagram for a single MAC address (although this may be a multicast or broadcast MAC address, so the packet would actually be received by several receivers). While it is possible for an IP datagram to be larger than an MPEG-2 section, this is not supported by DSM-CC. IP datagrams used in multi-protocol encapsulation should have an MTU value of 4080 bytes if the LLC/SNAP flag is not set and 4074 bytes otherwise. Since IP datagrams are guaranteed to fit in one section, both the section number and the last section number will be set to zero when the section is carrying IP data.
The LLC/SNAP structure allows the section to transport any kind of OSI layer 3 networking protocol. If the section is being used for IP data, the LLC/SNAP structure isn’t necessary and the payload consists of just the IP datagram. Since we’re concentrating on IP only in this tutorial, we won’t look at the LLC/SNAP structure in any detail. The DSM-CC specification gives a few more details, but not many.
Service information and multi-protocol encapsulation
Service information plays an important part in multi-protocol encapsulation. As well as the descriptors that are defined to handle other types of DSM-CC data (see the section of this tutorial on service information and DSM-CC), DVB has defined some additional service information to optimise the use of DSM-CC multi-protocol encapsulation with IP data. Initially, MHP defined an additional descriptor (the IP routing descriptor) to tell a receiver how
Between MHP 1.0.2 and MHP 1.0.3, however, DVB revised the data broadcasting specification. The new version included some extra SI that defined how IP packets where to be handled, and as of MHP 1.0.3 this replaced the IP routing descriptor as the way that broadcasters should tell the receiver about IP data. MHP 1.0.2 and OCAP systems must use the older version of the SI, however.
Routing descriptors
Older versions of the MHP specification used the routing descriptor to define how multicast IP addresses used by MHP applications where mapped on to DVB component tags. This let the receiver know how where to look for data that an application was waiting for. These descriptors were contained in the common descriptor loop of MHP’s AIT, and so they applied to every application in that AIT. of course, this also means that they were not general-purpose descriptors: they applied specifically to MHP systems. This is one of the reasons why they were replaced by the SI specified in the new version of the data broadcasting specification. (The other resaon was that the data broadcasting specification was defined by people who knew about and cared about IP transport over DVB transport streams, while MHP was defined by people for whom this was a necessary evil. Better leave the job to the people who care about getting it right).
MHP defined routing descriptors for both IPv4 and IPv6 traffic – in the real world, no-one uses IPv6 for this, and so we will only look at the IPv4 version of the descriptor:
| Syntax | No. of bits | Mnemonic |
|---|---|---|
| routing_descriptor_ip4 { | ||
| descriptor_tag | 8 | uimsbf |
| descriptor_length | 8 | uimsbf |
| for (i=0; i < N, i++) { | ||
| component_tag | 8 | uimsbf |
| address | 32 | uimsbf |
| port_number | 6 | uimsbf |
| address_mask | 32 | uimsbf |
| } | ||
| } |
As you can see, this is a fairly simple descriptor that simply maps a multicast IP address range (specified by an IP address and subnet mask) and port number on to a given component tag. Since this descriptor is defined in MHP 1.0.2, it is also supported by GEM and OCAP.
The IP/MAC Notification Table
As of version 1.3.1 of the data broadcasting specification, DVB produced a general-purpose way of defining how IP was carried on DVB transport streams. This is called the IP/MAC Notification Table (INT) and it consists of several sub-tables that define a set of targets and a set of actions that apply to those targets. Each sub-table is carried in INT sections, and the format of these sections is as follows:
| Syntax | No. of bits | Mnemonic | Comments |
|---|---|---|---|
| IP/MAC_notification_section { | |||
| table_id | 8 | uimsbf | 0x4C |
| section_syntax_indicator | 1 | bslbf | 1b |
| reserved_for_future_use | 1 | bslbf | 1b |
| reserved | 2 | bslbf | 11b |
| section_length | 12 | uimsbf | |
| action_type | 8 | uimsbf | See EN 301 192 table 14 |
| platform_id_hash | 8 | uimsbf | |
| reserved | 2 | bslbf | 11b |
| version_number | 5 | uimsbf | |
| current_next_indicator | 1 | bslbf | 1b |
| section_number | 8 | uimsbf | |
| last_section_number | 8 | uimsbf | |
| platform_id | 24 | uimsbf | |
| processing_order | 8 | uimsbf | 0x00 |
| platform_descriptor_loop () { | |||
| reserved | 4 | uimsbf | |
| platform_descriptor_loop_length | 12 | uimsbf | |
| for (i = 0; i < N; i++) { | |||
| platform_descriptor() | |||
| } | |||
| } | |||
| for (i = 0; i < N; i++) { | |||
| target_descriptor_loop () | |||
| operational_descriptor_loop () | |||
| } | |||
| CRC _32 |
32 | rpchof | |
| } |
Since many different types of receiver may be operating on a given network, there has to be some way of choosing which receivers these messages apply to. Each receiver manufacturer has a platform ID that is specified by DVB. Every sub-table will identify a different platform ID, although there may also be cases where the same platform ID is used in more than one INT sections (for instance, when a sub-table is too big for a single section). In this case, sections with the same platform ID belong to the same sub-table.
Each INT consists of three types of descriptor. The first of these, known as the platform descriptors, provide some information about the platform. This extends the platform ID to give a little more information about the platform that is the target for this sub-table. The platform descriptors are contained in the platform descriptor loop. This has the following format:
| Syntax | No. of bits | Mnemonic | Comments |
|---|---|---|---|
| platform_descriptor_loop () { | |||
| reserved | 4 | uimsbf | |
| platform_descriptor_loop_length | 12 | uimsbf | |
| for (i = 0; i < N; i++) | |||
| platform_descriptor() | |||
| } |
The other two descriptor types are target descriptors, which identify a set or receivers or an IP address range, and the operational descriptors, which define a set of actions that apply to those receivers or IP address ranges. These are grouped together in a larger loop, so that each iteration of the larger loop contains a set of target descriptors and a set of operational descriptors that apply to those targets.
Target descriptors can identify either a receiver (by its serial number, smart card number, MAC address range and IP address range) or some network traffic (by MAC address range, IP address range or a source/destination address pair). This allows the target descriptors to be used for two purposes. Typically, they identify a set of IP addresses and a port number, and the operational descriptor loop then tells the receiver where to find the data for those addresses. A target descriptor could also be used to force only a small set of receivers to see this service.
| Syntax | No. of bits | Mnemonic | Comments |
|---|---|---|---|
| target_descriptor_loop () { | |||
| reserved | 4 | bslbf | |
| target_descriptor_loop_length | 12 | uimsbf | |
| for (k = 0; k <P; k++) { | |||
| target_descriptor() | |||
| } |
The number and type of target descriptors gives the broadcaster a great deal of flexibility in addressing a receiver, and is the reason why the platform ID is so important. A broadcaster could identify one group of receivers by IP address, another by a range of smart card numbers and a third by their serial numbers.
The operational descriptor loop contains a set of descriptors that specify which actions should be applied to the receivers identified in the target descriptor loop.
| Syntax | No. of bits | Mnemonic | Comments |
|---|---|---|---|
| operational_descriptor_loop () { | |||
| reserved | 4 | bslbf | |
| operational_descriptor_loop_length | 12 | uimsbf | |
| for (l = 0; l < R; l++) | |||
| operational_descriptor() | |||
| } |
The most important of the descriptors in the operational descriptor loop is the IP/MAC stream location descriptor:
| Syntax | No. of bits | Mnemonic | Comments |
|---|---|---|---|
| IP/MAC_stream_location_descriptor () { | |||
| descriptor_tag | 8 | uimsbf | 0x13 |
| descriptor_length | 8 | uimsbf | |
| network_id | 16 | uimsbf | |
| original_network_id | 16 | uimsbf | |
| transport_stream_id | 16 | uimsbf | |
| service_id | 16 | uimsbf | |
| component_tag | 8 | uimsbf | |
| } |
This serves basically the same purpose as the routing descriptor defined in early versions of MHP: it tells the receiver how to map a given address range and port number to a given DSM-CC stream. In this case, there is no information about which address range and port number is mapped to this stream, because that is defined by the target descriptor loop.
Other descriptors that are part of the operational descriptor loop include the telephone descriptor (which tells the receiver what telephone number should be dialed to access that service) and the ISP access mode descriptor, that tells the receiver how it should access an ISP to use a service. At the moment, only dial-up access is defined, and so this descriptor is commonly used with the telephone descriptor.
The order in which different INT sub-tables are processed may be important in some cases. For this reason, each INT section has a processing order. This must start at 0x00 for the first sub-table to be processed, and the receiver will then process sub-tables in the ascending order of their processing order values. Thus, a sub-table with a processing order value of 0x10 will be processed before a sub-table with a processing order value of 0x12.
There’s a lot more to the INT table than we’ve discussed here – more information can be found in version 1.3.1 or higher of the DVB Data Broadcasting Specification (ETSI document number EN 301 192). Since the INT is only supported in versions 1.0.3 and 1.1.1 of MHP at the moent, it is not used in any systems that are currently deployed. OCAP and GEM both follow the older approach to IP routing.