Internet Engineering Task Force Gorry Fairhurst Internet Draft University of Aberdeen, U.K. Document: draft-fair-ipdvb-req-04.txt Horst D. Clausen Bernhard Collini-Nocker Hilmar Linder University of Salzburg, A Category: Informational December 2003 Requirements for transmission of IP datagrams over MPEG-2 networks Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. Abstract This document describes a framework 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 include the Digital Video Broadcast (DVB) and Advanced Television Systems Committee (ATSC) Standards for Digital Television. It 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 resolution, to associate IP packets with the properties of the Logical Channels provided by an MPEG-2 TS. Expires June 2004 [page 1] INTERNET DRAFT Requirements for IP transport over DVB December 2003 Table of Contents 1. Introduction 2. Conventions used in this document 3. Motivation 4. IP Transport Service. 5. Encapsulation Protocol Requirements 6. Address Resolution Functions 7. Multicast Support 8. Examples of Usage 9. Summary 10. Security Considerations 11. Acknowledgments 12. References >>> To be completed. <<< Expires June 2003 [page 2] INTERNET DRAFT Requirements for IP transport over DVB December 2003 Document History -00 This draft is intended as a study item for proposed future work by the IETF in this area. -01 This draft has been expanded with additional rationale for the simple encapsulation described in [ID-IPDVB-Enc]. -02a Comments received from Isabel Amonou, May 2002. Corrections to spelling. Addition of section filter. Addition of first draft of text on Ïaddressed areaÓ in arp. -02b GF Added some long-awaited figures -02c GF Added text on section processing in MPE -03a GF Updated text June 2003, comments from Bernhard C-N. Abstract shortened Description generalised to all MPEG-2 TS networks;-) Improved discussion of PES / PUSI Subtle title change -03b GF updated to reflect ULE [ID-IPDVB-ULE]. IPv6 terminology improved. -03c GF formatting for ID. >>> Comments relating to this document will be gratefully received by the authors and the ip-dvb mailing list at: ip-dvb@erg.abdn.ac.uk Further input is requested to refine these requirements and to identify details of the other proposed protocols within this framework. <<< -04a NiTs following IETF-57 BOF -04b Updated section on encapsulation. New section numbering New summary section -04d Aligned with charter and reduced discussion on MPE/ULE/etc -04e rewritten conclusion. -04e feedback from various people on DVB address resolution process -04f new address resolution section. Expires June 2003 [page 3] INTERNET DRAFT Requirements for IP transport over DVB December 2003 1. Introduction This document identifies requirements for a framework for transport of IP Datagrams over ISO MPEG-2 Transport Streams [MPEG2]. The framework is also 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],Cable Transmission [ETSI-DVBC; ATSC-PSIP-TC]). +---------+-+-+-+-+------+--------+---+--+--+ | |T|V|A|O| O | | O |S |O | | |e|i|u|t| t | | t |I |t | |Other |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 of types of data, MPEG- 2 components may, and are, also used to build IP-only networks. In this case, standard system components offer advantages of mass market and improved interoperability. Such networks often do not implement all parts of a DVB / ATSC system, and may for instance support minimal, or no, signalling of Service Information (SI) tables. 1.1 TS Logical Channels The service provided by an MPEG-2 transport multiplex offers a number of parallel 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 channels is limited to 8192, 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- Expires June 2003 [page 4] INTERNET DRAFT Requirements for IP transport over DVB December 2003 VID], IP packets [ISO-DSMCC; ETSI-DAT; ATSC-DAT], or other data [ISO-DSMCC; ETSI-DAT; ATSC-DAT]. The value 8191 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 Mux. In most cases the data sent over the TS Logical Channels will differ for different multiplexes. The above figure shows 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 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). Similarities in the way PIDs are used may be observed with the operation of virtual channels in ATM, however, unlike ATM, a PID defines a unidirectional broadcast channel and not a point-to-point link; there is, as yet, no specified interface for 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. Expires June 2003 [page 5] INTERNET DRAFT Requirements for IP transport over DVB December 2003 1.2 MPEG-2 Transmission Networks Packet data for transmission over the MPEG-2 transport multiplex is passed to an encapsulator. This receives Sub-Network Data Units, SNDUs (e.g., Ethernet frames or IP packets) and formats each SNDU into a series of TS Packets adding an encapsulation header and trailer (see section 5). There are many possible topologies for the MPEG-2 Transmission Network. In a simple example, one or more TS are processed by a MPEG-2 multiplexor resulting in a TS Multiplex. That is forwarded over a physical bearer towards one or more Receivers. See 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 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. One example is a satellite that provides on-board processing of the TS packets, multiplexing the TS Logical Channels received from one or Expires June 2003 [page 6] INTERNET DRAFT Requirements for IP transport over DVB December 2003 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. In all cases, the final result is a "TS Multiplex" which is transmited over the physical bearer towards the Receiver. To receive IP packets sent over a MPEG-2 transport multiplex, a Receiver needs to identify the specific TS Multiplex (physical link) and also the TS Logical Channel (i.e. 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, may utilise receiver hardware to filter other unwanted TS Logical Channels. 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, multiple PIDs must be allowed. Most Receivers currently have a limit on 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 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. 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. It includes a set of optional header components and requires decoding of the control headers. This processing is therefore not optimal for IP, since it incurs significant receiver processing overhead and some extra link overhead [CLC99]. Expires June 2003 [page 7] INTERNET DRAFT Requirements for IP transport over DVB December 2003 +-----------------------------------------+ |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). 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 of this include a TV distribution network, or ISP offering an Internet service to her customers. MPEG-2 transmission networks are also used for private networks. These typically involve a smaller number of terminals and do not require the same level of centralised control as a managed network. Examples of this include companies wishing to link DVB- capable routers to form links within an Internet subnetwork. 1.3 Proposed Framework The framework proposed in this document describes a set of protocols to support transmission of IP packets over the MPEG-2 TS. A key characteristic of these networks is that they may provide link-level broadcast capability, and many applications require support for very large numbers of subnetwork nodes. Some or 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 are to reduce complexity when using the system, while improving performance, increasing flexibility, and providing opportunities for better integration with IP Internet services. Since most MPEG-2 transmission networks are bandwidth-limited, the framework needs to be simple, robust, extensible (i.e. provide support for a range of link services), and have good link efficiency (i.e. small overhead). Supporting protocols need to provide resolution of IP flows to the TS Logical Channels provided by the MPEG-2 TS. The Logical Channels provide multiplexing, addressing, and error reporting. The Logical Channel is also the basis of providing Quality of Service (QoS). Mapping functions are required to relate this to IP-level QoS. A key goal will be to provide functions in a dynamic way, permitting integration with other IP protocols. Collectively, these form MPEG-2 TS address resolution. Expires June 2003 [page 8] INTERNET DRAFT Requirements for IP transport over DVB December 2003 2. Conventions used in this document ACK: A cumulative TCP acknowledgment. In this document, this term refers to a TCP segment (packet) that carries a cumulative acknowledgement (ACK), but no data. 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 Management 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: Programme Elementary Stream. A format of MPEG-2 TS packet payload usually used for video or audio information in MPEG-2 [ISO- MPEG]. Expires June 2003 [page 9] INTERNET DRAFT Requirements for IP transport over DVB December 2003 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 indicates a null packet that must be discarded by a Receiver. REVERSE DIRECTION: The direction in which feedback control messages generally flow (e.g. acknowledgments of a forward TCP transfer flow). Data transfer could also happen in this direction (and it is termed "reverse transfer"). 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 June 2003 [page 10] INTERNET DRAFT Requirements for IP transport over DVB December 2003 3. Motivation The network layer protocols to be supported by this framework are: (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 The framework describes: (i) The framework will offer guidance on which MPEG-2 features are pre-requisites for this service, and any optional fields that impact performance/correct operation. (ii) Standards will be defined to provide an efficient and flexible encapsulation scheme that may be easily implemented in an Encapsulator or Receiver. The framework must support IPv4 and IPv6 network protocols, and should support alternate payloads Ò such as bridged, compressed packets, and extension options. The payload encapsulation requires a type field for the SNDU to indicate the type of packet. (iii) Standards will be defined to associate a particular IP address with a Network Point of Attachment (NPA) (e.g. a MAC Address). This process resembles the IPv4 Address Resolution Protocol, ARP, or IPv6 Neighbour Discovery, ND, protocol [AR- DRAFT]. The standard must be compatible with IPv6 autoconfiguration. (iv) Standards will be defined 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. This could be implemented via descriptors sent in the SI tables (e.g. using the existing MPEG-2 control plane), via one or more new SI tables, or in-band by a protocol using a data channel (e.g. utilising UDP) [AR-DRAFT]. (v) Existing standards do not address many areas, which are desirable for Internet Service provision, (e.g., mapping of QoS functions, such as IP QoS/DSCP and RSVP, to under-lying MPEG-2 TS QoS, multi-homing and mobility). The need for and scope of this is to be determined. Expires June 2003 [page 11] INTERNET DRAFT Requirements for IP transport over DVB December 2003 (vi) Security. 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. There may be a need for standardised SNMP MIBs and error reporting procedures. The need for and scope of this is to be determined. The specified framework and techniques to be developed should be suited to a range of systems employing the MPEG-2 TS, and may also suit other (sub)networks offering similar transfer capabilities. Sections 4 and 5 describe encapsulation issues. Sections 6 and 7 desctribe address resolution issues for unicast and multicast. Section 8 provides some examples of use. Expires June 2003 [page 12] INTERNET DRAFT Requirements for IP transport over DVB December 2003 4. IP Transport Service. The section identifies key needs 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. 4.1 Options for Encapsulation 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 used scheme. Due to investments in existing equipment, usage is likely to continue in some applications in current and future networks. Expires June 2003 [page 13] INTERNET DRAFT Requirements for IP transport over DVB December 2003 (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 structure is transparent to the Receiver. It may conform to any protocol, e.g., IP, Ethernet, NFS, FDDI, MPEG-2 PES, etc. The ULE specification [IPDVB-ULE] is an example of protocol that uses this profile. (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 Data Streaming is intended to handle a single stream of data at a high data rate using standard demultiplexing ICs (e.g. developed for STBs) that have been designed for video streams. Transporting data packets at the PES level offers the benefits of PES layer functions integrated into the chip sets, e.g. handling of program specific information (tables), scrambling and synchronization with other TS. The standard PES Packet as defined in table 2-18 of [ISO- MPEG] can also be used as a container for data packets. The two values for the stream_id are "private_stream_1" and "private_stream_2". The private_stream_2 permits the use of the short PES header with limited overhead. This makes it attractive for publicly accessible multicast distribution services. The private_stream_1 makes available the scrambling control and the timing and clock reference features of the PES layer. The "PES_data_packet_header_length" will be used in this context to insert stuffing bytes. This is an important aspect since the payload can be aligned to 32-bit word boundaries. When the "data_identifier" field is used in conjunction with the first 4 bits of the "sub_stream_id" field it forms a 12 bit field. This carries a descriptor of the next level protocol. The list of protocol codes will be managed by [EUTELSAT], and the values of the part stored into the "data_identifier" field will be in the range 0x80-0xFF (assigned by DVB as user defined). The remaining 4 bits of the "sub_stream_id" field are used for storing the current version of the encapsulation format. Expires June 2003 [page 14] INTERNET DRAFT Requirements for IP transport over DVB December 2003 5. Encapsulation Protocol Requirements The aim of a encapsulation protocol is to transport a SNDU over the MPEG-2 TS service and provide 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 (e.g., length of SNDU, Receiver address, multiplexing information, payload type, sequence numbers). 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 3: 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]. This section describes existing standard encapsulations used with MPEG-2 transmission networks. The section also reviews the requirements for performing an encapsulation optimised for IP. The existing proposals and standards for use with MPEG-2 (described in the previous section) all introduce overhead that consumes link capacity and receiver processing power. The then current state of chip technology played an important role in defining these encapsulations and it may be argued that there was little previous implementation experience considered. Arguably, too much consideration was paid to existing digital video/audio technology and too little to Internet protocol aspects. 5.1 Convergence Functions Carrying IP packets over a TS Logical Channel involves several convergence protocol functions: 5.1.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 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, Expires June 2003 [page 15] INTERNET DRAFT Requirements for IP transport over DVB December 2003 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. 5.1.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 in the case of the IP service, 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 of the current Internet. This would seem a suitable maximum size for an MPEG-2 transmission network. Expires June 2003 [page 16] INTERNET DRAFT Requirements for IP transport over DVB December 2003 5.1.3 Next Level Protocol Type There is a need to identify the type of payload being transported (e.g., to differentiate IPv4, IPv6, arp messages, and compressed packet headers). 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 cased a SNAP (subnetwork access protocol) header is also required for IP packets). The MPE encapsulation header does not directly include a type field (e.g., to differentiate IPv4 and IPv6 packets). If such support is required, an option must be specified in the MPE encapsulation header to indicate the addition of an LLC header, and this must be followed by a SNAP header. This introduces additional overhead. 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 framework, 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 wire-less (e.g., satellite, terrestrial TV, line of sight microwave) 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. It is therefore recommended that the selected type field contains sufficient code points for support of this technique. It is desirable therefore to include a Next Level Protocol Type field in the encapsulation header. Such a field should specify values for at least IPv4, IPv6, and ROHC (e.g. [RFC3095]). It is also desirable to allow for other values (e.g., MAC-level bridging). 5.1.4 L2 Subnet Addressing In the MPEG-2 system 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 Expires June 2003 [page 17] INTERNET DRAFT Requirements for IP transport over DVB December 2003 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. 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 Recievers 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 are being 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). MPE defines a NPA destination address in the convergence header. No NPA source address is present. There are cases where an IP service has no need for NPA addresses, in this case these add unnecessary processing and transmission overhead, and should not be included in the encapsulation header. 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, and there may therefore be a good case for allowing the use of a reduced (smaller than an IEEE MAC address) NPA. There are many cases where a NPA is Expires June 2003 [page 18] INTERNET DRAFT Requirements for IP transport over DVB December 2003 not required, and network layer filtering may be used. A new encapsulation protocol should therefore support an optional NPA and may allow for future specification of the size of NPA. 5.1.5 Integrity Check For the IP service, the probability of undetected packet error should be small (or negligible) [LINK-ID]. 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). 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. 5.1.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. 5.1.7 Extensibility The evolution of the Internet service may in future require additional functions (examples include the introduction of new protocols at the network level, support of 802.1Q tags). A flexible protocol should therefore provide a way to introduce new features when required, without having to provide additional out-of-band configuration. 5.2 Header Overhead The fixed 184 byte payload size of a TS Packet also introduces a bandwidth overhead due to the "padding" (or stuffing) commonly employed when placing data in the TS Packets. Expires June 2003 [page 19] INTERNET DRAFT Requirements for IP transport over DVB December 2003 One common application is the use of a DVB-S multiplex to provide the forward link for satellite delivery of IP data. In many current applications the forward data traffic over the satellite link is mostly data with a packet size 1500 bytes. This overhead is approximately 2-11%. Short IP packets, (e.g., carrying control information (e.g. ICMP, IGMP, and TCP ACK packets), can lead to a much more overhead (up to approximately 500% for IPv4), if they are carried individually in a TS Packet. IP header compression (e.g. [RFC3095]), would offer no benefit in this case. The "Payload_Unit_Start_Indicator" (PUSI) may be used to alleviate this, by allowing the MPEG-2 payload pointer to indicate the presence of a second payload unit within a single TS Packet. The second payload unit may directly follow the end of the first, in a procedure sometimes called "Packing". Note, an under-run of data at the IP Encapsulator may cause a TS Packet to be sent with less than 184 bytes of payload. Such a TS Packet will need to be "padded". 5.3 TS Multiplexing MPEG-2 multiplexers may forward TS Packets using a stream-based design. They do not usually flush their buffers, but store TS Packets until an input buffer fills to a threshold, (assuming that the data arrives in a more or less continuous stream). This assumption is not necessarily valid for IP packets, which tend to arrive in intermittent traffic bursts. The forwarding behaviour of the multiplex can lead to significant link transit delays for the last TS Packet(s) in a traffic burst. Various solutions to this problem are possible including: (i) Flushing an IP packet stream with null TS Packets after each traffic burst. (ii) Redesign of the TS multiplexer buffer management to control the maximum queuing latency for IP traffic flows. (iii) Addition of a new push identifier that lets the TS multiplexer identify the end of a traffic burst. An Encapsulator could specify a maximum holding time (configured based on well-known requirements, such as the TCP ACK_Delay interval, but could also be based on QoS metric derived for the IP traffic being carried). If required, the IP-DVB framework must identify how this is to operate and specify appropriate values for parameters. 5.4 Encapsulation Efficiency In this section the following ranking is used to evaluate the performance of different encapsulation methods: Efficiency = Sum of transferred bytes / Payload size Expires June 2003 [page 20] INTERNET DRAFT Requirements for IP transport over DVB December 2003 The overhead of 4 bytes for each 188 byte TS Packet introduced by the MPEG-2 TS results in a maximum of 0.98. In MPE, this overhead is increased by the DSM-CC private section mechanism that generates at least 17 bytes per IPv4 packet (16 bytes for the datagram section and 1 byte for the Payload Pointer field). This excludes the LLC/SNAP field that is optional and not required in all cases. Implementations supporting Packing may approach the maximum performance for large SNDUs. The volume of data transmitted for additional tables and descriptors should be omitted because PSI information and system tables are immanent to the MPEG2/DVB transmission scheme and have nothing to do with actual data transmission. Expires June 2003 [page 21] INTERNET DRAFT Requirements for IP transport over DVB December 2003 6. Address Resolution Functions Address Resolution (AR) provides a mechanism that associates L2 information (including (NPA) address(es)) 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 (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 control (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 more than the MAC address. This includes identifying other parameters required for L2 transmission, such as channel IDs (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 MPEG-2 transmission networks. 6.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 (Program IDentifier) 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. 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 June 2003 [page 22] INTERNET DRAFT Requirements for IP transport over DVB December 2003 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. Expires June 2003 [page 23] INTERNET DRAFT Requirements for IP transport over DVB December 2003 6.1.1 Example of AR in a Star Network The example below shows a star topology MPEG-2 TS transmission network, 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 brodcast MPEG-2TS \ ----------------X /-----\ / / \ | Terminal| /----------+ A | / \ / /-----\ / \-----/ / \ / | Hub |/ | +\ /-----\ \ / \ / \ \-----/ \ | Terminal| \-----------+ B | \ / \-----/ 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. 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. A 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. Expires June 2003 [page 24] INTERNET DRAFT Requirements for IP transport over DVB December 2003 6.2 The AR Process Several features are desirable for AR over broadcast-style networks: (i) A table based approach to promote AR scaling. This requires a 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) Appropriate security associations to authenticate the parties. 6.3 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 implantations of this are known) (iii) An address resolution protocol transported over IP (as in ND) There are three distinct scenarios 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. 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. 6.3.1 Table-based AR over MPEG-2 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 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 Expires June 2003 [page 25] INTERNET DRAFT Requirements for IP transport over DVB December 2003 delivering and co-ordinating the various TS Logical Channels associated with a multimedia TV programme. One possible approach 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. This process could be: (i) A 2-stage process, specifically decoupling PID using a Transport Stream ID (TS-ID). This allows the transmission network to remultiplex TS Logical Channels (resulting in a change of the PID value associated with a TS Logical Channel). This is suited to Scenario A.single stage where a target IP address resolves directly providing full L2 information. (ii) A 2-stage process, specifically the Receiver uses AR information to establish the TS Logical Channel and a separate process is used (when required) to resolve Receiver L2 addresses. (iii) A one-stage process in which the tuning parameters and PID is already known, or are resolved in the same process as used to determine the NPA/MAC address. The DVB INT and the A/92 Specification from ATSC [ATSC-A92] are examples of (i). The DVB INT can associate an IP address with: network_id, original_network_id, transport_stream_id, service_id and component_tag. - Network_id identifies the DVB network. - Original_network_id and transport_stream_id together identify the transport stream (globally, not only within the network. i.e. the network_id is not actually needed, but it's there anyway). - service_id identifies the PMT sub-table within the transport stream. - component_tag identifies the component within the PMT sub-table. PMT announces PID for each component. N.B. When a TS is re-mux'ed the remultiplexor doesn't update the INT, but does modify the PMT for each of the PIDs it renumbers. 6.3.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 Expires June 2003 [page 26] INTERNET DRAFT Requirements for IP transport over DVB December 2003 and therefore do not need to provide interoperability with TV equipment (e.g. links used solely for connecting IP (sub)networks). The AR function could be centralised in one or more (replicated) databases (as in MARS) so a Receiver can do the address mapping with AR information from a known place. There are both drawbacks and advantages in this approach. To find an address, a Receiver sends a query to a server/servers, who respond (proxy) for other known Receivers. In the simple case, the server is pre-configured with the bindings of all clients (e.g. tables created from a DHCP server when it allocates IP addresses). A variant of the above is when each Receiver sends an unsolicited neighbor advertisement registering its L2 binding to the server. 6.3.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. 6.4 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; 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. Expires June 2003 [page 27] INTERNET DRAFT Requirements for IP transport over DVB December 2003 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 packet may lead to unexpected protocol behaviour. This also provides a security vulnerability since arbitrary packets may be passed to the IP layer. 6.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 it receives. There are similarities here with SEND [REF-to-SEND- WG]. 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. 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. Expires June 2003 [page 28] INTERNET DRAFT Requirements for IP transport over DVB December 2003 7. 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. These issues 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 signalling information to allow a Receiver to locate an IP multicast flow within an MPEG-2 TS Multiplex. (iv) Determining group membership (e.g. utilising IGMP/MLD). (v) Error Reporting. 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. 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. Expires June 2003 [page 29] INTERNET DRAFT Requirements for IP transport over DVB December 2003 7.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 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. \ | +---+----+ +--------+ | Tuner |---+TS Tabl | . . . . +---+----+ +--------+ . | . +--------+ +--------+ . | deMux |---+PID Tabl|........ +---+----+ +--------+ : | : +--------+ +--------+ +--------+ |MPE/ULE |---+AR Cache|---+ MFIB | +---+----+ +--------+ +--------+ | | | +---+----+ +---+----+ +---+----+ | IP | | AR | |IGMP/MLD| +---+----+ +---+----+ +---+----+ | | | *------------+------------+ | Expires June 2003 [page 30] INTERNET DRAFT Requirements for IP transport over DVB December 2003 8. Examples of Usage 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. 8.1 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 June 2003 [page 31] INTERNET DRAFT Requirements for IP transport over DVB December 2003 8.2 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 June 2003 [page 32] INTERNET DRAFT Requirements for IP transport over DVB December 2003 8.3 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 June 2003 [page 33] INTERNET DRAFT Requirements for IP transport over DVB December 2003 9. Summary This document proposes a framework for defining a set of protocols to perform efficient and flexible support for IP network services over networks built upon the MPEG-2 Transport Stream (TS). An informational document is recommended to document the existing approaches, focussing on IP networking, the mechanisms that are used and their applicability to supporting IP unicast and multicast services. This document is the first stage of this process. Import areas include the interface between the IP network at the Sender and Receiver and any protocols required. Scenarios and use-cases need to be proposed and studied, specifically this should include detailing how IP-only MPEG-2 networks can be used as a link technology in the general Internet. The encapsulation to transfer IPv4 and IPv6 packets is described, outlining current encapsulation methods, together with guidelines on the requirements for developing a new encapsulation. All other protocols in the framework will support IP packet transmission using both the Multiprotocol Encapsulation (MPE), which is currently widely implemented, and also any new optimised encapsulation. The framework also includes MPEG-2 Address Resolution (AR) procedures to allow dynamic configuration of the sender and Receiver using an MPEG-2 transmission link/network. These will support IPv4 and IPv6 services in both the unicast and multicast modes. This proposed work is within scope of the ip-dvb WG and protocol design could be done in this forum with the support and expertise of other protocol design work. For this to be successful requires inputs from the wider community and good liason with other organisations. Comments are invited from implementers, operators, and others interested people. 10. Security Considerations The normal security issues relating to the use of wire-less links for transport Internet traffic should be considered. 11. Acknowledgments The authors wish to thank Isabel Amonou , Torsten Jaekel, Pierre Loyer, Marie-Jose Montpetit, Luoma Juha-Pekkaand , and Rod Walsh, for their detailed inputs. We also wish to acknowledge the input provided by the members of the ip-dvb (ip-dvb@erg.abdn.ac.uk) mailing list. Expires June 2003 [page 34] INTERNET DRAFT Requirements for IP transport over DVB December 2003 12. References [ATSC] A/53, "ATSC Digital Television Standard", Advanced Television Systems Committee (ATSC), Doc. A/53, 1995. [ATSC-DAT] A/90, "ATSC Data Broadcast Standard", Advanced Television Systems Committee (ATSC), Doc. A/090, 200 [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/54, "Guide to the use of the ATSC Digital Television Standard", Advanced Television Systems Committee (ATSC), Doc. A/54, 1995. [ATSC-PSIP-TC] A/65A, "Program and System Information Protocol for Terrestrial Broadcast and Cable", Advanced Television Systems Committee (ATSC), Doc. A/65A, 23 Dec 1997, Rev. A , 2000. [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). [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-fair-ipdvb-ule-xx.txt, Work in Progress, IP-DVB WG. Expires June 2003 [page 35] INTERNET DRAFT Requirements for IP transport over DVB December 2003 [IP-DVB-AR] Fairhurst, G., M-J. Montpetit, "Address Resolution for IP datagrams over MPEG-2 networks", Internet Draft, draft-fair- ipdvb-ar-xx.txt, Work in Progress, IP-DVB 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-MPEG] ISO/IEC DIS 13818-1 "Information technology -- Generic coding of moving pictures and associated audio information: Systems", International Standards Organisation (ISO). [ISO-VID] ISO/IEC DIS 13818-2 "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. [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. 13.Authors' Addresses Godred Fairhurst Department of Engineering University of Aberdeen Aberdeen, AB24 3UE Expires June 2003 [page 36] INTERNET DRAFT Requirements for IP transport over DVB December 2003 UK Email: gorry@erg.abdn.ac.uk Web: http://www.erg.abdn.ac.uk/users/gorry Horst D. Clausen, Bernhard Collini-Nocker, Hilmar Linder Institute of Computer Sciences University of Salzburg Jakob Haringer Str. 2 5020 Salzburg Austria Email: [clausen|bnocker|hlinder]@cosy.sbg.ac.at Web: http://www.cosy.sbg.ac.at/cs/ Full Copyright Statement "Copyright (C) The Internet Society (date). 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 implementation 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 revoked by the Internet Society or its successors or assigns. 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 June 2003 [page 37] INTERNET DRAFT Requirements for IP transport over DVB December 2003 [AUTHORS NOTES:XXX THIS SECTION MUST BE REMOVED BY THE RFC Ed] Evaluation of IP Service over MPEG-2 networks A set of methodologies may be defined to assist in the evaluation of the protocols defined by this framework. These could define terminology, evaluation criteria (utilisation, throughput, loss rate, undetected error rate, etc), and may specify tests to indicate the impact of such parameters as IP Packet size, IP version, multicast/unicast, and rate of transmission. A set of test cases could also be defined to allow performance to be quantitatively measured and compared. Rationale for ULE Packing Measurements of IPv4 traffic have shown that the overwhelming majority of the datagrams have lengths of 1500 or 576 bytes for data and 40 or 48 bytes for control traffic; for example, these values represent almost 96% of the typical world-wide-web traffic. The most frequent situations for the Encapsulator are: - a short control packet using only a fraction of the TS Packet payload of 184 bytes; - a long data packet using a number of TS Packets with the last containing only a remainder. Both of these lead to a fairly high overhead in the last TS Packet. Since radio/satellite bandwidth is an expensive resource, as opposed to bandwidth in wired LANs, a more efficient method is specified here. One possibility is header compression, however this is outside the scope of this document. Additional Reading Matter ETSI EN 301 192 [V1.3.1 (2003-05) RFC 2461 - Neighbor Discovery RFC 2462 - IPv6 Address Autoconfiguration RFC 826 - An Ethernet Address Resolution Protocol, STD 37 MARS: RFC2121; RFC2149;RFC2269;RFC2443;RFC2602 IETF ND Working Group IETF SEND Working Group [XXX END of AUTHOR NOTE XXX] Expires June 2003 [page 38] INTERNET DRAFT Requirements for IP transport over DVB December 2003 Appendix A The following principles are suggested for this work: (i) Ubiquity. The framework operates below the IP network layer. It must not require modifications to existing implementations of IP (IPv4 or IPv6), UDP, TCP. (ii) Minimal overhead. The framework should minimize protocol overhead, in terms of the number of additional bytes to be sent in addition to the IP packet and processing overhead in terms of parsing effort of variable length headers or options fields (see iv). The number of header bytes can significantly impact performance for bandwidth-limited systems (such as satellite, terrestrial radio/TV links). (iii) Minimal set of required options. Reducing the number and type of optional parameters reduces the receiver processing overhead. Importantly, it also simplifies Receiver implementation, allowing easier implementation and promoting better interoperability between vendor implementations. The header format currently adopted by MPE is known to be not optimal for IP, incurring significant receiver processing overhead and extra link overhead [CLC99]. (iv) Maximum Throughput. The framework should offer minimal transmit/receive processing load. In some cases, the use of header compression may represent a useful trade-off in increased processing overhead, but reduced packet header size. In some cases (e.g., to meet the QoS delay requirement of a flow) efficiency at the MPEG-2 TS level may have to be sacrificed for reduced transit delay. (v) Flexibility. The framework should provide sufficient flexibility to allow future inclusion of other mechanisms for specific applications (e.g., synchronisation with other MPEG- 2 TS Logical Channels). There is also need for the framework to operate over the range of MPEG-2 multiplexes in the forward direction, and the diverse range of return channel systems in the reverse direction. (vi) Compatibility. If new protocols are defined by the framework, it is desirable that they allow co-existence with existing schemes, such as MPE, to allow continued use of the broad- base of existing equipment. (viii) Scalability. The framework must be efficient when used in both large and small networks. The size of a network using MPEG-2 transport may range from a pair of nodes, to one including millions of Receivers. Expires June 2003 [page 39]