[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 draft-ietf-ipdvb-ar

Internet Engineering Task Force                         Gorry Fairhurst
Internet Draft                                   University of Aberdeen
Document: draft-fair-ipdvb-ar-04.txt               Marie-Jose Montpetit
                                                               Motorola
                                                     Hidetaka Izumiyama
                                                                Wishnet


Category: Internet Draft                           Expires October 2005


Address Resolution for IP datagrams over MPEG-2 networks


Status of this Draft

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that
   other groups may also distribute working documents as Internet-
   Drafts. Internet-Drafts are draft documents valid for a maximum of
   six months and may be updated, replaced, or obsoleted by other
   documents at any time. It is inappropriate to use Internet-Drafts as
   reference material or to cite them other than as "work in progress".

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   Abstract

   This document describes the process of binding/associating IPv4/IPv6
   addresses with MPEG-2 Transport Streams (TS). This procedure is
   known as Address Resolution (AR), or Neighbour Discovery (ND). Such
   address resolution complements the higher layer resource discovery
   tools that are used to advertise IP sessions. In MPEG-2 networks, an
   IP address must be associated with a Packet ID (PID) and a specific
   Transmission Multiplex The document reviews current methods. It also
   describes the interaction with well-known protocols for address
   management including DHCP, ARP, and NDP, and provides guidance on
   usage.








Expires September 2005                                        [page 1]


INTERNET DRAFT  AR for IP over MPEG-2 networks              April 2005


   Table of Contents

   1. Introduction
   2. Convention used in the document
   3. Address Resolution Requirement
        3.1 Unicast Support
        3.2 Multicast Support
   4. MPEG-2 Address Resolution
        4.1 Static configuration.
        4.1.1 MPEG-2 Cable Networks
        4.2 MPEG-2 Table-Based Address Resolution
        4.2.1 IP/MAC Notification Table (INT) and its usage
        4.2.2 Multicast Mapping Table (MMT) and its usage
        4.2.3 Application Information Table (AIT) and its usage
        4.2.4 Comparison of SI/PSI table approaches
        4.3 IP-based resolution of TS Logical Channels
        4.3.1 IP-based multicast resolution of TS Logical Channels
      5. Mapping IP addresses to NPA/MAC addresses
      5.1 Uni-directional links supporting uni-directional connectivity

       5.2 Uni-directional links with bi-directional connectivity
        5.3 Bi-directional links
        5.4 IP Multicast AR
   6. Link Layer Support
        6.1 ULE without a destination MAC/NPA address (D=1)
        6.2 ULE with a destination NPA/MAC address (D=0)
        6.3 MPE without LLC/SNAP Encapsulation
        6.4 MPE with LLC/SNAP Encapsulation
        6.5 ULE with Bridging Header Extension (D=1)
        6.6 ULE with Bridging Header Extension and NPA Address (D=0)
        6.7 MPE with LLC/SNAP and Bridging
   7. Conclusions
   8. Security Considerations
   9. Acknowledgements
   10. References
   11. Author's Addresses
   12. IPR Notices
   13. Copyright Statements
   14. IANA Considerations

       Appendices












Expires September 2005                                        [page 2]


INTERNET DRAFT  AR for IP over MPEG-2 networks              April 2005


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.  It is defined in
   specification ISO/IEC 138181 [ISO-MPEG2]. Each Layer-2 frame, known
   as a TS Packet, contains a 4 byte header and 188 bytes of 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 using System Information
   (SI) Tables [ETSI-SI, ETSI-SI1], or Program Specific Information
   (PSI) Tables.

   To utilise the MPEG-2 TS as an IP link, a sender must associate an
   IP address with a particular Transmission Multiplex, and within the
   multiplex identify the specific PID to be used. This document calls
   this mapping Address Resolution (AR) [ipdvb-arch]. In some AR
   schemes, the MPEG-2 TS address space is sub-divided into logical
   contexts known as Platforms. Each platform associates an IP service
   provider with a separate context that share a common MPEG-2 TS (use
   the same PID value).

   MPEG-2 Receivers may use a Network Point of Attachment (NPA) [ipdvb-
   arch] to uniquely identify the L2 node within the MPEG-2
   transmission network. An example of an NPA is the IEEE Medium Access
   Control (MAC) address. Where such addresses are used, these must
   also be signalled by the AR procedure. Finally, address resolution
   may need to signal the format of the data being transmitted, for
   example, the encapsulation, any L2 encryption method and any
   compression scheme [ID-IPDVB-ARCH].

   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 address and/or Platform ID. A range of approaches
   is described, including Layer-2 methods (utilising MPEG-2 SI
   tables), and protocols at the IP level (including the IPv4 Address
   Resolution Protocol, ARP [RFC826] and the IPv6 Neighbor Discovery
   Protocol, NDP [RFC2461]).  Interactions and dependencies between
   these methods and the encapsulation methods are described.










Expires September 2005                                        [page 3]


INTERNET DRAFT  AR for IP over MPEG-2 networks              April 2005


   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.

   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 in an MPEG-2
   Private Section, defined by the ISO MPEG-2 standard.

   DVB: Digital Video Broadcast [ETSI-DVB]. A framework and set of
   associated standards published by the European Telecommunications
   Standards Institute (ETSI) for the transmission of video, audio, and
   data, using the ISO MPEG-2 Standard.

   DVB-RCS: Digital Video Broadcast Return Channel via Satellite.
   A bi-directional IPv4/IPv6 service employing low-cost Receivers.

   Encapsulator: A network device that receives PDUs and formats these
   into Payload Units (known here as SNDUs) for output as a stream of
   TS Packets.

   INT: Internet/MAC Notification Table.  A uni-directional
   addressing resolution mechanism using SI and/or PSI Tables.

   MAC: Medium Access Control [IEEE-802.3]. A link layer protocol
   defined by the IEEE 802.3 standard (or by Ethernet v2 [DIX]).

   MAC Header: The link layer header of the IEEE 802.3 standard [IEEE-
   802.3] or Ethernet v2 [DIX]. It consists of a 6B destination
   address, 6B source address, and 2B type field (see also NPA, LLC).
   MAC: Medium Access and Control of the Ethernet IEEE 802 standard
   of protocols (see also NPA).

   MHP: Multimedia Home Platform. An integrated MPEG-2 multimedia
   receiver, that may (in some cases) support IPv4/IPv6 services.

   MMT: Multicast Mapping Table (proprietary extension to DVB-RCS
   defining an AR table that maps IPv4 multicast addresses to PID
   values).

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

Expires September 2005                                        [page 4]


INTERNET DRAFT  AR for IP over MPEG-2 networks              April 2005


   Channel.

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

   NPA: Network Point of Attachment. In this document, refers to a 6
   byte destination address (resembling an IEEE MAC address) within the
   MPEG-2 transmission network that is used to identify individual
   Receivers or groups of Receivers.

   PID: Packet Identifier  [ISO-MPEG2]. A 13 bit field carried in the
   header of TS Packets. This is used to identify the TS Logical
   Channel to which a TS Packet belongs [ISO-MPEG2]. The TS Packets
   forming the parts of a Table Section, PES, or other Payload Unit
   must all carry the same PID value.  The all 1s 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. The all 1s 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.

   Private Section: A syntactic structure constructed in accordance
   with 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.

   PSI: Program Specific Information [ISO-MPEG2]. PSI is used to
   convey information about services carried in a TS Multiplex.
   It is carried in one of four specifically identified table
   section constructs [ISO-MPEG2], see also SI Table.

   Receiver: Equipment that processes the signal from a TS Multiplex
   and performs filtering and forwarding of encapsulated PDUs to the
   network-layer service (or bridging module when operating at the link
   layer).

   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

Expires September 2005                                        [page 5]


INTERNET DRAFT  AR for IP over MPEG-2 networks              April 2005


   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.
   to two terrestrial TV transmission cells.

   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 signalling.
   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) [ID-
   ipdvb-arch], 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, plus optional
   overhead including an Adaptation Field, encryption details and time
   stamp information to synchronise a set of related TS Logical
   Channels.

   UDL: Unidirectional link: A one-way transmission IP over DVB link,
   e.g., a broadcast satellite link.

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






