TVDNS
An initial draft version has been published of the RadioDNS specification amendments to support TVDNS
There will be some implementation guidelines needed, with specific example zonefiles.
This is a wiki – comments and questions are explicitly invited. A ‘comments’ section exists at the end of this page which you can add to – all you need is a GitHub account. Failing that, comments are welcome at baird@projectbaird.com
In order to provide services over IP which are linked to services delivered over-the-air, some sort of mapping must occur. One approach is to embed data within the SI tables of a DVB stream; another (as described here) is to provide a resolution mechanism for key identifiers which are already carried by the DVB stream in order to link them to IP-delivered services. The two are not mutually exclusive. This proposal may prove logistically less problematic to implement, as it doesn’t involve touching both Internet infrastructure and the broadcast chain itself, but this is not assumed to always be the case. In this proposal, DNS is used as the resolution mechanism, and a combination of (network_id,service_id,transport_id,original_network_id) are used together to form a fully-qualified domain name which can be queried.
Note that there is no particular issue of “ownership” here: as proposed, the platform operator has responsibility for either the delegation or registration of DNS records relating to a service (or collection of services operated by a given broadcaster), just as they do over-the-air. One scenario is that the platform operator then delegates to the broadcaster who supplies the SRV (and other) records which are used by devices. This is simply one scenario, however. The finer points of the bureaucratic aspects of delegation and ownership are broadly outside of the scope of this proposal (and, in general, are solved problems already); the concern here is the technical mechanics.
While this proposal provides a mechanism for different services to be advertised on a per-station (or per-station-per-platform) basis, it is anticipated that broadcasters would typically opt to provide the same set of services across all channels and platforms; performing differentiation where needed at the application level, rather than in DNS. DNS afford plenty of flexibility in this regard, with judicious use of CNAMES, wildcards and generated records and configurations allowing comparatively easy management of large sets of near-identical records.
The proposal is based upon, and is an extension to, RadioDNS, which is designed to achieve the same goals within the context of radio broadcasts. One approach might be for a single organisation to take on the management of both the RadioDNS and TVDNS domains, but this does not necessarily have to be the case.
My assumptions about the meaning (though not the relationship) of network_id vs original_network_id were incorrect; original_network_id could be termed a “platform id”, while “network_id” is more like a transmitter identifier.
In Freeview, at least, each multiplex has a single transport_id. EN 300 468 states both that a transport_id is unique within a given original_network_id, and that a service_id is unique within a given (original_network_id,transport_id), however it doesn’t account for opt-outs.
In order to identify a service, including regional variations, it’s therefore necessary to use (original_network_id,transport_id,service_id,network_id). country_code is not required, as it’s largely implied by original_network_id in any case.
Those familiar with DVB will recognise the above quad as a straightforward extension to the standard DVB triplet. The DNS hierarchy will follow the same order as this quad; thus, wildcards can be used where regional opt-outs aren’t relevant to a service.
In Freeview, (original_network_id,transport_id) appears to identify a multiplex, though the same multiplex has different transport_ids by location (presumably a colouring scheme). In the case of the BBC, at least, delegation can happen at the transport_id level of the FQDN — as all BBC services are carried with the same transport_id in a given location (thus, the specific values of network_id and service_id are unimportant in determining that it’s the BBC who operates the service).
Excepting the above (which wil not be the case for many services), it is expected that in the vast majority of cases, delegation will occur at the service_id level of the FQDN: that is, the network_id is contained within the hostname (which may be useful for TVDNS applications in identifying regional opt-outs), but would generally not be required in order to perform proper delegation. The only except to this is where services from different broadcasters are delivered with the same (original_network_id,transport_id,service_id) in different regions, although this is not supposed to occur. The hierarchical nature of TVDNS accounts for this possibility, however.
TVDNS (described in this blog post) is a minor extension of RadioDNS in order to provide service-discovery infrastructure for DVB TV broadcasts.
Fully-qualified DVB TVDNS domains take the form:
<network_id>.<service_id>.<transport_stream_id>.<original_network_id>.dvb.tvdns.net.
As specified, the network_id.dvb.tvdns.net domains may be delegated to each platform operator, who delegates subdomains to individual broadcasters, however this is not a critical aspect and may change to suit non-technical factors.
The level within the hierarchy at which delegation can vary, depending upon administrative boundaries and constraints imposed by the broadcast platform.
233a.dvb.tvdns.net. – All of Freeview (expectation being that further delegations are then performed by Freeview to broadcasters)
3098.204c.200c.233a.dvb.tvdns.net. – ITV1 (Bristol)
204c.200c.233a.dvb.tvdns.net. – ITV1 (multiple regions; assuming no triplet clashes)
1041.233a.dvb.tvdns.net. – BBC services (various regions)
1004.233a.dvb.tvdns.net. – BBC services (various regions)
3005.1044.1004.233a.dvb.tvdns.net. – BBC One (London)
Any DOCSIS experts want to propose a similar scheme for non-DVB cable TV?
This section has now been published on projectbaird.com
The blog describes the use of a TXT record to complement the SRV record, which is not advisible. The reason is that you cannot query both the SRV and TXT record in one go, causing additional overhead for both the client and server. The overhead is increased further by permitting the use of a CNAME record.
Since the SRV record provides limited room for future updates, I would recommend using solely the TXT record to provide the exact location for the metadata. It can provide more information in one go, and as such it would be easier to implement versioning and extensions, similar to the SPF and DKIM use in DNS records.
On a minor note, the blog also includes an event ID and timestamp. I would recommend that the timestamp be of UNIX format, rather as described in the blog. Particularly, the use of a colon (:) is not advisible for use within URLs (possibility of resource hijacking, due to it being used as a separator for the scheme and avoids faulty clients/servers). — Myatu 08-06-2010 22:57 BST
Using just a TXT record is inconsistent with DNS-SD (on which RadioDNS is based) — and in that context a TXT record in tandem with the SRV isn’t at all uncommon — bear in mind that this is a periodic query, performed in computing terms once in a blue moon; compared to the overhead (to a client) of performing a single HTTP request, even multiple DNS queries are a drop in the ocean.
The actual PO resolver service spec lives on a different page: Programmes Ontology resolver — I actually realised it would make far more sense for it to accept URIs rather than DVB-specific event_ids. Were it to accept the latter as described in the blog, UNIX timestamps would be absolutely the wrong approach — pretty much everything else out there is heading towards the ISO datetime format, after all! Colons shouldn’t be included bare in the URLs, though — my error! — Mo 08-06-2010 23:12 BST
Personally, that it would be inconsistent with DNS-SD should not be an issue, particularly since it is not an IETF standard protocol (See SLP for one that is) nor is it in widespread use.
The key point I would like to make here is to reduce overhead as much as possible, even if it appears insignificant at the time of draft. Having had a chance to work on another successful protocol, one of the main pitfalls we had was not giving overhead a high enough priority. It seemed such an insignificant amount – a mere 59 bytes – but it reduced scalability significantly and total consumption grew exponentially. It meant that the first version had to be scrapped but because it was in such widespread use, the 2nd version had to grandfather a lot of its flaws and thus making it a very difficult task.
For example, if the TTL is set at a low value, either due to an error or on purpose (let’s say, a live event). Two requests, where portions of the response data contains the same details as the one prior (ie., SOA, NS if provided) multiplied by the number of active devices. There’s quite an overhead, and would especially be wasteful on for instance mobile devices.
PS: This could use a Programmes Ontology resolver page X-reference ;-)
— Myatu 08-06-2010 23:51 BST (Edit 09-06-2010 00:03 BST; Incorrect SLP link/spelling)
DNS-SD is widely-deployed (every Linux, OpenSolaris, and Mac computer ships with it amongst others, as well as most printers, and many other kinds of devices; SLP lost that battle a long time ago), and RadioDNS is well on its way — I think the time has long-since passed to bring about change in the way that RadioDNS itself works (though obviously I wouldn’t stand in your way if you wanted to!), but more importantly, you’re making the case to the wrong person for that :)
There’s no reason why the TTL should be low — this isn’t per-programme lookups, it’s per channel; a device would perform service resolution once per channel when it first sees it, and periodically thereafter — literally hours, or even days between requests. The heavyweight part is in the actual services themselves. All told, it’s even lighter-weight than ordinary DNS traffic, even when multiplied up to lots of devices but that’s what caching resolvers are for. That’s part of why TVDNS builds on top of RadioDNS: clever people have gone to the trouble of trying all of this stuff out before I got close to proposing it.
Bear in mind that VoIP applications do SRV lookups and regular expression replacement in NAPTRs all the time (arguably far more resource-intensive than SRV+TXT) in the split-second it takes to establish a call.
— Mo 09-06-2010 00:37 BST