Internet Engineering Task Force Gorry Fairhurst Internet Draft University of Aberdeen, U.K. Document: draft-fair-ipdvb-ar-00.txt Marie-JosŪ Montpetit MJMontpetit.com Expires December 2003 Category: Informational June 2003 Address Resolution for IP datagrams over MPEG-2 networks Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document describes mechanisms to bind IPv4/IPv6 addresses with MPEG-2 Transport Streams (TS). Protocols are required to signal these addresses to the link receivers and transmitters, known as Address Resolution, or Neighbour Discovery. Although this is often associated with Ethernet [RFC803], these processes are essential to the operation of any L2 network. MPEG-2 transmission networks often utilize broadcast media (e.g., satellite and cable) where the mapping may take into account issues related to network operations and traffic engineering. In MPEG-2 transmission networks, an IP address must be associated with a Packet ID (PID) and specific transmission multiplex. Address resolution complements the higher layer resource discovery tools that are used to advertise IP sessions, such as SDP, and IMG. In this document the different mechanisms used for address resolution are reviewed and guidelines for future developments of efficient schemes are given. Expires December 2003 [page 1] INTERNET DRAFT Address Resolution for IP datagrams over MPEG-2 networks June 2003 Table of Contents >>> AuthorsĖ Note: To be completed. <<< Document History -00 This draft is intended as a study item for proposed future work by the IETF in this area. Expires December 2003 [page 2] INTERNET DRAFT Address Resolution for IP datagrams over MPEG-2 networks June 2003 1. Introduction The MPEG-2 stream is defined in the specification ISO/IEC 138181. MPEG-2 provides a time-division multiplexed stream that may contains audio, video and other information. Each frame, known as an MPEG-2 TS Packet, contains 4 bytes of header and 188 bytes of data. The standard also defines the PES packet (Packetized Elementary Stream) and the Section Packet or Transport Stream (TS). The PES packet can carry video, audio, private data and was originally used for some data streaming applications; this usage is now historical. Each MPEG-2 TS Packet is associated with one Transport Stream (TS) logical channel, which is identified by a 13 bit Packet ID (PID) carried in the MPEG-2 TS Packet header. The standard also defines a MPEG-2 control plane that may be used to transmit control information. For example, using System Information (SI) Tables (ETSI-SI, ETSI-SI1], or System Information (SI) PSI Tables can be used to carry PID information about the transported stream. MPEG-2 address resolution assigns IP addresses to particular transmission multiplexes, and within a multiplex to a specific PID. The protocol signals this mapping to the other communicating devices (Gateways and Receivers). In some address resolution schemes, this address space is sub- divided into logical contexts € known as Platforms or Sections. One use of this sub-division is to associate a separate context with each IP service provider that shares a common MPEG-2 TS (i.e., uses the same PID). MPEG-2 Receivers may optionally be assigned a Network Point of Attachment (NPA) to uniquely identify the L2 node within the MPEG-2 transmission network. An example of an NPA is the IEEE Medium Access Control (MAC) address. Where such addresses are used, these must also be signalled by the address resolution procedure. Finally, address resolution may need to signal the format of the data being transmitted. For example, the encapsulation used (together with any compression scheme that was used at the sender) [ID-IPDVB-REQ]. This document describes mechanisms to signal the TS Multiplex, the PID, and (if used) the MAC address / platform ID associated with each IP flow to the network layer at the sender and receiver (address resolution). This could, for example, be implemented via descriptors sent in MPEG-2 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). Expires December 2003 [page 3] INTERNET DRAFT Address Resolution for IP datagrams over MPEG-2 networks June 2003 1.1 Address Resolution Issues The IP address resolution support should support both existing IP over MPEG-2 encapsulations (e.g., MPE [ETSI-DAT, ETSI-DAT1], and also any IETF encapsulation that may be defined [ID-IPDVB-REQ]. In some case, an MPEG-2 Transmission Network may support multiple IP networks. If this is the case, it is important to recognise the context (scope) within which an address is resolved, to prevent packets from one addressed scope leaking into other scopes. Examples of overlapping IP address assignments include: (i) Private unicast addresses (e.g. in IPv4, 10/8 prefix; 172.16/12 prefix; 192.168/16 prefix) should be confined to one addressed area. (ii) Some multicast addresses, (e.g., the scoped multicast addresses sometimes used in private networks). These are only valid within an addressed area (examples for IPv4 include; 239/8; 224.0.0/24; 224.0.1/24). Similar cases exist for some IPv6 multicast addresses. (iii) Scoped multicast addresses. Forwarding of these addresses is controlled by the scope associated with the address. IP packets with these addresses must not be allowed to travel outside their intended scope, and may cause unexpected behaviour if allowed to do so. In addition, overlapping address assignments can arise when using Level 2 Network Point of Attachment (NPA) addresses [ID-IPDVB-REQ]: (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 Expires December 2003 [page 4] INTERNET DRAFT Address Resolution for IP datagrams over MPEG-2 networks June 2003 The additional network traffic may contribute to processing load but should not lead to unexpected protocol behaviour. It does however introduce a potential Denial of Service (DoS) opportunity. When the Receiver acts as an IP router, the receipt of such packet may lead to unexpected protocol behaviour. This also provides a security vulnerability since arbitrary packets may be passed to the IP layer. 1.2 Multicast Support There are specific issues concerning IPv4 and IPv6 multicast over MPEG-2 Transmission Networks. (i) Mapping IP multicast groups to the underlying MPEG-2 TS Logical Channel (PID) and the MPEG-2 TS Multiplex. (ii) Provide signalling information to allow a receiver to locate an IP multicast flow within an MPEG-2 TS Multiplex. (iii) Determining group membership (e.g. utilising IGMP/MLD). 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. Expires December 2003 [page 5] INTERNET DRAFT Address Resolution for IP datagrams over MPEG-2 networks 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. AIT: Application Information Table specified by the Multimedia Home Platform (MHP) specifications [ETSI-MHP]. This table may carry IPv4/IPv6 to MPEG-2 TS address resolution information. 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. DVB-RCS: Digital Video Broadcast Return Channel via Satellite. A bi- directional IPv4/IPv6 service employing low-cost Receivers. 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. INT: Internet/MAC Notification Table. A uni-directional addressing resolution mechanism using SI and/or PSI Tables. MAC: Medium Access and Control of the Ethernet IEEE 802 standard of protocols (see also NPA). MHP: Multimedia Home Platform. An integrated MPEG-2 multimedia receiver, that may (in some cases) support IPv4/IPv6 services. MMT: Multicast Mapping Table (proprietary extension to DVB-RCS). Expires December 2003 [page 6] INTERNET DRAFT Address Resolution for IP datagrams over MPEG-2 networks June 2003 MPE: Multiprotocol Encapsulation [ETSI-DAT, ETSI-DAT1]. 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]. 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. PSI: Programme Specific Information: In this document, the term is used to describe any table used to convey information about a subset of services carried in a TS Multiplex (e.g. [ISO-MPEG]). PSI tables are carried in MPEG-2 private sections. SI TABLE: Service Information Table. In this document, the term is used to describe any table used to convey information about the service carried in a TS Multiplex (e.g. [ISO-MPEG]). SI tables are carried in MPEG-2 private sections. STB: Set Top Box. A consumer equipment (Receiver) for reception of digital TV services. TS: Transport Stream [ISO-MPEG], a method of transmission at the MPEG-2 level using TS Packets; it represents level 2 of the ISO/OSI reference model. See also TS Logical Channel and TS Multiplex. Expires December 2003 [page 7] INTERNET DRAFT Address Resolution for IP datagrams over MPEG-2 networks June 2003 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 December 2003 [page 8] INTERNET DRAFT Address Resolution for IP datagrams over MPEG-2 networks June 2003 3. MPEG-2 Address Resolution Operation In this section, the MPEG-2 address resolution mechanisms are reviewed. In MPEG-2, the 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 [ETSI- SI, ETSI-SI1] (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. Because of its historical usage, there is no direct support for IP mechanisms for identification of the TS multiplex and PID in use for a particular IP address. It is also important to highlight that a PID value is associated with a unidirectional channel, also a result of its initial usage. >>> AuthorĖs Note: Input requested from ATSC, and users/vendors of other non-DVB systems <<< 3.1 Static configuration. The static mapping option (IP addresses or flows statically mapped to PIDs) is the equivalent to signalling "out-of-band". The application programmer, installing engineer, or user receives the mapping via some outside means (not in the MPEG-2 TS). This is useful for testing, experimental networks, small subnetworks and closed domains. A single "well-known" PID is a specialisation of this, but requires all IP traffic to be placed into the specified TS logical channel. Section filtering may be used to differentiate subnetworks at the expense of added complexity and potential performance penalties. 3.2 Table-Based Address Resolution MPEG-2 associates multimedia MPEG information with PIDs, using MPEG- 2 Tables. A TS multiplex may provide PID information for IP services by integrating additional information into the existing MPEG-2 tables, or to define additional tables specific to the IP service. This has a dual advantage: (i) IP specific information can be obtained directly. (ii) The mechanism uses an already standardised mechanism. Expires December 2003 [page 9] INTERNET DRAFT Address Resolution for IP datagrams over MPEG-2 networks June 2003 A large number of methods exist within the standards and current implementations of systems for allowing a MPEG-2 receiver to identify the appropriate PID and multiplex using to transmit traffic to a specific IP address. Examples include: (i) IP/MAC Notification Table (INT) in the DVB Data standard [ETS_DAT]. This provides uni-directional address resolution of IPv4/IPv6 multicast addresses to MPEG-2 TS. (ii) Application Information Table (AIT) in the Multimedia Home Platform (MHP) specifications [ETSI-MHP]. (iii) Multicast Mapping Table (MMT) an MPEG-2 Table employed by some DVB-RCS systems to provide uni-directional address resolution of IPv4 multicast addresses to MPEG-2 TS. (iv) >>> AuthorĖs Note: Please send details of experience using the above schemes (and any others) to authors. <<< The MMT and AIT are used for specific applications. The INT is more general purpose, and supports both IPv4 and IPv6 and can be used in combination with the other tables. It is the favoured choice of some members of the DVB community for address management and is briefly described below. 3.2.1 Description of the IP/MAC Notification Table (INT) and its usage. The INT provides a mechanism for carrying information about the location of IP/MAC flows within DVB networks. An IP/MAC Platform represents a set of IP/MAC streams and/or receiver devices. Such a Platform may span several transport streams within one or multiple DVB networks and represents a single IP network with a harmonized address space (i.e. one without address conflicts). The IP/MAC Platform concept allows for the coexistence of several non- harmonized IP/MAC address spaces on the same DVB network. The INT allows "subnets" and fully specified single destination addresses to make signalling bandwidth efficient and flexible as required. The "subnet mask" (also for IPv6) can be given in full form or in slash notation (e.g. /127), this supports IPv6 prefixes. Multicast addresses can be given with or without source (address or range), although if source address is given then only the slash notation can be used for prefixes/subnets. In addition to identification and security descriptors the following descriptors are used for address binding in INT tables: Expires December 2003 [page 10] INTERNET DRAFT Address Resolution for IP datagrams over MPEG-2 networks June 2003 (i) target_MAC_address_descriptor: The descriptor used to describe a single or group of MAC addresses (and their mask). (ii) target_MAC_address_range_descriptor: May be used to setup filters. (iii) target_IP_address_descriptor: The descriptor describing a single or group of IPv4 unicast or multicast addresses (and their mask). (iv) target_IP_slash_descriptor: Allows definition and announment of an IPv4 subnet. (v) target_IP_source_slash_descriptor: Uses source and destination addresses to target a single or group of devices; could be used to define flows. (vi) IP/MAC stream_location_descriptor: This descriptor directly locates the IP/MAC stream in a DVB network. The following descriptors provide corresponding functions for IPv6 addresses: target_IPv6_address_descriptor target_IPv6_slash_descriptor and target_IPv6_source_slash_descriptor In addition, the ISP_access_mode_descriptor allows definition if the access to the ISP is done via an alternative non-DVB network (hence another address is necessary). The INT provides a set of descriptors to manage addressing in a DVB network. Its drawbacks are that while the IP/MAC concept is general enough there is still a need to manage the addressing (and the traffic) at the PID level. It currently is defined only for Multi- Protocol Encapsulation (MPE) and would need extension to support other schemes (e.g. [IPDVB-REQ]). In addition the use of a centralized management prevents the implementation of a more dynamic scheme. 3.3 IP Address Resolution Protocol Another possible approach is to design a query/response protocol (similar to, or based on the neighbour advertisements of the IPv6 ND protocol), which operates over an MPEG-2 TS Logical Channel using a Expires December 2003 [page 11] INTERNET DRAFT Address Resolution for IP datagrams over MPEG-2 networks June 2003 previously agreed PID (e.g. configured, or communicated using a SI table). While the Neighbour Advertisement Protocol [RFC2461]could be used as a basis for such a design for IPv6 addresses, the extensive use of broadcast messages to request and transmit layer 2 addresses would prove inefficient for DVB systems using a wireless physical layer. Both ARP and ND allow unsolicited advertisements of bindings by a sender that are broadcast/multicast to the network, without requiring the overhead of a client request. However, both ND and ARP are currently restricted to advertising a single association per message. To achieve efficient transmission and receiver processing over broadcast physical layer, a method needs to be found that advertises several associations in a single message (e.g., following the method used in MPEG-2 Tables). The development of IP_layer address resolution would have several merits, particularly for IP-only services and two-way MPEG-2 transmission networks. Not only would may release a Receiver from performing MPEG-2 table processing, it would also allow much more dynamic association of PIDs to traffic. Examples of dynamic associations include: association/freeing of PIDs in response to join or prune actions taken by multicast routing protocols, or on assignment of new IP addresses using DHCP/DHCPv6. Implementing such protocols above the IP layer (e.g. using multicast IP transport, as used by ND), would allow this protocol to be implemented in a portable way € not dependent on specific receiver hardware/drivers and would allow future integration of the functions within IP routers. The nature of an MPEG-2 transport network and the need to maintain flexibility for the operator, means that a protocol would need to use operator specifics for address resolution. Adding to this complexity, 2-way MPEG-2 services (such as DVB-RCS) employ a pair of logically separate unidirectional TS, requiring separate return and forward resolution. No address resolution protocol has yet been defined for MPEG-2 transmission networks. 4. Recommendations >>> AuthorĖs note: Input required, please send to ip-dvb mailing list <<< >>> AuthorĖs note: Input requested from operators <<< 5. Security Considerations Expires December 2003 [page 12] INTERNET DRAFT Address Resolution for IP datagrams over MPEG-2 networks June 2003 The normal security issues relating to the use of wire-less links for transport Internet traffic should be considered. Readers are also refered to the known security issues associated with ARP [RFC826] and ND. 6. Acknowledgments The authors wish to thank Rod Walsh, Jun Takei, and Alexander Adolf for their inputs. Expires December 2003 [page 13] INTERNET DRAFT Address Resolution for IP datagrams over MPEG-2 networks June 2003 7. References >>> AuthorĖs note: This list may need to be pruned <<< [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-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. [ETSI-DAT] EN 301 192, "Specifications for Data Broadcasting", v1.3.1, European Telecommunications Standards Institute (ETSI), May 2003. http://www.etsi/org/ [ETSI-DAT1] EN 101 202, "Implementation Guide for Data", v1.2.1, European Telecommunications Standards Institute (ETSI), May 2003. http://www.etsi/org/ [ETSI-MHP] ETSI TS 101 812, "Digital Video Broadcasting (DVB); Multimedia Home Platform (MHP) Specification", v1.2.1, European Telecommunications Standards Institute (ETSI), June 2002. http://www.etsi/org/ [ETSI-SI] ETSI EN 300 468: "Digital Video Broadcasting (DVB); Specification for Service Information (SI) in DVB systems". [ETSI-SI1] ETSI TR 101 162: "Digital Video Broadcasting (DVB); Allocation of Service Information (SI) codes for DVB systems". [ID-IPDVB-REQ] Fairhurst, G., Clausen, H.D., Collini-Nocker, B., and H. Liner, "Requirements for transmission of IP datagrams over DVB networks", Internet Draft, Work in Progress, IETF. [ID-IPDVB-Enc] H. D. Clausen, B. Collini-Nocker, H. Linder, G. Fairhurst, "Simple Encapsulation for transmission of IP Datagrams over MPEG-2/DVB networks‚, draft-unisal-ipdvb-enc-xx.txt, Internet Draft, Work in Progress, IETF. [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). Expires December 2003 [page 14] INTERNET DRAFT Address Resolution for IP datagrams over MPEG-2 networks June 2003 [RFC826] Plummer, D. "An Ethernet Address Resolution Protocol", RFC 826, IETF, November 1982. [RFC1112] Deering, S.E., "Host Extensions for IP Multicasting", RFC1112, (STD05), IETF. August 1989. [RFC1122] B. Braden, ed., "Requirements for Internet Hosts - Communication Layers", RFC 1122. [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6), RFC 2461, December 1998. [RFC2464] Crawford. M., "Transmission of IPv6 Packets over Ethernet Networks", RFC2464, IETF December 1998. [RFC3077] Duros, E., W. Dabbous, H. Izumiyama, Y. Zhang, "A Link Layer Tunneling Mechanism for Unidirectional Links", RFC3077. 8.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 Marie-JosŪ Montpetit 168 Mystic Valley Parkway Arlington, MA, USA Email: marie@mjmontpetit.com 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 Expires December 2003 [page 15] INTERNET DRAFT Address Resolution for IP datagrams over MPEG-2 networks June 2003 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. 9. IANA Considerations NOT KNOWN AT THIS TIME. Expires December 2003 [page 16]