Expires September 2005                                        [page 6]


INTERNET DRAFT  AR for IP over MPEG-2 networks              April 2005


   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 Ultra Lightweight Encapsulation (ULE) [ID-
   ARCH,ID-ULE].

   The general IP over MPEG-2 AR requirements are summarized below:

        - A scalable and efficient transmission.
        - A method to represent the AR information.
        - Support for scoping of the addresses.
        - Incremental update of clients with AR information.
        - Procedures for purging stale client AR information.
        - A method to identify the Server sourcing AR information.
        - A method to install AR information at the AR server
          (unsolicited registration).
        - Security associations to authenticate the 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. Examples of
   overlapping IP address assignments include:

   (i)  Private unicast addresses (e.g. in IPv4, 10/8 prefix;
        172.16/12 prefix; 192.168/16 prefix) should be confined to
        one addressed area. IPv6 also defines link-local addresses that
        must not be forwarded beyond the link on which they were first
        sent.

   (ii) Some multicast addresses, (e.g., the scoped multicast
        addresses sometimes used in private networks). These are
        only valid within an addressed area (examples for IPv4
        include; 239/8; 224.0.0/24; 224.0.1/24). Similar cases
        exist for some IPv6 multicast addresses.

   (iii)Scoped multicast addresses.  Forwarding of these addresses
        is controlled by the scope associated with the address.


   Overlapping address assignments may also occur at L2, where the same
   NPA/MAC address is used to identify multiple receivers [ID-IPDVB-
   ARCH]:

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


Expires September 2005                                        [page 7]


INTERNET DRAFT  AR for IP over MPEG-2 networks              April 2005


   (ii) The NPA broadcast address (all 1 MAC address). Traffic
        with this address should be confined to one addressed area.

   (iii) IP and other protocols may view sets of MAC multicast
        addresses as link-local, and may produce unexpected results if
        frames with these address are distributed across several
        private networks.


   Reception of unicast packets destined for another addressed area
   will lead to an increase in the rate of received packets by systems
   connected via the network. Reception of the additional network
   traffic may contribute to processing load, but should not lead to
   unexpected protocol behaviour. 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 may be required at two levels. At the
   upper level, the AR procedure needs to associate an IP address with
   a specific NPA/MAC address. At the lower level, the IP (or MAC)
   address needs to be associated with a specific TS Logical Channel
   (PID value) and the corresponding TS Multiplex.

   The same unicast IP address may be associated with more than one TS
   Logical Channel within the same scope [DVB-DAT]. These may have
   different content, but there is also the possibility of a Receiver
   receiving duplicated copies of packets.


