Internet Engineering Task Force Gorry Fairhurst Internet Draft University of Aberdeen, U.K. Document: draft-fair-ipdvb-req-00.txt Horst D. Clausen Bernhard Collini-Nocker Hilmar Linder University of Salzburg, A Category: Informational January 2002 Requirements for transmission of IP datagrams over DVB 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. One example is the Digital Video Broadcast (DVB), specified by standards published by the European Telecommunications Standards Institute (ETSI). The document 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 March 2002 [page 1] INTERNET DRAFT Requirements for IP transport over DVB Sept 2001 Document history -00 This draft is intended as a study item for proposed future work by the IETF in this area. 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 Expires June 2002 [page 2] INTERNET DRAFT Requirements for IP transport over DVB Sept 2001 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 | DSMCC | | | | +-+-+-+-+---+------+--------+--+--+ | | PES | ATM |Priv. Section | +---------+-------+----------+--------------+ | MPEG-2 TS | +-------+-------+-------+-------------------+ | DVB-S | DVB-C | DVB-T | Other PHY | +-------+-------+-------+-------------------+ Figure 1: Overview of protocol stack for DVB 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. The service provided by a MPEG-2 transport multiplex offers a number of parallel channels, which correspond to logical links (forming the MPEG Transport Stream (TS)). Each MPEG-2 TS channel is uniquely identified by the Packet ID, PID, value carried in the header of MPEG-2 TS packets. 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 datagrams [ISO- DSMCC;ETSI-DAT;ATSC-DAT], or other data [ISO-DSMCC;ETSI-DAT; ATSC- DAT]. Expires June 2002 [page 3] INTERNET DRAFT Requirements for IP transport over DVB Sept 2001 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 to 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. Data for transmission over the MPEG-2 transport multiplex is passed to an encapsulator which typically receives PDUs (Ethernet frames or IP datagrams). It formats each PDU into a series of TS packets (usually adding an encapsulation header), forming a TS. In a simple example, one or more TS are processed by a MPEG-2 multiplexor resulting in a TS Multiplex. In more complex examples, the same TS may be fed to multiple MPEG-2 multiplexors and these may, in turn, feed other MPEG-2 multiplexors (remultiplexing). In all cases, the final result is a "TS Multiplex" which is transmitted over the physical bearer towards the receiver. To receive IP datagrams 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 subnetwork Protocol Data Units (PDUs), and the receiver must therefore filter (accept) IP datagrams sent with a number of PID values, and must independently reassemble each subnetwork PDU. A system which simultaneously receives from several TS logical channels, utilise receiver hardware to filter unwanted TS logical channels. Most current hardware has a limit on the maximum number of active PIDs (e.g. 32). 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 Datagrams over other media not using MPEG-2 transmission. Bi-directional (duplex) transmission can be provided in the DVB framework by using one of a number of alternate return channel schemes [DVB-RC]. Duplex IP paths may also be supported using non- DVB 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 datagrams or Ethernet_style frames in the control plane associated with audio/video transport. It includes a set of optional header components and requires decoding of the control headers. Expires June 2002 [page 4] INTERNET DRAFT Requirements for IP transport over DVB Sept 2001 +-----------------------------------------+ |Encap Header| Subnetwork PDU | +-----------------------------------------+ / / \ \ / / \ \ / / \ \ +------*----------* +------*----------* +------*----------+ |MPEG-2| MPEG-2 |..|MPEG-2| MPEG-2 |...|MPEG-2| MPEG-2 | |Header| Payload | |Header| Payload | |Header| Payload | +------+----------+ +------+----------+ +------+----------+ Figure 2: Encapsulation of subnetwork PDU (e.g. IP datagram) into a series of MPEG-2 Transport Stream, TS, packets (each TS packet carries a header with a common Packet ID, PID, value). The framework proposed in this document describes a set of protocols designed to allow IP datagrams to be sent over an MPEG-2 TS logical channel. Since most MPEG-2 transmission links are bandwidth-limited, this needs to be simple, robust, and have good link efficiency (i.e. small overhead) when transporting variable sized IP datagrams. The document also suggests 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]). 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. 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 which receives Ethernet frames or IP datagrams, and formats these for output as a transport stream of TS packets. Expires June 2002 [page 5] INTERNET DRAFT Requirements for IP transport over DVB Sept 2001 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. MPE: Multiprotocol Encapsulation [ETSI-DAT]. A scheme that encapsulates Ethernet frames or IP Datagrams, 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]. PID: Packet Identifier. A field carried in the header of all MPEG-2 Transport Stream packets. This is used to identify the TS logical channel to which it belongs [ISO-MPEG]. 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. 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 transport stream channels sent over a single common physical link (i.e. a transmission 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 Expires June 2002 [page 6] INTERNET DRAFT Requirements for IP transport over DVB Sept 2001 pointers to the next payload header, encryption details and time stamp information to synchronise a set of Transport Streams. 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 over a link are: (i) IPv4 Unicast datagrams, destined for a single end host (ii) IPv4 Broadcast datagrams, sent to all end systems in an IP network (iii) IPv4 Multicast datagrams (iv) IPv6 Unicast datagrams, destined for a single end host (v) IPv6 Multicast datagrams (vi) Datagrams with compressed IPv4 / IPv6 packet headers (e.g. [RFC1114;RFC2507;RFC3095]) Two issues are addressed by this framework: First that of providing an efficient encapsulation scheme which may be easily implemented in IP-based transmitters and receivers. Second, existing standards do not define how an IP node should associate a particular IP address with a subnetwork 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. 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 datagram 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 header format currently adopted by MPE known to be not optimal for IP, incurring significant receiver processing overhead and extra link overhead [CLC99]. Expires June 2002 [page 7] INTERNET DRAFT Requirements for IP transport over DVB Sept 2001 (iv) Maximum Link Thruput. 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. (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 IP 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. (vi) 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. 4. Requirements for IP datagrams This section describes the requirements for transporting IPv4 and IPv6 over MPEG-2 links The section identifies key needs and provides examples of mechanisms that may be used to implement these. (i) MPEG-2 Transport Stream. The framework should provide mechanisms to access the underlying network features (MPEG-2 timestamps, PIDs, etc). It should also offer guidance on which MPEG-2 features are pre-requisites for this service, and any optional fields which impact performance / correct operation of the IP encapsulation. (ii) Probability of undetected packet error. There should be a small (or negligible) probability of an undetected packet error [LINK-ID]. The scheme therefore needs to be robust to software failures and link loss. The need for a subnetwork PDU CRC will be determined. (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 subnetwork, a soft-state approach Expires June 2002 [page 8] INTERNET DRAFT Requirements for IP transport over DVB Sept 2001 may prove desirable. This could, for example, be implemented via descriptors sent in the SI tables (using the MPEG-2 control plane), or in-band by a protocol using a data channel (e.g. similar to the Ethernet address resolution protocol (ARP)). (iv) IPv4 and IPv6. The framework must support IPv4 and IPv6 network protocols. To do this, the payload encapsulation may require a type field in the subnetwork PDU to indicate the type of the PDU being carried (e.g. IPv4, IPv6). (v) Compressed Headers. The framework must address the need in certain applications for the support of header compression schemes. This may require a type field in the subnetwork PDU to indicate the type of the PDU being carried (e.g. IPv4, IPv6, Compressed Header). (vi) Multicast. The framework must support IP multicast transmission of IPv4 and IPv6 datagrams. Support for broadcast must also be considered for IPv4. (vii) Frame size and fragmentation. Specification of minimum and maximum frame sizes (MTU). The need (or not) for IP fragmentation and transparent fragmentation to support the minimum MTU [RFC1191;Ken87;LINK-ID]. There is no currently anticipated need to support IPv6 Jumbograms. (viii) Identification of subnetwork source/destination. A new encapsulation scheme may need to support layer 2 addresses (e.g. Ethernet MAC source and destination addresses) of nodes in the MPEG-2 transport network. These are not required for layer 3 functionality, and the need, and applicability, must be addressed by the framework. (ix) Filtering. Support for efficient filtering and extraction of IP packets. This may require layer 2 addresses or labelling of streams corresponding to IP flows. (x) Diffserv and QoS. The mapping of QoS functions may also be addressed (if specific issues arose). This may include how such fields as IP address, IP QoS/DSCP should be mapped to the under-lying MPEG-2 transport stream. (xi) 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 (i.e. where there is also a reverse direction path between the receiving IP end host and the sending IP end host). Consideration should also be given to Expires June 2002 [page 9] INTERNET DRAFT Requirements for IP transport over DVB Sept 2001 security of the TS Multiplex, the need for closed user groups and the use of MPEG-2 TS encryption. (xii) Management. There may be a future need for standardised SNMP MIBs and error reporting procedures. The need for and scope of this is yet to be determined. The first goal of this work is to define a lightweight encapsulation protocol that meets the above requirement. 5. 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 audio/video distribution to set-top-boxes. The design requires access to and processing of the SI table information (which is carried in DSM-CC 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 the 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 (like ARP) 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. Expires June 2002 [page 10] INTERNET DRAFT Requirements for IP transport over DVB Sept 2001 (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 datagrams 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. 6. Multicast Support This section addresses specific issues concerning IPv4 and IPv6 multicast over MPEG-2 links. 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 datagrams 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. 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. 7. Evaluation of transmission of IP datagrams over DVB networks Expires June 2002 [page 11] INTERNET DRAFT Requirements for IP transport over DVB Sept 2001 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 Datagram 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. 8. 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 framework transmits IP datagrams using the Multiprotocol Encapsulation (MPE), which is widely implemented, and in addition, proposes a new optimised encapsulation procedure. 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. The framework will support IPv4 and IPv6 services in both the unicast and multicast modes. Support for compression is also a key element in this proposed framework. 9. Acknowledgments The authors wish to thank Torsten Jaekel, Rod Walsh, and , Luoma Juha-Pekkaand 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. 10. 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 [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 Expires June 2002 [page 12] INTERNET DRAFT Requirements for IP transport over DVB Sept 2001 [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). [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. Expires June 2002 [page 13] INTERNET DRAFT Requirements for IP transport over DVB Sept 2001 [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. 11.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/ 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. Expires June 2002 [page 14] INTERNET DRAFT Requirements for IP transport over DVB Sept 2001 12. 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 2002 [page 15] INTERNET DRAFT Requirements for IP transport over DVB Sept 2001 Appendix 1 Examples of Available Mechanisms for Encapsulation NOTE: The text in this appendix is working notes, and not intended for publication in the final document. List of possible issues include: (i) Delineation of start and end of datagrams (and padding, if required to end of a MPEG-2 TS packet). - Should the MPEG-2 TS start-of-payload indicator be used? - Many IP packets (e.g. a TCP ACK) are typically much smaller than an MPEG-2 TS packet; Packing of multiple datagrams per MPEG-2 packet may significantly improve link efficiency. (ii) 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. Current DVB implementations of DVB receivers frequently restrict the number of PIDs that may be simultaneously received. A simpler encapsulation method may reduce receiver complexity and/or increase the number of PIDs that may be received. (iii) Subnetwork PDUs could have an encapsulation header with address field(s) (if required, e.g. MAC or layer 2 end-point) This may not be required for direct router-to-router communication. (iv) Subnetwork PDUs could have a Protocol Type Field. - Is this required? - May be a pre-requisite for ROHC [RFC3095]? - Also useful for supporting extension headers - Also useful for IPv6 / IPv4 service access points. (v) Subnetwork PDUs must have a Payload Length Field. - Padding must also be supported. (vi) Subnetwork options (to be discouraged, but could be provided via an alternate protocol type field and an extension header). (vii) Payload Checksum / CRC (required? or optional?) [LINK-ID] suggests a CRC-32 may be suitable. A PDU CRC may also be used to validate (viii) Error Reporting. If an equipment is an IP device, then it should conform to standard requirements for hosts [RFC1122] or routers [RFC1812] (depending on its behaviour). (ix) The framework should allow IPSEC. Link level encryption may be provided using an MPEG-2 TS option. Expires June 2002 [page 16] INTERNET DRAFT Requirements for IP transport over DVB Sept 2001 (x) There are benefits from designing a framework which may be appropriate a packet/cell size different from 188B. This would allow evolution of the techniques, to support future versions of MPEG-2 and other cell based physical layers. A common standard would also be very desirable for hybrid systems which employ different physical links in the forward and reverse directions. Expires June 2002 [page 17]