Tech-invite3GPPspaceIETF RFCsSIP
in Index   Prev   Next

RFC 4947

Address Resolution Mechanisms for IP Datagrams over MPEG-2 Networks

Pages: 41
Part 1 of 2 – Pages 1 to 21
None   None   Next

Top   ToC   RFC4947 - Page 1
Network Working Group                                       G. Fairhurst
Request for Comments: 4947                        University of Aberdeen
Category: Informational                                  M.-J. Montpetit
                                       Motorola Connected Home Solutions
                                                               July 2007

  Address Resolution Mechanisms for IP Datagrams over MPEG-2 Networks

Status of This Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The IETF Trust (2007).


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 Neighbor 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. This document reviews current methods appropriate to a range of technologies (such as DVB (Digital Video Broadcasting), ATSC (Advanced Television Systems Committee), DOCSIS (Data-Over-Cable Service Interface Specifications), and variants). It also describes the interaction with well-known protocols for address management including DHCP, ARP, and the ND protocol.
Top   ToC   RFC4947 - Page 2

Table of Contents

1. Introduction ....................................................3 1.1. Bridging and Routing .......................................4 2. Conventions Used in This Document ...............................7 3. Address Resolution Requirements ................................10 3.1. Unicast Support ...........................................12 3.2. Multicast Support .........................................12 4. MPEG-2 Address Resolution ......................................14 4.1. Static Configuration ......................................15 4.1.1. MPEG-2 Cable Networks ..............................15 4.2. MPEG-2 Table-Based Address Resolution .....................16 4.2.1. IP/MAC Notification Table (INT) and Its Usage ......17 4.2.2. Multicast Mapping Table (MMT) and Its Usage ........18 4.2.3. Application Information Table (AIT) and Its Usage ..18 4.2.4. Address Resolution in ATSC .........................19 4.2.5. Comparison of SI/PSI Table Approaches ..............19 4.3. IP-Based Address Resolution for TS Logical Channels .......19 5. Mapping IP Addresses to MAC/NPA Addresses ......................21 5.1. Unidirectional Links Supporting Unidirectional Connectivity ..............................................22 5.2. Unidirectional Links with Bidirectional Connectivity ......23 5.3. Bidirectional Links .......................................25 5.4. AR Server .................................................26 5.5. DHCP Tuning ...............................................27 5.6. IP Multicast AR ...........................................27 5.6.1. Multicast/Broadcast Addressing for UDLR ............28 6. Link Layer Support .............................................29 6.1. ULE without a Destination MAC/NPA Address (D=1) ...........30 6.2. ULE with a Destination MAC/NPA Address (D=0) ..............31 6.3. MPE without LLC/SNAP Encapsulation ........................31 6.4. MPE with LLC/SNAP Encapsulation ...........................31 6.5. ULE with Bridging Header Extension (D=1) ..................32 6.6. ULE with Bridging Header Extension and NPA Address (D=0) ..32 6.7. MPE with LLC/SNAP & Bridging ..............................33 7. Conclusions ....................................................33 8. Security Considerations ........................................34 9. Acknowledgments ................................................35 10. References ....................................................35 10.1. Normative References .....................................35 10.2. Informative References ...................................36
Top   ToC   RFC4947 - Page 3

1. Introduction

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 Neighbor Discovery (ND). Such address resolution complements the higher layer resource discovery tools that are used to advertise IP sessions. The document reviews current methods appropriate to a range of technologies (DVB, ATSC, DOCSIS, and variants). It also describes the interaction with well- known protocols for address management including DHCP, ARP, and the ND protocol. The MPEG-2 TS provides a time-division multiplexed (TDM) stream that may contain audio, video, and data information, including encapsulated IP Datagrams [RFC4259], defined in specification ISO/IEC 138181 [ISO-MPEG2]. Each Layer 2 (L2) 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 a L2 link supporting IP, 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 an AR function. In some AR schemes, the MPEG-2 TS address space is subdivided into logical contexts known as Platforms [ETSI-DAT]. Each Platform associates an IP service provider with a separate context that shares a common MPEG-2 TS (i.e., uses the same PID value). MPEG-2 Receivers may use a Network Point of Attachment (NPA) [RFC4259] to uniquely identify a 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 signalled by the AR procedure. Finally, address resolution could signal the format of the data being transmitted, for example, the encapsulation, with 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 arbitrarily
Top   ToC   RFC4947 - Page 4
   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 a significant path delay (satellite links, use of dial-up
   modem return, cellular return, etc.).  This higher delay may need to
   be accommodated by address resolution protocols that use this