3.2 Multicast Support

   Multicast is an important application for MPEG-2 Transmission
   Networks, since it exploits the advantages of native support for
   link broadcast.

   Multicast address resolution occurs at one level in associating a
   specific L2 address with am IP Group Destination Address (section
   5).  In IPv4 and IPv6 over Ethernet, this association is normally a
   direct mapping, and this is the default method also specified in
   both ULE [ID-IPDVB-ULE] and in MPE [ETSI-DAT].

   Address resolution must also occur at the MPEG-2 level (section 4).
   The goal of this multicast address resolution is the association of
   an IPv4 or IPv6 multicast address with a specific TS Logical Channel
   (PID value) and the corresponding TS Multiplex.  This association
   needs to permit a large number of active multicast groups, and
   should minimise the processing load at the Receiver when filtering
   and forwarding IP multicast packets. For example, schemes that may

Expires September 2005                                        [page 8]


INTERNET DRAFT  AR for IP over MPEG-2 networks              April 2005


   be easily implemented in hardware would be beneficial, since these
   may relieve the drivers and operating systems from discarding
   unwanted multicast traffic.

   There are specific issues concerning IPv4 and IPv6 multicast over
   MPEG-2 Transmission Networks:

   (i)  Mapping IP multicast groups to the underlying MPEG-2 TS
        Logical Channel (PID) and the MPEG-2 TS Multiplex.

   (ii) Provide signalling information to allow a receiver to
        locate an IP multicast flow within an MPEG-2 TS Multiplex.

   (iii) Determining group membership (e.g. utilising IGMP/MLD).

   Methods are required to identify the scope of an address when an
   MPEG-2 transmission network supports several logical IP network and
   carries groups within different multicast scopes.

   Appropriate procedures need to specify the correct action when the
   same multicast group is available on separate TS Logical Channels.
   This could arise when different end hosts act as senders to
   contribute IP packets with the same IP Group Destination Address in
   the ASM address range.

   Another different 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 also known as Simulcasting [DVB-DAT]). In this
   case, at the IP level, the host/router may be unaware of this
   duplication and it needs to be detected by other means.






















Expires September 2005                                        [page 9]


INTERNET DRAFT  AR for IP over MPEG-2 networks              April 2005


4. MPEG-2 Address Resolution

   In this section, current MPEG-2 address resolution mechanisms are
   reviewed.


4.1 Static configuration.

   The static mapping option, where IP addresses or flows are
   statically mapped to specific PIDs is the equivalent to signalling
   "out-of-band". The application programmer, installing engineer, or
   user receives the mapping via some outside means, not in the MPEG-2
   TS. This is useful for testing, experimental networks, small
   subnetworks and closed domains.

   A single "well-known" PID is a specialisation of this. This scheme
   is used by current DOCSIS cable modems [DOCSIS], where all IP
   traffic is placed into the specified TS stream. Section or MAC
   filtering may be used to differentiate subnetworks.


4.1.1 MPEG-2 Cable Networks

   Cable networks use a different transmission schemes for downstream,
   (headend to cable modem/STB) and upstream (cablemodem/STB to
   headend) transmission.

   The information is sent (on the downstream) to the STBs as
   IP/Ethernet packets encapsulated in MPEG-2 TS Packets sent on a
   single well-known TS Logical Channel (PID); there is no use of
   inband 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 in cable networks for IP traffic was proprietary,
   and did not usually employ a table-based address resolution method.
   Proprietary methods continue to be used in some cases where STBs
   require interaction. In this case, equipment at the headend may act
   as gateways between the cablemodem/STB and the Internet. These
   gateways receive L2 information and allocate an IP address.

   DOCSIS utilises DHCP for IP client configuration. The Cable Modem
   Terminal System (CMTS) provides a DHCP server that allocates IP
   addresses to DOCSIS cable modems and STBs. The MPEG-2 Transmission
   Network provides a L2 bridged network to the cable modem. This
   usually acts as a DHCP relay for IP devices [RFC2131, RFC3256].
   Issues in deployment of IPv6 are described in [ID-V6OPS-DEPLOY].





Expires September 2005                                       [page 10]


INTERNET DRAFT  AR for IP over MPEG-2 networks              April 2005


4.2 MPEG-2 Table-Based Address Resolution

   The information about the set of MPEG-2 TS streams carried over a TS
   Multiplex can be distributed via tables that are assigned a specific
   and well-known set of PID values. This design requires access to and
   processing of the SI Table information [ETSI-SI, ETSI-SI1].  This
   scheme reflects the complexity of delivering and co-ordinating the
   various TS associated with multimedia TV. A TS Multiplex may provide
   AR information for IP services by integrating additional information
   into the existing MPEG-2 tables or by transmitting additional SI
   Tables 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 MPEG-2 TS.

   (ii) Application Information Table (AIT) in the Multimedia
        Home Platform (MHP) specifications [ETSI-MHP].

   (iii)Multicast Mapping Table (MMT) an MPEG-2 Table employed by some
        DVB-RCS systems to provide uni-directional address resolution
        of IPv4 multicast addresses to MPEG-2 TS.

   The MMT and AIT are used for specific applications. The INT [DVB-
   DAT] is a more general DVB standard, that supports MAC, IPv4, and
   IPv6 AR when used in combination with the other MPEG-2 tables.


