Internet Engineering Task Force                         Gorry Fairhurst 
Internet Draft                                   University of Aberdeen 
Document: draft-ietf-ipdvb-ar-04.txt               Marie-Jose Montpetit 
                                                     Motorola Connected 
                                                         Home Solutions 
                                                                        
                                                                        
                                                                        
Category: Draft                                               June 2006 
 
 
  
  Address Resolution Mechanisms 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 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, and provides guidance on usage. 
    
    

  
Expires Jan 2007                                              [page 1] 
INTERNET DRAFT  AR Mechanisms for IP over MPEG-2 Networks     June 2006  
 
 
   Table of Contents 
    
   1. Introduction 
   1.1 Bridging and Routing 
    
   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 MAC/NPA 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 AR Server 
   5.5 DHCP Tuning 
   5.6 IP Multicast AR 
   5.6.1 Multicast/Broadcast addressing for UDLR 
    
   6. Link Layer Support 
   6.1 ULE without a destination MAC/NPA address (D=1) 
   6.2 ULE with a destination MAC/NPA 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 
 

  
Expires January 2007                                          [page 2] 
INTERNET DRAFT  AR Mechanisms for IP over MPEG-2 Networks     June 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], 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 an Layer-2 (L3) 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 an Address Resolution (AR) function. In 
   some AR schemes, the MPEG-2 TS address space is sub-divided into 
   logical contexts known as Platforms [ETSI-DAT]. 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 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, 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 by address resolution protocols that use this 
   service. 
    
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 

  
Expires January 2007                                          [page 3] 
INTERNET DRAFT  AR Mechanisms for IP over MPEG-2 Networks     June 2006  
 
 
   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 feeding 3 downstream routers (R2-R4). 
   AR takes place at the Encapsulator (R1) to identify each Receiver at 
   L2 within the IP subnetwork (R2, etc). 
    
   When considering unicast communication from R1 to R2, several L2 
   addresses are involved: 
    
    1a is the L2 interface address of R1 on the MPEG-2 link 
    2b is the L2 interface address of R2 on the MPEG-2 link 
    2a is the L2 interface address of R2 on the next hop link 
    
   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 topology. The Encapsulator associates a 
   destination MAC/NPA address with each bridged PDU sent on an MPEG-2 
   link. Two methods are defined by ULE [RFC4326]: 
    
   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 (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 L1/L2 
   services (including the use of UDLR [RFC3077]). 
    
   It is also possible for a bridging Encapsulator (B1) to encapsulate 
   a PDU with a link-specific header that contains the MAC/NPA address 
   associated with a Receiver L2 interface on the MPEG-2 link. In this 
   case, the destination MAC/NPA address of the encapsulated frame is 
  
Expires January 2007                                          [page 4] 
INTERNET DRAFT  AR Mechanisms for IP over MPEG-2 Networks     June 2006  
 
 
   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, 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 subnetwork.  
    
    
                                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 feeding 3 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 
   L2 (R2, etc). 
 
    
   Methods also exist to assign IP addresses to Receivers within a 
   network (e.g. DHCP [RFC2131], DHC [RFC3736]).  Receivers may also 
   participate in remote configuration of the L3 IP addresses used in 
   connected equipment (e.g. using DHCP-Relay [RFC3046]). 
 
   The remainder of the 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 methods (using MPEG-2 SI 
   tables), and protocols at the IP level (including ARP [RFC826] and 
   the ND [RFC2461]).  Interactions and dependencies between these 
   methods 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 resolution. 
  
Expires January 2007                                          [page 5] 
INTERNET DRAFT  AR Mechanisms for IP over MPEG-2 Networks     June 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-MPEG2]. 
    
   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 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 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 address 
   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). 
    
   MAC Header: The link-layer header of the IEEE 802.3 standard [IEEE- 
   802.3 or Ethernet v2. 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).  
    
  
Expires January 2007                                          [page 6] 
INTERNET DRAFT  AR Mechanisms for IP over MPEG-2 Networks     June 2006  
 
 
   MPE: Multiprotocol Encapsulation [ETSI-DAT; ATSC-DAT; ATSC-DATG]. 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 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. 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 
  
Expires January 2007                                          [page 7] 
INTERNET DRAFT  AR Mechanisms for IP over MPEG-2 Networks     June 2006  
 
 
   network-layer service (or bridging module when operating at the 
   link-layer). 
        
   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 
   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]. 
    
   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 January 2007                                          [page 8] 
