Internet Engineering Task Force Gorry Fairhurst Internet Draft University of Aberdeen Document: draft-ietf-ipdvb-ar-02.txt Marie-Jose Montpetit Motorola Connected Home Solutions Category: Draft February 2006 Address Resolution for IP Datagrams over MPEG-2 Networks Status of this Draft By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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/1id-abstracts.html. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document describes the process of binding/associating IPv4/IPv6 addresses with MPEG-2 Transport Streams (TS). This procedure is known as Address Resolution (AR), or Neighbour Discovery (ND). Such address resolution complements the higher layer resource discovery tools that are used to advertise IP sessions. In MPEG-2 Networks, an IP address must be associated with a Packet ID (PID) value and a specific Transmission Multiplex. The document reviews current methods. It also describes the interaction with well-known protocols for address management including DHCP, ARP, and the ND protocol, and provides guidance on usage. Expires Sept 2006 [page 1] INTERNET DRAFT AR for IP over MPEG-2 networks Feb 2006 Table of Contents 1. Introduction 2. Convention used in the document 3. Address Resolution Requirement 3.1 Unicast Support 3.2 Multicast Support 4. MPEG-2 Address Resolution 4.1 Static configuration. 4.1.1 MPEG-2 Cable Networks 4.2 MPEG-2 Table-Based Address Resolution 4.2.1 IP/MAC Notification Table (INT) and its usage 4.2.2 Multicast Mapping Table (MMT) and its usage 4.2.3 Application Information Table (AIT) and its usage 4.2.4 Address Resolution in ATSC 4.2.5 Comparison of SI/PSI table approaches 4.3 IP-based resolution of TS Logical Channels 4.3.1 IP-based multicast resolution of TS Logical Channels 5. Mapping IP addresses to NPA/MAC addresses 5.1 Uni-directional links supporting uni-directional connectivity 5.2 Uni-directional links with bi-directional connectivity 5.3 Bi-directional links 5.4 IP Multicast AR 6. Link Layer Support 6.1 ULE without a destination MAC/NPA address (D=1) 6.2 ULE with a destination NPA/MAC address (D=0) 6.3 MPE without LLC/SNAP Encapsulation 6.4 MPE with LLC/SNAP Encapsulation 6.5 ULE with Bridging Header Extension (D=1) 6.6 ULE with Bridging Header Extension and NPA Address (D=0) 6.7 MPE with LLC/SNAP and Bridging 7. Conclusions 8. Security Considerations 9. Acknowledgements 10. References 11. Author's Addresses 12. IPR Notices 13. Copyright Statements 14. IANA Considerations Appendix Expires June 2006 [page 2] INTERNET DRAFT AR for IP over MPEG-2 networks Feb 2006 1. Introduction The MPEG-2 Transport Stream (TS) provides a time-division multiplexed (TDM) stream that may contain audio, video and data information, including encapsulated IP Datagrams [RFC4259]. It is defined in specification ISO/IEC 138181 [ISO-MPEG2]. Each Layer-2 frame, known as a TS Packet, contains a 4 byte header and a 184 byte payload. Each TS Packet is associated with a single TS Logical Channel, identified by a 13-bit Packet ID (PID) value that is carried in the MPEG-2 TS Packet header. The MPEG-2 standard also defines a control plane that may be used to transmit control information to Receivers in the form of System Information (SI) Tables [ETSI-SI, ETSI-SI1], or Program Specific Information (PSI) Tables. To utilize the MPEG-2 TS as an IP link, a sender must associate an IP address with a particular Transmission Multiplex, and within the multiplex identify the specific PID to be used. This document calls this mapping Address Resolution (AR). In some AR schemes, the MPEG-2 TS address space is sub-divided into logical contexts known as Platforms. Each Platform associates an IP service provider with a separate context that share a common MPEG-2 TS (use the same PID value). MPEG-2 Receivers may use a Network Point of Attachment (NPA) [RFC4259] to uniquely identify the L2 node within an 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 signaled by the AR procedure. Finally, address resolution could signal the format of the data being transmitted, for example, the encapsulation, any L2 encryption method and any compression scheme [RFC4259]. The numbers of Receivers connected via a single MPEG-2 link may be much larger than found in other common LAN technologies, (e.g. Ethernet). This has implications on design/configuration of the address resolution mechanisms. Current routing protocols, and some multicast application protocols also do not scale to arbitrary large numbers of participants. Such networks do not by themselves introduce an appreciable subnetwork round trip delay, however many practical MPEG-2 transmission networks are built using links that may introduce significant path delay (satellite links, use of dial- up modem return, cellular return, etc). This higher delay may need to be accommodated for in the design of protocols that use this service. The remainder of the document describes current mechanisms and their use to associate an IP address with the corresponding TS Multiplex, PID value, the NPA/MAC address and/or Platform ID. A range of approaches is described, including Layer-2 methods (using MPEG-2 SI tables), and protocols at the IP level (including the IPv4 Address Resolution Protocol, ARP [RFC826] and the IPv6 Neighbor Discovery Expires June 2006 [page 3] INTERNET DRAFT AR for IP over MPEG-2 networks Feb 2006 Protocol, ND [RFC2461]). Interactions and dependencies between these methods and the encapsulation methods are described. Expires June 2006 [page 4] INTERNET DRAFT AR for IP over MPEG-2 networks Feb 2006 2. Conventions used in this document 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 framework and a set of associated standards for the transmission of video, audio, and data using the ISO MPEG-2 standard [ISO-MPEG]. b: bit. For example, one byte consists of 8b. B: Byte. Groups of bytes are represented in Internet byte order. DSM-CC: Digital Storage Media Command and Control [ISO-DSMCC]. A format for transmission of data and control information carried in an MPEG-2 Private Section, defined by the ISO MPEG-2 standard. DVB: Digital Video Broadcast [ETSI-DVB]. A framework and set of associated standards published by the European Telecommunications Standards Institute (ETSI) 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 PDUs and formats these into Payload Units (known here as SNDUs) for output as a stream of TS Packets. Feed Router: The router delivering the IP service over a Unidirectional Link. INT: Internet/MAC Notification Table. A uni-directional addressing resolution mechanism using SI and/or PSI Tables. MAC: Medium Access Control [IEEE-802.3]. A link-layer protocol defined by the IEEE 802.3 standard (or by Ethernet v2 [DIX]). MAC Header: The link-layer header of the IEEE 802.3 standard [IEEE- 802.3 or Ethernet v2 [DIX]. It consists of a 6B destination address, 6B source address, and 2B type field (see also NPA, LLC). MHP: Multimedia Home Platform. An integrated MPEG-2 multimedia receiver, that may (in some cases) support IPv4/IPv6 services [ETSI- MHP]. MMT: Multicast Mapping Table (proprietary extension to DVB-RCS [ETSI-RCS] defining an AR table that maps IPv4 multicast addresses to PID values). MPE: Multiprotocol Encapsulation [ETSI-DAT; ATSC-DAT; ATSC-DATG]. A method that encapsulates PDUs, forming a DSM-CC Table Section. Each Expires June 2006 [page 5] INTERNET DRAFT AR for IP over MPEG-2 networks Feb 2006 Section is sent in a series of TS Packets using a single Stream (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/IEC 113818-1) [ISO-MPEG2], and ITU-T (in H.220). NPA: Network Point of Attachment. In this document, refers to a 6 byte destination address (resembling an IEEE MAC address) within the MPEG-2 transmission network that is used to identify individual Receivers or groups of Receivers [RFC4259]. PAT: Program Association Table. An MPEG-2 PSI control table. It associates each program with the PID value that is used to send the associated PMT. The table is sent using the well-known PID value of 0x000, and is required for an MPEG-2 compliant Transport Stream. PDU: Protocol Data Unit. Examples of a PDU include Ethernet frames, IPv4 or IPv6 Datagrams, and other network packets. PID: Packet Identifier [ISO-MPEG2]. A 13 bit field carried in the header of each TS Packet. This identifies the TS Logical Channel to which a TS Packet belongs [ISO-MPEG2]. The TS Packets that form the parts of a Table Section, or other Payload Unit must all carry the same PID value. The all ones PID value indicates a Null TS Packet introduced to maintain a constant bit rate of a TS Multiplex. There is no required relationship between the PID values used for TS Logical Channels transmitted using different TS Multiplexes. PMT: Program Map Table. An MPEG-2 PSI control table that associates the PID values used by the set of TS Logical Channels/ Streams that comprise a program [ISO-MPEG2]. The PID value used to send the PMT for a specific program is defined by an entry in the PAT. Private Section: A syntactic structure constructed according to Table 2-30 of [ISO-MPEG2]. The structure may be used to identify private information (i.e. not defined by [ISO-MPEG2]) relating to one or more elementary streams, or a specific MPEG-2 program, or the entire Transport Stream. Other Standards bodies, e.g. ETSI, ATSC, have defined sets of table structures using the private_section structure. A Private Section is transmitted as a sequence of TS Packets using a TS Logical Channel. A TS Logical Channel may carry sections from more than one set of tables. PSI: Program Specific Information [ISO-MPEG2]. PSI is used to convey information about services carried in a TS Multiplex. It is carried in one of four specifically identified table section constructs [ISO-MPEG2], see also SI Table. Receiver: Equipment that processes the signal from a TS Multiplex and performs filtering and forwarding of encapsulated PDUs to the network-layer service (or bridging module when operating at the link-layer). Expires June 2006 [page 6] INTERNET DRAFT AR for IP over MPEG-2 networks Feb 2006 SI Table: Service Information Table [ISO-MPEG2]. In this document, this term describes a table that is been defined by another standards body to convey information about the services carried in a TS Multiplex. A Table may consist of one or more Table Sections, however, all sections of a particular SI Table must be carried over a single TS Logical Channel [ISO-MPEG2]. SNDU: Subnetwork Data Unit. An encapsulated PDU sent as an MPEG-2 Payload Unit. STB: Set-Top Box. A consumer equipment (Receiver) for reception of digital TV services. Table Section: A Payload Unit carrying all or a part of an SI or PSI Table [ISO-MPEG2]. TS: Transport Stream [ISO-MPEG2], a method of transmission at the MPEG-2 level using TS Packets; it represents layer 2 of the ISO/OSI reference model. See also TS Logical Channel and TS Multiplex. TS Logical Channel: Transport Stream Logical Channel. In this document, this term identifies a channel at the MPEG-2 level [ISO- MPEG2]. This exists at level 2 of the ISO/OSI reference model. All packets sent over a TS Logical Channel carry the same PID value (this value is unique within a specific TS Multiplex). The term "Stream" is defined in MPEG-2 [ISO-MPEG2]. This describes the content carried by a specific TS Logical Channel (see, ULE Stream). Some PID values are reserved (by MPEG-2) for specific signaling. Other standards (e.g., ATSC, DVB) also reserve specific PID values. TS Multiplex: In this document, this term defines a set of MPEG-2 TS Logical Channels sent over a single lower layer connection. This may be a common physical link (i.e. a transmission at a specified symbol rate, FEC setting, and transmission frequency) or an encapsulation provided by another protocol layer (e.g. Ethernet, or RTP over IP). The same TS Logical Channel may be repeated over more than one TS Multiplex (possibly associated with a different PID value) [RFC4259], for example to redistribute the same multicast content to two terrestrial TV transmission cells. TS Packet: A fixed-length 188B unit of data sent over a TS Multiplex [ISO-MPEG2]. Each TS Packet carries a 4B header. UDL: Unidirectional link: A one-way transmission link. For example, and IP over DVB link using a broadcast satellite link. ULE: Unidirectional Lightweight Encapsulation (ULE). A scheme that encapsulates PDUs, into SNDUs that are sent in a series of TS Packets using a single TS Logical Channel [RFC4326]. Expires June 2006 [page 7] INTERNET DRAFT AR for IP over MPEG-2 networks Feb 2006 ULE Stream: An MPEG-2 TS Logical Channel that carries only ULE encapsulated PDUs. ULE Streams may be identified by definition of a stream_type in SI/PSI [RFC4326, ISO-MPEG2]. Expires June 2006 [page 8] INTERNET DRAFT AR for IP over MPEG-2 networks Feb 2006 3. Address Resolution Requirements The MPEG IP address resolution process is independent of the choice of encapsulation and needs to support a set of IP over MPEG-2 encapsulation formats, including MPE [ETSI-DAT, ETSI-DAT1, ATSC- DAT]) and the IETF-defined Unidirectional Lightweight Encapsulation (ULE) [RFC4326]. The general IP over MPEG-2 AR requirements are summarized below: A protocol version, to indicate the specific AR protocol in use and which may include the supported encapsulation method. A method (e.g. well-known L2/L3 address/addresses) to identify the AR server sourcing the AR information. A method to represent IPv4/IPv6 AR information (including security associations to authenticate the AR information that will present address masquerading). A method to install AR information associated with clients at the AR server (registration). Scalable and efficient method for transmission of AR information from an AR server to clients (link local multicast, is preferable to subnet broadcast). Incremental update of the AR information held by clients. Procedures for purging clients of stale AR information. 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 [RFC4259]. 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). Packets with these addresses should be confined to one addressed area. IPv6 also defines link-local addresses that must not be forwarded beyond the link on which they were first sent. (ii) Local scope multicast addresses. These are only valid within the local area (examples for IPv4 include: 224.0.0/24; 224.0.1/24). Similar cases exist for some IPv6 multicast addresses [RFC2375]. (iii) Scoped multicast addresses [RFC2365] [RFC 2375]. Forwarding of these addresses is controlled by the scope associated with the address. The addresses are only valid within an addressed area (e.g. the 239/8 [RFC2365]). Expires June 2006 [page 9] INTERNET DRAFT AR for IP over MPEG-2 networks Feb 2006 Overlapping address assignments may also occur at L2, where the same NPA/MAC address is used to identify multiple Receivers [RFC4259]: (i) An NPA unicast address must be unique within the addressed area. The IEEE assigned MAC addresses used in Ethernet LANs are globally unique. If the NPA addresses are not globally unique, an NPA address must only be re-used by Receivers in different addressed (scoped) areas. (ii) The NPA broadcast address (all 1 MAC address). Traffic with this address should be confined to one addressed area. (iii) IP and other protocols may view sets of MAC multicast addresses as link-local, and may produce unexpected results if frames with these address are distributed across several private networks. Reception of unicast packets destined for another addressed area will lead to an increase in the rate of received packets by systems connected via the network. Reception of the additional network traffic may contribute to processing load, but should not lead to unexpected protocol behaviour, providing that systems can be uniquely addressed. It does however introduce a potential Denial of Service (DoS) opportunity. When the Receiver operates as an IP router, the receipt of such a packet can lead to unexpected protocol behaviour. 3.1 Unicast Support Unicast address resolution is required at two levels. At the upper level, the AR procedure needs to associate an IP address with a specific NPA/MAC address. At the lower level, the IP (or MAC) address needs to be associated with a specific TS Logical Channel (PID value) and the corresponding TS Multiplex. Within a specific scope, the same unicast IP address may be associated with more than one TS Logical Channel [ETSI-DAT]. These may have different content (e.g. when several different IP Encapsulators contribute IP flows destined to the same Receiver), but there is also the possibility of receiving duplicated copies of IP packets. 3.2 Multicast Support Multicast is an important application for MPEG-2 Transmission Networks, since it exploits the advantages of native support for link broadcast. Multicast address resolution occurs at the network level in associating a specific L2 address with an IP Group Destination Address (section 5). In IPv4 and IPv6 over Ethernet, Expires June 2006 [page 10] INTERNET DRAFT AR for IP over MPEG-2 networks Feb 2006 this association is normally a direct mapping, and this is the default method also specified in both ULE [RFC4326] and in MPE [ETSI-DAT]. Address resolution must also occur at the MPEG-2 level (section 4). The goal of this multicast address resolution is the association of an IPv4 or IPv6 multicast address with a specific TS Logical Channel (PID value) and the corresponding TS Multiplex. This association needs to permit a large number of active multicast groups, and should minimise the processing load at the Receiver when filtering and forwarding IP multicast packets (e.g. by distributing the multicast traffic over a number of TS Logical Channels). Schemes that allow hardware filtering can be beneficial, since these may relieve the drivers and operating systems from discarding unwanted multicast traffic. There are specific issues concerning IP 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 at the Encapsulator. (ii) Provide signaling information to allow a Receiver to locate an IP multicast flow within an MPEG-2 TS Multiplex. Methods are required to identify the scope of an address when an MPEG-2 network supports several logical IP networks and carries groups within different multicast scopes. Appropriate procedures need to specify the correct action when the same multicast group is available on separate TS Logical Channels. This could arise when different Encapsulators contribute IP packets with the same IP Group Destination Address in the ASM address range. Another case arises when a Receiver could receive more than one copy of the same packet (e.g. when packets are replicated across different TS Logical Channels, or even different TS Multiplexes, a method known as Simulcasting [DVB-DAT]). At the IP level, the host/router may be unaware of this duplication and this needs to be detected by other means. In some scenarios, a pre-defined set of IP multicast group destination addresses may be in used within a MPEG-2 transmission network. Prior knowledge of the active set of addresses allows appropriate AR records to be constructed for each address, and to pre-assign the corresponding PID value (e.g., selected to optimise Receiver processing; to group related addresses to the same PID value; and/or to reflect a policy for usage of specific ranges of PID values). When the MPEG-2 Network is peered to the multicast-enabled Internet, an arbitrarily large number of IP multicast group destination addresses may be in use and the set forwarded on the transmission Expires June 2006 [page 11] INTERNET DRAFT AR for IP over MPEG-2 networks Feb 2006 network may be expected to vary significantly with time. Note that some uses of IP multicast employ a range of addresses to support a single application (e.g., ND [RFC2461], LCT [RFC3451], WEBRC [RFC3738]). The current set of active addresses may be determined dynamically via a multicast group membership protocol (e.g., IGMP [RFC3376], MLD [RFC3810]), via multicast routing (e.g., PIM [RFC2362]) and/or other means (e.g. [RFC3819]), however each active address requires a binding by the AR method. There are therefore advantages in using a method that does not need to explicitly advertise AR binding for each IP traffic flow, but is able to distribute traffic across a number of L2 TS Logical Channels (e.g., using a hash/mapping that resembles the mapping from IP addresses to MAC addresses [RFC1112, RFC2464]). Such methods can reduce the volume of AR information that needs to be distributed, and reduce the AR processing. Expires June 2006 [page 12] INTERNET DRAFT AR for IP over MPEG-2 networks Feb 2006 4. MPEG-2 Address Resolution The first part of this section describes the role of MPEG-2 signaling to identify streams (TS Logical Channels [RFC4259]) within the L2 infrastructure. The MPEG-2 TS in ISO 13818-1 [ISO-MPEG2] identifies the existence and format of a stream, using a combination of two PSI tables: the Programme Association Table (PAT) and entries in the program element loop of a Programme Map Table (PMT). PMT Tables are sent infrequently, and are typically small in size. The PAT is sent using the well-known PID value of 0X000. This table provides the correspondence between a program_number and a PID value. (The program_number is the numeric label associated with a program.) Each program in the Table is associated with a specific PID value, used to identify a TS. The identified TS is used to send the PMT, which associates a set of PID values with the individual components of the programme. This approach de-references the PID values when the MPEG- 2 Network includes multiplexors or re-multiplexors that renumber the PID values of the TS Logical Channels that they process. In addition to signaling the Receiver with the PID value assigned to a stream, PMT entries indicate the presence of Streams using ULE and MPE to the variety devices that may operate in the MPEG-2 transmission network (multiplexors, remultiplexors, rate shapers, advertisement insertion equipment, etc). A multiplexor or remultiplexor may also change the PID values associated with a Stream during the multiplexing process, the new value being reflected in an updated PMT. TS Packets that carry a PID value that is not associated with a PMT entry (an orphan PID), may, and usually will, be dropped by ISO 13818-1 compliant L2 equipment, resulting in the TS Logical Channel not being forwarded across the transmission network. In networks that do not employ any intermediate devices (e.g. scenarios C,E,F of [RFC4259]), or where devices have other means to determine the set of PID values in use, the PMT table may still be sent (but is not required for this purpose). Although the basic PMT information may be used to identify the existence of IP traffic, it does not associate a Stream with an IP prefix/address. The remainder of the section describes IP addresses resolution mechanisms relating to MPEG-2. 4.1 Static configuration. The static mapping option, where IP addresses or flows are statically mapped to specific PIDs is the equivalent to signaling "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. Expires June 2006 [page 13] INTERNET DRAFT AR for IP over MPEG-2 networks Feb 2006 A single "well-known" PID is a specialisation of this. This scheme is used by current DOCSIS cable modems [DOCSIS], where all IP traffic is placed into the specified TS stream. Section, or MAC, filtering may be used to differentiate subnetworks. 4.1.1 MPEG-2 Cable Networks Cable networks use a different transmission schemes for downstream, (head-end to cable modem) and upstream (cable modem to head-end) transmission. The information is sent (on the downstream) to the cable modems as IP/Ethernet packets encapsulated in MPEG-2 TS Packets sent on a single well-known TS Logical Channel (PID). There is no use of in- band signaling tables. On the upstream, the common approach is to use Ethernet framing, rather than IP/Ethernet over MPEG-2, although other proprietary schemes also continue to be used. Until the deployment of DOCSIS and EuroDOCSIS, most address resolution schemes for IP traffic in cable networks were proprietary, and did not usually employ a table-based address resolution method. Proprietary methods continue to be used in some cases where cable modems require interaction. In this case, equipment at the head-end may act as gateways between the cable modem and the Internet. These gateways receive L2 information and allocate an IP address. DOCSIS uses DHCP for IP client configuration. The Cable Modem Terminal System (CMTS) provides a DHCP server that allocates IP addresses to DOCSIS cable modems. The MPEG-2 Transmission Network provides a L2 bridged network to the cable modem. This usually acts as a DHCP Relay for IP devices [RFC2131, RFC3256]. Issues in deployment of IPv6 are described in [ID-V6OPS-DEPLOY]. 4.2 MPEG-2 Table-Based Address Resolution The information about the ser if MPEG-2 Transport Streams carried over a TS Multiplex can be distributed can be distributed via SI/PSI Tables, which are usually sent periodically (section 4). This design requires access to and processing of the SI Table information by each Receiver [ETSI-SI, ETSI-SI1]. This scheme reflects the complexity of delivering and co-ordinating the various Transport Streams associated with multimedia TV. A TS Multiplex may provide AR information for IP services by integrating additional information into the existing control tables or by transmitting additional SI Tables that are specific to the IP service. Examples of MPEG-2 Table usage to allow an MPEG-2 Receiver to identify the appropriate PID and multiplex associated with a specific IP address include: Expires June 2006 [page 14] INTERNET DRAFT AR for IP over MPEG-2 networks Feb 2006 (i) IP/MAC Notification Table (INT) in the DVB Data standard [ETSI-DAT]. This provides uni-directional address resolution of IPv4/IPv6 multicast addresses to an 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 an MPEG-2 TS. The MMT and AIT are used for specific applications. The INT [DVB- DAT] is a more general DVB method, that supports MAC, IPv4, and IPv6 AR when used in combination with the other MPEG-2 tables (see section 4). 4.2.1 IP/MAC Notification Table (INT) and its usage The INT provides a method for carrying information about the location of IP/L2 flows within a DVB network. A Platform_ID, identifies the addressing scope for a set of IP/L2 streams and/or Receivers. A Platform may span several Transport Streams within one or multiple TS Multiplexes and represents a single IP network with a harmonized address space (scope). This allows for the coexistence of several independent IP/MAC address scopes within an MPEG-2 Network. The INT allows both fully-specified IP addresses and prefix matching, to reduce the size of table (and hence enhance signaling efficiency). An IPv4/IPv6 "subnet mask" may be specified in full form or using a slash notation (e.g. /127). IP multicast addresses can be specified with or without a source (address or range), although if a source address is specified, then only the slash notation may be used for prefixes. In addition to identification and security descriptors, the following descriptors are defined for address binding in INT tables: (i) target_MAC_address_descriptor: The descriptor used to describe a single or set of MAC addresses (and their mask). (ii) target_MAC_address_range_descriptor: May be used to set filters. (iii) target_IP_address_descriptor: The descriptor describing a single or set of IPv4 unicast or multicast addresses (and their mask). (iv) target_IP_slash_descriptor: Allows definition and announcement of an IPv4 prefix. (v) target_IP_source_slash_descriptor: Uses source and destination Expires June 2006 [page 15] INTERNET DRAFT AR for IP over MPEG-2 networks Feb 2006 addresses to target a single or set of systems. (vi) IP/MAC stream_location_descriptor: This descriptor locates an 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 The ISP_access_mode_descriptor allows specification of a second address descriptor to access an ISP via an alternative non-DVB (possibly non-IP) network. The INT provides a set of descriptors to specify addressing in a DVB network. One key benefit is that the approach follows the MPEG-2 signaling methods (section 4) and is integrated with the other signaling information. This allows the INT to operate in the presence of (re)multiplexors [RFC4259] and to refer to PID values that are carried within a number of different TS Multiplexes. This makes it well-suited to a Broadcast TV Scenario [RFC4259]. The principle drawback is a need for a Encapsulator to introduce associated PSI/SI MPEG-2 control information. This control information needs to be processed at a Receiver. This requires access to information below the IP layer. The position of this processing within the protocol stack makes it hard to associate the results with IP Policy, management and security functions. The use of centralized management prevents the implementation of a more dynamic scheme. This method is currently specified for Multi- Protocol Encapsulation (MPE) [ETSI-DAT]. 4.2.2 Multicast Mapping Table (MMT) and its usage The Multicast Mapping Table (MMT) is carried in an MPEG-2 control table that associates a set of multicast addresses with the corresponding PID values. This table allows a DVB-RCS Forward Link Subsystem (FLSS) to specify the mapping of IPv4 addresses to PID values within a specific TS Multiplex. Receivers (DVB-RCS Return Channel Satellite Terminals, RCSTs) may use this table to determine the PID values associated with an IP multicast flow that it requires to receive. The MMT is not currently a part of the DVB-RCS specification. 4.2.3 Application Information Table (AIT) and its usage The DVB Multimedia Home Platform (MHP) specification [ETSI-MHP] does not define a specific AR function. However, an Application Information Table (AIT) is defined that allows MHP Receivers to Expires June 2006 [page 16] INTERNET DRAFT AR for IP over MPEG-2 networks Feb 2006 receive a variety of control information. The AIT uses a DSMCC format table providing information about data broadcasts, the required activation state of applications carried by a broadcast stream, etc. This information allows a broadcaster to request that a Receiver change the activation state of an application, and to direct applications to receive specific multicast packet flows (using IPv4 or IPv6 descriptors). In MHP, AR is not seen as a specific function, but as a part of a wider configuration and control function. 4.2.4 Address Resolution in ATSC ATSC defines a system that allows transmission of IP packets within an MPEG-2 network. An MPEG-2 Program (defined by the PMT) may contain one or more applications [ATSC-A90] that include IP Multicast streams [ATSC-A92]. IP Multicast data are signaled in the PMT using a stream_type indicator equal to 0x0D. A MAC address list descriptor [SCTE-1] may also be included in the PMT. The approach focuses on applications that serve the transmission network. A method is defined that binds the IP Multicast media streams and the corresponding SDP announcement streams to particular MPEG-2 Program Elements by using the MPEG-2 SI tables. Each application constitutes an independent network. The MPEG-2 Network boundaries establish an IP addressing scope. 4.2.5 Comparison of SI/PSI table approaches The MPEG-2 methods based on SI/PSI meet the specified requirements of the groups that created them and all have their strength: the INT in terms of flexibility and extensibility, the MMT in its simplicity, the AIT in its extensibility. However, they exhibit scalability constraints, represent technology specific solutions and do not fully adopt IP-centric approaches that would enable easier use of the MPEG-2 bearer as a link technology within the wider Internet. 4.3 IP-based resolution of TS Logical Channels As MPEG-2 Networks evolve to become multi-service networks, the use of IP protocols is becoming more prevalent. Most MPEG-2 Networks now use some IP protocols for operations, control and data delivery, address resolution information could also be sent using IP transport. There is an opportunity to define an IP-level method that could use an IP multicast protocol over a well-known IP multicast address. The advantages of using an IP-based address resolution for Transport Streams include: (i) Simplicity: Expires June 2006 [page 17] INTERNET DRAFT AR for IP over MPEG-2 networks Feb 2006 The AR mechanism does not require interpretation of Layer 2 tables; this is an advantage especially in the growing market share for home network and audio video networked entities. (ii) Uniformity: An IP-based protocol can provide a common method across different network scenarios for IP/MAC address mappings to TS Logical Channels (PID values). (iii) Extensibility: IP-based AR mechanisms allow an independent evolution of the AR protocol. This includes dynamic methods to request address resolution and the ability to include other L2 information (e.g. Encryption keys). (iv) Integration The information exchanged by IP-based AR protocols can easily be integrated as a a part of the IP network layer, simplifying support for AAA, policy, OAM, mobility, configuration control, etc. that combine AR with security. The drawbacks of an IP-based method include: (i) It can not operate over an MPEG-2 Network that uses MPEG-2 remultiplexors [RFC4259] that modify the PID values of the TS Logical Channels during the multiplexing operation. This makes the method unsuitable for use in deployed broadcast TV networks [RFC4259]. (ii) IP-based methods can introduce concerns about the integrity of the information and authentication of the sender [RFC4259]. (These concerns are also applicable to MPEG-2 Table methods, but in this case the information is confined to the L2 network, or parts of the network where gateway devices isolate the MPEG-2 devices from the larger Internet creating virtual MPEG-2 private networks.) IP-based solutions should therefore implement security mechanisms that may be used to authenticate the sender and verify the integrity of the AR information, as a part of a larger security framework. 4.3.1 IP-based multicast resolution of TS Logical Channels Address resolution must also be performed to associate the IP multicast Group Destination Address with an MPEG-2 layer TS Logical Channel (PID) and TS Multiplex. Solutions have been described in 4.2 that perform this below the IP layer using MPEG-2 Tables. Such methods currently perform a direct mapping (where a single address or set of addresses are associated with a specific PID value). An IP-level method may use an IP multicast protocol running over a well-known (or discovered) IP multicast address. Scalability is an important feature of any multicast AR protocol. Methods that employ Expires June 2006 [page 18] INTERNET DRAFT AR for IP over MPEG-2 networks Feb 2006 prefix matching (e.g. where a range of source/destination addresses are matched to a single entry are desirable), as also are methods that allow a range of IP addresses to mapped to a set of TS Logical Channels (similar to the mapping of IP Group Destination Addresses to Ethernet MAC addresses). Expires June 2006 [page 19] INTERNET DRAFT AR for IP over MPEG-2 networks Feb 2006 5. Mapping IP addresses to NPA/MAC addresses This section reviews IETF protocols that may be used to assign and manage the mapping of IP addresses to/from NPA/MAC addresses over MPEG-2 Networks. An IP Encapsulator requires AR information to select an appropriate MAC/NPA address in the SNDU header [RFC 4259] (see also section 6). The information to complete this header may be taken directly from a neighbour/arp cache, or may require the Encapsulator to retrieve the information using an AR protocol. The way in which this information is collected will depend upon whether the Encapsulator functions as a Router (at L3) or a Bridge (at L2). Two IETF-defined protocols for mapping IP addresses to NPA/MAC addresses are the Address Resolution Protocol, ARP [RFC-ARP], and the Neighbor Discovery Protocol, ND [RFC2461], for IPv4 and IPv6 respectively. Both protocols are normally used in a bi-directional mode, although both also permit unsolicited transmission of mappings. The mapping defined in [RFC4624] can result in a large number of active MAC multicast addresses (at least one per end host). ARP requires support for L2 broadcast packets. A large number of Receivers can lead to a proportional increase in ARP traffic, a concern for bandwidth-limited networks. Transmission delay can also impact protocol performance. ARP also has a number of security vulnerabilities. ARP spoofing is where a system can be fooled by a rogue device that sends a fictitious ARP response that includes the IP address of a legitimate network system, and the MAC of a rogue system. This causes legitimate systems on the network to update their ARP tables with the false mapping and then send future packets to the rogue system instead of the legitimate system. Using this method, a rogue system can see (and modify) packets sent through the network. Secure ARP (SARP) uses a secure tunnel between each client and a server at a wireless access point or router [RFC2246]. The router ignores any ARP responses not associated with clients using the secure tunnels. Therefore, only legitimate ARP Responses are used for updating ARP tables. SARP requires the installation of software at each client. It suffers from the same scalability issues as the standard ARP. The ND protocol uses a set of IP multicast addresses. In large networks, many multicast addresses are used, but clients typically only listen to a restricted set of group destination addresses and little traffic is usually sent in each group. An AR multicast mechanism for MPEG-2 Networks therefore needs to be able to support this in a scalable manner. Expires June 2006 [page 20] INTERNET DRAFT AR for IP over MPEG-2 networks Feb 2006 A large number of ND Router Solicitation messages may cause a large demand for performing asymmetric operations. The base ND protocol limits the rate at which multicast responses to solicitations can be sent. The Secure Neighbor Discovery or SEND [RFC3917] was developed to address known security vulnerabilities in ND. It can also reduce the AR traffic compared to ND. SEND also does not impact the IPSec architecture and implementations, and provides improved support for security decisions based on application state. This allows co- existence of SEND and insecure ND on the same link. DHCP [RFC2131] may be used over MPEG-2 transmission networks. DHCP consists of two components: a protocol for delivering system- specific configuration parameters from a DHCP server to a DHCP client (e.g. default router, DNS server) and a mechanism for allocation of network addresses to systems. DHCP messages (e.g. DHCPDISCOVER, DHCPREQUEST, DHCPOFFER) may include options [RFC2132]. 5.1 Uni-directional links supporting uni-directional connectivity MPEG-2 Networks may provide a Uni-Directional broadcast Link (UDL), with no return path. Such links may be used for unicast applications that do not require a return path (e.g. based on UDP), but are more commonly used for IP multicast content distribution. /-----\ MPEG-2 Uplink /MPEG-2 \ ###################( Network ) # \ / +----#------+ \--.--/ | Network | | | Provider + v MPEG-2 downlink +-----------+ | +-----v------+ | MPEG-2 | | Receiver | +------------+ Figure 1: Uni-directional connectivity Although ARP and ND may both operate in an unsolicited/promiscuous mode where they advertise local address binding information to the remote nodes, this does not provide an appropriate method to resolve the remote (destination) address in a uni-directional environment. To perform this task, these protocols require bi-directional L2/L3 connectivity. Unidirectional links therefore require a separate out-of-band configuration method to establish the appropriate AR information at Expires June 2006 [page 21] INTERNET DRAFT AR for IP over MPEG-2 networks Feb 2006 the sender and clients. ULE [RFC4326] defines a mode in which the NPA/MAC address is omitted from the SNDU. In some scenarios, this may relieve an Encapsulator of the need for L2 AR. 5.2 Uni-directional links with bi-directional connectivity Bi-directional connectivity may be realised using a uni-directional link in combination with another network path. Common combinations are a Feed link using MPEG-2 satellite transmission and a return link using terrestrial network infrastructure. This topology is often known as a Hybrid network, and has asymmetric network routing. /-----\ MPEG-2 uplink /MPEG-2 \ ###################( Network ) # \ / +----#------+ \--.--/ | Network | | | Provider +-<-+ v MPEG-2 downlink +-----------+ | | | +-----v------+ +--<<--+ MPEG-2 | Return | Receiver | Path +------------+ Figure 2: Bi-directional connectivity The Uni-Directional Link Routing, UDLR [RFC3077] protocol may be used to overcome issues associated with asymmetric routing. It hides the uni-directional routing is hidden from the IP and upper layer protocols, by providing a L2 tunneling mechanism that emulates a bi- directional broadcast link at L2. A network using UDLR has a topology where a Feed Router and all Receivers form a logical Local Area Network. Encapsulating L2 frames allows them to be sent through an Internet Path. Since many uni-directional links employ wireless technology for the forward (Feed) link (e.g., [ETSI-DAT]), there may be an appreciable cost associated with forwarding traffic on the Feed link. Therefore, it is often desirable to prevent forwarding unnecessary traffic, (e.g. for multicast this implies control of which groups are forwarded). The implications of forwarding in the return direction must also be considered (e.g., asymmetric capacity and loss [RFC3449]). This suggests a need to minimise the volume and frequency of control messages. Three different AR cases may be identified: (i) A Feed Router needs a Receiver NPA/MAC address. This occurs when a Feed Router sends an IP packet using the Feed UDL to a Receiver whose NPA/MAC address is unknown. In IPv4, the Feed Expires June 2006 [page 22] INTERNET DRAFT AR for IP over MPEG-2 networks Feb 2006 Router sends an ARP REQUEST with the IP address of the Receiver. The Receiver that recognises its IP address replies with an ARP RESPONSE to the NPA/MAC address of the Feed Router (e.g. using a UDLR tunnel). The Feed Router may then address IP packets to the unicast NPA/MAC address associated with the Receiver. (The ULE packet format also permits packets to be sent without specifying a NPA/MAC address, where this is desirable (section 6.1, 6.5).) (ii) A Receiver needs the Feed Router NPA/MAC address. This occurs when a Receiver sends an IP packet to a Feed Router whose NPA/MAC address is unknown. In IPv4, the Receiver sends an ARP REQUEST with the IP address of the Feed Router (e.g. using a UDLR tunnel). The Feed Router replies with an ARP RESPONSE using the Feed UDL. The Receiver may then address IP packets to the NPA/MAC address of the recipient. (iii) A Receiver needs another Receiver NPA/MAC address. This occurs when a Receiver sends an IP packet to another Receiver whose NPA/MAC address is unknown. In IPv4, the Receiver sends an ARP REQUEST with the IP address of the remote Receiver (e.g. using a UDLR tunnel to the Feed Router). The request is forwarded over the Feed UDL. The target Receiver replies with an ARP RESPONSE (e.g. using a UDLR tunnel). The Feed Router forwards the response on the UDL. The Receiver may then address IP packets to the NPA/MAC address of the recipient. These 3 cases allow any system connected to the UDL to obtain the NPA/MAC address of any other system. Similar exchanges may be performed using the ND protocol for IPv6. A long round trip delay (via the UDL and UDLR tunnel) impacts the performance of reactive address resolution procedures. In contrast to Ethernet, during the interval when resolution is taking place, many IP packets may be received that are addressed to the AR Target address. The arp specification allows the interface to discard these packets while awaiting the response to the resolution request. An appropriately sized buffer would however prevent this loss. The time to complete address resolution may also be reduced by use of an AR Server at the Feed, which may learn MAC addresses from ARP RESPONSES and would (proxy) publish them in response to Receiver ARP REQUESTS. Using DHCP with UDLR requires prior establishment of the L2 connectivity to a DHCP server. Therefore, when UDLR networks use DHCP, it can be beneficial to tune the DTCP HELLO message periodicity. The configuration of DHCP Servers and Clients should take into account the link round trip delay. A larger delay may make it desirable to tune the DHCP lease duration and the size of address pool. Appropriate timer values should also be selected: the DHCP messages retransmission timeout, and the maximum delay that a DHCP Expires June 2006 [page 23] INTERNET DRAFT AR for IP over MPEG-2 networks Feb 2006 Server waits before deciding that the absence of an ICMP echo response means that the relevant address is free. DHCP Clients may retransmit DHCP messages if they do not receive a response. Some client implementations specify a timeout for the DHCPDISCOVER message that is small (e.g. suited to Ethernet delay) providing insufficient time for a DHCP Server to respond to a DHCPDISCOVER retransmission before expiry of the check on the lease availability (by an ICMP echo request), resulting in potential address conflict. 5.3 Bi-directional Links Bi-directional IP networks can be and are constructed by a combination of two MPEG-2 transmission links. The combined link functions as a full duplex interface. Examples of this use include two-way DVB-S satellite links and the DVB-RCS system. 5.4 IP Multicast AR This section describes the case where the destination network layer address is an IP multicast Group Destination Address. In MPE [DVB-DAT], the mapping of IP multicast addresses to MAC/NPA addresses follows normal practice for IEEE MAC Addresses when using IPv4 and IPv6. (A variant of DVB (DVB-H) uses a modified MAC header [DVB_DAT]). In ULE [ID-RFC 4326], the L2 NPA address is optional, and is not necessarily required when the Receiver is able to perform efficient L3 multicast address filtering. When present, it follows the mapping of MPE and many other L2 link technologies. Expires June 2006 [page 24] INTERNET DRAFT AR for IP over MPEG-2 networks Feb 2006 6. Link Layer Support This section considers link-layer (L2) support for address resolution. It considers two issues: One is the code-point used at L2 and the other is the efficiency of encapsulation for transmission required to support the AR method. The table below summarises the options for both MPE [ETSI-DAT] and ULE [RFC4326] encapsulations. +-------------------------------+--------+----------------------+ | | PDU |L2 Frame Header Fields| | L2 Encapsulation |overhead+----------------------+ | |[bytes] |src mac|dst mac| type | +-------------------------------+--------+-------+-------+------+ |6.1 ULE without dst MAC address| 8 | - | - | x | |6.2 ULE with dst MAC address | 14 | - | x | x | |6.3 MPE without LLC/SNAP | 16 | - | x | - | |6.4 MPE with LLC/SNAP | 24 | - | x | x | |6.5 ULE with Bridging extension| 22 | x | x | x | |6.6 ULE with Bridging & NPA | 28 | x | x | x | |6.7 MPE+LLC/SNAP+Bridging | 38 | x | x | x | +-------------------------------+--------+-------+-------+------+ Table of L2 support and overhead (x=supported, -=not supported) The remainder of the section describes IETF-specified AR methods for use with these encapsulation formats. 6.1 ULE without a destination MAC/NPA address (D=1) The ULE encapsulation supports a mode (D=1) where the NPA/MAC address is not present in the encapsulated frame. This mode may be used with both IPv4 and IPv6. When used, the Receiver is expected to perform network-layer filtering of packets based on their IP destination address. Encapsulators must ensure that packets are associated with a TS Logical Channel (PID value) that uniquely identifies the intended recipient [RFC4326]. This requires careful consideration of the network topology when a receiver acts is, or delivers data to an IP router (a simple case where this is permitted is the connection of stub networks that have no connectivity to other networks). Since there is no MAC/NPA address in the SNDU, ARP and NDP are not required. IPv6 systems can automatically configure their IPv6 network address based upon a local MAC address [RFC2462]. To use auto-configuration, the IP driver at the Receiver may need to access the MAC/NPA address of the receiving interface, even though this value is not being used to filter received SNDUs. Expires June 2006 [page 25] INTERNET DRAFT AR for IP over MPEG-2 networks Feb 2006 6.2 ULE with a destination NPA/MAC address (D=0) The IPv4 Address Resolution Protocol (ARP) [RFC826] uses an IANA- assigned EtherType and may be used over ULE [RFC4326]. Although no MAC source address is present in the ULE SNDU, the ARP protocol still communicates the source MAC address in the ARP record payload of any query messages that it generates. The IPv6 ND protocol may be used. The protocol uses a block of IPv6 addresses, which need to be carried by the L2 network. The protocol does not require specification of a MAC source address, although this is required for a node to participate in Duplicate Address Detection (DAD) [RFC2462]. 6.3 MPE without LLC/SNAP Encapsulation This is the default (and sometimes only) mode specified by most MPE Encapsulators. MPE does not provide an IANA-assigned EtherType and therefore can not support the Address Resolution Protocol (ARP) [RFC826]. IPv6 is not supported in this encapsulation format, and therefore it is not appropriate to consider the ND protocol. 6.4 MPE with LLC/SNAP Encapsulation The LLC/SNAP format of MPE provides an IANA-assigned EtherType and therefore may support the ARP [RFC826]. There is no specification to define how this is performed. No MAC source address is present in the SNDU, although the protocol still communicates the source MAC address in the ARP record payload of any query messages that it generates. The IPv6 ND protocol may be used with The LLC/SNAP format of MPE. This requires specific multicast address to be carried by the L2 network. A MAC source address is required for a node to participate in DAD. 6.5 ULE with Bridging Header Extension (D=1) The ULE encapsulation supports a bridging extension header that supplies both a source and destination MAC address. This can be used without an NPA address (D=1). When no other Extension Headers are present, the MAC destination address has the same position in the ULE SNDU as that used for an NPA destination address. The Receiver may optionally be configured so that MAC destination address value is identical to the Receiver NPA address. At the Encapsulator, the ULE NPA/MAC destination address is determined by a L2 forwarding decision. Received frames may be Expires June 2006 [page 26] INTERNET DRAFT AR for IP over MPEG-2 networks Feb 2006 forwarded or may be addressed to the Receiver itself. As in other L2 LANs, the Receiver may choose to filter received frames based on a configured MAC destination address filter. ARP and ND messages may be carried within a PDU that is bridged by this encapsulation format. 6.6 ULE with Bridging Header Extension and NPA Address (D=0) The combination of a NPA address (D=0) and a bridging extension header are allowed in ULE. This SNDU format supplies both a source and destination MAC address and a NPA destination address (i.e. Receiver NPA/MAC address). At the Encapsulator, the value of the ULE NPA/MAC destination address is determined by a L2 forwarding decision. At the Receiver, frames may be forwarded or may be addressed to the Receiver itself. As in other L2 LANs, the Receiver may choose to filter received frames based on a configured MAC destination address filter. ARP and ND messages may be carried within a PDU that is bridged by this encapsulation format. 6.7 MPE+LLC/SNAP+Bridging The LLC/SNAP format MPE frames may optionally support an IEEE bridging header [LLC]. This header supplies both a source and destination MAC address, at the expense of larger encapsulation overhead. The format defines two MAC destination addresses, one associated with the MPE SNDU (i.e. Receiver MAC address) and one with the bridged MAC frame (i.e. the MAC address of the intended recipient in the remote LAN). At the Encapsulator, the MPE MAC destination address is determined by a L2 forwarding decision. As in other L2 LANs, the Receiver may choose to filter received frames based on a configured MAC destination address filter. At the Encapsulator, the MPE MAC destination address is determined by a L2 forwarding decision. A Receiver may forward frames or they may be addressed to the Receiver itself. As in other L2 LANs, the Receiver may choose to filter received frames based on a configured MAC destination address filter. ARP and ND messages may be carried within a PDU that is bridged by this encapsulation format. The MPE MAC destination address is determined by a L2 forwarding decision. Expires June 2006 [page 27] INTERNET DRAFT AR for IP over MPEG-2 networks Feb 2006 7. Conclusions This document has described addressing and address resolution issues for the using IP protocols over MPEG-2 transmission networks using both wired and wireless technologies. A number of specific IETF protocols are discussed along with their expected behaviour over MPEG-2 transmission networks. Recommendations for their usage are provided. In MPEG-2 Networks, a static binding can be configured for IP addresses and PIDs (as in some cable networks). In broadcast networks, this information is normally provided by the Encapsulator/Multiplexor and carried in tables (e.g. AIT in MHP, the IP Notification Table, INT, of DVB and the DVB-RCS Multicast Mapping Table, MMT). This document has reviewed the status of these current address resolution mechanisms in MPEG-2 transmission networks, defined their usage and provided information to identify what would be needed to improve their support for IP protocols. 8. Security Considerations L2 signaling in MPEG-2 transmission networks is provided by (periodic) broadcasting information in the control plane using PSI/SI tables. A loss or modification of the SI information may result in an inability to identify the TS Logical Channel (PID) that is used for a service. This will prevent reception of the intended IP packet stream. The normal security issues relating to the use of wireless links for transmission of Internet traffic should be considered. It is recommended that future AR protocols support authentication of the source of AR messages and the integrity of the AR information, this avoids known security vulnerabilities resulting from insertion of unauthorised AR messages within a L2 infrastructure. Readers are also referred to the known security issues associated with ARP [RFC826] and ND [RFC2461]. 9. Acknowledgments The authors wish to thank Rod Walsh, Jun Takei, Michael Mercurio and the ipdvb WG members for their inputs. The authors also acknowledge the support of the European Space Agency, Martin Stiemerling, for contributions of scenarios and configuration, and Hidetaka Izumiyama for his contributions on UDLR and IPv6 issues. A number of issues discussed in the UDLR working group (summarised in draft-ietf-udlr- experiments-01.txt) have also provided valuable inputs to this document. Expires June 2006 [page 28] INTERNET DRAFT AR for IP over MPEG-2 networks Feb 2006 10. References 10.1 Normative References [ETSI-DAT] EN 301 192, "Specifications for Data Broadcasting", v1.3.1, European Telecommunications Standards Institute (ETSI), May 2003. [ETSI-MHP] TS 101 812, "Digital Video Broadcasting (DVB); Multimedia Home Platform (MHP) Specification", v1.2.1, European Telecommunications Standards Institute (ETSI), June 2002. [ETSI-SI] EN 300 468, "Digital Video Broadcasting (DVB); Specification for Service Information (SI) in DVB systems", European Telecommunications Standards Institute (ETSI). [ISO-MPEG2] ISO/IEC IS 13818-1, "Information technology -- Generic coding of moving pictures and associated audio information -- Part 1: Systems", International Standards Organisation (ISO), 2000. [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. [RFC2246] T. Dierks, C. Allen, The TLS Protocol Version 1.0, RFC2246, January 1999. [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", RFC 2464, December 1998. [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [RFC3077] Duros, E., Dabbous, W., Izumiyama, H., Fujii, N., and Y. Zhang, "A Link-Layer Tunneling Mechanism for Unidirectional Links", RFC 3077, March 2001. 10.2 Informative References [ATSC] A/53C, "ATSC Digital Television Standard", Advanced Television Systems Committee (ATSC), Doc. A/53C, 2004. [ATSC-G] A/54A, "Guide to the use of the ATSC Digital Television Standard", Advanced Television Systems Committee (ATSC), Doc. A/54A, 2003. Expires June 2006 [page 29] INTERNET DRAFT AR for IP over MPEG-2 networks Feb 2006 [ATSC-A90] A/90, "ATSC Data Broadcast Standard", Advanced Television Systems Committee (ATSC), Doc. A/90, 2000. [ATSC-A92] A/92, "Delivery of IP Multicast Sessions over ATSC Data Broadcast", Advanced Television Systems Committee (ATSC), Doc. A/92, 2002. [DOCSIS] Data-Over-Cable Service Interface Specifications, DOCSIS 2.0, Radio Frequency Interface Specification, CableLabs, document CM-SP-RFIv2.0-I10-051209, 2005. [ETSI-SI1] TR 101 162, "Digital Video Broadcasting (DVB); Allocation of Service Information (SI) codes for DVB systems", 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). [ID-V6OPS-DEPLOY] Asadullah, S., Ahmed, A., Popoviciu, C., "ISP IPv6 Deployment Scenarios in Broadband Access Networks" draft-ietf-v6ops-bb-deployment-scenarios-04.txt, Work in Progress, v6ops WG. [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [RFC2362] Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering, S., Handley, M., Jacobson, V., Liu, C., Sharma, P., and L. Wei, "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification", RFC 2362, June 1998. [RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC 2365, July 1998. [RFC2375] Hinden, R. and S. Deering, "IPv6 Multicast Address Assignments", RFC 2375, July 1998. [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. [RFC3256] Jones, D. and R. Woundy, "The DOCSIS (Data-Over-Cable Service Interface Specifications) Device Class DHCP (Dynamic Host Configuration Protocol) Relay Agent Information Sub-option", RFC 3256, April 2002. [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002. Expires June 2006 [page 30] INTERNET DRAFT AR for IP over MPEG-2 networks Feb 2006 [RFC3449] Balakrishnan, H., Padmanabhan, V., Fairhurst, G., and M. Sooriyabandara, "TCP Performance Implications of Network Path Asymmetry", BCP 69, RFC 3449, December 2002. [RFC3451] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., Handley, M., and J. Crowcroft, "Layered Coding Transport (LCT) Building Block", RFC 3451, December 2002. [RFC3738] Luby, M. and V. Goyal, "Wave and Equation Based Rate Control (WEBRC) Building Block", RFC 3738, April 2004. [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. [RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. Wood, "Advice for Internet Subnetwork Designers", BCP 89, RFC 3819, July 2004. [RFC4259] Montpetit, M.J., Fairhurst, G., Clausen, H.D., Collini-Nocker, B., and H. Linder, "Architecture for IP transport over MPEG-2 Networks". [RFC4326] Fairhurst, G., Collini-Nocker, B., "Unidirectional Lightweight Encapsulation (ULE) for transmission of IP datagrams over an MPEG-2 Transport Stream". [SCTE-1] "IP Multicast for Digital MPEG Networks", SCTE DVS 311r6, March 2002. 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 Marie-JosČ Montpetit Motorola Connected Home Solutions Advanced Technology 55 Hayden Avenue , 3rd Floor Lexington Massachusetts 02421 USA EMail: mmontpetit@motorola.com Expires June 2006 [page 31] INTERNET DRAFT AR for IP over MPEG-2 networks Feb 2006 12. IPR Notices 12.1 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. 12.2 Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 13. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. 14. IANA Considerations This document does not define a protocol or protocol extension. No action is required by the IANA. Expires June 2006 [page 32] INTERNET DRAFT AR for IP over MPEG-2 networks Feb 2006 APPENDIX: Candidate IP-based L2 AR Protocols This appendix contains a list of candidate protocols that could be used to define "above IP" AR. None of these protocols currently support the AR methods required for MPEG-2 Transmission Networks. Specifically they do not all support: (i) Resolution of Addresses to TS Logical Channels (ii) Resolution of multiple addresses in a single AR update message (table-based). (iii) Multicast transport. Candidate protocols include: ARP - IPv4 only. - No table support - Support for versioning within current implementations not clear. - Broadcast mode has drawbacks. - No obvious support for scoping to multiple addressing domains. ND - IPv6 only. - No table support - Use multicast address. - No obvious support for scoping to multiple addressing domains. DTCP [RFC3077] - IPv4 and IPv6. - Table support seems natural. - Uses multicast address. - Need to consider scoping for multiple addressing domains. - Not really an IP AR protocol - Already used on some (UDLR) links - and this new use seems complementary. AR/IP - IPv4 and IPv6. - Based on UDP or at network-layer. - Could use multicast address. - Could use some SIP-based signaling - Table support possible. - New protocol format. - Could add scoping for multiple addressing domains. XML/SIP/IP - IPv4 and IPv6. - Based on UDP or at network-layer or an XML transport/SIP for compatibility with DVB and 3GPP/3GPP2. - Could use multicast address. - Table support seems natural. - New protocol format. Expires June 2006 [page 33] INTERNET DRAFT AR for IP over MPEG-2 networks Feb 2006 - Could add scoping for multiple addressing domains. - Extensible/flexible to other configuration data (if required). - Compression of XML required to achieve efficiency comparable with other methods. Expires June 2006 [page 34] INTERNET DRAFT AR for IP over MPEG-2 networks Feb 2006 >>> NOTE to RFC Editor: Please remove this appendix prior to publication] Document History -00 This draft is intended as a study item for proposed future work by the IETF in this area. -01 Review of initial content, major edit and refinement of concepts -02 fairly important review; took out all new protocol reference; added one author; added contribution on real implementation -02 Added content to respond to 61st IETF comments; refined ID goals; rewrote section 4.2 and 4.3; added cable information. -03 Major reorganise to align with Charter, and clearly identify IP issues. -04 restructured the draft (major rewrite) and added discussion of arp and ND related to specific cases for use. WG -00 Reformatted as WG Draft. Added inputs from UDLR working group on UDLR, DHCP, etc. WG-01 This rev. included a number of changes: * Added the case for large no. of groups/dynamic join to 3.2 * ISO MPEG-2 table requirements added to section 4, following discussion on the list. * Added AR Authentication note to security considerations. [>>> NOTE to RFC Editor: End of appendix] WG-02 * Major editorial work to bring this up tro DRAFT RFC format * Removed duplication of scoping discussion with ipdvb-arch * Reworded UDLR section to separate protocol issues from UDLR specifics. * Added SI security discussion. * Minor corrections * Added text from A/92 on scoping. * Aligned definitions with ipdvb-arch. * Fixed Reference format * Removed markers for additional contributions * No contributions received on PPPoE (removed). <<<<< Expires June 2006 [page 35]