4.2.1 IP/MAC Notification Table (INT) and its usage

   The INT provides a mechanism for carrying information about the
   location of IP/L2 flows within a DVB network. The INT defines the
   concept of a Platform_ID, which may identify the addressing scope
   for a set of IP/L2 streams and/or Receivers. A Platform may span
   several transport streams within one or multiple DVB multiplexes and
   represents a single IP network with a harmonized address space (i.e.
   addressing scope). This allows for the coexistence of several non-
   harmonized IP/MAC address spaces on the same DVB network.

   The INT allows both fully-specified IP addresses and prefix matching
   to reduce the size of table (and hence enhance signalling
   efficiency). An IPv4/IPv6 "subnet mask" may be given in full form or
   in 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.


Expires September 2005                                       [page 11]


INTERNET DRAFT  AR for IP over MPEG-2 networks              April 2005


   In addition to identification and security descriptors, the
   following descriptors are defined for address binding in INT tables:

   (i)   target_MAC_address_descriptor: The descriptor used to
         describe a single or set of MAC addresses (and their mask).

  (ii) target_MAC_address_range_descriptor: May be used to set
        filters.

   (iii) target_IP_address_descriptor: The descriptor describing a
         single or set of IPv4 unicast or multicast addresses (and
         their mask).

   (iv) target_IP_slash_descriptor:  Allows definition and announcement
        of an IPv4 prefix.

   (v)  target_IP_source_slash_descriptor: Uses source and destination
        addresses to target a single or set of systems.

   (vi) IP/MAC  stream_location_descriptor: This descriptor locates an
        IP/MAC stream in a DVB network.

   The following descriptors provide corresponding functions for IPv6
   addresses:

        target_IPv6_address_descriptor
        target_IPv6_slash_descriptor
        and target_IPv6_source_slash_descriptor

   The ISP_access_mode_descriptor allows specification of a second
   address descriptor to access an ISP via an alternative non-DVB
   (possibly non-IP) network.

   The INT provides a set of descriptors to specify addressing in a DVB
   network. One key benefit is that the approach follows the MPEG-2
   signaling methods and is integrated with the other signalling
   information. This allows the INT to operate in the presence of
   (re)multiplexors [ipdvb-arch] and refer to PID values that are
   carried within a number of different TS Multiplexes. This makes it
   well-suited to a Broadcast TV Scenario [ipdvb-arch].

   The principle drawbacks are that while the INT, there is a need for
   a Gateway to introduce associated PSI/SI MPEG-2 control information.
   This control information also needs to be processed at the receiver
   below the IP layer, and 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. The
   method is currently defined only for Multi-Protocol Encapsulation
   (MPE) and would need extension to support other schemes.



Expires September 2005                                       [page 12]


INTERNET DRAFT  AR for IP over MPEG-2 networks              April 2005


4.2.2 Multicast Mapping Table (MMT) and its usage

   The Multicast Mapping Table (MMT) is an MPEG-2 level control table
   to that associates a set of multicast addresses with the
   corresponding PID values.  This table allows a DVB-RCS Forward Link
   Subsystem (FLSS) to specify the mapping of IPv4 addresses to PID
   values within a specific TS Multiplex. Receivers (DVB-RCS Return
   Channel Satellite Terminals, RCSTs) may use this table to determine
   the PID values associated with an IP multicast flow that it requires
   to receive. The MMT is not currently a part of the DVB-RCS
   specification.


4.2.3 Application Information Table (AIT) and its usage

   The DVB Multimedia Home Platform (MHP) specification does not define
   a specific AR function. However, the MHP Standard specifies an
   Application Information Table (AIT) that allows MHP Receivers to
   receive a variety of control information. The AIT uses a DSMCC
   format table providing information about data broadcasts, the
   required activation state of applications carried by a broadcast
   stream, etc. This information allows a broadcaster to request that a
   Receiver change the activation state of an application, and to
   direct applications to receive specific multicast packet flows
   (using IPv4 or IPv6 descriptors).  In MHP, AR is not seen as a
   specific function, but as a part of a wider configuration and
   control function.

4.2.4 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, encourage the development of technology
   specific solutions and do not fully adopt IP-centric approaches that
   would enable easier use of the MPEG-2 bearer as a link technology
   within the wider Internet.

4.3 IP-based resolution of TS Logical Channels

   As MPEG-2 transmission networks evolve to become multiservice
   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, transmission using IP packets could
   also be used for address resolution. The advantages of using a
   IP-based address resolution for TS 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.

Expires September 2005                                       [page 13]


INTERNET DRAFT  AR for IP over MPEG-2 networks              April 2005



   (ii) Uniformity:
   An IP-based protocol can provide a common method across
   different network scenarios for IP/MAC address mappings to TS
   Logical Channels (PID Values).

   (iii) Extensibility:
   IP-based AR mechanisms allow an independent evolution of the AR
   protocol. This includes dynamic methods to request address
   resolution and the ability to include other L2 information
   (e.g. Encryption keys).

   (iv) Integration
   The information exchanged by IP-based AR protocols can easily
   be integrated as a a part of the IP network layer, simplifying
   support for AAA, policy, OAM, mobility, configuration control,
   etc. that combine AR with security.

   Drawbacks of an IP-based method include:

   One drawback of IP-based AR is that this method can not operate
   over an MPEG-2 Transmission Network that uses remultiplexors
   [ipdvb-arch] to 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
   [ipdvb-arch].

   IP-based methods can also introduce concerns about the
   integrity of the information and authentication of the sender
   [ipdvb-arch] (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 devices from the larger Internet creating
   virtual MPEG2 private networks.) IP-based solutions should
   therefore implement security mechanisms that may be used to
   authenticate the sender and verify the integrity of the AR
   information, as a part of a larger security framework.