INTERNET DRAFT  AR Mechanisms for IP over MPEG-2 Networks     June 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 prevent address masquerading [RFC3756]).  
         
        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] [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]). 
  
Expires January 2007                                          [page 9] 
INTERNET DRAFT  AR Mechanisms for IP over MPEG-2 Networks     June 2006  
 
 
    
   Overlapping address assignments may also occur at L2, where the same 
   NPA 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. This may produce unexpected results  
           if frames with these multicast L2 addresses are distributed 
           to systems in a different L3 network or multicast scope (see         
           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 behaviour.  
    
    
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  
  
Expires January 2007                                         [page 10] 
INTERNET DRAFT  AR Mechanisms for IP over MPEG-2 Networks     June 2006  
 
 
    
   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 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 the association of 
   an IPv4 or IPv6 multicast address with a specific TS Logical Channel 
   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 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 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], LCT [RFC3451], WEBRC [RFC3738]).  
  
Expires January 2007                                         [page 11] 
INTERNET DRAFT  AR Mechanisms for IP over MPEG-2 Networks     June 2006  
 
 
   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], [RFC-IGMP-Proxy]), 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 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. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 


  
Expires January 2007                                         [page 12] 
INTERNET DRAFT  AR Mechanisms for IP over MPEG-2 Networks     June 2006  
 
 
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. 
    
   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 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 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 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 
   the Transport 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.  
  
Expires January 2007                                         [page 13] 
INTERNET DRAFT  AR Mechanisms for IP over MPEG-2 Networks     June 2006  
 
 
   A pre-defined set of IP addresses may be 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). This presumes that the PID values are not modified 
   during transmission (section 4). 
    
   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 scheme for downstream, 
   (head-end to cable modem) and upstream (cable modem to head-end) 
   transmission.  
    
   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. 
    
   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], 
   [RFC3256]. Issues in deployment of IPv6 are described in [ID-V6OPS-
   DEPLOY].  
 
    
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 
  
Expires January 2007                                         [page 14] 
INTERNET DRAFT  AR Mechanisms for IP over MPEG-2 Networks     June 2006  
 
 
   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:   
    
   (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, 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 (see 
   section 4).  
    
    
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. Use of this method is specified for Multi-Protocol 
   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 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: A descriptor to describe a 
  
Expires January 2007                                         [page 15] 
INTERNET DRAFT  AR Mechanisms for IP over MPEG-2 Networks     June 2006  
 
 
         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  
         
   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 
   [RFC4259]. 
    
   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.  
    
   The Multicast Mapping Table (MMT) is carried in an MPEG-2 control 
   table that associates a set of multicast addresses with the 
  
Expires January 2007                                         [page 16] 
INTERNET DRAFT  AR Mechanisms for IP over MPEG-2 Networks     June 2006  
 
 
   corresponding PID values.  This table allows a DVB-RCS Forward Link 
   Subsystem (FLSS) to specify the mapping of IPv4 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 not specified as 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 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-G] 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 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. 
    
  
Expires January 2007                                         [page 17] 
INTERNET DRAFT  AR Mechanisms for IP over MPEG-2 Networks     June 2006  
 
 
    
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.  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. The 
   advantages of using an IP-based address resolution for Transport 
   Streams include: 
    
   (i) Simplicity: 
   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 both IP to MAC address mappings and to map 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 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 
  
Expires January 2007                                         [page 18] 
INTERNET DRAFT  AR Mechanisms for IP over MPEG-2 Networks     June 2006  
 
 
   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 5.4) over a well-known (or discovered) IP multicast 
   address. To satisfy the requirement for scalability to networks with 
   large number of systems (section 1), a single packet needs to 
   transport multiple AR records, and define the intended scope for 
   each address. Methods that employ 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 (a hashing 
   technique similar to the mapping of IP Group Destination Addresses 
   to Ethernet MAC addresses may be beneficial). 
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
 
 
 
 
 
 
 
 
 
    
  
Expires January 2007                                         [page 19] 
INTERNET DRAFT  AR Mechanisms for IP over MPEG-2 Networks     June 2006  
 
 
    
