Internet Engineering Task Force Gorry Fairhurst Internet Draft University of Aberdeen, U.K. Document: draft-fair-ipdvb-req-03.txt Horst D. Clausen Bernhard Collini-Nocker Hilmar Linder University of Salzburg, A Category: Informational June 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 contains requirements for a framework for 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), specified by standards published by the European Telecommunications Standards Institute (ETSI) and the ATSC Digital Television Standard specified by the Advanced Television Systems Committee (ATSC). It identifies the need for the definition of a set of network protocols to standardise the interface between the MPEG-2 Transport Stream and an IP subnetwork. It also suggests an optimised encapsulation method for IP datagrams. The requirements for these functions are described, and a framework proposed for their implementation. Expires December 2003 [page 1] INTERNET DRAFT Requirements for IP transport over DVB June 2003 Table of Contents >>> To be completed. <<< 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. <<< Expires September 2002 [page 2] INTERNET DRAFT Requirements for IP transport over DVB May 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 | +-------+-------+-------+-------------------+ | DVB-S | DVB-C | DVB-T | 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- VID], IP packets [ISO-DSMCC;ETSI-DAT;ATSC-DAT], or other data [ISO- Expires September 2002 [page 3] INTERNET DRAFT Requirements for IP transport over DVB June 2003 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. Logical Channels are independently numbered on each MPEG-2 TS Mux. In most cases the data sent over the 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 MPEG-TS Logical Channel. Expires September 2002 [page 4] INTERNET DRAFT Requirements for IP transport over DVB June 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). This forms a TS. 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 Expires September 2002 [page 5] INTERNET DRAFT Requirements for IP transport over DVB June 2003 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). 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 the receiver must therefore filter (accept) IP packets sent with a number of PID values, and must independently reassemble each SNDU. A system that simultaneously receives from several TS Logical Channels, may utilise receiver hardware to filter 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 UP, since it incurs significant receiver processing overhead and some extra link overhead [CLC99]. Expires September 2002 [page 6] INTERNET DRAFT Requirements for IP transport over DVB June 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 designed to allow IP packets to be sent over an MPEG-2 TS Logical Channel. Since most MPEG-2 transmission networks are bandwidth- limited, this needs to be simple, robust, and have good link efficiency (i.e. small overhead) when transporting variable sized IP packets. The document also identifies the need for supporting protocols (e.g. to support operation and configuration of the link, provide resolution of the MPEG-2 TS Logical Channel, error reporting, etc). The framework may also be applicable to other subnetworks utilizing the MPEG-2 TS, and also similar links (e.g. other MPEG-2 transmission networks, regenerative satellite links [ETSI-BSM]). Expires September 2002 [page 7] INTERNET DRAFT Requirements for IP transport over DVB June 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 September 2002 [page 8] INTERNET DRAFT Requirements for IP transport over DVB June 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 equipoment (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 September 2002 [page 9] INTERNET DRAFT Requirements for IP transport over DVB June 2003 3. Motivation This section describes existing solutions and the need for a new framework. This framework may be used over a link in the forward and/or the reverse direction. The protocols to be supported 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]) Three issues are addressed by this framework: (i) Providing an efficient encapsulation scheme that may be easily implemented in an encapsulator or receiver. (ii) Existing standards do not define a standard IP mechanism to associate a particular IP address with a TS channel (PID, TS Multiplex). Bindings are required for both unicast transmission, and multicast reception. In this document, these are referred to as IP address resolution issues. (iii) Existing standards do not address many areas, which are desirable for Internet Service provision, (e.g. network management, the communication required to support Internet QoS, support for auto-configuration, multi-homing and mobility). 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). This is important 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 Expires September 2002 [page 10] INTERNET DRAFT Requirements for IP transport over DVB June 2003 header format currently adopted by MPE 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 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. (vii) 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. The specified framework and techniques to be developed may also be suited to non-DVB systems employing the MPEG-2 TS, or other (sub)networks offering similar transfer capabilities. Expires September 2002 [page 11] INTERNET DRAFT Requirements for IP transport over DVB June 2003 4. Framework for the IP Service. This section describes the requirements for transporting IPv4 and IPv6 over MPEG-2 transmission networks. The section identifies key needs and provides examples of mechanisms that may be used to implement these. (i) The framework should offer guidance on which MPEG-2 features are pre-requisites for this service, and any optional fields that impact performance/correct operation. (ii) The framework must be robust to software failures and link loss. (iii) TS Logical Channel Resolution. There is a need to signal the PID and TS Multiplex that is associated with each IP flow to the network layer at the sender and receiver (address resolution). To make such schemes robust to loss and state changes within the MPEG-2 transmission network, a soft-state approach may prove desirable. This could, for example, be implemented via descriptors sent in the SI tables (using the MPEG-2 control plane), via one or more new SI tables, or in- band by a protocol using a data channel (e.g. similar to the IPv4 Address Resolution Protocol, ARP, or IPv6 Neighbour Discovery (ND) protocol). (iv) IPv4 and IPv6. The framework must support IPv4 and IPv6 network protocols. The payload encapsulation requires a type field for the SNDU to indicate the type of packet. (v) Compressed Headers. The framework must address the need for the support of header compression schemes. This requires the encapsulation to have a type field for each SNDU. (vi) Multicast. The framework must support IP multicast transmission of IPv4 and IPv6 packets. IPv4 network broadcast must also be supported. (vii) Diffserv and QoS. The mapping of QoS functions should be addressed. This includes how such fields as IP QoS/DSCP and RSVP should be mapped to the under-lying MPEG-2 TS. (viii) 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. Expires September 2002 [page 12] INTERNET DRAFT Requirements for IP transport over DVB June 2003 (ix) 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. 5. Motivation for a Lightwight Protocol 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. One advantage of this is that 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 the most widely used scheme. Due to investments in existing equipment, usage is likely to continue in some applications in current and future networks. (ii) Data Piping. The DVB 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 Expires September 2002 [page 13] INTERNET DRAFT Requirements for IP transport over DVB June 2003 profile, the MPEG-2 receiver is intended to provide PID filtering, packet reassembly according to [DVB-SIDAT-368], error detection and optionally CA support. 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. (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 handling video streams. Transporting data packets using 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. Some or all of these proposals have been implemented and are used in current systems. Expires September 2002 [page 14] INTERNET DRAFT Requirements for IP transport over DVB June 2003 6. Convergence Protocol Requirements A convergence protocol typically adds header fields that are placed before the SNDU, and carry protocol control information (e.g., the length of the SNDU, addresses, multiplexing information, payload type identification, sequence numbers). The SNDU is typically followed by a trailer, which carries an Integrity Check (e.g., Cyclic Redundancy Check, CRC). Some protocols add additional control information and/or padding to 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, and MPEG-2 MPE. 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 section 5) all introduce considerable overhead. This 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. 6.1 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. 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. To alleviate this problem, some implementers have made use of the Payload_Unit_Start_Indicator (PUSI) to indicate the start of a new SNDU within a TS Packet. The PUSI value may be used to indicate the presence of a second payload unit within a single TS Packet. This Expires September 2002 [page 15] INTERNET DRAFT Requirements for IP transport over DVB June 2003 allows a second payload unit to 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 for which would have less than 184 bytes of payload. Such a Packet will need to be padded to the standard payload size of 188 bytes. 6.2 TS Multiplexing Most current MPEG-2 multiplexers are 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 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. This also raises a configuration option, in the specification of the maximum holding time. This could be configured based on well-known requirements (such as a function of the ACK_Delay interval in TCP), but could also be based on QoS metric derived for the IP traffic being carried. The IP-DVB framework must identify how this is to operate and specify appropriate values for parameters. 6.3 Convergence Functions Carrying IP packets over a TS involves several convergence protocol functions, in particular (i) delimiting the payload unit i.e. the SNDU, (ii) identifying the size of payload, (iii) conveying control and signalling information between sender and receiver process, and (iv) naming and addressing the recipient. (i) Payload_Unit Delimitation The start of a payloads may be delimited by alignment with lower layer framing (e.g. aligning data with the start of an MPEG-2 TS Packet or ATM Cell), or via a unique delimiter sequence (e.g. the HDLC or PPP Flag symbol) . Use of a delimiting sequence requires a transparency procedure to ensure the sequence does not appear in the payload data (e.g. bit stuffing in HDLC and byte-stuffing in PPP). Expires September 2002 [page 16] INTERNET DRAFT Requirements for IP transport over DVB June 2003 MPEG-2 indicates the start of a payload unit in a new TS Packet with a "start_of_payload_unit_indicator" [ISO-MPEG]. 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 Packet data, the PUSI value is '1' to indicate the payload of this TS Packet 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, PES Packet starts in the TS Packet. When the payload of the TS Packet contains PSI data, the PUSI value of '1' indicates the first byte of the TS Packet payload carries a pointer_field that indicates the position of the first byte of the Section being carried; if the TS Packet does not carry the first byte of a PSI section, the PUSI is set to '0', indicating that there is no pointer_field in the TS Packet payload. 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. It 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 define how private data may use the PUSI bit. (ii) Length Indicator The end of a payload_unit is signalled directly in some protocols (e.g. by the absence of a carrier in Ethernet, by the presence of a delimiting sequence in HDLC/PPP, or by a marker bit in AAL5). Most services using MPEG-2 include a length field in the payload header to allow the receiver to identify the end of the payload unit (e.g. PES Packet, Section). When parts of more than two payload units are carried in the same TS Packet, only the start of the first is indicated by Expires September 2002 [page 17] INTERNET DRAFT Requirements for IP transport over DVB June 2003 the PUSI pointer. Placement of the length indicator in the encapulation 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. (iii) Next level Protocol Type There is a common 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 in turn be followed by a SNAP header. This introduces considerable overhead. A Next Level Protocol Type field is also required when Robust Header Compression (ROHC) is used. The ROHC framework defines a number of header compression techniques which 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 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. Expires September 2002 [page 18] INTERNET DRAFT Requirements for IP transport over DVB June 2003 [RFC3095]). It is also desirable to allow for other values (e.g., MAC-level bridging). (iv) 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 one table 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. Whereas network layer addresses are used for routing, NPA addresses are primarily used for station (receiver) identification. Receivers may use the NPA of a received SNDU to reject unwanted unicast packets within the interface drive of the receiver, but must also perform forwarding checks based on the network level IP level address. IP multicast and broadcast may also filter based on the NPA, but 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 network layer address is sufficient for both functions. L3 Ethernet switching devices can recognise the destination network layer addresses (often with the assistance of hardware) and perform fast line-rate filtering/forwarding based on IPv4 / IPv6 addresses. Multicast filtering/forwarding can also be performed in this way using a combination of the IP source and destination addresses. 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 Expires September 2002 [page 19] INTERNET DRAFT Requirements for IP transport over DVB June 2003 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 be seen to 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, 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 cases where the use of a NPA is desirable 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 does 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 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. (v) 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 Expires September 2002 [page 20] INTERNET DRAFT Requirements for IP transport over DVB June 2003 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. (vi) 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 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. 6.4 Encapsulation Efficiency To evaluate the performance of different encapsulation methods, a measure has to be found to provide a ranking. 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. In this section the following ranking is used: Efficiency = Sum of transferred bytes / Payload size The goal is to reach a number close to 1.0. However, by using an MPEG-2 TS for transmission the theoretical minimum is 1.0217. This overhead is caused by the 4 byte header for each 188 byte TS Packet. MPE utilizes DSM-CC private sections for conveying IPv4 packets. The section mechanism generates at least 17 bytes per IPv4 packet (16 bytes for the datagram section and 1 byte for the PUSI pointer field). This excludes the LLC/SNAP field which is optional and not required in all cases. Depending on the implementation (i.e., the use of Pacing) it is possible that one TS Packet may contain multiple sections (e.g. the end of one section and the start of another one). A mimumum encapsulation requires the following fields: Frame Length; Payload Type; and Integrity Check. In addition the PUSI field would be required in TS Packets that carry the first byte of an encapsulated SNDU. 7. Supporting Protocols 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 system was originally designed for Expires September 2002 [page 21] INTERNET DRAFT Requirements for IP transport over DVB June 2003 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 is complex, and reflects the complexity of delivering and co-ordinating the various TS Logical Channels associated with a multimedia TV programme. There is no direct support for IP mechanisms for identification of the TS multiplex and PID in use for a particular IP address. 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. Another alternate approach is to carry this information over a TS data channel, (e.g. using a 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 full interoperability with TV equipment (e.g. links used solely for connecting IP (sub)networks). A final possible approach is to design a query/response protocol (similar tpo, or based on the neighbor Advertisements of the IPv6 ND protocol), which operates over an MPEG-2 TS Logical Channel using a previously agreed PID (e.g. configured, or communicated using a SI table). Work in this area includes: (i) Request by a sender to associate a PID with an IP flow. (ii) Request by a sender to establish a QoS association for a PID carried over the MPEG-2 TS Multiplex. (iii) Indication of the MPEG-2 TS Multiplex capabilities to configure the upstream IP sender. (iv) Indication to the IP receiver of the PID and TS Multiplex that should be used for reception of IP packets from a particular address. (v) Definition of a MIB to provide standard management of the IP subnetwork using SNMP. The IP address resolution support may also be suited for use with other IP over MPEG-2 encapsulations (e.g., MPE [ETSI-DAT]). As part of address resolution, there is also a need to signal whether MPE or an IETF encapsulation is used. In some case, an MPEG-2 Transmission Network may support multiple IP networks. If this is the case, it is important to recognise the Expires September 2002 [page 22] INTERNET DRAFT Requirements for IP transport over DVB June 2003 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. 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 addressed area. 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 1Ìs 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 arbitary packets may be passed to the IP layer. Expires September 2002 [page 23] INTERNET DRAFT Requirements for IP transport over DVB June 2003 8. Multicast Support This section addresses specific issues concerning IPv4 and IPv6 multicast over MPEG-2 Transmission Networks. 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. Appropriate procedures need to be specified to identify the correct action when the same multicast group is available on separate TS Logical Channels. This could arise when different end hosts act as senders to contribute IP packets with the same IP group destination address. Another different case arises when a receiver may potentially receive more than one copy of the same packet. In some cases, these may be sent in different TS Logical Channels, or even different TS Multiplexes. In this case, at the IP level, the host/router may be unaware of this duplication. 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 the drivers and operating systems from discarding unwanted multicast traffic. 9. 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. Expires September 2002 [page 24] INTERNET DRAFT Requirements for IP transport over DVB June 2003 10. 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). This document describes the encapsulation required to transfer IPv4 and IPv6 packets over an MPEG-2 transmission network. The current encapsulation methods for IP packets have been outlined, together with guidelines on the requirements for developing a new encapsulation. The framework will support IP packet transmission using the Multiprotocol Encapsulation (MPE), which is widely implemented, and in addition, a new optimised encapsulation procedure. Support for header compression is also a key element in this proposed framework. The framework also includes one or more new MPEG-2 TS Logical Channel resolution procedures to allow dynamic configuration of the sender and receiver using an MPEG-2 link. These will support IPv4 and IPv6 services in both the unicast and multicast modes. 11. Security Considerations The normal security issues relating to the use of wire-less links for transport Internet traffic should be considered. 12. Acknowledgments The authors wish to thank Isabel Amonou , Torsten Jaekel, 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. 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, 26 July 00 [ATSC-DATG] A/91, "Recommended Practice: Implementation Guidelines for the ATSC Data Broadcast Standard", Advanced Television Systems Committee (ATSC),Doc. A/91. 10 June 2001 [ATSC-G] A/54, "Guide to the use of the ATSC Digital Television Standard", Advanced Television Systems Committee (ATSC), Doc. A/54, 4 Oct 95 Expires September 2002 [page 25] INTERNET DRAFT Requirements for IP transport over DVB June 2003 [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 € 31 May 2000 [ATSC-S] A/80, "Modulation and Coding Requirements for Digital TV (DTV) Applications over Satellite", Advanced Television Systems Committee (ATSC), Doc. A/80, 17 July 99 [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-Enc] Horst D. Clausen, Bernhard Collini-Nocker, Hilmar Linder, Gorry Fairhurst Simple Encapsulation for transmission of IP datagrams over MPEG-2/DVB networks, Internet Draft, draft-clausen- ipdvb-enc-xx.txt, Work in Progress. [ID-IPDVB-ULE] Gorry Fairhurst, Bernhard 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. [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). Expires September 2002 [page 26] INTERNET DRAFT Requirements for IP transport over DVB June 2003 [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] E. Duros, W. Dabbous, H. Izumiyama, Y. Zhang, "A Link Layer Tunneling Mechanism for Unidirectional Links", RFC3077. [RFC3095] C. Bormann, 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 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/ Expires December 2003 [page 27] INTERNET DRAFT Requirements for IP transport over DVB June 2003 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 December 2003 [page 28]