4.3.1 IP-based multicast resolution of TS Logical Channels

   AR resolution must also be performed to associate the IP multicast
   Group Destination Address with an MPEG-2 layer TS Logical Channel
   (PID) and TS Multiplex. Solutions have been described in 4.2 to
   perform this below the IP layer using MPEG-2 Tables.  Such methods
   currently perform a direct mapping (where a single address or set of
   addresses are associated with a specific PID value).

   There is an opportunity to define an IP-level method that could use
   an IP multicast protocol over a well-known IP multicast address.
   Scalability is an important feature of any multicast AR protocol,
   methods that employ prefix matching (e.g. where a range of
   source/destination addresses are matched to a single entry are

Expires September 2005                                       [page 14]


INTERNET DRAFT  AR for IP over MPEG-2 networks              April 2005


   desirable), but so also are methods that allow a range of addresses
   to mapped to a set of TS Logical Channels (similar to the mapping of
   IP Group Destination Addresses to Ethernet MAC addresses).


















































Expires September 2005                                       [page 15]


INTERNET DRAFT  AR for IP over MPEG-2 networks              April 2005


5. Mapping IP addresses to NPA/MAC addresses

   This section reviews IETF protocols that may be used to assign and
   manage the mapping of IP addresses to/from NPA/MAC addresses.

   IP Encapsulation Gateways may require AR information to select an
   appropriate MAC/NPA address in the SNDU header [ipdvb-arch] (see
   also section 6). The information to complete this header may be
   taken directly from a neighbour/arp cache, or may require the
   Gateway to retrieve the information using an AR protocol. The way in
   which this information is collected will depend upon whether the
   Gateway functions as a Router (at L3) or a Bridge (at L2).

   Two IETF-defined protocols for mapping IP addresses to NPA/MAC
   addresses are ARP [RFC-ARP] and NDP [RFC-ND] for IPv4 and IPv6
   respectively. Both protocols are normally used in a bi-directional
   mode, although both also permit unsolicited transmission of
   mappings. The mapping defined in [RFC2464] may result in use of a
   large number of L2 MAC addresses.

   ARP requires support for L2 broadcast packets.

   << inputs requested on ARP scalability to large receiver groups >>

   << inputs requested on ARP security for wireless networks >>

   << inputs requested on ARP scoping when supporting multiple ISPs >>


   The NDP uses a set of IP multicast addresses. In large networks,
   many multicast addresses are likely to be used, although little
   traffic is likely to be sent in each group. The AR multicast
   mechanism therefore needs to be able to support this in a scalable
   manner (see section XXX).

   << inputs requested on NDP scalability to large receiver groups >>

   << inputs requested on NDP security for wireless networks >>

   << inputs requested on NDP scoping when supporting multiple ISPs >>




5.1 Uni-directional links supporting uni-directional connectivity

   Most MPEG-2 Transmission Networks provide a Uni-Directional
   broadcast link (UDL), with no return path. Such links may be used
   for unicast applications that do not require a return path (e.g.
   based on UDP), but are more commonly used for IP multicast content
   distribution.


Expires September 2005                                       [page 16]


INTERNET DRAFT  AR for IP over MPEG-2 networks              April 2005


                                           ,-----.
                         MPEG-2 uplink    /MPEG-2 \
                      *##################( Network )
                      #                   \       /
                 +----*------+             `--.--'
                 |  Network  |                |
                 |  Provider +                v MPEG-2 downlink
                 +-----------+                |
                                        +-----v------+
                                        |   MPEG-2   |
                                        |  Receiver  |
                                        +------------+

                Figure XX: Uni-directional connectivity

   Although ARP and NDP may both operate in an unsolicited/promiscuous
   mode where they advertise information to the remote nodes, this does
   not provide an appropriate method to resolve the remote
   (destination) address in a uni-directional environment. To perform
   this task, these protocols require bi-directional L2/L3
   connectivity.

   << inputs required on receiver address assignment in this case >>


5.2 Uni-directional links with bi-directional connectivity

   Bi-directional connectivity may be realised using a pair of uni-
   directional 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. It also often exhibits asymmetric network capacity
   [RFC-ASYM].

                                           ,-----.
                         MPEG-2 uplink    /MPEG-2 \
                      *##################( Network )
                      #                   \       /
                 +----*------+             `--.--'
                 |  Network  |                |
                 |  Provider +-<-+            v MPEG-2 downlink
                 +-----------+   |            |
                                 |      +-----v------+
                                 +--<<--+   MPEG-2   |
                               uplink   |  Receiver  |
                                        +------------+

                Figure XX: Bi-directional connectivity

   The Uni-Directional Link Routing, UDLR [RFC3077] protocol may be
   used to overcome the routing issues associated with asymmetric

Expires September 2005                                       [page 17]


INTERNET DRAFT  AR for IP over MPEG-2 networks              April 2005


   routing. UDLR provides a L2 tunnelling mechanism that emulates a bi-
   directional broadcast link at L2. The uni-directional routing is
   hidden from IP and upper layer protocols.

   This section introduces how to use UDLR link layer tunnelling
   mechanisms to use ARP and ND on Uni-Directional DVB links.

    <<< Will be completed later, inputs required from WG >>>


5.3 Bi-directional links

   Bi-directional IP networks can be and are constructed by a
   combination of two MPEG-2 transmission links. The combined link
   functions as a full duplex interface. Examples of this use include
   two-way DVB-S satellite links and the DVB-RCS system.

    <<< text on DHCP, L2TP, PPoE, etc to be added by
    other volunteers >>>