5. Mapping IP addresses to MAC/NPA addresses  
    
   This section reviews IETF protocols that may be used to assign and 
   manage the mapping of IP addresses to/from MAC/NPA addresses over 
   MPEG-2 Networks. 
    
   An IP Encapsulator requires AR information to select an appropriate 
   MAC/NPA address in the SNDU header [RFC4259] (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) (section 1.1).  
    
   Two IETF-defined protocols for mapping IP addresses to MAC/NPA 
   addresses are the Address Resolution Protocol, ARP [RFC826], and the 
   Neighbor Discovery protocol, ND [RFC2461], respectively for IPv4 and 
   IPv6. Both protocols are normally used in a bi-directional mode, 
   although both also permit unsolicited transmission of mappings. The 
   IPv6 mapping defined in [RFC2464] can result in a large number of 
   active MAC multicast addresses (e.g. one for each 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 (e.g. 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. Layer-2 AR for MPEG-2 
   Networks therefore must support this in a scalable manner. 
    
   A large number of ND Router Solicitation messages may cause a large 
   demand for performing asymmetric operations. The base ND protocol 
  
Expires January 2007                                         [page 20] 
INTERNET DRAFT  AR Mechanisms for IP over MPEG-2 Networks     June 2006  
 
 
   limits the rate at which multicast responses to solicitations can be 
   sent. 
    
   ND has similar security vulnerabilities to ARP. The Secure Neighbor 
   Discovery, SEND [RFC3971] was developed to address known security 
   vulnerabilities in ND [RFC3756]. 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.  
 
 
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 commonly 
   are used for IP multicast content distribution. 
 
                                           /-----\ 
                         MPEG-2 Uplink    /MPEG-2 \ 
                      ###################( Network ) 
                      #                   \       / 
                 +----#------+             \--.--/ 
                 |  Network  |                | 
                 |  Provider +                v MPEG-2 downlink 
                 +-----------+                | 
                                        +-----v------+ 
                                        |   MPEG-2   | 
                                        |  Receiver  | 
                                        +------------+ 
    
                Figure 3: Uni-directional connectivity 
 
   The ARP and ND protocols require bi-directional L2/L3 connectivity. 
   They do not provide an appropriate method to resolve the remote 
   (destination) address in a uni-directional environment.  
    
   Unidirectional links therefore require a separate out-of-band 
   configuration method to establish the appropriate AR information at 
   the Encapsulator and Receivers. ULE [RFC4326] defines a mode in 
   which the MAC/NPA 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.  
    
  
Expires January 2007                                         [page 21] 
INTERNET DRAFT  AR Mechanisms for IP over MPEG-2 Networks     June 2006  
 
 
                                           /-----\ 
                         MPEG-2 uplink    /MPEG-2 \ 
                      ###################( Network ) 
                      #                   \       / 
                 +----#------+             \--.--/ 
                 |  Network  |                | 
                 |  Provider +-<-+            v MPEG-2 downlink 
                 +-----------+   |            | 
                                 |      +-----v------+ 
                                 +--<<--+   MPEG-2   | 
                               Return   |  Receiver  | 
                               Path     +------------+ 
    
                Figure 4: Bi-directional connectivity 
    
   The Uni-Directional Link Routing, UDLR [RFC3077] protocol may be 
   used to overcome issues associated with asymmetric routing. The 
   Dynamic Tunnel Configuration Protocol (DTCP) enables automatic 
   configuration of the return path.  UDLR hides the uni-directional 
   routing from the IP and upper layer protocols, by providing a L2 
   tunnelling 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 (i.e. 
   bridging).  
    
   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 (each considers sending 
   an IP packet to a next-hop IP address that is not currently cached 
   by the sender): 
    
   (i) A Feed Router needs a Receiver MAC/NPA address. 
    
   This occurs when a Feed Router sends an IP packet using the Feed UDL 
   to a Receiver whose MAC/NPA address is unknown. In IPv4, the Feed 
   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 MAC/NPA address of the Feed Router (e.g. using a UDLR 
   tunnel). The Feed Router may then address IP packets to the unicast 
   MAC/NPA address associated with the Receiver. The ULE packet format 
   also permits packets to be sent without specifying a MAC/NPA 
   address, where this is desirable (section 6.1, 6.5). 
    
   (ii) A Receiver needs the Feed Router MAC/NPA address. 
  
Expires January 2007                                         [page 22] 
INTERNET DRAFT  AR Mechanisms for IP over MPEG-2 Networks     June 2006  
 
 
    
   This occurs when a Receiver sends an IP packet to a Feed Router 
   whose MAC/NPA 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 MAC/NPA address 
   of the recipient. 
    
   (iii) A Receiver needs another Receiver MAC/NPA address. 
    
   This occurs when a Receiver sends an IP packet to another Receiver 
   whose MAC/NPA 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 MAC/NPA address 
   of the recipient. 
    
    
   These 3 cases allow any system connected to the UDL to obtain the 
   MAC/NPA 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 the reactive address resolution procedures provided 
   by ARP, ND and SEND. 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 an interface to discard these packets while awaiting the 
   response to the resolution request. An appropriately sized buffer 
   would however prevent this loss.  
    
   In case (iii), the time to complete address resolution may be 
   reduced by use of an AR Server at the Feed (section 5.4).  
 
   Using DHCP requires prior establishment of the L2 connectivity to a 
   DHCP server. The delay in establishing return connectivity in UDLR 
   networks that use DHCP, may make it beneficial to increase the 
   frequency of the DTCP HELLO message. Further information about 
   tuning DHCP is provided in section 5.5. 
 
    
5.3 Bi-directional Links 
     
   Bi-directional IP networks can be and are constructed by a 
   combination of two MPEG-2 transmission links. One link is usually a 
   broadcast link that feeds a set of remote Receivers. Links are also 
   provided from Receivers so that 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. 
    
    
  
Expires January 2007                                         [page 23] 
INTERNET DRAFT  AR Mechanisms for IP over MPEG-2 Networks     June 2006  
 
 
5.4 AR Server 
    
   An AR Server can be used to distribute AR information to Receivers 
   in an MPEG-2 Network. In some topologies this may significantly 
   reduce the time taken for Receivers to discover AR information.  
    
   The AR Server can operate as a proxy responding on behalf of 
   Receivers to received AR requests. When an IPv4 AR request is 
   received (e.g. Receiver ARP REQUEST), an AR Server responds by 
   (proxy) sending an AR response providing the appropriate IP to 
   MAC/NPA binding.  
    
   Information may also be sent unsolicited by the AR Server using 
   multicast/broadcast to update the arp/neighbor cache at the 
   Receivers without the need for explicit requests. The unsolicited 
   method can improve scaling in large networks. Scaling could be 
   further improved by distributing a single broadcast/multicast AR 
   message that binds multiple IP and MAC/NPA addresses. This reduces 
   the network capacity consumed and simplifies client 
   processing/server in networks with large numbers of clients.  
 
   An AR Server can be implemented using IETF-defined Protocols by 
   configuring the subnetwork so that AR Requests from Receivers are 
   intercepted rather than forwarded to the Feed/broadcast link.  The 
   intercepted messages are sent to an AR Server.  The AR Server 
   maintains a set of MAC/NPA address bindings. These may be configured 
   or may learned by monitoring ARP messages sent by Receivers. 
   Currently defined IETF protocols only allow one binding per message, 
   (i.e. there is no optimisation to conserve L2 bandwidth). 
 
   Equivalent methods could provide IPv6 AR. Procedures for 
   intercepting ND messages are defined in [ID-ND-PROXY]. To perform an 
   AR Server function, the AR information must also be cached. 
   Interactions with SEND are described in [ID-SP-ND]. 
    
   Current IETF-defined methods provide bindings of IP addresses to 
   MAC/NPA, but do not allow the bindings to other L2 information 
   pertinent to MPEG-2 Networks, requiring the use of other methods for 
   this function (section 4).  AR Servers can be implemented using non-
   IETF AR protocols to provide the AR information required by 
   Receivers. 
    
 
5.5 DHCP Tuning 
    
   DHCP [RFC2131] may be used over MPEG-2 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 [RFC2131]. 
    

  
Expires January 2007                                         [page 24] 
INTERNET DRAFT  AR Mechanisms for IP over MPEG-2 Networks     June 2006  
 
 
   The configuration of DHCP Servers and Clients should take into 
   account the local link round trip delay (possibly including the 
   additional delay from bridging, e.g. using UDLR). A larger delay may 
   make it desirable to tune the DHCP lease duration and the size of 
   the address pool. Appropriate timer values should also be selected: 
   the DHCP messages retransmission timeout, and the maximum delay that 
   a DHCP Server waits before deciding that the absence of an ICMP echo 
   response indicates 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 
   rather than appropriate to a MPEG-2 Network) 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.  This value 
   may need to be tuned for MPEG-2 networks. 
    
    
5.6 IP Multicast AR 
    
   Section 3.2 describes multicast address resolution requirements. 
   This section describes L3 address bindings when the destination 
   network layer address is an IP multicast Group Destination Address.  
    
   In MPE [ETSI-DAT], a mapping is specified for the MAC Address based 
   on the IP multicast address for IPv4 [RFC1112] and IPv6 [RFC2464]. 
   (A variant of DVB (DVB-H) uses a modified MAC header [DVB_DAT]). 
    
   In ULE [RFC4326], 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, a mapping is defined 
   based on the IP multicast address for IPv4 [RFC1112] and IPv6 
   [RFC2464].  
    
   The L2 group addressing method specified in [RFC1112] and [RFC2464] 
   can result in more than one IP destination addresses mapping to the 
   same L2 address. In Source-Specific Multicast, SSM [RFC3569], 
   multicast groups are identified by the combination of the IP source 
   and IP destination addresses. Systems may therefore independently 
   select their IP group destination address that could map to the same 
   L2 address if forwarded onto the same L2 link. These considerations 
   are the same as for Ethernet LANs, and may not be of concern to 
   Receivers that can perform efficient L3 filtering. Section 3 noted 
   that a MPEG-2 Network may need to support multiple addressing scopes 
   at the network and link layers.  Separation of the different groups 
   into different Transport Streams is one remedy (with signalling of 
   IP to PID value mappings). Another approach is to employ alternate 
   MAC/NPA mappings to those defined in [RFC1112] and [RFC2464], but 
   such mappings need to be consistently bound at the Encapsulator and 
   Receiver using AR procedures in a scalable manner. 
    
    
  
Expires January 2007                                         [page 25] 
INTERNET DRAFT  AR Mechanisms for IP over MPEG-2 Networks     June 2006  
 
 
5.6.1 Multicast/Broadcast addressing for UDLR 
 
   UDLR is a layer 2 solution, in which a Receiver may send 
   multicast/broadcast frames that are subsequently forwarded natively 
   by a Feed Router (using the topology in figure 2), and are finally 
   received at the feed interface of the originating Receiver.  This 
   multicast forwarding does not include the normal L3 Reverse Path 
   Forwarding (RPF) check or L2 spanning tree checks, the processing of 
   the IP Time To Live (TTL) field, or the filtering of 
   administratively scoped multicast addresses. This raises a need to 
   carefully consider multicast support [. RFC3077 notes that a 
   Receiver needs to be configured to discard these received packets.  
    
   When the encapsulation includes an NPA/MAC source address, such 
   packets may be filtered at the link-layer using a filter that 
   discards L2 addresses that are local to the Receiver. In some 
   circumstances, systems can send packets with an unknown (all zero) 
   MAC source address (e.g. IGMP Proxy Queriers [RFC-IGMP-Proxy]), 
   where the source at L2 can not be determined at the Receiver, these 
   packets need to be silently discarded, which may prevent running the 
   associated services on the Receiver. 
    
   Some encapsulations do not include an NPA/MAC source address (Table 
   2).  Multicast packets may therefore alternatively be discarded at 
   the IP layer if their IP source address matches a local IP address 
   (or address range).  Systems can send packets with an all zero IP 
   source address (e.g. BOOTP [RFC951], DHCP [RFC2131] and ND 
   [RFC2461]), where the source at L3 can not be determined at the 
   Receiver these packets need to be silently discarded.  This may 
   prevent running the associated services at a Receiver, e.g. 
   participation in IPv6 Duplicate Address Detection, or running a DHCP 
   server. 
    
    
    
    
    
    
    
    
    
    
    
    
 
    
    
    
    
    
    
    
    
  
Expires January 2007                                         [page 26] 
INTERNET DRAFT  AR Mechanisms for IP over MPEG-2 Networks     June 2006  
 
 
6. Link Layer Support 
    
   This section considers link-layer (L2) support for address 
   resolution in MPEG-2 Networks. It considers two issues: The code-
   point used at L2 and 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 showing 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 MAC/NPA 
   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 [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 January 2007                                         [page 27] 
INTERNET DRAFT  AR Mechanisms for IP over MPEG-2 Networks     June 2006  
 
 
6.2 ULE with a destination MAC/NPA address (D=0) 
    
   The IPv4 Address Resolution Protocol (ARP) [RFC826] is identified by 
   an IEEE 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 is supported. 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 EtherType field 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 EtherType field 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 is supported using 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 [RFC2462]. 
    
    
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 the MAC destination 
   address value is identical to the Receiver NPA address. 
    
   At the Encapsulator, the ULE MAC/NPA destination address is 
   determined by a L2 forwarding decision.  Received 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 
  
Expires January 2007                                         [page 28] 
INTERNET DRAFT  AR Mechanisms for IP over MPEG-2 Networks     June 2006  
 
 
   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 MAC/NPA address).  
    
   At the Encapsulator, the value of the ULE MAC/NPA 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 January 2007                                         [page 29] 
INTERNET DRAFT  AR Mechanisms for IP over MPEG-2 Networks     June 2006  
 
 
7. Conclusions  
    
   This document describes addressing and address resolution issues for 
   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.  
    
   There is no single common approach used in all MPEG-2 networks. A 
   static binding may 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 Tafble, 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 and defined their usage.  
    
   The document also considers a unified IP-based method for AR that 
   could be independent of the physical layer, but does not define a 
   new protocol. It examines the design criteria for a method, with 
   recommendations to ensure scalability and improve support for the IP 
   protocol stack.  
    
    
8. Security Considerations  
    
   The normal security issues relating to the use of wireless links for 
   transmission of Internet traffic should be considered.  
    
   L2 signalling in MPEG-2 transmission networks is currently provided 
   by (periodic) broadcasting information in the control plane using 
   PSI/SI tables (section 4). 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.  
    
   There are known security issues relating to the use of unsecured 
   address resolution [RFC3756].  Readers are also referred to the 
   known security issues when mapping IP addresses to MAC/NPA addresses 
   using ARP [RFC826] and ND [RFC2461]. It is recommended that 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.  For IPv6, the SEND protocol [RFC3971] 
   may be used in place of ND. This defines security mechanisms that 
   can protect AR. 
 
   AR Servers (section 5.4) are susceptible to the same kind of 
   security issues as hosts using unsecured AR.  These issues include 
   hijacking traffic and denial-of-service within the subnet. Malicious 
   nodes within the subnet can take advantage of this property, and 
   hijack traffic.  In addition, an AR Server is essentially a 
   legitimate man-in-the-middle, which implies that there is a need to 
  
Expires January 2007                                         [page 30] 
INTERNET DRAFT  AR Mechanisms for IP over MPEG-2 Networks     June 2006  
 
 
   distinguish such proxies from unwanted man-in- the-middle attackers. 
   This document does not introduce any new mechanisms for the 
   protection of these AR functions (e.g. authenticating servers, or 
   defining AR Servers that interoperate with the SEND protocol [ID-SP-
   ND]). 
 
 
9. Acknowledgments  
    
   The authors wish to thank the ipdvb WG members for their inputs and 
   in particular, Rod Walsh, Jun Takei, and Michael Mercurio. The 
   authors also acknowledge the support of the European Space Agency. 
   Martin Stiemerling contributed descriptions of scenarios, 
   configuration, and provided extensive proof reading. Hidetaka 
   Izumiyama contributed on UDLR and IPv6 issues. A number of issues 
   discussed in the UDLR working group have also provided valuable 
   inputs to this document (summarised in draft-ietf-udlr-experiments-
   01.txt).  
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
  
Expires January 2007                                         [page 31] 
INTERNET DRAFT  AR Mechanisms for IP over MPEG-2 Networks     June 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", v1.7.1, 
   European Telecommunications Standards Institute (ETSI), December 
   2005.  
 
   [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), 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. 
    
   [RFC4326] Fairhurst, G., Collini-Nocker, B., "Unidirectional 
   Lightweight Encapsulation (ULE) for transmission of IP datagrams 
   over an MPEG-2 Transport Stream", RFC 4326, December 2005. 
 
    
10.2 Informative References 
    
   [ATSC] A/53C, "ATSC Digital Television Standard", Advanced 
   Television Systems Committee (ATSC), Doc. A/53C, 2004. 
    
  
Expires January 2007                                         [page 32] 
INTERNET DRAFT  AR Mechanisms for IP over MPEG-2 Networks     June 2006  
 
 
   [ATSC-G] A/54A, "Guide to the use of the ATSC Digital Television 
   Standard", Advanced Television Systems Committee (ATSC), Doc. A/54A, 
   2003. 
    
   [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.   
    
   [DVB] Digital Video Broadcasting (DVB) Project. http://www.dvb.org 
    
   [ETSI-SI1] TR 101 162, "Digital Video Broadcasting (DVB); Allocation 
   of Service Information (SI) codes for DVB systems", European 
   Telecommunications Standards Institute (ETSI). 
    
   [ETSI-RCS]  EN 301 790, "Digital Video Broadcasting (DVB); 
   Interaction channel for satellite distribution 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), 2002.  
 
   [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. XXX Publication Requested XX 
    
   [ID-ND-PROXY] Thaler, D. Talwar, M., Patel, C., "Neighbor Discovery 
   Proxies (ND Proxy)", Work in Progress, draft-ietf-ipv6-ndproxy-
   04.txt, 2006. 
    
   [ID-SP-ND] Daley, G., "Securing Proxy Neighbour Discovery Problem 
   Statement", Work in progress, draft-daley-send-spnd-prob-01.txt, 
   February 2005. 
    
   [LLC] ISO/IEC 8802.2, "Information technology; Telecommunications 
   and information exchange between systems; Local and metropolitan 
   area networks; Specific requirements; Part 2: Logical Link Control", 
   International Standards Organisation (ISO), 1998. 
    
   [RFC951] Croft, W. and J. Gilmore, "Bootstrap Protocol", RFC 951, 
   September 1985. 
 
   [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 
   2131, March 1997. 
  
Expires January 2007                                         [page 33] 
INTERNET DRAFT  AR Mechanisms for IP over MPEG-2 Networks     June 2006  
 
 
    
   [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. 
    
   [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 
   3046, January 2001. 
    
   [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. 
    
   [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. 
    
   [RFC3569] Bhattacharyya, S., "An Overview of Source-Specific 
   Multicast (SSM)", RFC 3569, July 2003. 
    
   [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 
   (DHCP) Service for IPv6", RFC 3736, April 2004. 
    
   [RFC3756] Nikander, P., Kempf, J. and E. Nordmark, "IPv6 Neighbor 
   Discovery (ND) Trust Models and Threats", RFC 3756, May 2004. 
    
   [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, 

  
Expires January 2007                                         [page 34] 
INTERNET DRAFT  AR Mechanisms for IP over MPEG-2 Networks     June 2006  
 
 
   "Advice for Internet Subnetwork Designers", BCP 89, RFC 3819, July 
   2004. 
    
   [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 
   Neighbor Discovery (SEND)", RFC 3971, March 2005. 
    
   [RFC4259] Montpetit, M.J., Fairhurst, G., Clausen, H.D., Collini-
   Nocker, B., and H. Linder, "Architecture for IP transport  
   over MPEG-2 Networks".  
    
   [RFC-IGMP-Proxy] B. Fenner,H. He, B. Haberman, H. Sandick, 
   l"IGMP/MLD-based Multicast Forwarding ("IGMP/MLD Proxying")", RFC 
   XXX, 2006. <currently draft-ietf-magma-igmp-proxy-06.txt> 
 
   [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  
     gorry@erg.abdn.ac.uk  
     http://www.erg.abdn.ac.uk/users/gorry  
      
     Marie-Jose Montpetit 
     Motorola Connected Home Solutions 
     Advanced Technology 
     55 Hayden Avenue , 3rd Floor 
     Lexington  
     Massachusetts 
     02421 
     USA 
     mmontpetit@motorola.com 
    
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. 
    
  
Expires January 2007                                         [page 35] 
INTERNET DRAFT  AR Mechanisms for IP over MPEG-2 Networks     June 2006  
 
 
   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 January 2007                                         [page 36] 
INTERNET DRAFT  AR Mechanisms for IP over MPEG-2 Networks     June 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). 
    
   WG-03  
   * Sections restructured to offer clearer advice on IETF-defined 
   protocols.  
   * Section added on bridging v routing cases 
   * Section added on AR Server and use with arp and ND. 
   * Section added to collect issues relating to DHCP 
   * English improved to prepare for WGLC. 
    
  
Expires January 2007                                         [page 37] 
INTERNET DRAFT  AR Mechanisms for IP over MPEG-2 Networks     June 2006  
 
 
   WG-04 
   * Fixed spelling mistake noted by George Kinal 
   * Comments on various issues received from Rupert Goodrings 
   * Comments on various issues received from Martin Striemerling 
   * Comments on DAD and UDLR from Tina Strauf  
   * Comments on DAD and MAC addresses from Bernhard Collini-Nocker 
   * English fixed. 
   * Title change (inserted methods) 
 
    
<<<<< 










































  
Expires January 2007                                         [page 38]