1.1. Bridging and Routing

The following two figures illustrate the use of AR for a routed and a bridged subnetwork. Various other combinations of L2 and L3 forwarding may also be used over MPEG-2 links (including Receivers that are IP end hosts and end hosts directly connected to bridged LAN segments). Broadcast Link AR - - - - - - - - - | | \/ 1a 2b 2a +--------+ +--------+ ----+ R1 +----------+---+ R2 +---- +--------+ MPEG-2 | +--------+ Link | | +--------+ +---+ R3 +---- | +--------+ | | +--------+ +---+ R4 +---- | +--------+ | | Figure 1: A routed MPEG-2 link Figure 1 shows a routed MPEG-2 link feeding three downstream routers (R2-R4). AR takes place at the Encapsulator (R1) to identify each Receiver at Layer 2 within the IP subnetwork (R2, etc.). When considering unicast communication from R1 to R2, several L2 addresses are involved: 1a is the L2 (sending) interface address of R1 on the MPEG-2 link. 2b is the L2 (receiving) interface address of R2 on the MPEG-2 link. 2a is the L2 (sending) interface address of R2 on the next hop link.
Top   ToC   RFC4947 - Page 5
   AR for the MPEG-2 link allows R1 to determine the L2 address (2b)
   corresponding to the next hop Receiver, router R2.

   Figure 2 shows a bridged MPEG-2 link feeding three downstream bridges
   (B2-B4).  AR takes place at the Encapsulator (B1) to identify each
   Receiver at L2 (B2-B4).  AR also takes place across the IP subnetwork
   allowing the Feed router (R1) to identify the downstream Routers at
   Layer 2 (R2, etc.).  The Encapsulator associates a destination
   MAC/NPA address with each bridged PDU sent on an MPEG-2 link.  Two
   methods are defined by ULE (Unidirectional Lightweight Encapsulation)

   The simplest method uses the L2 address of the transmitted frame.
   This is the MAC address corresponding to the destination within the
   L2 subnetwork (the next hop router, 2b of R2).  This requires each
   Receiver (B2-B4) to associate the receiving MPEG-2 interface with the
   set of MAC addresses that exist on the L2 subnetworks that it feeds.
   Similar considerations apply when IP-based tunnels support L2
   services (including the use of UDLR (Unidirectional Links)

   It is also possible for a bridging Encapsulator (B1) to encapsulate a
   PDU with a link-specific header that also contains the MAC/NPA
   address associated with a Receiver L2 interface on the MPEG-2 link
   (Figure 2).  In this case, the destination MAC/NPA address of the
   encapsulated frame is set to the Receiver MAC/NPA address (y), rather
   than the address of the final L2 destination.  At a different level,
   an AR binding is also required for R1 to associate the destination L2
   address 2b with R2.  In a subnetwork using bridging, the systems R1
   and R2 will normally use standard IETF-defined AR mechanisms (e.g.,
   IPv4 Address Resolution Protocol (ARP) [RFC826] and the IPv6 Neighbor
   Discovery Protocol (ND) [RFC2461]) edge-to-edge across the IP
Top   ToC   RFC4947 - Page 6
                                Subnetwork AR
                      - - - - - - - - - - - - - - - -
                      |                             |

                      |        MPEG-2 Link AR       |
                             - - - - - - - - -
                      |      |               |      |
                      \/     \/
                      1a      x              y      2b        2a
             +--------+  +----+              +----+  +--------+
         ----+   R1   +--| B1 +----------+---+ B2 +--+   R2   +----
             +--------+  +----+ MPEG-2   |   +----+  +--------+
                                Link     |
                                         |   +----+
                                         +---+ B3 +--
                                         |   +----+
                                         |   +----+
                                         +---+ B4 +--
                                         |   +----+

                       Figure 2: A bridged MPEG-2 link

   Methods also exist to assign IP addresses to Receivers within a
   network (e.g., stateless autoconfiguration [RFC2461], DHCP [RFC2131],
   DHCPv6 [RFC3315], and stateless DHCPv6 [RFC3736]).  Receivers may
   also participate in the remote configuration of the L3 IP addresses
   used in connected equipment (e.g., using DHCP-Relay [RFC3046]).

   The remainder of this document describes current mechanisms and their
   use to associate an IP address with the corresponding TS Multiplex,
   PID value, the MAC/NPA address and/or Platform ID.  A range of
   approaches is described, including Layer 2 mechanisms (using MPEG-2
   SI tables), and protocols at the IP level (including ARP [RFC826] and
   ND [RFC2461]).  Interactions and dependencies between these
   mechanisms and the encapsulation methods are described.  The document
   does not propose or define a new protocol, but does provide guidance
   on issues that would need to be considered to supply IP-based address
Top   ToC   RFC4947 - Page 7

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-MPEG2]. b: bit. For example, one byte consists of 8-bits. B: Byte. Groups of bytes are represented in Internet byte order. DSM-CC: Digital Storage Media Command and Control [ISO-DSMCC]. A format for the transmission of data and control information carried in an MPEG-2 Private Section, defined by the ISO MPEG-2 standard. DVB: Digital Video Broadcasting [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 bidirectional IPv4/IPv6 service employing low-cost Receivers [ETSI-RCS]. DVB-S: Digital Video Broadcast for Satellite [ETSI-DVBS]. 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 unidirectional address resolution mechanism using SI and/or PSI Tables. L2: Layer 2, the link layer. L3: Layer 3, the IP network layer. MAC: Medium Access Control [IEEE-802.3]. A link layer protocol defined by the IEEE 802.3 standard (or by Ethernet v2). MAC Address: A 6-byte link layer address of the format described by the Ethernet IEEE 802 standard (see also NPA).
Top   ToC   RFC4947 - Page 8
   MAC Header: The link layer header of the IEEE 802.3 standard
   [IEEE-802.3] or Ethernet v2.  It consists of a 6-byte destination
   address, 6-byte source address, and 2 byte type field (see also NPA,
   LLC (Logical Link Control)).

   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
   [ETSI-RCS] defining an AR table that maps IPv4 multicast addresses to
   PID values).

   MPE: Multiprotocol Encapsulation [ETSI-DAT], [ATSC-A90].  A  method
   that encapsulates PDUs, forming a DSM-CC Table Section.  Each Section
   is sent in a series of TS Packets using a single Stream (TS Logical

   MPEG-2: A set of standards specified by the Motion Picture Experts
   Group (MPEG), and standardized by the International Standards
   Organization (ISO/IEC 113818-1) [ISO-MPEG2], and ITU-T (in H.220).

   NPA: Network Point of Attachment.  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 (Program Map Table).  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.  A PID value of all ones 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.
Top   ToC   RFC4947 - Page 9
   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 and 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

   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.

   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
Top   ToC   RFC4947 - Page 10
   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 and DVB) also reserve specific PID

   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.  A scheme that
   encapsulates PDUs, into SNDUs that are sent in a series of TS Packets
   using a single TS Logical Channel [RFC4326].

   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].

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 Multi-Protocol Encapsulation (MPE) ([ETSI-DAT], [ATSC-A90]) and the IETF-defined Unidirectional Lightweight Encapsulation (ULE) [RFC4326]. The general IP over MPEG-2 AR requirements are summarized below: - A scalable architecture that may support large numbers of systems within the MPEG-2 Network [RFC4259]. - 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.
Top   ToC   RFC4947 - Page 11
      - A method to represent IPv4/IPv6 AR information (including
        security mechanisms to authenticate the AR information to
        protect against address masquerading [RFC3756]).

      - A method to install AR information associated with clients at
        the AR Server (registration).

      - A method for transmission of AR information from an AR Server to
        clients that minimize the transmission cost (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 recognize the 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; and 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] and [RFC2375].
            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]).

   Overlapping address assignments may also occur at L2, where the same
   MAC/NPA address is used to identify multiple Receivers [RFC4259]:

      (i)   An MAC/NPA unicast address must be unique within the
            addressed area.  The IEEE-assigned MAC addresses used in
            Ethernet LANs are globally unique.  If the addresses are not
            globally unique, an address must only be re-used by
            Receivers in different addressed (scoped) areas.