5.4 IP Multicast AR

   This section describes the case where the destination network layer
   address is an IP multicast Group Destination Address.

   In MPE [DVB-DAT], the mapping of IP multicast addresses to MAC/NPA
   addresses follows normal practice for IEEE MAC Addresses when using
   IPv4 and IPv6. (A variant of DVB (DVB-H) uses a modified MAC header
   [DVB_DAT]).

   In ULE [ID-IPDVB-ULE], the L2 NPA address is optional, and is not
   necessarily required when the Receiver is able to perform efficient
   L3 multicast address filtering. When present, it follows the mapping
   of MPE and many other L2 link technologies.


















Expires September 2005                                       [page 18]


INTERNET DRAFT  AR for IP over MPEG-2 networks              April 2005


6. Link Layer Support

   This section considers layer 2 support for address resolution. It
   considers two issues that need to be considered. One is the code-
   point to be used at L2 and the other is the efficiency of
   encapsulation for transmission to utilise the AR method. The table
   below summarises the options for both MPE and ULE encapsulations.

      +-------------------------------+--------+----------------------+
      |                               | PDU    |L2 Frame Header Fields|
      | L2 Encapsulation              |overhead+----------------------+
      |                               |[bytes] |src mac|dst mac| type |
      +-------------------------------+--------+-------+-------+------+
      |6.1 ULE without dst MAC address| 8      |   -   |  -    | x    |
      |6.2 ULE with dst MAC address   | 14     |   -   |  x    | x    |
      |6.3 MPE without LLC/SNAP       | 16     |   -   |  x    | -    |
      |6.4 MPE with LLC/SNAP          | 24     |   -   |  x    | x    |
      |6.5 ULE with Bridging extension| 22     |   x   |  x    | x    |
      |6.6 ULE with Bridging & NPA    | 28     |   x   |  x    | x    |
      |6.7 MPE+LLC/SNAP+Bridging      | 38     |   x   |  x    | x    |
      +-------------------------------+--------+-------+-------+------+

      Table of L2 support and overhead (x=supported, -=not supported)

   The remainder of the section describes IETF-specified AR methods for
   use with these encapsulation formats.

6.1 ULE without a destination MAC/NPA address (D=1)

   The ULE encapsulation supports a mode (D=1) where the NPA/MAC
   address is not present in the encapsulated frame. This mode may be
   used with both IPv4 and IPv6.  When this mode is used, the Receiver
   is expected to perform network-layer filtering of packets based on
   their IP destination address. Encapsulation Gateways must ensure
   that packets are associated with a TS Logical Channel (PID value)
   that uniquely identifies the intended recipient [IP-IPDVB-ULE]. This
   requires careful consideration of the network topology when used as
   a link between IP routers (a simple case where this is permitted is
   the connection of stub networks).

   Since there is no MAC/NPA address in the SNDU, ARP and NDP are not
   required.

   Note, since IPv6 systems can (and usually do) automatically
   configure their IPv6 network address based upon a local MAC address,
   the IP driver at the Receiver may still need to access the MAC/NPA
   address of the receiving interface.






Expires September 2005                                       [page 19]


INTERNET DRAFT  AR for IP over MPEG-2 networks              April 2005


6.2 ULE with a destination NPA/MAC address (D=0)

   The IPv4 Address Resolution Protocol (ARP) [RFC826] uses an IANA-
   assigned EtherType and may be used over a link that supports ULE
   [IP-IPDVB-ULE]. Although no MAC source address is present in the
   SNDU, the protocol still communicates the source MAC address in the
   ARP record payload of any query messages that it generates.

   The ND protocol of IPv6 [RFC2461] may be used.NDP does not require
   specification of a MAC source address, although this is required for
   a node to participate in Duplicate Address Detection (DAD).

    << More info on use of ND is required, also on usage of DAD and
   SEND>>


6.3 MPE without LLC/SNAP Encapsulation

   This is the default (and sometimes only) mode specified by most MPE
   Encapsulation Gateways.

   MPE does not provide an IANA-assigned EtherType and therefore can
   not support the Address Resolution Protocol (ARP) [RFC826].

   IPv6 is not supported in this encapsulation format, and therefore it
   is not appropriate to consider the NDP.


