INTERNET DRAFT Richard Hodges Document: draft-hodges-dtv-chanchange-00.txt Matriplex, inc. Expires: January, 2002 August, 2001 Digital TV Channel Changing Protocol Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [2]. Abstract Advances in video compression techniques and new technology for delivering broadband services are making digital television (DTV) services practical and marketable. One of the missing elements is a flexible and open protocol for DTV clients to request desired video/audio streams, or "channel changing". This document describes a protocol that a client may use to change DTV channels, and how servers may authenticate the client, authorize the requested streams, perform viewership accounting, and form a reply to inform the client on the status of the request. 1. Terminology This section defines some terms that are used in the rest of this document: Hodges [Page 1] Internet-Draft Digital TV Channel Changing Protocol July, 2001 Digital Television (DTV) : This is any service that provides video and audio continuously to a client over some kind of data network. It is expected that many different streams will be available at any given time, and the client may select any of them (change channels) subject only to administrative controls. MPEG2 or MPEG1 will likely be used for video compression, but others may be used as desired. DTV-CCP : This is the Digital TV Channel Changing Protocol described in this document. This includes the packet structure itself and the methods used by the DTV clients and servers. AAA : This term refers to the authentication, authorization, and accounting functions described below. Authentication : This is the service that determines whether the client request is genuine. Both client and authentication server share a common secret, also known as the client key, or password. The key is not transmitted, but is used by the client to sign the request with an MD5 hash, and for the server to verify the MD5 hash. Authorization : This is the service that checks the client request to verify that the client is eligible to receive the requested DTV channel. A simple implementation may check only the client and the requested DTV channel. A more featureful server may also allow or deny access based on requested bitrate, time of day, encapsulation options, or any other useful criteria. Accounting : This is an optional service that tracks the client DTV requests, and provides statistical information for the DTV service provider on DTV channel viewership. This would typically be used to graph DTV viewership to see how many clients were on an given DTV channel at any one time. The actual implementation may decide the resolution, which may be viewer-minutes or some fraction thereof. This information can be invaluable to advertisers and to DTV service managers that need to know which programs are popular, and which are not. Sub-ID : This is a number that uniquely identifies a particular client where multiple clients exist at one location. This may be the case where a residence has a set-top box with multiple video decoders. In this case, the network and/or hardware address may be identical, and the sub-id number is needed to identify the client making the request. 2. Current DTV Channel Changing Methods One simple method that has some success is for each DTV channel to be transmitted on its own multicast address. The network listens for Hodges [Page 2] Internet-Draft Digital TV Channel Changing Protocol July, 2001 IGMP requests from clients, and forwards the appropriate multicast group traffic to the clients that want to receive those channels (groups). Since most network clients are capable of receiving IP multicast traffic and generating the neccessary IGMP messages, very little effort is needed to build and evaluate such a DTV service. 3. Problems with IGMP for Channel Changing IGMP has some advantages, notably simplicity and relatively mature industry support. There are five noteworthy drawbacks, however. First, there is no inherent mechanism for authenticating the client. The client IP address may be taken from the IP header, but it is not difficult for a malicious or misconfigured host to send an IGMP packet with any arbitrary source address. While it may be possible to add IP security functionality to the network switches, this may be impractical for cost or administrative reasons. Second, the client has no way to specify optional video or audio options, such as encoding methods. Nor is there any way for the client to request a particular encapsulation method (such as RTP) or transport (eg, ethernet or ATM). Third, IGMP does not provide for immediate termination of a group's multicast traffic. When the DTV bandwidth is a major percentage of the available link capacity, it is imperative that the network discontinue the old channel to that client before starting to send the new channel. Otherwise, the link bandwidth will be exceeded and packets will be dropped, resulting in corrupted video and audio at the client, and an unacceptable viewing experience. Fourth, IGMP, as implemented in typical switches, does not have any inherent authorization mechanism. In other words, if a client makes a request (via IGMP) for a DTV channel, the switch will simply provide that stream. Adminstrative control over DTV channels may be somewhat of a challenge when using IGMP for switching DTV. Fifth, IGMP is unidirectional. The client does not receive any acknowlegement, and must wait for the new stream to start arriving in order to know whether the request was accepted and acted upon. This makes it difficult for the client to discern whether the IGMP packet was lost, late, or ignored. 4. DTV-CCP Benefits and Requirements The packet structure and methods described in this document should Hodges [Page 3] Internet-Draft Digital TV Channel Changing Protocol July, 2001 provide the neccessary functionality to implement a DTV channel changing system. This system can provide for administrative control over the network assets (DTV channels) and also the flexibility that facilitates transport over non-ethernet networks (ATM for example). The authentication, authorization, and accounting functions may be contained within a single server, or separated into different ones, allowing for customization and/or scalability. 5. DTV-CCP Packet Structure The DTV request packet is 100 bytes long, and contains an MD5 hash that the receiver can use to verify the identity of the sender. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version # | Encapsulation | Option-Audio | 0000 | Auth | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Request Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Desired Bandwidth Minimum | Desired Bandwidth Maximum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Old (leaving) DTV Channel | New (joining) DTV Channel | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Client ID Number (or Sub-ID number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Client IP4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Client IP6 Address | | (16 bytes) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Client ATM Address | | (20 bytes) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Multicast IP4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Multicast IP4 Port# | AAA Flags | Fail Reason | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Reserved for future use | | Client sets all 16 bytes to zero | | | Hodges [Page 4] Internet-Draft Digital TV Channel Changing Protocol July, 2001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | MD5 Hash of entire packet | | Including Following Key | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Secret Hash Key | | NOT transmitted | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Offset Bytes Field 0 1 version number (set to 1) 1 1 encapsulation method (bitfield flags) 2 1 audio options (language and/or encoding method) 3 1 authentication options, MD5 or other 4 4 request sequence number (client increments) 8 2 bandwidth minimum, times 1000 bits/second 10 2 bandwidth maximum, times 1000 bits/second 12 2 channel old (leaving this channel, zero=no data) 14 2 channel new (joining this channel, zero=no data) 16 4 client ID (client sets to sub-ID, or zero) 20 4 client IP4 address (or server if reply) 24 16 client IP6 address (or server if reply) 40 20 client ATM address (or server if reply) 60 4 multicast IP address (server informs client) 64 2 multicast port (server informs client) 66 1 Server AAA flags, shows AAA progress 67 1 Failure reason code, zero if successful 68 16 reserved (set to zero) 84 16 MD5 hash of packet (including following key) 100 16 Secret key for authenticating packet (NOT transmitted) The version number should be set to 1. The encapsulation field may contain one or more of the following flags: ENCAPS_ETHER 0x01 Include 14-byte ethernet header ENCAPS_IPUDP 0x02 Package datagram in an IP UDP packet ENCAPS_RTP 0x04 Add an RTP (12 byte) header ENCAPS_AAL5 0x08 Use ATM, send in an AAL5 PDU ENCAPS_AAL1 0x10 Use ATM, send in AAL1 cells ENCAPS_LOCAL 0x80 Private or proprietary method Many encapsulation methods are possible, for instance: ETHER + IPUDP: Send as IP/UDP packets over ethernet. ETHER + IPUDP + RTP: Send as IP/UDP RTP packets over ethernet. Hodges [Page 5] Internet-Draft Digital TV Channel Changing Protocol July, 2001 ETHER + AAL5 + IPUDP: Send as IP/UDP over ATM, RFC1483/bridged. AAL5 + IPUDP: Send as IP/UDP over ATM, RFC1483/routed. AAL5: Send raw in ATM AAL5 PDUs. The audio options are reserved for further study. Set to zero. The "other" options are reserved for further study. Set to zero. The authentication option field should be set to zero for regular MD5 authentication. Values of 1 to 3 may be used for local or experimental methods, and 4 to 15 are reserved for future methods. A server that does not understand the packet's authentication option MAY set the option to zero (MD5) and continue the authentication process. This may be useful as a primitive backwards compatibility feature. Otherwise, if the server does not understand the authentication option, it SHOULD handle the packet as a failed authentication. Future versions of this protocol may have key exchange features, and the packet fields may have different meanings when the authentication option field has different values. The request sequence number is an incrementing serial number. The server(s) SHOULD use this number to discard duplicate requests or ignore old requests that were delayed in transit. Since the client is verified by the MD5 hash signature, there is no special denial of service consideration with a third party injecting bogus sequence numbers. The bandwidth minimum and maximum fields are optional, and allow the client to request the desired bandwidth for the new DTV channel. If multiple presentations of the requested channel exist, the server SHOULD use these values to choose the best fit, if administrative controls allow. These values are in units of 1000 bits per second, and the client may use zero to indicate no preference. The channel old and channel new fields indicate the current channel the client is receiving and the next desired DTV channel. The client SHOULD set the "old" channel field. The client MAY set the "new" channel to zero in order to discontinue DTV service. The exact meaning of channel numbers is specific to the administrative goals of the DTV provider, and the channel numbers MAY have different mappings for different clients in order to provide customized presentations or service offerings. The client ID number is used to uniquely identify a client, and is typically set by the authentication server for the convenience of the other servers. The client MAY set this field to its client ID number, if known. Otherwise, the client SHOULD set this field to its "sub-ID" number to indicate which video decoder or player it is at Hodges [Page 6] Internet-Draft Digital TV Channel Changing Protocol July, 2001 that particular location. This "sub-id" number should start at one, and has a maximum value of 99. The client IP4 address field contains the client's IP4 address, or zero if an IP6 or ATM address is used. If zero, the authentication server should insert the correct address, if one is known. The client IP6 address field contains the client's IP6 address, or zeroes if an IP4 or ATM address is used. If zero, the authentication server should insert the correct address, if one is known. The client ATM address field contains the client's ATM address, or zeroes if an IP4 or IP6 address is used. If zero, the authentication server should insert the correct address, if one is known. The multicast IP4 field is used in the reply to the client if the stream is to be sent on a multicast group. This allows the channel number to multicast group mapping to be hidden from the client, and facilitates dynamic mapping, which may be neccessary if a channel is available in multiple bandwidths or encapsulations. If IP multicast is not used, this field MUST be set to zero. The multicast IP port is the destination port number associated with the multicast IP group described above. Set to zero if IP multicast is not used for the DTV channel. The AAA flags field indicates which of the AAA functions have been successfully performed on the request. The client sets this field to zero, and the servers set the flags as the request is handled. The servers SHOULD use the flags in this field to avoid unneccessary duplication of AAA effort. AAAFLAG_AUTH1 1 Client has been identified AAAFLAG_AUTH2 2 Client request has been authenticated (MD5 OK) AAAFLAG_AUTH3 4 Client request is approved AAAFLAG_ACCT 8 Client request has been logged The fail reason code is a field that contains the error code (if any) for a request, should it fail. Zero indicates no error. RESULT_NOUSER 1 Client is unknown RESULT_BADMD5 2 Request MD5 checksum is incorrect RESULT_NOCHAN 3 Requested channel does not exist RESULT_DENIED 4 Requested channel not approved RESULT_BADREQ 5 General problem with request RESULT_AAAFLAG 6 AAA flag field was not zero Any fields marked "reserved" are for future use. Set these to zero. Hodges [Page 7] Internet-Draft Digital TV Channel Changing Protocol July, 2001 The MD5 hash field contains the 128-bit MD5 hash of the packet and the secret key to authenticate the sender. This field should be cleared to zero before actually computing the MD5 hash. The client MUST compute the hash for every DTV request packet it sends. The secret key is a 128-bit field immediately following the packet data, and is included when computing the MD5 hash. It MUST NOT be transmitted. Since the request packet is 100 bytes long, the MD5 hash will be computed on 116 bytes. The key does not have to have a length of 128 bits, and may be created from an ASCII password or other means. In case the keylength is less than 128 bits, the unused bits MUST be set to zero, and the key MUST be "left justified" (lowest addresses occupied first). This is to ensure that all hosts can agree on how to handle short keys. 6. DTV-CCP Client Methods When a client wants to initiate service, change channels, or stop DTV service, it sends a DTV request packet to its designated server. This server may be the actual video encoder, but is more likely to be a server that will be the first in a chain, eventually passing the request to the video encoder or network element that handles the video streams. The client sets the packet fields as follows: 1. Version is 1. 2. Set the desired encapsulation flags. 3. Set the audio and "other" option flags (or zero). 4. Increment the request sequence number and store it. 5. Set the desired minimum and maximum bandwidth, or zero. 6. Set the old channel number, or zero if starting service. 7. Set the new channel number, or zero if terminating service. 8. Set the client ID number if known, otherwise store the sub-ID number (unique identifier at that location, 1 <= x <= 99) 9. Set one or more of the client IP4, IP6, and ATM addresses. 10. Clear all other unused or reserved fields. 11. Insert the client key into the secret hash key field. 12. Clear the MD5 hash field. 13. Compute the MD5 hash of the packet data and the key field. 14. Store the resulting MD5 hash in the MD5 hash field. 15. Send the packet to the designated server. If using UDP, the port number is 2253. The client MAY close the current DTV channel connection before or immediately after sending the request packet. This may give better channel changing performance on certain types of networks. Or the client MAY wait until receiving the DTV request reply before closing Hodges [Page 8] Internet-Draft Digital TV Channel Changing Protocol July, 2001 or otherwise affecting the current DTV channel stream. It may be advantageous to add another DTV request packet field to allow the client to state its intentions on this matter, but that is a topic for future study. The client SHOULD take steps to ensure that the request sequence number is always increasing, even if the client restarts. Using the system (32 bit) time value as an initial value is one way to achieve this goal. After sending the DTV request packet, the client SHOULD receive and inspect the reply to learn the status of the request. If using UDP, the client SHOULD listen on the DTV request port (2253) so that the server does not receive an ICMP "unreachable" message. If the client does not receive a reply in a reasonable amount of time, it MAY resend the exact same packet with the same sequence number, and MAY repeat as desired until it receives a reply. If the client receives a reply indicating that the request failed, it MAY compose a new request, changing one or more fields that may lead to approval by the servers. The client SHOULD NOT send a duplicate request, since the server will certainly refuse that too. Upon receiving a reply indicating approval, the client should use the packet information to start receiving the new DTV channel stream. In particular, the client should inspect the encapsulation, audio option, and multicast IP fields for guidance on how to prepare to start receiving the new DTV channel. The client should take the appropriate steps to close or stop the old DTV channel stream, if it has not already done so. 7. DTV-CCP Server Methods The DTV request server is actually one or more servers providing one or more of the AAA functions: authentication, authorization, and accounting. In principle, these servers can be deployed in a network in most any order, but in practise they will probably work best if organized so that they are in "obvious" order: 1. Authentication: Who are you? Prove it. 2. Authorization: Are you authorized to get this DTV channel? 3. Accounting: How many clients were watching channel x? For scalability, it is easy to deploy many authentication servers, each one serving a subset of the total client base. After verifying the client requests, they forward the requests to the next server which checks the request against general policy or the specific rights for that particular client. The "authorized" packet is then Hodges [Page 9] Internet-Draft Digital TV Channel Changing Protocol July, 2001 forwarded to a network device (possibly the video encoder) that manages the network to cause that DTV channel to be available to the client. The accounting server is optional, and should be used just after the authorization server. In a small to medium sized deployment, all three functions may be located in the same server. Authentication: When the authentication server receives a DTV request packet, it should determine the client's identity and then verify the packet by computing the correct MD5 checksum based on the secret key known to be correct for that client. Once the client has been identified, the server MUST fill in the client ID number, the IP4, IP6, and ATM addresses from its local information (known to be correct). This prevents a client from impersonating another client, and possibly disrupting service. This also means that the sub-ID and address information provided by the client is not trusted, but is simply used as a "hint" when looking for the client key to use to validate the packet. When the client is identified the server sets the "AUTH1" flag in the AAA field to indicate that a client match was found. When the request MD5 checksum has been checked, and the request is known to be genuiune, the server sets the "AUTH2" flag in the AAA field to indicate that the client did make this request. If a client sends a request with a non-zero flags field, the server MAY zero the field and continue normal processing. Otherwise, the server MUST return the request to the client with fail reason 6, "AAAFLAG". In both cases, it is RECOMMENDED that the server log this event appropriately. After validating the packet and inserting correct ID and address information, the authentication server signs the packet with its own key and forwards it to the next server in line. This will most likely be the authentication server. The authorization server checks the request's MD5 checksum to verify the signature from the authentication server. If the MD5 hash does not match the previous server, the authorization MUST discontinue processing, and either return it to the client with failure code 6, "system" (RECOMMENDED), or alternately it MAY forward the request to the authentication server for validation. If the latter case is chosen, the servers should take measures to prevent processing loops or potential denial of service attacks. To protect client privacy, the authorization server SHOULD NOT provide "what if" information to Hodges [Page 10] Internet-Draft Digital TV Channel Changing Protocol July, 2001 a client that has not been authenticated. After checking local administrative policy and/or permissions for the client, the authorization server either rejects the request or approves it, and forwards the request to the next server (probably the accounting server). In the case of failure, the server sets the failure code appropriately and forwards the request to the client. If the request is approved, the server sets the "AUTH3" flag in the AAA field to indicate that the request is approved. The accounting server should verify that the MD5 hash signature is from a trusted server (probably the authorization server), and logs the request appropriately. This will probably include updating viewership totals for the DTV channels for storage in a database or other uses. After logging the request, the accounting server sets the "ACCT" flag in the AAA field, signs the request with its MD5 signature, and forward the request to the next server, which will probably be a network device that handles the actual channel stream switching. Information from the accounting server can take any form useful to the implementor, and will probably include channel viewership statistics by the minute. It is also possible to track daily summaries of how many minutes a client spent on each channel for a particular day. If the accounting server has knowlege of special time slots (eg, advertising), it might track the percentage of viewers that changed channels during that spot. Knowlege of what the viewers will (and won't) watch can be a useful tool in providing programming that better serves the clients. If one or more of these AAA functions are colocated in the server, and have trusted communications paths, some of the MD5 signing may be unneccessary. This may be the case where a single server handles all three AAA functions. In this case, there is no need to compute and test the intermediate MD5 hashes. 8. Security Considerations This protocol provides for client authentication via an MD5 hash. So long as both client and server protect the shared secret, this protection is as strong as the key length and the MD5 algorithm itself. Initial key exchange is an implementation detail not covered in this document. No explicit encryption is defined or recommended by this document. An implementation may encrypt the payload in some manner that is invisible to this protocol. Such an implementation may also elect to incorporate an appropriate key exchange as well. Hodges [Page 11] Internet-Draft Digital TV Channel Changing Protocol July, 2001 9. References 1 Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April, 1992 2 Schulzrinne, H, et al, "RTP: A Transport Protocol for Real-TIme Application", RFC 1889, January 1996 3 Hoffman, D, et al, "RTP Payload Format for MPEG1/MPEG2 Video", RFC 2250, January 1998 4 Fenner, W, "Internet Group Management Protocol, Version 2", RFC 2236, November 1997 5 Heinanen, J, "Multiprotocol Encapsulation over ATM Adaptation Layer 5", RFC 1483, July 1993 10. Author's Addresses Richard hodges Matriplex, inc. 769 Basque Way Carson City, NV 89706 Phone: (775) 886-6477 Email: rh@matriplex.com Please direct all comments to rh@matriplex.com This Internet-Draft expires January, 2002. Full Copyright Statement "Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be Hodges [Page 12] Internet-Draft Digital TV Channel Changing Protocol July, 2001 revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on as "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Hodges [Page 13]