Top   ToC   RFC4947 - Page 12
      (ii)  The MAC/NPA address broadcast address (a L2 address of all
            ones).  Traffic with this address should be confined to one
            addressed area.

      (iii) IP and other protocols may view sets of L3 multicast
            addresses as link-local.  This may produce unexpected
            results if frames with the corresponding multicast L2
            addresses are distributed to systems in a different L3
            network or multicast scope (Sections 3.2 and 5.6).

   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 at L2.  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

3.1. Unicast Support

Unicast address resolution is required at two levels. 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 (Section 4). Each Encapsulator within an MPEG-2 Network is associated with a set of unique TS Logical Channels (PID values) that it sources [ETSI-DAT, RFC4259]. Within a specific scope, the same unicast IP address may therefore be associated with more than one Stream, and each Stream contributes different content (e.g., when several different IP Encapsulators contribute IP flows destined to the same Receiver). MPEG-2 Networks may also replicate IP packets to send the same content (Simulcast) to different Receivers or via different TS Multiplexes. The configuration of the MPEG-2 Network must prevent a Receiver accepting duplicated copies of the same IP packet. At the upper level, the AR procedure needs to associate an IP address with a specific MAC/NPA address (Section 5).

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.6). In IPv4 and IPv6 over Ethernet, this
Top   ToC   RFC4947 - Page 13
   association is normally a direct mapping, and this is the default
   method also specified in both ULE [RFC4326] and MPE [ETSI-DAT].

   Address resolution must also occur at the MPEG-2 level (Section 4).
   The goal of this multicast address resolution is to allow a Receiver
   to associate an IPv4 or IPv6 multicast address with a specific TS
   Logical Channel and the corresponding TS Multiplex [RFC4259].  This
   association needs to permit a large number of active multicast
   groups, and should minimize 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 two specific functions required for address resolution in
   IP multicast over MPEG-2 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 signalling 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 [RFC4259].

   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 (Any-Source
   Multicast) 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 [ETSI-DAT]).  At the IP
   level, the host/router may be unaware of this duplication and this
   needs to be detected by other means.

   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
   network may be expected to vary significantly with time.  Some uses
   of IP multicast employ a range of addresses to support a single
   application (e.g., ND [RFC2461], Layered Coding Transport (LCT)
   [RFC3451], and Wave and Equation Based Rate Control (WEBRC)
   [RFC3738]).  The current set of active addresses may be determined
   dynamically via a multicast group membership protocol (e.g., Internet
Top   ToC   RFC4947 - Page 14
   Group Management Protocol (IGMP) [RFC3376] and Multicast Listener
   Discovery (MLD) [RFC3810]), via multicast routing (e.g., Protocol
   Independent Multicast (PIM) [RFC4601]) and/or other means (e.g.,
   [RFC3819] and [RFC4605]), however each active address requires a
   binding by the AR method.  Therefore, there are advantages in using a
   method that does not need to explicitly advertise an 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.

   Section 5.6 describes the binding of IP multicast addresses to
   MAC/NPA addresses.