6.4 MPE with LLC/SNAP Encapsulation

   The LLC/SNAP format of MPE provides an IANA-assigned EtherType and
   therefore may support the Address Resolution Protocol (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 ND protocol of IPv6 [RFC2461] may be used with The LLC/SNAP
   format of MPE.  NDP does not require specification of a MAC source
   address, although this is required for a node to participate in
   Duplicate Address Detection (DAD).

    << More info on use of ND is required, also on usage of DAD and
   SEND>>


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

Expires September 2005                                       [page 20]


INTERNET DRAFT  AR for IP over MPEG-2 networks              April 2005


   the ULE SNDU as that used for an NPA destination address.  The
   Receiver may optionally be configured so that MAC destination
   address value is identical to the Receiver NPA address.

   At the Encapsulation Gateway, the ULE NPA/MAC 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
   configured MAC destination address filter.

   ARP messages may be carried within a PDU that is bridged by this
   encapsulation format.

   The NDP messages may be carried within an IPv6 PDU that is bridged
   by this encapsulation format.


6.6 ULE with Bridging Header Extension and NPA Address (D=0)

   The combination of a NPA address (D=0) and a bridging extension
   header are allowed in ULE. This SNDU format supplies both a source
   and destination MAC address and a NPA destination address (i.e.
   Receiver NPA/MAC address).

   At the Encapsulation Gateway, the ULE NPA/MAC 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
   configured MAC destination address filter.

   An ARP message may be carried within a PDU that is bridged by this
   encapsulation format.

   An NDP message may be carried within an IPv6 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. This 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 Encapsulation Gateway, 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 Encapsulation Gateway, the MPE MAC destination address is
   determined by a L2 forwarding decision. Received frames may be

Expires September 2005                                       [page 21]


INTERNET DRAFT  AR for IP over MPEG-2 networks              April 2005


   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.

   An ARP message may be carried within a PDU that is bridged by this
   encapsulation format.

   An NDP message may be carried within an IPv6 PDU that is bridged by
   this encapsulation format. The MPE MAC destination address is
   determined by a L2 forwarding decision.











































Expires September 2005                                       [page 22]


INTERNET DRAFT  AR for IP over MPEG-2 networks              April 2005


7. Conclusions

   This document has described addressing and address resolution issues
   concerning the use of IP protocols over MPEG-2 transmission
   networks. A number of specific IETF protocols are discussed along
   with their expected behaviour over MPEG-2 transmission networks and
   recommendations for usage.

   In current MPEG-2 networks, a static binding may be configured for
   IP addresses and PIDs (as in some cable networks).  This information
   may also be provided by the Gateway/Multiplexor and carried in
   tables (e.g. AIT in MHP, the IP Notification Table, INT, of DVB and
   the DVB-RCS Multicast Mapping Table, MMT). This document has
   reviewed the status of these current address resolution mechanisms
   in MPEG-2 transmission networks, defined their usage and provided
   information to identify what would be needed to improve their
   support for IP protocols.


8. Security Considerations

   The normal security issues relating to the use of wireless links for
   transport Internet traffic should be considered.  Readers are also
   referred to the known security issues associated with ARP [RFC826]
   and ND [RFC-ND].


9. Acknowledgments

   The authors wish to thank Rod Walsh, Jun Takei, Michael Mercurio and
   the ipdvb WG members for their inputs. The authors would also like
   to acknowledge the support of the European Space Agency. The authors
   also thank Martin Stiemerling, for contributions of scenarios and
   configuration, and Hidetaka Izumiyama for his contributions on UDLR
   issues.


















Expires September 2005                                       [page 23]


INTERNET DRAFT  AR for IP over MPEG-2 networks              April 2005


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. http://www.etsi/org/

   [ETSI-MHP] ETSI TS 101 812, "Digital Video Broadcasting (DVB);
   Multimedia Home Platform (MHP) Specification", v1.2.1, European
   Telecommunications Standards Institute (ETSI), June 2002.
   http://www.etsi/org/

   [ETSI-SI] ETSI EN 300 468: "Digital Video Broadcasting (DVB);
   Specification for Service Information (SI) in DVB systems".

   [ISO-DSMCC] ISO/IEC IS 13818-6 "Information technology -- Generic
   coding of moving pictures and associated audio information -- Part
   6: Extensions for DSM-CC is a full software implementation",
   International Standards Organisation (ISO).

   [ISO-MPEG2] ISO/IEC IS 13818-1 "Information technology -- Generic
   coding of moving pictures and associated audio information -- Part
   1: Systems", International Standards Organisation (ISO), 2000.

   [RFC826] Plummer, D. "An Ethernet Address Resolution Protocol",
   RFC 826, IETF, November 1982.

   [RFC1112] Deering, S.E., "Host Extensions for IP Multicasting",
   RFC1112, (STD05), IETF. August 1989.

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

   [RFC3077] Duros, E., Dabbous, W., Izumiyama, H., Fujii, N., and Y.
   Zhang, "A Link-Layer Tunneling Mechanism for Unidirectional Links",
   RFC 3077, March 2001.


10.2 Informative References

   [ATSC] A/53C, "ATSC Digital Television Standard", Advanced
   Television Systems Committee (ATSC), Doc. A/53C, 2004.

   [DOCSIS]>>> Missing Reference <<<

   [ETSI-SI1] ETSI TR 101 162: "Digital Video Broadcasting (DVB);
   Allocation of Service Information (SI) codes for DVB systems".


Expires September 2005                                       [page 24]


INTERNET DRAFT  AR for IP over MPEG-2 networks              April 2005


   [ID-IPDVB-ARCH] Montpetit, M.J., Fairhurst, G., Clausen, H.D.,
   Collini-Nocker, B., and H. Linder, "Architecture for IP transport
   over MPEG-2 Networks", Internet Draft, draft-ipdvb-arch-00.txt,
   February 2005, Work in Progress, IPDVB WG.

   [ID-IPDVB-ULE] Fairhurst, G., Collini-Nocker, B. "Ultra Lightweight
   Encapsulation (ULE) for transmission of IP datagrams over an MPEG-2
   Transport Stream", February 2005, Work in Progress, IPDVB WG.

   [ID-V6OPS-DEPLOY] Asadullah, S., Ahmed, A., Popoviciu, C.,
   "ISP IPv6 Deployment Scenarios in Broadband Access Networks"
   draft-ietf-v6ops-bb-deployment-scenarios-00.txt, Work in Progress,
   IPDVB WG

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

   [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
   2131, March 1997.


10.3 Un-cited references (to be used or removed in final edit):

   [RFC1122] B. Braden, ed., "Requirements for Internet Hosts  -
   Communication Layers", RFC 1122.

   http://www.atsc.org/standards/Code_Point_Registry.pdf

   [ID-MMUSIC-IMG] Y. Nomura, R. Walsh, J-P. Luoma, J. Ott, H.
   Schulzrinne, "Protocol Requirements for Internet Media Guides",
   Internet Draft, draft-ietf-mmusic-img-req-07.txt, June 2004, Work
   in Progress, MMUSIC WG.

   [ATSC-DAT] A/90, "ATSC Data Broadcast Standard", Advanced Television
   Systems Committee (ATSC), Doc. A/090, 2000.

   [ATSC-DATG] A/91, "Recommended Practice: Implementation Guidelines
   for the ATSC Data Broadcast Standard", Advanced Television Systems
   Committee (ATSC),Doc. A/91, 2001.

   [ATSC-A92] A/92  "Delivery of IP Multicast Sessions over ATSC Data
   Broadcast", Advanced Television Systems Committee (ATSC),
   Doc. A/92, 2002.

   [ATSC-G] A/54A, "Guide to the use of the ATSC Digital Television
   Standard", Advanced Television Systems Committee (ATSC),
   Doc. A/54A, 2003.

   [ATSC-PSIP-TC] A/65B, "Program and System Information Protocol for


Expires September 2005                                       [page 25]


INTERNET DRAFT  AR for IP over MPEG-2 networks              April 2005


   Terrestrial Broadcast and Cable", Advanced Television Systems
   Committee (ATSC), Doc. A/65B, 2003.

   [ETSI-DAT1] EN 101 202, "Implementation Guide for Data", v1.2.1,
   European Telecommunications Standards Institute (ETSI), May 2003.
   http://www.etsi/org/


11. Authors' Addresses

     Godred Fairhurst
     Department of Engineering
     University of Aberdeen
     Aberdeen, AB24 3UE
     UK
     Email: gorry@erg.abdn.ac.uk
     Web: http://www.erg.abdn.ac.uk/users/gorry

     Marie-Jose Montpetit
     MJMontpetit.com
     Email: marie@mjmontpetit.com

     Hidetaka Izumiyama
     President CEO, Wishnet Inc.
     5-15-5-001 Shirokanedai, Minato-ku
     Tokyo, 108-0071, Japan
     Email: izu@wishnet.co.jp


























Expires September 2005                                       [page 26]


INTERNET DRAFT  AR for IP over MPEG-2 networks              April 2005


12. IPR Notices

12.1 Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed
   to pertain to the implementation or use of the technology described
   in this document or the extent to which any license under such
   rights might or might not be available; nor does it represent that
   it has made any independent effort to identify any such rights.
   Information on the procedures with respect to rights in RFC
   documents can be found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use
   of such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository
   at http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.


12.2 Disclaimer of Validity

   This document and the information contained herein are provided on
   an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
   INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
   IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


13. Copyright Statement

   Copyright (C) The Internet Society (2004).  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

   NOT KNOWN AT THIS TIME.




Expires September 2005                                       [page 27]


INTERNET DRAFT  AR for IP over MPEG-2 networks              April 2005


APPENDICES

   [>>> NOTE to RFC Editor: Please remove this appendix prior to
   publication]

APPENDIX A: 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.

   [>>> NOTE to RFC Editor: End of appendix]































Expires September 2005                                       [page 28]


INTERNET DRAFT  AR for IP over MPEG-2 networks              April 2005


APPENDIX B: Candidate IP-based L2 AR Protocols

   This appendix contains a list of candidate protocols for "above IP"
   AR. None of these protocols currently support the AR methods
   required for MPEG-2 Transmission Networks. Specifically they do not
   all support:

   (i) Resolution of Addresses to TS Logical Channels
   (ii) Resolution of multiple addresses in a single AR update message
   (table-based).
   (iii) Multicast transport.

   Candidate protocols include:

   ARP <extension required>
    - IPv4 only.
    - No table support <could be added>
    - Support for versioning within current implementations not clear.
    - Broadcast mode has drawbacks.
    - No obvious support for scoping to multiple addressing domains.

   ND <extension required>
    - IPv6 only.
    - No table support <could be added>
    - Use multicast address.
    - No obvious support for scoping to multiple addressing domains.

   DTCP [RFC3077]  <extension required>
    - IPv4 and IPv6.
    - Table support seems natural.
    - Uses multicast address.
    - Need to consider scoping for multiple addressing domains.
    - Not really an IP AR protocol
    - Already used on some (UDLR) links - and this new use seems
   complementary.

   AR/IP  <new protocol required>
    - IPv4 and IPv6.
    - Based on UDP or at network-layer.
    - Could use multicast address.
    - Table support possible.
    - New protocol format.
    - Could add scoping for multiple addressing domains.

   XML/foo/IP <new protocol required>
    - IPv4 and IPv6.
    - Based on UDP or at network-layer or an XML transport (which?).
    - Could use multicast address.
    - Table support seems natural.
    - New protocol format.
    - Could add scoping for multiple addressing domains.
    - Extensible/flexible to other configuration data (if required).

Expires September 2005                                       [page 29]


INTERNET DRAFT  AR for IP over MPEG-2 networks              April 2005


    - Compression of XML required to achieve efficiency comparable with
   other methods.

   <<<<

















































Expires September 2005                                       [page 30]


Html markup produced by rfcmarkup 1.124, available from https://tools.ietf.org/tools/rfcmarkup/