Internet Engineering Task Force Marie J. Montpetit ed. Internet Draft MJMontpetit.com, USA Document: draft-ipdvb-arch-00.txt Gorry Fairhurst University of Aberdeen, U.K. Horst D. Clausen Bernhard Collini-Nocker Hilmar Linder University of Salzburg, Austria Category: Informational July 2004 A Framework for transmission of IP datagrams over MPEG-2 networks Status of this Memo By submitting this Internet-Draft, we certify that any applicable patent or other IPR claims of which we am aware have been disclosed, or will be disclosed, and any of which we become aware will be disclosed, in accordance with RFC 3668. By submitting this Internet-Draft, we accept the provisions of Section 3 of RFC 3667 (BCP 78). 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. Copyright (C) The Internet Society (2004), All Rights Reserved Abstract This document describes a new architecture for the transport of IP Datagrams over ISO MPEG-2 Transport Streams (TS). The MPEG-2 TS has been widely accepted not only for providing digital TV services, but also as a subnetwork technology for building IP networks. Examples of systems using MPEG-2 include the Digital Video Broadcast (DVB) and Advanced Television Systems Committee (ATSC) Standards for Digital Television. The document identifies the need for a set of Internet standards defining the interface between the MPEG-2 Transport Stream and an IP subnetwork. It suggests a new encapsulation method for IP datagrams, and proposes protocols to perform IPv6/IPv4 address resolution, to associate IP packets with the properties of the Logical Channels provided by an MPEG-2 TS. Expires November 2004 [page 1] INTERNET DRAFT Architecture for IP transport over DVB July 2004 Table of Contents 1. Introduction 2. Conventions Used in this Document 3. Architecture 4. Encapsulation Protocol 5. Address Resolution Functions 6. Multicast Support 7. Summary 8. Security Considerations 9. Acknowledgments 10. References 11. Author's Addresses 12. IANA Considerations Appendices Expires November 2004 [page 2] INTERNET DRAFT Architecture for IP transport over DVB July 2004 Document History -00 Current version Expires November 2004 [page 3] INTERNET DRAFT Architecture for IP transport over DVB July 2004 1. Introduction This document identifies requirements and an architecture for transport of IP Datagrams over ISO MPEG-2 Transport Streams [MPEG2]. The prime focus is the efficient and flexible delivery of IP services over those subnetworks that use the MPEG-2 transport stream. Hence, the architecture is designed to be compatible with services based on MPEG-2, for example the Digital Video Broadcast (DVB) architecture, the Advanced Television Systems Committee (ATSC) system [ATSC; ATSC-G], and other similar MPEG-2 based transmission systems. Such systems typically provide unidirectional (simplex) physical and link layer standards, and have been defined for a wide range of physical media (e.g. Terrestrial TV [ETSI-DVBT; ATSC-PSIP- TC], Satellite TV [ETSI-DVBS; ATSC-S] and Cable Transmission [ETSI- DVBC; ATSC-PSIP-TC]). +---------+-+-+-+-+------+--------+---+--+--+ | |T|V|A|O| O | | O |S |O | | |e|i|u|t| t | | t |I |t | | |l|d|d|h| h | IP | h | |h | |Protocols|e|e|i|e| e | | e |T |e | |native |t|o|o|r| r | | r |a |r | |over |e| | | | | | |b | | |MPEG-2 TS|x| | | | | +----+-+ |l | | | |t| | | | | | MPE | |e | | | | | | | | +--+---+------+ | | | | | | | | | | AAL5 |Priv. | | | | | +-+-+-+-+---+------+ +-+--+--+ | | PES | ATM |Sect. |Section| +---------+-------+----------+------+-------+ | MPEG-2 TS | +---------+-------+-------+-----------------+ |Satellite| Cable | D-TV | Other PHY | +---------+-------+-------+-----------------+ Figure 1: Overview of the MPEG-2 protocol stack Although many MPEG-2 systems carry a mixture data types, MPEG-2 components may, and are, also used to build IP-only networks. Often, those networks do not implement all parts of a DVB / ATSC system, and may for instance support minimal, or no, signalling of Service Information (SI) tables. Standard system components offer advantages of improved interoperability and larger deployment. 1.1 Salient features of the Architecture The architecture proposed in this document describes a set of protocols to support transmission of IP packets over the MPEG-2 TS. Key characteristics of these networks are that they may provide link- level broadcast capability, and that many supported applications require access to a very large number of subnetwork nodes. Some or Expires November 2004 [page 4] INTERNET DRAFT Architecture for IP transport over DVB July 2004 all of these protocols may also be applicable to other subnetworks, e.g., other MPEG-2 transmission networks, regenerative satellite links [ETSI-BSM], and some types of broadcast wireless links. The key goals of the architecture are to reduce complexity when using the system, while improving performance, increasing flexibility for IP services, and providing opportunities for better integration with IP services. Since a majority of MPEG-2 transmission networks are bandwidth- limited, encapsulation protocols must therefore add minimal overhead to ensure good link efficiency while providing adequate network services. They also needs to be simple to minimize processing, robust to errors and security threats, and extensible to a wide range of services. In MPEG-2 systems, logical channels provide multiplexing, addressing, and error reporting. The logical channel may also be used to provide Quality of Service (QoS). Mapping functions are required to relate Logical Channels to IP addresses, to map Logical Channels to IP-level QoS, and to associate IP flows with specific subnetwork capabilities. An important feature of the proposed architecture will be to provide these functions in a dynamic way, allowing transparent integration with other IP-layer protocols. Collectively, these will form a MPEG-2 TS address resolution protocol suite. Expires November 2004 [page 5] INTERNET DRAFT Architecture for IP transport over DVB July 2004 2. Conventions Used In This Document Adaptation Field: Option control overhead or padding associated with an MPEG-2 TS Packet. Examples of overhead are: TS Logical Channel encryption details and clock (PCR) information to synchronise a set of TS Logical Channels. ATSC: Advanced Television Systems Committee [ATSC]. A set of framework and associated standards for the transmission of video, audio, and data, using the ISO MPEG-2 standard. DSM-CC: Digital Storage Media Command and Control [ISO-DSMCC]. A formatting defined by the ISO MPEG-2 standard, which is carried in an MPEG-2 private section. DVB: Digital Video Broadcast [ETSI-DVB]. A set of framework and associated standards for the transmission of video, audio, and data, using the ISO MPEG-2 standard. ENCAPSULATOR: A network device that receives Ethernet frames or IP packets, and formats these for output as a transport stream of TS Packets. FORWARD DIRECTION: The dominant direction of data transfer over a network path. Data transfer in the forward direction is called "forward transfer". Packets travelling in the forward direction follow the forward path through the IP network. MAC: Medium Access and Control of the Ethernet IEEE 802 standard of protocols (see also NPA). MPE: Multiprotocol Encapsulation [ETSI-DAT]. A scheme that encapsulates Ethernet frames or IP Packets, creating a DSM-CC Section. The Section will be sent in a series of TS Packets over a TS Logical Channel. MPEG-2: A set of standards specified by the Motion Picture Experts Group (MPEG), and standardized by the International Standards Organisation (ISO) [ISO-MPEG]. NPA: Network Point of Attachment. Addresses primarily used for station (Receiver) identification within a local network (e.g. IEEE MAC address). PES: Packetized Elementary Stream. A format of MPEG-2 TS packet payload usually used for video or audio information in MPEG-2 [ISO- MPEG]. Expires November 2004 [page 6] INTERNET DRAFT Architecture for IP transport over DVB July 2004 PID: Packet Identifier. A 13-bit field carried in the header of all MPEG-2 Transport Stream packets [ISO-MPEG]. This is used to identify the TS Logical Channel to which it belongs. A PID of 8191 (decimal) indicates a null packet that must be discarded by a Receiver. PRIVATE SECTION: A syntactic structure used for mapping all service information (e.g. an SI table) into TS Packets. A table may be divided into a number of sections. All sections of a table must be carried over a single TS Logical Channel. SI TABLE: Service Information Table. In this document, the term is used to describe any table used to convey information about the service carried in a TS Multiplex (e.g. [ISO-MPEG]). SI tables are carried in MPEG-2 private sections. STB: Set Top Box. A consumer equipment (Receiver) for reception of digital TV services. TS: Transport Stream [ISO-MPEG], a method of transmission at the MPEG-2 level using TS Packets; it represents level 2 of the ISO/OSI reference model. See also TS Logical Channel and TS Multiplex. TS LOGICAL CHANNEL: A channel identified at the MPEG-2 level; it represents level 2 of the ISO/OSI reference model. All packets sent over a channel carry the same PID value. TS MULTIPLEX: A set of MPEG-2 TS Logical Channels sent over a single common physical bearer (i.e. a link transmitting at a specified symbol rate, FEC setting, and transmission frequency). TS PACKET: A fixed-length 188B unit of data sent over an MPEG-2 multiplex [ISO-MPEG]; it corresponds to the cells, of e.g. ATM networks, and is frequently also referred to as a TS_cell. Each TS Packet carries a 4B header, plus optional overhead including a pointer to the next payload header (PUSI), and an adaptation field. Each TS packet carries a PID value to associate it with a single TS Logical Channel. Expires November 2004 [page 7] INTERNET DRAFT Architecture for IP transport over DVB July 2004 3. Architecture The following sections introduce the components of the MPEG-2 Transmission network and relate these to a networking framework. 3.1 MPEG-2 Transmission Networks There are many possible topologies for the MPEG-2 Transmission Networks. A number of example scenarios are briefly described below, and the following text relates specific functions to this set of scenarios. A) Broadcast TV and Radio Delivery The principal service in the Broadcast TV and Radio Delivery scenario is Digital TV and/or Radio and their associated data [ID- MMUSIC-IMG]. Such networks typically contain two components: the contribution feed and the broadcast part. Contribution feeds provide communication from a typically small number of individual sites (usually at high quality) to the Hub of a broadcast network. The traffic carried on contribution feeds is typically encrypted, and is usually processed prior to being resent on the Broadcast part of the network. The Broadcast part uses a star topology centred on the Hub to reach a typically large numbers of down-stream Receivers. Although such networks may provide IP transmission, they do not necessarily provide access to the public Internet. B) Broadcast Networks used as an ISP Another scenario resembles that above, but includes the provision of IP-services providing access to the public Internet. The IP traffic in this scenario is typically not related to the digital TV/Radio content, and the service may be operated by an independent operator such as uni- directional File Delivery or bi-directional ISP access. The IP service must adhere to the full system specification used for the broadcast transmission, including allocation of PIDs, and generation of appropriate MPEG-2 control information (e.g. DVB and ATSC SI tables). C) Uni-directional Star IP Scenario The Uni-directional Star IP Scenario utilises a Hub station to provide a data network delivering a common bit stream to medium- sized groups of Receivers. MPEG-2 transmission technology provides the forward physical and link layers for this transmission, the return link (if required) is provided by other means. IP services typically form the main proportion of the transmission traffic. Such networks may not necessarily implement the MPEG-2 control plane. D) Data-cast overlay The Data-cast overlay scenario employs MPEG-2 physical and link layers to provide additional connectivity such as uni-directional multicast to supplement an existing IP-based Internet service. Examples of such a network includes IP Datacast to mobile wireless receivers [ID-MMUSIC-IMG]. Expires November 2004 [page 8] INTERNET DRAFT Architecture for IP transport over DVB July 2004 E) Point-to-point links Point-to-point connectivity may be provided using a pair of transmit and receive interfaces supporting the MPEG-2 physical and link layers. Typically the transmission from a sender is received by only one or a small number of Receive terminals. Examples include the use of transmit/receive DVB-S terminals to provide satellite links between ISPs utilising BGP routing. F) Two-Way IP Networks Two-Way IP networks are typically satellite-based and star-based utilising a Hub station to deliver a common bit stream to medium- sized groups of receivers. A bi-directional service is provided over a common air-interface. The transmission technology in the forward physical and link layers for this transmission is MPEG-2, which may also be used in the return direction. Such systems also usually include a control plane element to manage the (shared) return link capacity. A concrete example is the DVB-RCS system. IP services typically form the main proportion of the transmission traffic. Scenarios A-D employ uni-directional MPEG-2 Transmission networks. For satellite-based networks, these typically have a star topology, with a central Hub providing service to large numbers of down-stream Receivers. Terrestrial networks may employ several transmission Hubs each serving a particular coverage cell with a community of Receivers. From an IP viewpoint, the service is typically either uni- directional multicast, or a bi-directional service in which some complementary link technology (e.g. Modem, LMDS, GPRS, ...) is used to provide the return path from Receivers to the Internet. Routing in this case could be provided using Uni-Directional Link Routing (UDLR) [RFC3077]. Note that only Scenarios A-B actually carry MPEG-2 video and audio intended for reception by digital Set Top Boxes (STBs) as the primary traffic. The other scenarios are IP-based data networks and need not necessarily implement the MPEG-2 control plane. Scenarios E-F provide two-way connectivity using MPEG-2 transmission. Such networks provide direct support for bi- directional protocols above and below the IP layer. The complete MPEG-2 transmission network may be managed by a transmission service operator. In such cases, the assignment of addresses and TS Logical Channels at Receivers are usually under the control of the service operator. Examples include a TV operator (Scenario A), or an ISP (Scenarios B-F). MPEG-2 transmission networks are also used for private networks. These typically involve a smaller number of Receivers and do not require the same level of centralised control. Examples include companies wishing to connect DVB-capable routers to form links within the Internet (Scenario B). Expires November 2004 [page 9] INTERNET DRAFT Architecture for IP transport over DVB July 2004 3.2 TS Logical Channels An MPEG-2 transport multiplex offers a number of parallel channels, which are known here as TS Logical Channels. Each MPEG-2 TS Logical Channel is uniquely identified by the Packet ID, PID, value carried in the header of each MPEG-2 TS Packet. The PID value is a 13 bit field and, thus, the number of available channels is limited to 8192 (decimal), some of which are reserved for transmission of SI tables. Non-reserved TS Logical Channels may be use to carry audio [ISO-AUD], video [ISO-VID], IP packets [ISO-DSMCC; ETSI-DAT; ATSC-DAT], or other data [ISO-DSMCC; ETSI-DAT; ATSC-DAT]. The value 8191 (decimal) indicates a null packet, used to maintain the physical bearer bit rate when there are no other MPEG-2 TS Packets to be sent. TS-LC-A-1 /---\--------------------/---\ \ / \ / \ \ | | | | TS-LC-A-2 ----------- | | ------------- -------------------- | | ------------- | | | | /-------- / | ------------- / \----/-------------------\----/ TS-LC-A-3/ MPEG-2 TS MUX A / TS-LC / ------------X \ TS-LC-B-3 /---\------------------------/---\ \ / \ / \ \ | | | | TS-LC-B-2 \----------- | | --------- -------------------- | | --------- | | | | /-------- / | --------- / \----/-----------------------\----/ / MPEG-2 TS MUX B TS-LC-B-1 Figure 2: Example showing MPEG-2 TS Logical Channels carried over 2 MPEG-2 TS Multiplexes. TS Logical Channels are independently numbered on each MPEG-2 TS Multiplex (MUX). In most cases the data sent over the TS Logical Channels will differ for different multiplexes. The above figure shows a set of TS Logical Channels sent using two MPEG-2 TS Multiplexes (A and B). There are cases where the same data may be distributed over two or more multiplexes (e.g., some SI tables; multicast content which needs to be received by Receivers tuned to either MPEG-2 TS; unicast data were the Receiver may be in either/both two potentially overlapping MPEG-2 transmission cells). In figure 2, each multiplex Expires November 2004 [page 10] INTERNET DRAFT Architecture for IP transport over DVB July 2004 carries 3 MPEG-2 TS Logical Channels. These Logical Channels may differ (TS-LC-A-1, TS-LC-A-2, TS-LC-B-2, TS-LC-B-1), or may be common to both MPEG-2 TS Multiplexes (i.e. TS-LC-A-3 and TS-LC-B-3 carry identical content). As can been seen above, there are similarities between the way PIDs are used and the operation of virtual channels in ATM. However, unlike ATM, a PID defines a unidirectional broadcast channel and not a point-to-point link. Contrary to ATM, there is, as yet, no specified standard interface for MPEG-2 connection setup, or for signalling mappings of IP flows to PIDs, or to set the Quality of Service, QoS, assigned to an TS Logical Channel. 3.3 Multiplexing and Re-Multiplexing In a simple example, one or more TS are processed by a MPEG-2 multiplexor resulting in a TS Multiplex. The TS Multiplex is forwarded over a physical bearer towards one or more Receivers (figure 3). +------------+ +------------+ | IP | | IP | | End Host | | End Host | +-----+------+ +------------+ | ^ +------------>+---------------+ | + IP | | +-------------+ Encapsulator | | SI-Data | +------+--------+ | +-------+-------+ |MPEG-2 TS Logical Channel | | MPEG-2 | | | | SI Tables | | | +-------+-------+ ->+------+--------+ | | -->| MPEG-2 | . . . +------------>+ Multiplexor | | MPEG-2 TS +------*--------+ | Logical Channel |MPEG-2 TS Mux | | | Other ->+------+--------+ | MPEG-2 -->+ MPEG-2 | | TS --->+ Multiplexor | | ---->+------+--------+ | |MPEG-2 TS Mux | | | +------+--------+ +------+-----+ |Physical Layer | | MPEG-2 | |Modulator +---------->+ Receiver | +---------------+ MPEG-2 +------------+ TS Mux Figure 3: An example configuration for a uni-directional service for IP transport over MPEG-2 Expires November 2004 [page 11] INTERNET DRAFT Architecture for IP transport over DVB July 2004 In a more complex example, the same TS may be fed to multiple MPEG-2 multiplexors and these may, in turn, feed other MPEG-2 multiplexors (remultiplexing). Remultiplexing may occur in several places (and is common in Scenario A of section 3.1). One example is a satellite that provides on-board processing of the TS packets, multiplexing the TS Logical Channels received from one or more up-link physical bearers (TS Multiplex) to one (or more in the case of broadcast/multicast) down-link physical bearer (TS Multiplex). As part of the remultiplexing process, a remultiplexor may renumber the PID values associated with one or more TS Logical Channels to prevent clashes between input TS Logical Channels with the same PID carried on different input multiplexes. It may also modify and/or insert new SI data into the control plane to reflect the content output using TS Multiplex. In all cases, the final result is a "TS Multiplex" which is transmitted over the physical bearer towards the Receiver. 3.4 IP Datagram Transmission Packet data for transmission over the MPEG-2 transport multiplex is passed to an Encapsulator, sometimes known as a Gateway. This receives Protocol Data Units, PDUs, such as Ethernet frames or IP packets, and formats each into a Sub-Network Data Unit, SNDU, by adding an encapsulation header and trailer (see section 5). The SNDUs are subsequently fragmented into a series of TS Packets. To receive IP packets over a MPEG-2 transport multiplex, a Receiver needs to identify the specific TS Multiplex (physical link) and also the TS Logical Channel (the PID value of a logical link). It is common for a number of MPEG-2 TS Logical Channels to carry SNDUs, and a Receiver must therefore filter (accept) IP packets sent with a number of PID values, and must independently reassemble each SNDU. A Receiver that simultaneously receives from several TS Logical Channels, must filter other unwanted TS Logical Channels by employing for example specific hardware support. Packets for one IP flow (i.e. a specific combination of IP source and destination addresses) must be sent using the same PID. It should not be assumed that all IP packets are carried on a single PID, as in some cable modem implementations, and multiple PIDs must be allowed in the architecture. Many current hardware filters limit the maximum number of active PIDs (e.g. 32), although if needed, future systems may reasonably be expected to support more. In some cases, Receivers may need to select TS Logical Channels from a number of simultaneously active TS Multiplexes. To do this, they need multiple physical receive interfaces (e.g., RF front-ends and demodulators). Some applications also envisage the concurrent Expires November 2004 [page 12] INTERNET DRAFT Architecture for IP transport over DVB July 2004 reception of IP Packets over other media that may not necessarily use MPEG-2 transmission. Bi-directional (duplex) transmission can be provided using a MPEG-2 transmission network by using one of a number of alternate return channel schemes [DVB-RC]. Duplex IP paths may also be supported using non-MPEG-2 return links (e.g. in Scenarios B-D of section 3.1). One example of such an application is that of Uni-Directional Link Routing, UDLR [RFC3077]. The DVB family of standards currently defines a mechanism for transporting an IP packet, or Ethernet frame using the Multi- Protocol Encapsulation (MPE) [ETSI-DAT]. This scheme is also supported in ATSC [ATSC-DAT; ATSC-DATG]. It allows transmission of IP packets or Ethernet style frames in the control plane associated with audio/video transport. Data is formatted as if it were a Table Section. The MPE specification includes a set of optional header components and requires decoding of the control headers. This processing is suboptimal for Internet traffic, since it incurs significant receiver processing overhead and some extra link overhead [CLC99]. +-----------------------------------------+ |Encap Header| Subnetwork DU | +-----------------------------------------+ / / \ \ / / \ \ / / \ \ +------+----------+ +------+----------+ +------+----------+ |MPEG-2| MPEG-2 |..|MPEG-2| MPEG-2 |...|MPEG-2| MPEG-2 | |Header| Payload | |Header| Payload | |Header| Payload | +------+----------+ +------+----------+ +------+----------+ Figure 4: Encapsulation of an SNDU (e.g., IP packet) into a series of MPEG-2 TS Packets (each TS Packet carries a header with a common Packet ID, PID, value denoting the MPEG-2 TS Logical Channel). 3.5 Motivation The network layer protocols to be supported by this architecture include: (i) IPv4 Unicast packets, destined for a single end host (ii) IPv4 Broadcast packets, sent to all end systems in an IP network (iii) IPv4 Multicast packets (iv) IPv6 Unicast packets, destined for a single end host (v) IPv6 Multicast packets (vi) Packets with compressed IPv4 / IPv6 packet headers (e.g. [RFC1114; RFC2507; RFC3095]) (vii) Bridged Ethernet frames (viii) Other (MPLS, IPv6 anycast, potential new protocols__ Expires November 2004 [page 13] INTERNET DRAFT Architecture for IP transport over DVB July 2004 The architecture will provide: (i) Guidance on which MPEG-2 features are pre-requisites for the IP service, and identification of any optional fields that impact performance/correct operation. (ii) Standards to provide an efficient and flexible encapsulation scheme that may be easily implemented in an Encapsulator or Receiver. The payload encapsulation requires a type field for the SNDU to indicate the type of packet and a mechanism to signal which encapsulation is used on a certain PID. (iii) Standards to associate a particular IP address with a Network Point of Attachment (NPA) that could or could not be a MAC Address. This process resembles the IPv4 Address Resolution Protocol, ARP, or IPv6 Neighbour Discovery, ND, protocol [AR- DRAFT]. In addition, the standard will be compatible with IPv6 autoconfiguration. (iv) Standards to associate a MPEG-2 TS interface with one or more specific TS Logical Channels (PID, TS Multiplex). Bindings are required for both unicast transmission, and multicast reception. In the case of IPv4 this must also support network broadcast. To make the schemes robust to loss and state changes within the MPEG-2 transmission network, a soft-state approach may prove desirable. (v) Standards to associate the capabilities of a MPEG-2 TS Logical Channel with IP flows. This includes mapping of QoS functions, such as IP QoS/DSCP and RSVP, to underlying MPEG-2 TS QoS, multi-homing and mobility. This capability could be associated by the AR standard proposed above. (vi) Guidance on Security for IP transmission over MPEG-2. The framework must permit use of IPSEC and clearly identify any security issues concerning the specified protocols. The security issues need to consider two cases: unidirectional transfer (in which communication is only from the sending IP end host to the receiving IP end host) and bi-directional transfer. Consideration should also be given to security of the TS Multiplex: the need for closed user groups and the use of MPEG-2 TS encryption. (vii) Management of the IP transmission, including standardised SNMP MIBs and error reporting procedures. The need for and scope of this is to be determined. The specified architecture and techniques should be suited to a range of systems employing the MPEG-2 TS, and may also suit other (sub) networks offering similar transfer capabilities. Expires November 2004 [page 14] INTERNET DRAFT Architecture for IP transport over DVB July 2004 The following sections 4 and 5 describe encapsulation issues. Sections 6 and 7 describe address resolution issues for unicast and multicast. The appendix provides some use cases. 4. Encapsulation Protocol Requirements This section identifies requirements and provides examples of mechanisms that may be used to perform the encapsulation of IPv4 and IPv6 multicast and unicast packets over MPEG-2 transmission networks. The encapsulation protocol transports a SNDU over the MPEG-2 TS service and provides the appropriate mechanisms to deliver this to the Receiver IP interface. A convergence protocol typically adds header fields before a SNDU that carry protocol control information such as length of SNDU, Receiver address, multiplexing information, payload type, sequence numbers etc. The SNDU payload is typically followed by a trailer, which carries an Integrity Check (e.g., Cyclic Redundancy Check, CRC). Some protocols also add additional control information and/or padding to or after the trailer. +--------+-------------------------+-----------------+ | Header | SNDU | Integrity Check | +--------+-------------------------+-----------------+ Figure 5: Encapsulation of a subnetwork PDU (e.g. IPv4 or IPv6 packet) to form an MPEG-2 Payload Unit. Examples of existing convergence protocols include ATM AAL5 [ITU- AAL5], and MPEG-2 MPE [ETSI-DAT]. The existing proposals and standards for use with MPEG-2 carry heritage from legacy implementations that reflect the limitations of technology at their deployment. For example a majority are more dominated by audio/video considerations than IP requirements. This justifies the development of a new encapsulation that will be truly IP-centric. Carrying IP packets over a TS Logical Channel involves several convergence protocol functions. This section briefly describes these functions and highlights the requirements for a new encapsulation. 4.1 Payload_Unit Delimitation MPEG-2 indicates the start of a Payload Unit in a new TS Packet with a "start_of_payload_unit_indicator" (PUSI) [ISO-MPEG] carried in the 4B TS Packet header. The PUSI is a 1 bit flag that has normative meaning [ISO_MPEG] for TS Packets that carry PES Packets or PSI data. When the payload of a TS Packet contains PES data, a PUSI value of '1' indicates the TS Packet payload starts with the first byte of a Expires November 2004 [page 15] INTERNET DRAFT Architecture for IP transport over DVB July 2004 PES Packet. A value of '0' indicates that no PES Packet starts in this TS Packet. If the PUSI is set to '1', then one, and only one, PES Packet starts in the TS Packet. When the payload of the TS Packet contains PSI data, a PUSI value of '1' indicates the first byte of the TS Packet payload carries a payload pointer that indicates the position of the first byte of the Payload Unit (Section) being carried; if the TS Packet does not carry the first byte of a Section, the PUSI is set to '0', indicating that there is no payload pointer. Using this PUSI bit, the start of the first Payload Unit in a TS Packet is exactly known by the Receiver, unless that TS Packet has been corrupted or lost in the transmission. In which case, the payload is discarded until the next TS Packet is received with a PUSI value of '1'. The encapsulation should allow packing of more than one SNDU into the same TS Packet and should not limit the number of SNDUs that can be sent in a TS Packet. In addition, it should allow an IP Encapsulator to insert padding when there is an incomplete TS Packet payload. A mechanism needs to be identified to differentiate this padding from the case where another encapsulated SNDU follows. A combination of the PUSI and a Length Indicator (see below) allows an efficient MPEG-2 convergence protocol to receive accurate delineation of packed SNDUs. The MPEG-2 standard [ISO_MPEG] however does not specify how private data should use the PUSI bit. 4.2 Length Indicator Most services using MPEG-2 include a length field in the payload header to allow the Receiver to identify the end of a payload unit (e.g. PES Packet, Section, or an SNDU). When parts of more than two Payload Units are carried in the same TS Packet, only the start of the first is indicated by the Payload Pointer. Placement of a Length Indicator in the encapsulation header allows a Receiver to determine the number of bytes until the start of the next encapsulated SNDU. This placement also provides the opportunity for the Receiver to pre-allocate an appropriate-sized memory buffer to receive the reassembled SNDU. A Length Indicator is required, and should be carried in the encapsulation header. This should support SNDUs of at least the MTU size offered by Ethernet (1500 bytes). Although the IPv4 and IPv6 packet format permits an IP packet of size up to 64 KB, such packets are seldom seen on the current Internet. Since high speed links are often limited by the packet forwarding rate of routers, there has been a tendency for Internet core routers to support MTU values larger than 1500 bytes. A value of 16 KB is not uncommon in the core Expires November 2004 [page 16] INTERNET DRAFT Architecture for IP transport over DVB July 2004 of the current Internet. This would seem a suitable maximum size for an MPEG-2 transmission network. 4.3 Next Level Protocol Type A key feature of the new encapsulation is to identify the type of payload being transported (e.g., to differentiate IPv4, IPv6 etc.). Most protocols use a type field to identify a specific process at the next higher layer that is the originator or the recipient of the payload (SNDU). This method is used by IPv4, IPv6, and also by the original Ethernet protocol (DIX). OSI uses the concept of a 'Selector' for this, (e.g. in the IEEE 802/ISO 8802 standards for CSMA/CD [LLC], although in this case a SNAP (subnetwork access protocol) header is also required for IP packets. A Next Level Protocol Type field is also required if compression (e.g. Robust Header Compression, ROHC) is supported. No compression method has currently been defined that is directly applicable to this architecture, however the ROHC framework defines a number of header compression techniques that may yield considerable improvement in throughput on links which have a limited capacity. Since many MPEG-2 transmission networks are wireless the ROHC framework will be directly applicable for many applications. Use of ROHC implies the need to transfer smaller SNDUs and the need for additional processing at the Receiver to expand the received compressed packets. The selected type field should contain sufficient code points to support this technique. It is thus a requirement to include a Next Level Protocol Type field in the encapsulation header. Such a field should specify values for at least IPv4, IPv6, and must allow for other values (e.g., MAC- level bridging). 4.4 L2 Subnet Addressing In MPEG-2, the PID carried in the TS Packet header is used to identify individual services with the help of SI tables. This was primarily intended as a unidirectional (simplex) broadcast system. A TS Packet stream carries either tables or one PES Packet stream (i.e., compressed video or audio). Individual Receivers are not addressable at this level. IPv4 and IPv6 allocate addresses to end hosts and intermediate systems (routers). Each system (or interface) is identified by a globally assigned address. ISO uses the concept of a hierarchically structured Network Service Access Point (NSAP) address to identify an end user process in an Internet environment. Within a local network a completely different set of addresses for the Network Point of Attachment (NPA) is used; frequently these NPA addresses are referred to as Medium Access Control, MAC-level addresses. In the Internet they are also called hardware addresses. Expires November 2004 [page 17] INTERNET DRAFT Architecture for IP transport over DVB July 2004 Whereas network layer addresses are used for routing, NPA addresses are primarily used for Receiver identification. Receivers may use the NPA of a received SNDU to reject unwanted unicast packets within the (software) interface driver at the Receiver, but must also perform forwarding checks based on the IP address. IP multicast and broadcast may also filter based using the NPA, but Receivers must also filter unwanted packets at the network layer based on source and destination IP addresses. This does not imply that each IP address must map to a unique NPA (more than one IP address may map to the same NPA). If a separate NPA address is not required, the IP address is sufficient for both functions. If it is required to address an individual Receiver in an MPEG-2 transport system, this can be achieved either at the network level (IP address) or via a hardware-level NPA address (MAC-address). If both addresses used, they must be mapped either in a static or a dynamic way (e.g., by an address resolution process). A similar requirement may also exist to identify the PID and TS multiplex on which services are carried. Using an NPA address in a MPEG-2 transport system may enhance security, in that a particular payload may be targeted for a particular Receiver by specifying the Receiver NPA address. This is however only a weak form of security, since the NPA filtering is often reconfigurable (frequently performed in software), and may be modified by a user to allow reception of specified (or all) packets, similar to promiscuous mode operation in Ethernet. If security is required, it should be applied at another place (e.g. link encryption, authentication of address resolution, IPSEC, transport level security and/or application level security). There are also cases where the use of a NPA is required (e.g. where a system operates as a router) and if present this should be carried in encapsulation header where it may be used by Receivers as a pre- filter to discard unwanted SNDUs. The addresses allocated do not need to conform to the IEEE MAC address format. There are many cases where a NPA is not required, and network layer filtering may be used. A new encapsulation protocol should therefore support an optional NPA. 4.5 Integrity Check For the IP service, the probability of undetected packet error should be small (or negligible) [ID-PILC-LINK]. There is therefore a need for a CRC to verify correctness of a received IP packet. Such checks should be sufficient to detect incorrect operation of the encapsulator and Receiver (including reassembly errors following loss/corruption of TS Packets), in addition to protecting from loss and/or corruption by the transmission network (e.g., multiplexors and links). Expires November 2004 [page 18] INTERNET DRAFT Architecture for IP transport over DVB July 2004 Mechanisms exist in MPEG-2 transmission networks that may assist in detecting loss (e.g. the 4-bit continuity counter included as standard in the MPEG-2 TS Packet header). A convergence protocol should use an encapsulation that provides a strong integrity check. For ease of hardware implementation, this check should be carried in a trailer following the SNDU. A CRC-32 is sufficient for operation with up to a 12 KB payload, and may still provide adequate protection for larger payloads. 4.6 Identification of Scope. The MPE section header contains information that may be used by the Receiver to identify the scope of the (MAC) address carried as a NPA, and prevent TS Packets intended for one scope to be received by another. Similar functionality may be achieved by ensuring that only IP packets that do not have overlapping scope are sent on the same TS Logical Channel. In some cases, this may imply the use of multiple TS Logical Channels. 4.7 Extension Headers The evolution of the Internet service may in future require additional functions. A flexible protocol should therefore provide a way to introduce new features when required, without having to provide additional out-of-band configuration. IPv6 introduced the concept of extension headers that carry extra information necessary/desirable for certain subnetworks. The DOCSIS cable specification also allows a MAC header to carry extension headers to build operator-specific services. It is thus a requirement for the new encapsulation to allow extension headers. 4.8 Summary of Requirements for Encapsulation The main requirements for an IP-centric encapsulation include: - support of IPv4 and IPv6 packets - support for Ethernet encapsulated packets - flexibility to support other IP formats and protocols (e.g. ROHC, MPLS) - easy processing by hardware devices - low overhead/managed overhead - a fully specified algorithm that allows a sender to pack multiple packets per SNDU and to easily locate packet fragments - extensibility - compatibility with legacy deployments - ability to allow link encryption, when required - capability to support a full network architecture including data, control and management planes Expires November 2004 [page 19] INTERNET DRAFT Architecture for IP transport over DVB July 2004 5. Address Resolution Functions Address Resolution (AR) provides a mechanism that associates L2 information with the IP address of a system. Many L2 technologies employ unicast AR at the sender: an IP system wishing to send an IP packet encapsulates it and places it into a L2 frame. It then identifies the appropriate L3 adjacency (e.g. next hop router, end- host) and determines the appropriate L2 adjacency (e.g. MAC address in Ethernet) to which the frame should be sent so that the packet gets across the L2 link. The L2 addresses discovered using AR are normally recorded in a data structure known as the arp/neighbor cache. The results of previous AR requests are usually cached. Further AR protocol exchanges may be required as communication proceeds to update or re-initialise the client cache state contents (i.e. purge/refresh the contents [ND]). For stability, and to allow network topology changes and client faults, the cache contents are normally "soft state", that is, they are aged with respect to time and old entries removed. In some cases (e.g. ATM, FR, X.25, MPEG-2 and many more), AR involves finding other information than the MAC address. This includes identifying other parameters required for L2 transmission, such as channel IDs (VCs in X.25, VCIs in ATM, or PIDs in MPEG-2 TS). Address resolution has different purposes for unicast and multicast. Multicast address resolution is not required for many L2 networks, but is required for many MPEG-2 transmission networks. 5.1 Address Resolution for MPEG-2 There are three elements to the L2 information required to perform AR for a MPEG-2 TS. These are: (i) A Receiver ID (e.g. a 6B MAC/NPA address). (ii) A PID or index to find a PID. (iii) Tuner information (e.g. a Transport Stream ID) that maps to a set of physical layer parameters. Elements (ii) and (iii) need to be de-referenced via indexes to the PMT when remultiplexors are used that may renumber the PID values, (i.e. PIDs are not intended to be end-to-end identifiers). However, although such use is common in broadcast TV networks, many private networks do not need to employ multiplexors that renumber PIDs (see section 3.2). The third element (iii) allows an AR client to resolve to a different MPEG TS Multiplex. This is used when there are several channels that may be used for communication (i.e. multiple outbound/inbound links). In a mesh system, this could be used to determine connectivity. Expires November 2004 [page 20] INTERNET DRAFT Architecture for IP transport over DVB July 2004 This AR information is used in two ways at a Receiver: (i) AR resolves an IP unicast or IPv4 broadcast address to the (MPEG TS Multiplex, PID, MAC/NPA address). This allows the Receiver to set L2 filters to let traffic pass to the IP layer. This is used for unicast, and IPv4 subnet broadcast. Usually this is configured with the equivalent of an "ifconfig" on the interface. (ii) AR resolves an IP multicast address to the (MPEG TS Multiplex, PID, MAC/NPA address), and allows the Receiver to set L2 filters enabling traffic pass to the IP layer. This operation may need to be performed many times based on IGMP, MLD, and Multicast Routing protocol operation. A Receiver in a MPEG-2 TS network needs to resolve the PID value and tuning parameters associated with a TS Logical Channel and (at least for unicast) the destination Receiver NPA address. A star topology MPEG-2 TS transmission network is illustrated below, with two terminals receiving a forward broadcast channel sent by a Hub. (A mesh system has some additional cases.) The forward broadcast channel consists of a "TS Multiplex" (a single physical bearer) allowing communication with the terminals. These communicate using a set of return channels. Forward broadcast MPEG-2TS \ ----------------X /-----\ / / \ | Receiver| /----------+ A | / \ / /-----\ / \-----/ / \ / | Hub |/ | +\ /-----\ \ / \ / \ \-----/ \ | Receiver| \-----------+ B | \ / \-----/ Figure 6: MPEG-2 Transmission Network with 2 Receivers There are three possibilities for unicast AR: (1) A system at a terminal, A, needs to resolve an address of a system that is at the hub; (2) A system at a terminal, A, needs to resolve an address that is at another terminal, B; (3) A host at the hub needs to resolve an address that is at a terminal. The sender (encapsulation gateway), uses AR to provide the (MPEG TS Multiplex, PID, MAC/NPA address) to be used to send unicast, IPv4 subnet broadcast and multicast packets. Expires November 2004 [page 21] INTERNET DRAFT Architecture for IP transport over DVB July 2004 If the Hub is as an IP router, then case (1) and (2) are the same: the host at the Receiver doesn't know the difference. In these cases, the address to be determined is the L2 address of the device at the hub to which the IP packet should be forwarded, and which then relays the IP packet back to the forward (broadcast) MPEG-2 channel after AR (case 3). If the hub is a L2 bridge, then case 2 still has to relay the IP packet back to the outbound MPEG-2 channel. The AR protocol needs to resolve the specific Receiver L2 MAC address of B, but needs to send this on a L2 channel to the Hub. This requires terminals to be informed of the L2 address of other terminals. An end host connected to the hub needs to use the AR protocol to resolve the Receiver terminal MAC/NPA address. This requires the AR server at the Hub to be informed of the L2 addresses of other terminals. 5.2 Scenarios for MPEG AR An AR protocol may transmit AR information in three distinct ways: (i) An MPEG-2 signalling table transmitted at the MPEG-2 level (ii) An MPEG-2 signalling table transmitted at the IP level (tbd, no implementations of this are known) (iii) An address resolution protocol transported over IP (as in ND) There are three distinct cases in which AR may be used: A. Multiple TS-Mux and the use of re-multiplexors; e.g. Digital Terrestrial, Satellite TV broadcast multiplexes. Many such systems employ remultiplexors that modify the PID values associated with TS Logical Channels as they pass through the MPEG-2 transmission network (see Scenario A of Section 3.1). B. Tuner configuration(s) that are fixed or controlled by some other process. In these systems, the PID value associated with a TS Logical Channel may be known by the Sender. C. A service run over one TS Mux (i.e., uses only one PID, for example DOCSIS and some current DVB-RCS multicast systems). In these systems, the PID value of a TS Logical Channel may be known by the Sender. 5.2.1 Table-based AR over MPEG-2 In current deployments of MPEG-2 networks, information about the set of MPEG-2 TS Logical Channels carried over a TS Multiplex is usually distributed via tables (service information, SI) sent using channels assigned a specific (well-known) set of PIDs. This was originally designed for audio/video distribution to set-top-boxes. The design Expires November 2004 [page 22] INTERNET DRAFT Architecture for IP transport over DVB July 2004 requires access to and processing of the SI table information (which is carried in MPEG-2 section format [ISO_DSMCC]). This scheme reflects the complexity of delivering and co-ordinating the various TS Logical Channels associated with a multimedia TV programme. One possible requirement to provide TS multiplex and PID information for IP services is to integrate additional information into the existing MPEG-2 tables, or to define additional tables specific to the IP service. The DVB INT and the A/92 Specification from ATSC [ATSC-A92] are examples of the realization of such a requirement. 5.2.2 Table-based AR over IP AR information could be carried over a TS data channel, (e.g. using an IP protocol similar to the Service Announcement Protocol, SAP). Implementing this independently of the SI tables, would ease implementation, by allowing it to operate on systems where IP processing is performed in a software driver. It may also allow the technique to be more easily adapted to other similar delivery networks. It also is advantageous for networks which use the MPEG-2 TS but links, but do not necessarily support audio/video services and therefore do not need to provide interoperability with TV equipment (e.g. links used solely for connecting IP (sub)networks). 5.2.3. Query/Response AR over IP A query/response protocol may be used at the IP level (similar to, or based on IPv6 Neighbor Advertisements of the ND protocol). The AR protocol may operate over an MPEG-2 TS Logical Channel using a previously agreed PID (e.g. configured, or communicated using a SI table). In this case, the AR could be performed by the target system itself (as in arp and nd). This has good soft-state properties, and is very tolerant to failures. To find an address, a system sends a "query" to the network, and the "target" replies. 5.3 Scoping In some case, an MPEG-2 Transmission Network may support multiple IP networks. If this is the case, it is important to recognise the context (scope) within which an address is resolved, to prevent packets from one addressed scope leaking into other scopes. Examples of overlapping IP address assignments, include: (i) Private unicast addresses (e.g. in IPv4, 10/8 prefix; 172.16/12 prefix; 192.168/16 prefix) should be confined to one addressed area. (ii) Some multicast addresses, (e.g., the scoped multicast addresses sometimes used in private networks). These are only valid within an addressed area (examples for IPv4 include; Expires November 2004 [page 23] INTERNET DRAFT Architecture for IP transport over DVB July 2004 239/8; 224.0.0/24; 224.0.1/24). Similar cases exist for some IPv6 multicast addresses. (iii) Scoped multicast addresses. Forwarding of these addresses is controlled by the scope associated with the address. IP packets with these addresses must not be allowed to travel outside their intended scope, and may cause unexpected behaviour if allowed to do so. In addition, overlapping address assignments can arise using level 2 NPA addresses: (i) The NPA address must be unique within the TS Logical Channel. IEEE MAC addresses used in Ethernet LANs are globally unique. If the NPA addresses are not globally unique, the same NPA address may be re-used by Receivers in different addressed areas. (ii) The NPA broadcast address (all 1s MAC address). Traffic with this address should be confined to one addressed area. (iii) Other non-IP protocols may also view sets of MAC multicast addresses as link-local, and may produce unexpected results if distributed across several private networks! Reception of unicast packets destined for another addressed area may lead to an increase in the rate of received packets by systems connected via the network. IP end hosts normally filter received unicast IP packets based on their assigned IP address. Reception of the additional network traffic may contribute to processing load but should not lead to unexpected protocol behaviour. It does however introduce a potential Denial of Service (DoS) opportunity. When the Receiver acts as an IP router, the receipt of such an IP packet may lead to unexpected protocol behaviour. This also provides a security vulnerability since arbitrary packets may be passed to the IP layer. 5.5 AR Authentication In many AR designs authentication has been overlooked, because of the wired nature of most existing IP networks, which makes it easy to control hosts physically connected. With wireless connections, this is changing: unauthorised hosts actually can claim L2 resources. The address resolution client (i.e. Receiver) may also need to verify the integrity and authenticity of the AR information that it receives. There are trust relationships both ways: clients need to know they have a valid server and that the resolution is valid.Servers have a basic authorisation issue before they allow a L2 address to be used. Expires November 2004 [page 24] INTERNET DRAFT Architecture for IP transport over DVB July 2004 The MPEG-2 transmission system may also require access control to prevent unauthorised use of the satellite bearer, however, this is an orthogonal issue to address resolution. 5.6 Requirements for Unicast AR over MPEG-2 The requirement for AR over MPEG-2 networks include: (i) Use of a table based approach to promote AR scaling. This requires definition of the frequency of update and volume of AR traffic generated. (ii) Mechanisms to install AR information at the server (unsolicited registration). (iii) Mechanisms to verify AR information held at the server (solicited responses). Appropriate timer values need to be defined. (iv) An ability to purge client AR information (after IP network renumbering, etc.). (v) Support of IP subnetwork scoping. (vi) Appropriate security associations to authenticate the sender. 6. Multicast Support This section addresses specific issues concerning IPv4 and IPv6 multicast over MPEG-2 Transmission Networks. The primary goal of multicast support will be efficient filtering of IP-multicast packets by the Receiver, and the mapping of IPv4 and IPv6 multicast addresses onto the associated PID value and TS Multiplex. The design should permit a large number of active multicast groups, and should minimise the processing load at the Receiver when filtering and forwarding IP multicast packets. For example, schemes that may be easily implemented in hardware would be beneficial, since these may relieve drivers and operating systems from discarding unwanted multicast traffic. Multicast mechanisms are used at more than one protocol level. The upstream MPEG-2 router may forward multicast traffic on the MPEG-2 TS link using a static or dynamic set of groups. When static forwarding is used, the set of groups may also be configured or set using SNMP, Telnet, etc. A Receiver normally uses either IGMP/MLD or multicast routing to establish membership tables that it uses to dynamically set local forwarding of received groups. In a dynamic case, this group membership information is fed-back to the Sender to enable it to start sending new groups and (if required) to update the tables that it produces for multicast AR. Appropriate procedures need to identify the correct action when the same multicast group is available on more than one TS Logical Channel. This could arise when different end hosts act as senders to contribute IP packets with the same IP group destination address. Expires November 2004 [page 25] INTERNET DRAFT Architecture for IP transport over DVB July 2004 It may also arise when a sender duplicates the same IP group over several TS Logical Channels (or even different TS Multiplexes), and in this case a Receiver may potentially receive more than one copy of the same packet. At the IP level, the host/router may be unaware of this duplication. 6.1 Multicast AR Functions The functions required for multicast AR may be summarised as: (i) The Sender needs to know L2 mapping of multicast group. (ii) The Receiver needs to know L2 mapping of multicast group. In the Internet, multicast AR is normally a mapping function rather than a one-to-one association using a protocol. In Ethernet, the sender maps an IP address to a L2 MAC address, and the Receiver uses the same mapping to determine the L2 address to set a L2 hardware/software filter entry. A typical sequence of actions for the dynamic case is: L3) Populate the IP L3 membership tables at the Receiver. L3) Receivers send/forward IP L3 membership tables to the Hub L3) Dynamic/static forwarding at hub/upstream router of IP L3 groups L2) Populate the IP AR tables at the encapsulator gateway (i.e. Map IP L3 mcast groups to L2 (PIDs)) L2) Distribute the AR information to Receivers L2) Set Receiver L2 multicast filters for IP groups in the membership table. Multicast also introduces the concept of scoped addresses, requiring appropriate scoping to be followed. To be flexible AR must associate a Logical Channel (PID) not only with a group, possibly a QoS class, and other appropriate MPEG-2 TS attributes. Performing multicast AR at the IP level can enable providers wishing to provide independently scoped addresses would need to use multiple Multicast AR servers, one per multicast domain. Explicit per group AR to individual L2 addresses is to be avoided. Expires November 2004 [page 26] INTERNET DRAFT Architecture for IP transport over DVB July 2004 \ | +---+----+ +--------+ | Tuner |---+TS Tabl | . . . . +---+----+ +--------+ . | . +--------+ +--------+ . | deMux |---+PID Tabl|........ +---+----+ +--------+ : | : +--------+ +--------+ +--------+ |MPE/ULE |---+AR Cache|---+ MFIB | +---+----+ +--------+ +--------+ | | | +---+----+ +---+----+ +---+----+ | IP | | AR | |IGMP/MLD| +---+----+ +---+----+ +---+----+ | | | *------------+------------+ Figure 7: Receiver Processing Architecture 6.2 Requirements for Multicast over MPEG-2 The requirements for supporting multicast include, but are not restricted to: (i) Encapsulating multicast packets for transmission using a MPEG-2 TS. (ii) Mapping IP multicast groups to the underlying MPEG-2 TS Logical Channel (PID) and the MPEG-2 TS Multiplex. (iii) Provide AR information to allow a Receiver to locate an IP multicast flow within an MPEG-2 TS Multiplex. (v) Error Reporting. 7. Summary This document describes the architecture for a set of protocols to perform efficient and flexible support for IP network services over networks built upon the MPEG-2 Transport Stream (TS). It also describes existing approaches. It focuses on IP networking, the mechanisms that are used and their applicability to supporting IP unicast and multicast services. The requirements for a new encapsulation of IPv4 and IPv6 packets is described, outlining the limitations of current methods and the need for a streamlined IP-centric approach. The architecture also describes MPEG-2 Address Resolution (AR) procedures to allow dynamic configuration of the sender and Receiver using an MPEG-2 transmission link/network. These support IPv4 and IPv6 services in both the unicast and multicast modes. Resolution protocols will support IP packet transmission using both the Expires November 2004 [page 27] INTERNET DRAFT Architecture for IP transport over DVB July 2004 Multiprotocol Encapsulation (MPE), which is currently widely deployed, and also any new optimised encapsulation. 8. Security Considerations When the MPEG-2 network is not using a wireline network, the normal security issues relating to the use of wireless links for transport Internet traffic should be considered [ID-PILC-LINK]. End-to-end security (including confidentiality, authentication, integrity and access control) is closely associated with the end- user assets that are protected. This close association cannot be ensured when providing security mechanisms only within a subnetwork (e.g. an MPEG-2 transmission network). Several security mechanisms that can be used end-to-end have already been deployed in the general Internet and are enjoying increasing use. Important examples include: * The Secure Sockets Layer (SSL) and Transport Layer Security, TLS, which is primarily used to protect web commerce; * Pretty Good Privacy (PGP) and S/MIME, primarily used to protect and authenticate email and software distributions; * The Secure Shell (SSH), used to secure remote access and file transfer; * IPsec, a general purpose encryption and authentication mechanism above IP that can be used by any IP application. However, subnetwork security is also important [ID-PILC-LINK] and should be encouraged, on the principle that it is better than the default situation, which all too often is no security at all. Users of especially vulnerable subnets (such as radio/broadcast networks and /or shared media Internet access) often have control over at most one endpoint - usually a client and therefore cannot enforce the use of end-to-end mechanisms. A related role for subnetwork security is to protect users against traffic analysis, i.e., identifying the communicating parties (by IP or MAC address) and determining their communication patterns, even when their actual contents are protected by strong end-to-end security mechanisms (this is important for networks such as broadcast/radio, where eaves-dropping is easy). Where it is possible for an attacker to inject traffic into the subnetwork control plane, subnetwork security can additionally protect the subnetwork assets. This threat must specifically be considered for the protocols used for subnetwork control functions (e.g. address resolution, management, configuration). Possible threats include theft of service and denial of service; shared media subnets tend to be especially vulnerable to such attacks [ID-PILC- LINK]. Appropriate security functions must therefore be provided for Expires November 2004 [page 28] INTERNET DRAFT Architecture for IP transport over DVB July 2004 ipdvb control protocols [ID-PILC-LINK], particularly when the control functions are provided above the IP-layer using IP-based protocols. Internet level security mechanisms (e.g. IPSEC) can mitigate such threats. In general, End-to-End security is recommended for users of any communication path, especially when it includes a wireless/radio/broadcast link, where a range of security techniques already exist. Specification of security mechanisms at the application layer, or within the MPEG-2 transmission network are the concerns of organisations beyond the IETF. The complexity of any such security mechanisms should be considered carefully so that it will not unduly impact the IP operation. 8.1 Link Encryption Link level encryption of IP traffic is commonly used in broadcast/radio links to supplement End-to-End security (e.g. provided by SSL, SSH, PGP, IPSec). The encryption and key exchange methods vary significantly, depending on the intended application. For example, DVB-S/DVB-RCS operated by Access Network Operators (ANO) may wish to provide their customers (Internet Service Providers, ISP) with security services. Common targeted security services are: terminal authentication and data confidentiality (for unicast and multicast) between a gateway and Receivers. A common objective is to provide the same level of privacy as terrestrial links. An ISP may also wish to provide end-to-end security services to the end-users (based on the well known mechanisms such as IPSec). Therefore it is important to understand that both security solutions (ANO-to-ISP and ISP-to-end users) may co-exist. MPE supports optional link encryption using a pair of bits within the MPE protocol header to indicate the use of encryption. To support optional link level encryption, it is recommended that a new encapsulation also supports optional encryption of the SNDU payload. Furthermore, it may be desirable to encrypt/authenticate some/all of the SNDU headers. The method of encryption and the way in which keys are exchanged is beyond the scope of the ULE Specification. However, the specification must provide appropriate code points to allow such encryption to be implemented at the link layer. 9. Acknowledgments The authors wish to thank Isabel Amonou , Torsten Jaekel, Pierre Loyer, Luoma Juha-Pekkaand and Rod Walsh for their detailed inputs. We also wish to acknowledge the input provided by the members of the IETF ipdvb WG. Expires November 2004 [page 29] INTERNET DRAFT Architecture for IP transport over DVB July 2004 10. References 10.1 Normative References [ISO-MPEG] ISO/IEC DIS 13818-1:2000 "Information technology -- Generic coding of moving pictures and associated audio information: Systems", International Standards Organisation (ISO). [ETSI-DAT] EN 301 192 Specifications for Data Broadcasting, European Telecommunications Standards Institute (ETSI). [RFC1122] B. Braden, ed., "Requirements for Internet Hosts - Communication Layers", RFC 1122. 10.2 Informative References [ATSC] A/53C, "ATSC Digital Television Standard", Advanced Television Systems Committee (ATSC), Doc. A/53C, 2004. [ATSC-DAT] A/90, "ATSC Data Broadcast Standard", Advanced Television Systems Committee (ATSC), Doc. A/090, 2000. [ATSC-DATG] A/91, "Recommended Practice: Implementation Guidelines for the ATSC Data Broadcast Standard", Advanced Television Systems Committee (ATSC),Doc. A/91, 2001. [ATSC-A92] A/92 "Delivery of IP Multicast Sessions over ATSC Data Broadcast", Advanced Television Systems Committee (ATSC), Doc. A/92, 2002. [ATSC-G] A/54A, "Guide to the use of the ATSC Digital Television Standard", Advanced Television Systems Committee (ATSC), Doc. A/54A, 2003. [ATSC-PSIP-TC] A/65B, "Program and System Information Protocol for Terrestrial Broadcast and Cable", Advanced Television Systems Committee (ATSC), Doc. A/65B, 2003. [ATSC-S] A/80, "Modulation and Coding Requirements for Digital TV (DTV) Applications over Satellite", Advanced Television Systems Committee (ATSC), Doc. A/80, 1999. [CLC99] Clausen, H., Linder, H., and Collini-Nocker, B., "Internet over Broadcast Satellites", IEEE Commun. Mag. 1999, pp.146-151. [ETSI-DAT] EN 301 192 Specifications for Data Broadcasting, European Telecommunications Standards Institute (ETSI). [ETSI-DVBC] EN 300 800 Digital Video Broadcasting (DVB); DVB interaction channel for Cable TV distribution systems (CATV), European Telecommunications Standards Institute (ETSI). Expires November 2004 [page 30] INTERNET DRAFT Architecture for IP transport over DVB July 2004 [ETSI-DVBS] EN 301 421 Digital Video Broadcasting (DVB); Modulation and Coding for DBS satellite systems at 11/12 GHz, European Telecommunications Standards Institute (ETSI). [ETSI-DVBT] EN 300 744 Digital Video Broadcasting (DVB); Framing structure, channel coding and modulation for digital terrestrial television (DVB-T), European Telecommunications Standards Institute (ETSI). [ID-IPDVB-ULE] Fairhurst, G., B. Collini-Nocker, "Simple Ultra Lightweight Encapsulation for transmission of IP datagrams over MPEG-2/DVB networks", Internet Draft, draft-ipdvb-ule-xx.txt, Work in Progress, IP-DVB WG. [ID-PILC-LINK] P. Karn (ed) Advice for Internet Subnetwork Designers, Internet Draft draft-ietf-pilc-link-design-00.txt , Work in Progress, IETF PILC WG, BCP (with RFC-Ed). [ID-IPDVB-AR] Fairhurst, G., M-J. Montpetit, "Address Resolution for IP datagrams over MPEG-2 networks", Internet Draft, draft-fair- ipdvb-ar-00.txt, Work in Progress, IP-DVB WG. [ID-MMUSIC-IMG] Y. Nomura, R. Walsh, J-P. Luoma, J. Ott, H. Schulzrinne, "Protocol Requirements for Internet Media Guides", Internet Draft, draft-ietf-mmusic-img-req-XX.txt, Work in Progress, MMUSIC WG. [ISO-DSMCC] ISO/IEC IS 13818-6 "Information technology -- Generic coding of moving pictures and associated audio information -- Part 6: Extensions for DSM-CC is a full software implementation", International Standards Organisation (ISO). [ISO-VID] ISO/IEC DIS 13818-2:1998 "Information technology -- Generic coding of moving pictures and associated audio information: Video", International Standards Organisation (ISO). [ISO-AUD] ISO/IEC 13818-3:1995 "Information technology -- Generic coding of moving pictures and associated audio information -- Part 3: Audio", International Standards Organisation (ISO). [Ken87] Kent C.A., and J. C. Mogul, ?Fragmentation Considered Harmful", Proc. ACM SIGCOMM, USA, CCR Vol.17, No.5, 1988, pp.390- 401. [RFC793] Postel, J., "Transmission Control Protocol", RFC791. [RFC1122] B. Braden, ed., "Requirements for Internet Hosts - Communication Layers", RFC 1122. Expires November 2004 [page 31] INTERNET DRAFT Architecture for IP transport over DVB July 2004 [RFC1144] Jacobson, V., "Compressing TCP/IP Headers for Low-Speed Serial Links", RFC1144. [RFC1191] Mogul, J., Deering, S., "Path MTU Discovery", RFC 1191. [RFC2507] Degermark, M., Nordgren, B., and Pink, S., "IP Header Compression", RFC2507. [RFC3077] Duros, E., W. Dabbous, H. Izumiyama, Y. Zhang, "A Link Layer Tunneling Mechanism for Unidirectional Links", RFC3077. [RFC3095] Bormann, C., et al, "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP ESP and uncompressed", RFC3095. http://www.atsc.org/standards/Code_Point_Registry.pdf 11. Authorsí Addresses Marie J. Montpetit MJMontpetit.com Email: marie@mjmontpetit.com Godred Fairhurst Department of Engineering University of Aberdeen Aberdeen, AB24 3UE UK Email: gorry@erg.abdn.ac.uk Web: http://www.erg.abdn.ac.uk/users/gorry Horst D. Clausen, Bernhard Collini-Nocker, Hilmar Linder Debartment of Scientific Computing University of Salzburg Jakob Haringer Str. 2 5020 Salzburg Austria Email: [clausen|bnocker|hlinder]@cosy.sbg.ac.at Web: http://www.network-research.org Expires November 2004 [page 32] INTERNET DRAFT Architecture for IP transport over DVB July 2004 12. IPR Notices The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. 13. Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTORs, THE ORGANIZATIONS THEY REPRESENT OR ARE SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. 14. IANA Considerations A set of protocols which meet these requirements, will require the IANA to assign various numbers. This document by itself, however, does not require any IANA involvement. Expires November 2004 [page 33] INTERNET DRAFT Architecture for IP transport over DVB July 2004 Appendix A: MPEG-2 Encapsulation Mechanisms To transmit packet data over an MPEG-2 transmission network requires that individual SNDUs (e.g. IPv4, IPv6 packets, or bridged Ethernet Frames) are encapsulated using a convergence protocol. The following encapsulations are currently standardised for MPEG-2 transmission networks: (i) Multi-Protocol Encapsulation (MPE). The Multi-Protocol Encapsulation, MPE, specification of DVB [ETSI-DAT] uses private Sections for the transport of IP packets and uses encapsulation that is similar to the IEEE LAN/MAN standards [LLC]. Data packets are encapsulated in datagram sections that are compliant with the DSMCC section format for private data. Some Receivers may exploit section- processing hardware to perform a first-level filter of the packets that arrive at the Receiver. The section header also includes fields, which may be used by a Receiver to filter datagrams assigned to the same TS Logical Channel. This feature allows several logical networks to be established without assigning PID values to each of the services. Section filtering is especially well suited for TV broadcast environments where remultiplexing comes into play. This encapsulation makes use of a MAC-level network point of attachment address. The address format conforms to the ISO/IEEE standards for LAN/MAN LLC]. The 48-bit MAC address field contains the MAC address of the destination; it is distributed over six 8-bit fields, labeled MAC_address_1 to MAC_address_6. The MAC_address_1 field contains the most significant byte of the MAC address, while MAC_address_6 contains the least significant byte. How many of these bytes are significant is optional and defined by the value of the broadcast descriptor table [SI-DAT] sent separately over another MPEG-2 TS within the TS multiplex. MPE is currently a widely deployed scheme. Due to investments in existing systems, usage is likely to continue in current and future networks. (ii) Data Piping. The Data Piping profile [ETSI-DAT] is a minimum overhead, simple and flexible profile that makes no assumptions concerning the format of the data being sent. In this profile, the Receiver is intended to provide PID filtering, packet reassembly according to [DVB-SIDAT-368], error detection and optional Conditional Access (link encryption). The specification allows the user data stream to be unstructured or organized into packets. The specific Expires November 2004 [page 34] INTERNET DRAFT Architecture for IP transport over DVB July 2004 structure is transparent to the Receiver. It may conform to any protocol, e.g., IP, Ethernet, NFS, FDDI, MPEG-2 PES, etc. (iii) Data Streaming. The data broadcast specification profile [ETSI-DAT] for PES tunnels (Data Streaming) supports unicast and multicast data services that require a stream-oriented delivery of data packets. This encapsulation maps an IP packet into a single PES Packet payload. Two different types of PES headers can are selected via the stream_id values [ISO-MPEG]. The private_stream_2 value permits the use of the short PES header with limited overhead, while the private_stream_1 value makes available the scrambling control and the timing and clock reference features of the PES layer. Expires November 2004 [page 35] INTERNET DRAFT Architecture for IP transport over DVB July 2004 Appendix B: Address Resolution Use Cases Consider the case where a hub server collects a table of AR information. The collected AR information then needs to be redistributed to clients using the forward multicast link. The number of Receivers may range from 1 to many thousands. (i) Example 1 Example protocol stack for Sender Side (2 interface) Consider a router with two logical interface (A,B) each to an IP network which could use either private or global IP addresses. If AR is performed independently for each interface, the L2 addresses used by subnetworks A,B may also overlap or be globally unique. A separate association protocol could provide MPEG-2 other L2 information (MPEG-2 TS Logical Channels / PID mappings, etc) to the IP systems in each of the connected IP networks. Both AR for L2 addresses and for association with TS logical channel attributes may be performed by IP-level protocols using link-local IP multicast. A good solution may also permit multiple servers. A simple association protocol may only support networks that do not perform remux renumbering of PIDs. When this needs to be supported, a L2 table method may be used. | +--------+--------+ | Port C | +-------------+--------+--------+-------------+ | Router | +-----------------+---------+-----------------+ | Port A | | Port B | +--------+--------+ +--------+--------+ | IP Interface 1 | | IP Interface 2 | | (subnet) | | (subnet) | +------+----------+ +------+----------+ | AR | +-------+ | AR | +-------+ |Server|.. | AR +--+ |Server|.. | AR +--+ +------+ | Cache | | +------+ | Cache | | | +-+-----+ | | +-+-----+ | | | Assoc | | | Assoc | | +--------+ | +--------+ +-------( )--------------+----------( )-----------+ | Encapsulator X | Encapsulator Y | +---------+--------------+-----------+------------+ | | +----->------+ +----<----+ | | +-------( )-( )--( )-----+ | PID PID PID | | TS-Mux | +---------+--------------+ | Forward Link | (Feed) Expires November 2004 [page 36] INTERNET DRAFT Architecture for IP transport over DVB July 2004 (ii) Example 2 Suppose we have system B and a system A. The L2 address B is (Y:q) (i.e. Combination of MAC address, PID, TS) and the corresponding one for A is (X:p). | Forward | +-------+ +-------+ | Link | +-------+ +-------+ --+AR +--+Encaps +--------->--------+ A +--+AR +- |server | | | | | | | |Client | +-------+ +-------+ | | +-------+ +-------+ +------+ | | +------+ |A:X:p | | | |p:X:A | +------+ | | +------+ | | +-------+ +-------+ | | +-------+ +-------+ -+AR +--+ B +---------<--------+Encaps +--+AR +- |Client | | Decaps| | | | | |server | +-------+ +-------+ | Return | +-------+ +-------+ +------+ | Link | +------+ |q:Y:B | | | |B:Y:q | +------+ | | +------+ IP addr B IP addr A For B to send to A, the encapsulation gateway at B needs to resolve the IP address of A to the l2 address of X and identify that this must be carried over (PID,TS) of p. A already knows its L2 address is X, this doesn't need to be communicated. It also knows or can determine it's layer 3 IP address. It can not determine the (pid,TS-ID) to use, so it must be told p. Once it knows p it can tune and set the MPEG-2 demux filter. The corresponding addresses for B are Y and q. How do A and B find out X and Y? 1) X can be preassigned to A (e.g. A L2 address assigned by a Receiver manufacturer), in which case, A has to tell the AR server at B informing it that it will be using X (register). The AR server at B could then inform other devices by sending an AR table that includes an entry that says A uses X (mesh). The encapsulator needs this information, and also other clients that need to send to A. 2) B can assign X to A. B informs A that it is using X. B could then inform others by sending an AR table that includes an entry saying A uses X (mesh) or that B uses Y as a proxy (star). 3) It is also possible that B does not know that A is using X. To find this out, it may query the network/a third party AR server (Y) looking for address A. A can then respond giving its resolved address (X), which B then uses. The way in which Y is found is to be determined (e.g. configured, or determined by a protocol mechanism). Expires November 2004 [page 37] INTERNET DRAFT Architecture for IP transport over DVB July 2004 (iii) Example 3 Assume a unicast (e.g. TCP) stream originates at a host, S, and is intended for an end host, R. The path between S and R includes an MPEG-2 link, with an encapsulator B and a Receiver A. The Receiver, A, acts as a router. The Encapsulator receives the IP packets from S and encapsulate them with an SNDU destination address field of X, this is performed by determining that A is not local to the subnetwork, but reached via router with the IP Address A corresponding to the L2 value of X. The packet is fragmented into TS-Packets and a PID assigned. +-------+ +------+ +->----|AR | |A:X | | +--+Server | +------+ | | +-------+ +----> | | | | | | | | | Forward +----> | | | +-------+ | | | +-------+ | +->-+Encaps +------------>---+---->-------+Decaps +----+->-- | >---+ | | Data | | | | | IP +-------+ | A sent over X | +-------+ ++------+ | data +------+ | | +------+ |AR | | |A:X | | & AR Adverts (mcast)| |X:A | <-+Client | | +------+ | A uses X | +------+ ++------+ | | B uses Y | | | Encaps receives | | Cached values | | AR Tables | | used for rx | | | | AR of packets | | Cached values | | own unicast addr| | used for tx | | & mcast addrs | | | | | | | | | | | Reverse | | | +-------+ | | +-------+ | -+--<----+Decaps +------------<----------------+Encaps +-<--+--< Decaps | | | | | | +-------+ | AR requests | +-------+ | who-is-C? | | | | & AR registration | IP addr A | I-am A I-use X | For A to forward packets to B, the encapsulation gateway at A. For A to forward packets to B, the encapsulation gateway at A needs to resolve the IP address.of B to the L2 address X. A should already be listening on the L2 address X, because it is either the media- resolved of its A's IP address. (For multicast, this could be L2 multicast IP address for a multicast group for which it has enabled a filter). Expires November 2004 [page 38]