4. MPEG-2 Address Resolution

The first part of this section describes the role of MPEG-2 signalling to identify streams (TS Logical Channels [RFC4259]) within the L2 infrastructure. At L2, the MPEG-2 Transport Stream [ISO-MPEG2] identifies the existence and format of a Stream, using a combination of two PSI tables: the Program Association Table (PAT) and entries in the program element loop of a Program 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 Logical Channel (i.e., a TS). The identified TS is used to send the PMT, which associates a set of PID values with the individual components of the program. 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 signalling the Receiver with the PID value assigned to a Stream, PMT entries indicate the presence of Streams using ULE and MPE to the variety of devices that may operate in the MPEG-2 transmission network (multiplexors, remultiplexors, rate shapers, advertisement insertion equipment, etc.). A multiplexor or remultiplexor may 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
Top   ToC   RFC4947 - Page 15
   the Stream 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 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 pre-defined set of IP addresses may be used within an 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 optimize 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). This presumes that the PID mappings are not modified during transmission (Section 4). A single "well-known" PID is a specialization of this. This scheme is used by current DOCSIS cable modems [DOCSIS], where all IP traffic is placed into the specified TS stream. MAC filtering (and/or Section filtering in MPE) may be used to differentiate subnetworks.

4.1.1. MPEG-2 Cable Networks

Cable networks use a different transmission scheme for downstream (head-end to cable modem) and upstream (cable modem to head-end) transmissions. IP/Ethernet packets are sent (on the downstream) to the cable modem(s) encapsulated in MPEG-2 TS Packets sent on a single well- known TS Logical Channel (PID). There is no use of in-band signalling 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.
Top   ToC   RFC4947 - Page 16
   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 (Section 1).  This
   usually acts as a DHCP Relay for IP devices [RFC2131], [RFC3046], and
   [RFC3256].  Issues in deployment of IPv6 are described in [RFC4779].

4.2. MPEG-2 Table-Based Address Resolution

The information about the set of MPEG-2 Transport Streams carried over a TS Multiplex can be distributed via SI/PSI Tables. These tables 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 coordinating 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 that allows an MPEG-2 Receiver to identify the appropriate PID and the multiplex associated with a specific IP address include: (i) IP/MAC Notification Table (INT) in the DVB Data standard [ETSI-DAT]. This provides unidirectional 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) is an MPEG-2 Table employed by some DVB-RCS systems to provide unidirectional address resolution of IPv4 multicast addresses to an MPEG-2 TS. The MMT and AIT are used for specific applications, whereas the INT [ETSI-DAT] is a more general DVB method that supports MAC, IPv4, and IPv6 AR when used in combination with the other MPEG-2 tables (Section 4).
Top   ToC   RFC4947 - Page 17

4.2.1. IP/MAC Notification Table (INT) and Its Usage

The INT provides a set of descriptors to specify addressing in a DVB network. The use of this method is specified for Multiprotocol Encapsulation (MPE) [ETSI-DAT]. It 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 carried by 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 the table (and hence enhance signalling efficiency). An IPv4/IPv6 "subnet mask" may be specified in full form or by 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, for identification and security descriptors, the following descriptors are defined for address binding in INT tables: (i) target_MAC_address_descriptor: A descriptor to describe a single or set of MAC addresses (and their mask). (ii) target_MAC_address_range_descriptor: A descriptor that may be used to set filters. (iii) target_IP_address_descriptor: A 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 addresses to target a single or set of systems. (vi) IP/MAC stream_location_descriptor: A descriptor that 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
Top   ToC   RFC4947 - Page 18
   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.

   One key benefit is that the approach employs MPEG-2 signalling
   (Section 4) and is integrated with other signalling information.
   This allows the INT to operate in the presence of (re)multiplexors
   [RFC4259] and to refer to PID values that are carried in different TS
   Multiplexes.  This makes it well-suited to a Broadcast TV Scenario

   The principal drawback is a need for an 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.

4.2.2. Multicast Mapping Table (MMT) and Its Usage

In DVB-RCS, unicast AR is seen as a part of a wider configuration and control function and does not employ a specific protocol. A Multicast Mapping Table (MMT) may be carried in an MPEG-2 control table that associates a set of multicast addresses with the corresponding PID values [MMT]. This table allows a DVB-RCS Forward Link Subsystem (FLSS) to specify the mapping of IPv4 and IPv6 multicast 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 specified by the SatLabs Forum [MMT] and 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 receive a variety of control information. The AIT uses an MPEG-2 signalling 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
Top   ToC   RFC4947 - Page 19
   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 [ATSC-A54A] 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 signalled in the PMT using a stream_type indicator of value 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 uses MPEG-2 SI Tables to bind the IP multicast media streams and the corresponding Session Description Protocol (SDP) announcement streams to particular MPEG-2 Program Elements. Each application constitutes an independent network. The MPEG-2 Network boundaries establish the 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 each has their strength: the INT in terms of flexibility and extensibility, the MMT in its simplicity, and 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 Address Resolution for 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 and control and data delivery. Address resolution information could also be sent using IP transport. At the time of writing there is no standards-based IP-level AR protocol that supports the MPEG-2 TS. There is an opportunity to define an IP-level method that could use an IP multicast protocol over a well-known IP multicast address to resolve an IP address to a TS Logical Channel (i.e., a Transport Stream). The advantages of using an IP-based address resolution include:
Top   ToC   RFC4947 - Page 20
   (i)   Simplicity:
         The AR mechanism does not require interpretation of L2 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 both IP to MAC address mappings
         and mapping to TS Logical Channels (PID value associated with a

   (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 part of the IP network layer, simplifying
         support for AAA, policy, Operations and Management (OAM),
         mobility, configuration control, etc., that combine AR with

   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 associated
         with the TS Logical Channels during the multiplexing operation
         (Section 4).  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.

   An IP-level method could use an IP multicast protocol running an AR
   Server (see also Section 5.4) over a well-known (or discovered) IP
   multicast address.  To satisfy the requirement for scalability to
   networks with a large number of systems (Section 1), a single packet
   needs to transport multiple AR records and define the intended scope
Top   ToC   RFC4947 - Page 21
   for each address.  Methods that employ prefix matching are desirable
   (e.g., where a range of source/destination addresses are matched to a
   single entry).  It can also be beneficial to use methods that permit
   a range of IP addresses to be mapped to a set of TS Logical Channels
   (e.g., a hashing technique similar to the mapping of IP Group
   Destination Addresses to Ethernet MAC addresses [RFC1112] [RFC2464]).

(page 21 continued on part 2)

Next Section