diff options
Diffstat (limited to 'doc/rfc/rfc4947.txt')
| -rw-r--r-- | doc/rfc/rfc4947.txt | 2299 |
1 files changed, 2299 insertions, 0 deletions
diff --git a/doc/rfc/rfc4947.txt b/doc/rfc/rfc4947.txt new file mode 100644 index 0000000..b8bf068 --- /dev/null +++ b/doc/rfc/rfc4947.txt @@ -0,0 +1,2299 @@ + + + + + + +Network Working Group G. Fairhurst +Request for Comments: 4947 University of Aberdeen +Category: Informational M.-J. Montpetit + Motorola Connected Home Solutions + July 2007 + + + Address Resolution Mechanisms for IP Datagrams over MPEG-2 Networks + +Status of This Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The IETF Trust (2007). + +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 Neighbor Discovery (ND). Such + address resolution complements the higher-layer resource discovery + tools that are used to advertise IP sessions. + + In MPEG-2 Networks, an IP address must be associated with a Packet ID + (PID) value and a specific Transmission Multiplex. This document + reviews current methods appropriate to a range of technologies (such + as DVB (Digital Video Broadcasting), ATSC (Advanced Television + Systems Committee), DOCSIS (Data-Over-Cable Service Interface + Specifications), and variants). It also describes the interaction + with well-known protocols for address management including DHCP, ARP, + and the ND protocol. + + + + + + + + + + + + + + + + +Fairhurst & Montpetit Informational [Page 1] + +RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007 + + +Table of Contents + + 1. Introduction ....................................................3 + 1.1. Bridging and Routing .......................................4 + 2. Conventions Used in This Document ...............................7 + 3. Address Resolution Requirements ................................10 + 3.1. Unicast Support ...........................................12 + 3.2. Multicast Support .........................................12 + 4. MPEG-2 Address Resolution ......................................14 + 4.1. Static Configuration ......................................15 + 4.1.1. MPEG-2 Cable Networks ..............................15 + 4.2. MPEG-2 Table-Based Address Resolution .....................16 + 4.2.1. IP/MAC Notification Table (INT) and Its Usage ......17 + 4.2.2. Multicast Mapping Table (MMT) and Its Usage ........18 + 4.2.3. Application Information Table (AIT) and Its Usage ..18 + 4.2.4. Address Resolution in ATSC .........................19 + 4.2.5. Comparison of SI/PSI Table Approaches ..............19 + 4.3. IP-Based Address Resolution for TS Logical Channels .......19 + 5. Mapping IP Addresses to MAC/NPA Addresses ......................21 + 5.1. Unidirectional Links Supporting Unidirectional + Connectivity ..............................................22 + 5.2. Unidirectional Links with Bidirectional Connectivity ......23 + 5.3. Bidirectional Links .......................................25 + 5.4. AR Server .................................................26 + 5.5. DHCP Tuning ...............................................27 + 5.6. IP Multicast AR ...........................................27 + 5.6.1. Multicast/Broadcast Addressing for UDLR ............28 + 6. Link Layer Support .............................................29 + 6.1. ULE without a Destination MAC/NPA Address (D=1) ...........30 + 6.2. ULE with a Destination MAC/NPA Address (D=0) ..............31 + 6.3. MPE without LLC/SNAP Encapsulation ........................31 + 6.4. MPE with LLC/SNAP Encapsulation ...........................31 + 6.5. ULE with Bridging Header Extension (D=1) ..................32 + 6.6. ULE with Bridging Header Extension and NPA Address (D=0) ..32 + 6.7. MPE with LLC/SNAP & Bridging ..............................33 + 7. Conclusions ....................................................33 + 8. Security Considerations ........................................34 + 9. Acknowledgments ................................................35 + 10. References ....................................................35 + 10.1. Normative References .....................................35 + 10.2. Informative References ...................................36 + + + + + + + + + + +Fairhurst & Montpetit Informational [Page 2] + +RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007 + + +1. Introduction + + This document describes the process of binding/associating IPv4/IPv6 + addresses with MPEG-2 Transport Streams (TS). This procedure is + known as Address Resolution (AR), or Neighbor Discovery (ND). Such + address resolution complements the higher layer resource discovery + tools that are used to advertise IP sessions. The document reviews + current methods appropriate to a range of technologies (DVB, ATSC, + DOCSIS, and variants). It also describes the interaction with well- + known protocols for address management including DHCP, ARP, and the + ND protocol. + + The MPEG-2 TS provides a time-division multiplexed (TDM) stream that + may contain audio, video, and data information, including + encapsulated IP Datagrams [RFC4259], defined in specification ISO/IEC + 138181 [ISO-MPEG2]. Each Layer 2 (L2) frame, known as a TS Packet, + contains a 4 byte header and a 184 byte payload. Each TS Packet is + associated with a single TS Logical Channel, identified by a 13-bit + Packet ID (PID) value that is carried in the MPEG-2 TS Packet header. + + The MPEG-2 standard also defines a control plane that may be used to + transmit control information to Receivers in the form of System + Information (SI) Tables [ETSI-SI], [ETSI-SI1], or Program Specific + Information (PSI) Tables. + + To utilize the MPEG-2 TS as a L2 link supporting IP, a sender must + associate an IP address with a particular Transmission Multiplex, and + within the multiplex, identify the specific PID to be used. This + document calls this mapping an AR function. In some AR schemes, the + MPEG-2 TS address space is subdivided into logical contexts known as + Platforms [ETSI-DAT]. Each Platform associates an IP service + provider with a separate context that shares a common MPEG-2 TS + (i.e., uses the same PID value). + + MPEG-2 Receivers may use a Network Point of Attachment (NPA) + [RFC4259] to uniquely identify a L2 node within an MPEG-2 + transmission network. An example of an NPA is the IEEE Medium Access + Control (MAC) address. Where such addresses are used, these must + also be signalled by the AR procedure. Finally, address resolution + could signal the format of the data being transmitted, for example, + the encapsulation, with any L2 encryption method and any compression + scheme [RFC4259]. + + The numbers of Receivers connected via a single MPEG-2 link may be + much larger than found in other common LAN technologies (e.g., + Ethernet). This has implications on design/configuration of the + address resolution mechanisms. Current routing protocols and some + multicast application protocols also do not scale to arbitrarily + + + +Fairhurst & Montpetit Informational [Page 3] + +RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007 + + + large numbers of participants. Such networks do not by themselves + introduce an appreciable subnetwork round trip delay, however many + practical MPEG-2 transmission networks are built using links that may + introduce a significant path delay (satellite links, use of dial-up + modem return, cellular return, etc.). This higher delay may need to + be accommodated by address resolution protocols that use this + 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 + that are IP end hosts and end hosts directly connected to bridged LAN + segments). + + Broadcast Link AR + - - - - - - - - - + | | + \/ + 1a 2b 2a + +--------+ +--------+ + ----+ R1 +----------+---+ R2 +---- + +--------+ MPEG-2 | +--------+ + Link | + | +--------+ + +---+ R3 +---- + | +--------+ + | + | +--------+ + +---+ R4 +---- + | +--------+ + | + | + + Figure 1: A routed MPEG-2 link + + Figure 1 shows a routed MPEG-2 link feeding three downstream routers + (R2-R4). AR takes place at the Encapsulator (R1) to identify each + Receiver at Layer 2 within the IP subnetwork (R2, etc.). + + When considering unicast communication from R1 to R2, several L2 + addresses are involved: + + 1a is the L2 (sending) interface address of R1 on the MPEG-2 link. + 2b is the L2 (receiving) interface address of R2 on the MPEG-2 link. + 2a is the L2 (sending) interface address of R2 on the next hop link. + + + + +Fairhurst & Montpetit Informational [Page 4] + +RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007 + + + AR for the MPEG-2 link allows R1 to determine the L2 address (2b) + corresponding to the next hop Receiver, router R2. + + Figure 2 shows a bridged MPEG-2 link feeding three downstream bridges + (B2-B4). AR takes place at the Encapsulator (B1) to identify each + Receiver at L2 (B2-B4). AR also takes place across the IP subnetwork + allowing the Feed router (R1) to identify the downstream Routers at + Layer 2 (R2, etc.). The Encapsulator associates a destination + MAC/NPA address with each bridged PDU sent on an MPEG-2 link. Two + methods are defined by ULE (Unidirectional Lightweight Encapsulation) + [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 (B2-B4) to associate the receiving MPEG-2 interface with the + set of MAC addresses that exist on the L2 subnetworks that it feeds. + Similar considerations apply when IP-based tunnels support L2 + services (including the use of UDLR (Unidirectional Links) + [RFC3077]). + + It is also possible for a bridging Encapsulator (B1) to encapsulate a + PDU with a link-specific header that also contains the MAC/NPA + address associated with a Receiver L2 interface on the MPEG-2 link + (Figure 2). In this case, the destination MAC/NPA address of the + encapsulated frame is set to the Receiver MAC/NPA address (y), rather + than the address of the final L2 destination. At a different level, + an AR binding is also required for R1 to associate the destination L2 + address 2b with R2. In a subnetwork using bridging, the systems R1 + and R2 will normally use standard IETF-defined AR mechanisms (e.g., + IPv4 Address Resolution Protocol (ARP) [RFC826] and the IPv6 Neighbor + Discovery Protocol (ND) [RFC2461]) edge-to-edge across the IP + subnetwork. + + + + + + + + + + + + + + + + + + +Fairhurst & Montpetit Informational [Page 5] + +RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007 + + + Subnetwork AR + - - - - - - - - - - - - - - - - + | | + + | MPEG-2 Link AR | + - - - - - - - - - + | | | | + \/ \/ + 1a x y 2b 2a + +--------+ +----+ +----+ +--------+ + ----+ R1 +--| B1 +----------+---+ B2 +--+ R2 +---- + +--------+ +----+ MPEG-2 | +----+ +--------+ + Link | + | +----+ + +---+ B3 +-- + | +----+ + | + | +----+ + +---+ B4 +-- + | +----+ + | + + Figure 2: A bridged MPEG-2 link + + Methods also exist to assign IP addresses to Receivers within a + network (e.g., stateless autoconfiguration [RFC2461], DHCP [RFC2131], + DHCPv6 [RFC3315], and stateless DHCPv6 [RFC3736]). Receivers may + also participate in the remote configuration of the L3 IP addresses + used in connected equipment (e.g., using DHCP-Relay [RFC3046]). + + The remainder of this document describes current mechanisms and their + use to associate an IP address with the corresponding TS Multiplex, + PID value, the MAC/NPA address and/or Platform ID. A range of + approaches is described, including Layer 2 mechanisms (using MPEG-2 + SI tables), and protocols at the IP level (including ARP [RFC826] and + ND [RFC2461]). Interactions and dependencies between these + mechanisms and the encapsulation methods are described. The document + does not propose or define a new protocol, but does provide guidance + on issues that would need to be considered to supply IP-based address + resolution. + + + + + + + + + + + +Fairhurst & Montpetit Informational [Page 6] + +RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007 + + +2. Conventions Used in This Document + + AIT: Application Information Table specified by the Multimedia Home + Platform (MHP) specifications [ETSI-MHP]. This table may carry + IPv4/IPv6 to MPEG-2 TS address resolution information. + + ATSC: Advanced Television Systems Committee [ATSC]. A framework and + a set of associated standards for the transmission of video, audio, + and data using the ISO MPEG-2 standard [ISO-MPEG2]. + + b: bit. For example, one byte consists of 8-bits. + + B: Byte. Groups of bytes are represented in Internet byte order. + + DSM-CC: Digital Storage Media Command and Control [ISO-DSMCC]. A + format for the transmission of data and control information carried + in an MPEG-2 Private Section, defined by the ISO MPEG-2 standard. + + DVB: Digital Video Broadcasting [DVB]. A framework and set of + associated standards published by the European Telecommunications + Standards Institute (ETSI) for the transmission of video, audio, and + data, using the ISO MPEG-2 Standard. + + DVB-RCS: Digital Video Broadcast Return Channel via Satellite. A + bidirectional IPv4/IPv6 service employing low-cost Receivers + [ETSI-RCS]. + + DVB-S: Digital Video Broadcast for Satellite [ETSI-DVBS]. + + Encapsulator: A network device that receives PDUs and formats these + into Payload Units (known here as SNDUs) for output as a stream of TS + Packets. + + Feed Router: The router delivering the IP service over a + Unidirectional Link. + + INT: Internet/MAC Notification Table. A unidirectional address + resolution mechanism using SI and/or PSI Tables. + + L2: Layer 2, the link layer. + + L3: Layer 3, the IP network layer. + + MAC: Medium Access Control [IEEE-802.3]. A link layer protocol + defined by the IEEE 802.3 standard (or by Ethernet v2). + + MAC Address: A 6-byte link layer address of the format described by + the Ethernet IEEE 802 standard (see also NPA). + + + +Fairhurst & Montpetit Informational [Page 7] + +RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007 + + + MAC Header: The link layer header of the IEEE 802.3 standard + [IEEE-802.3] or Ethernet v2. It consists of a 6-byte destination + address, 6-byte source address, and 2 byte type field (see also NPA, + LLC (Logical Link Control)). + + MHP: Multimedia Home Platform. An integrated MPEG-2 multimedia + Receiver, that may (in some cases) support IPv4/IPv6 services + [ETSI-MHP]. + + MMT: Multicast Mapping Table (proprietary extension to DVB-RCS + [ETSI-RCS] defining an AR table that maps IPv4 multicast addresses to + PID values). + + MPE: Multiprotocol Encapsulation [ETSI-DAT], [ATSC-A90]. A method + that encapsulates PDUs, forming a DSM-CC Table Section. Each Section + is sent in a series of TS Packets using a single Stream (TS Logical + Channel). + + MPEG-2: A set of standards specified by the Motion Picture Experts + Group (MPEG), and standardized by the International Standards + Organization (ISO/IEC 113818-1) [ISO-MPEG2], and ITU-T (in H.220). + + NPA: Network Point of Attachment. A 6-byte destination address + (resembling an IEEE MAC address) within the MPEG-2 transmission + network that is used to identify individual Receivers or groups of + Receivers [RFC4259]. + + PAT: Program Association Table. An MPEG-2 PSI control table. It + associates each program with the PID value that is used to send the + associated PMT (Program Map Table). The table is sent using the + well-known PID value of 0x000, and is required for an MPEG-2 + compliant Transport Stream. + + PDU: Protocol Data Unit. Examples of a PDU include Ethernet frames, + IPv4 or IPv6 Datagrams, and other network packets. + + PID: Packet Identifier [ISO-MPEG2]. A 13 bit field carried in the + header of each TS Packet. This identifies the TS Logical Channel to + which a TS Packet belongs [ISO-MPEG2]. The TS Packets that form the + parts of a Table Section, or other Payload Unit must all carry the + same PID value. A PID value of all ones indicates a Null TS Packet + introduced to maintain a constant bit rate of a TS Multiplex. There + is no required relationship between the PID values used for TS + Logical Channels transmitted using different TS Multiplexes. + + + + + + + +Fairhurst & Montpetit Informational [Page 8] + +RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007 + + + PMT: Program Map Table. An MPEG-2 PSI control table that associates + the PID values used by the set of TS Logical Channels/ Streams that + comprise a program [ISO-MPEG2]. The PID value used to send the PMT + for a specific program is defined by an entry in the PAT. + + Private Section: A syntactic structure constructed according to Table + 2-30 of [ISO-MPEG2]. The structure may be used to identify private + information (i.e., not defined by [ISO-MPEG2]) relating to one or + more elementary streams, or a specific MPEG-2 program, or the entire + Transport Stream. Other Standards bodies, e.g., ETSI and ATSC, have + defined sets of table structures using the private_section structure. + A Private Section is transmitted as a sequence of TS Packets using a + TS Logical Channel. A TS Logical Channel may carry sections from + more than one set of tables. + + PSI: Program Specific Information [ISO-MPEG2]. PSI is used to convey + information about services carried in a TS Multiplex. It is carried + in one of four specifically identified Table Section constructs + [ISO-MPEG2], see also SI Table. + + Receiver: Equipment that processes the signal from a TS Multiplex and + performs filtering and forwarding of encapsulated PDUs to the + network-layer service (or bridging module when operating at the link + 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 + + + +Fairhurst & Montpetit Informational [Page 9] + +RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007 + + + content carried by a specific TS Logical Channel (see ULE Stream). + Some PID values are reserved (by MPEG-2) for specific signaling. + Other standards (e.g., ATSC and DVB) also reserve specific PID + 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. A scheme that + encapsulates PDUs, into SNDUs that are sent in a series of TS Packets + using a single TS Logical Channel [RFC4326]. + + ULE Stream: An MPEG-2 TS Logical Channel that carries only ULE + encapsulated PDUs. ULE Streams may be identified by definition of a + stream_type in SI/PSI [RFC4326, ISO-MPEG2]. + +3. Address Resolution Requirements + + The MPEG IP address resolution process is independent of the choice + of encapsulation and needs to support a set of IP over MPEG-2 + encapsulation formats, including Multi-Protocol Encapsulation (MPE) + ([ETSI-DAT], [ATSC-A90]) and the IETF-defined Unidirectional + Lightweight Encapsulation (ULE) [RFC4326]. + + The general IP over MPEG-2 AR requirements are summarized below: + + - A scalable architecture that may support large numbers of + systems within the MPEG-2 Network [RFC4259]. + + - A protocol version, to indicate the specific AR protocol in use + and which may include the supported encapsulation method. + + - A method (e.g., well-known L2/L3 address/addresses) to identify + the AR Server sourcing the AR information. + + + + +Fairhurst & Montpetit Informational [Page 10] + +RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007 + + + - A method to represent IPv4/IPv6 AR information (including + security mechanisms to authenticate the AR information to + protect against address masquerading [RFC3756]). + + - A method to install AR information associated with clients at + the AR Server (registration). + + - A method for transmission of AR information from an AR Server to + clients that minimize the transmission cost (link-local + multicast is preferable to subnet broadcast). + + - Incremental update of the AR information held by clients. + + - Procedures for purging clients of stale AR information. + + An MPEG-2 transmission network may support multiple IP networks. If + this is the case, it is important to recognize the scope within which + an address is resolved to prevent packets from one addressed scope + leaking into other scopes [RFC4259]. Examples of overlapping IP + address assignments include: + + (i) Private unicast addresses (e.g., in IPv4, 10/8 prefix; + 172.16/12 prefix; and 192.168/16 prefix). Packets with + these addresses should be confined to one addressed area. + IPv6 also defines link-local addresses that must not be + forwarded beyond the link on which they were first sent. + + (ii) Local scope multicast addresses. These are only valid + within the local area (examples for IPv4 include: + 224.0.0/24; 224.0.1/24). Similar cases exist for some IPv6 + multicast addresses [RFC2375]. + + (iii) Scoped multicast addresses [RFC2365] and [RFC2375]. + Forwarding of these addresses is controlled by the scope + associated with the address. The addresses are only valid + within an addressed area (e.g., the 239/8 [RFC2365]). + + Overlapping address assignments may also occur at L2, where the same + MAC/NPA address is used to identify multiple Receivers [RFC4259]: + + (i) An MAC/NPA unicast address must be unique within the + addressed area. The IEEE-assigned MAC addresses used in + Ethernet LANs are globally unique. If the addresses are not + globally unique, an address must only be re-used by + Receivers in different addressed (scoped) areas. + + + + + + +Fairhurst & Montpetit Informational [Page 11] + +RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007 + + + (ii) The MAC/NPA address broadcast address (a L2 address of all + ones). Traffic with this address should be confined to one + addressed area. + + (iii) IP and other protocols may view sets of L3 multicast + addresses as link-local. This may produce unexpected + results if frames with the corresponding multicast L2 + addresses are distributed to systems in a different L3 + network or multicast scope (Sections 3.2 and 5.6). + + Reception of unicast packets destined for another addressed area will + lead to an increase in the rate of received packets by systems + connected via the network. Reception of the additional network + traffic may contribute to processing load, but should not lead to + unexpected protocol behaviour, providing that systems can be uniquely + addressed at L2. It does however introduce a potential Denial of + Service (DoS) opportunity. When the Receiver operates as an IP + router, the receipt of such a packet can lead to unexpected protocol + 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 + + 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 + + + +Fairhurst & Montpetit Informational [Page 12] + +RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007 + + + association is normally a direct mapping, and this is the default + method also specified in both ULE [RFC4326] and MPE [ETSI-DAT]. + + Address resolution must also occur at the MPEG-2 level (Section 4). + The goal of this multicast address resolution is to allow a Receiver + to associate an IPv4 or IPv6 multicast address with a specific TS + Logical Channel and the corresponding TS Multiplex [RFC4259]. This + association needs to permit a large number of active multicast + groups, and should minimize the processing load at the Receiver when + filtering and forwarding IP multicast packets (e.g., by distributing + the multicast traffic over a number of TS Logical Channels). Schemes + that allow hardware filtering can be beneficial, since these may + relieve the drivers and operating systems from discarding unwanted + multicast traffic. + + There are two specific functions required for address resolution in + IP multicast over MPEG-2 Networks: + + (i) Mapping IP multicast groups to the underlying MPEG-2 TS Logical + Channel (PID) and the MPEG-2 TS Multiplex at the Encapsulator. + + (ii) Provide signalling information to allow a Receiver to locate an + IP multicast flow within an MPEG-2 TS Multiplex. + + Methods are required to identify the scope of an address when an + MPEG-2 Network supports several logical IP networks and carries + groups within different multicast scopes [RFC4259]. + + Appropriate procedures need to specify the correct action when the + same multicast group is available on separate TS Logical Channels. + This could arise when different Encapsulators contribute IP packets + with the same IP Group Destination Address in the ASM (Any-Source + Multicast) address range. Another case arises when a Receiver could + receive more than one copy of the same packet (e.g., when packets are + replicated across different TS Logical Channels or even different TS + Multiplexes, a method known as Simulcasting [ETSI-DAT]). At the IP + level, the host/router may be unaware of this duplication and this + needs to be detected by other means. + + When the MPEG-2 Network is peered to the multicast-enabled Internet, + an arbitrarily large number of IP multicast group destination + addresses may be in use, and the set forwarded on the transmission + network may be expected to vary significantly with time. Some uses + of IP multicast employ a range of addresses to support a single + application (e.g., ND [RFC2461], Layered Coding Transport (LCT) + [RFC3451], and Wave and Equation Based Rate Control (WEBRC) + [RFC3738]). The current set of active addresses may be determined + dynamically via a multicast group membership protocol (e.g., Internet + + + +Fairhurst & Montpetit Informational [Page 13] + +RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007 + + + Group Management Protocol (IGMP) [RFC3376] and Multicast Listener + Discovery (MLD) [RFC3810]), via multicast routing (e.g., Protocol + Independent Multicast (PIM) [RFC4601]) and/or other means (e.g., + [RFC3819] and [RFC4605]), however each active address requires a + binding by the AR method. Therefore, there are advantages in using a + method that does not need to explicitly advertise an AR binding for + each IP traffic flow, but is able to distribute traffic across a + number of L2 TS Logical Channels (e.g., using a hash/mapping that + resembles the mapping from IP addresses to MAC addresses [RFC1112, + RFC2464]). Such methods can reduce the volume of AR information that + needs to be distributed, and reduce the AR processing. + + Section 5.6 describes the binding of IP multicast addresses to + MAC/NPA addresses. + +4. MPEG-2 Address Resolution + + The first part of this section describes the role of MPEG-2 + signalling to identify streams (TS Logical Channels [RFC4259]) within + the L2 infrastructure. + + At L2, the MPEG-2 Transport Stream [ISO-MPEG2] identifies the + existence and format of a Stream, using a combination of two PSI + tables: the Program Association Table (PAT) and entries in the + program element loop of a Program Map Table (PMT). PMT Tables are + sent infrequently and are typically small in size. The PAT is sent + using the well-known PID value of 0X000. This table provides the + correspondence between a program_number and a PID value. (The + program_number is the numeric label associated with a program). Each + program in the Table is associated with a specific PID value, used to + identify a TS Logical Channel (i.e., a TS). The identified TS is + used to send the PMT, which associates a set of PID values with the + individual components of the program. This approach de-references + the PID values when the MPEG-2 Network includes multiplexors or re- + multiplexors that renumber the PID values of the TS Logical Channels + that they process. + + In addition to signalling the Receiver with the PID value assigned to + a Stream, PMT entries indicate the presence of Streams using ULE and + MPE to the variety of devices that may operate in the MPEG-2 + transmission network (multiplexors, remultiplexors, rate shapers, + advertisement insertion equipment, etc.). + + A multiplexor or remultiplexor may change the PID values associated + with a Stream during the multiplexing process, the new value being + reflected in an updated PMT. TS Packets that carry a PID value that + is not associated with a PMT entry (an orphan PID), may, and usually + will be dropped by ISO 13818-1 compliant L2 equipment, resulting in + + + +Fairhurst & Montpetit Informational [Page 14] + +RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007 + + + the Stream not being forwarded across the transmission network. In + networks that do not employ any intermediate devices (e.g., scenarios + C,E,F of [RFC4259]), or where devices have other means to determine + the set of PID values in use, the PMT table may still be sent (but is + not required for this purpose). + + Although the basic PMT information may be used to identify the + existence of IP traffic, it does not associate a Stream with an IP + prefix/address. The remainder of the section describes IP addresses + resolution mechanisms relating to MPEG-2. + +4.1. Static Configuration + + The static mapping option, where IP addresses or flows are statically + mapped to specific PIDs is the equivalent to signalling "out-of- + band". The application programmer, installing engineer, or user + receives the mapping via some outside means, not in the MPEG-2 TS. + This is useful for testing, experimental networks, small subnetworks + and closed domains. + + A pre-defined set of IP addresses may be used within an MPEG-2 + transmission network. Prior knowledge of the active set of addresses + allows appropriate AR records to be constructed for each address, and + to pre-assign the corresponding PID value (e.g., selected to optimize + Receiver processing; to group related addresses to the same PID + value; and/or to reflect a policy for usage of specific ranges of PID + values). This presumes that the PID mappings are not modified during + transmission (Section 4). + + A single "well-known" PID is a specialization of this. This scheme + is used by current DOCSIS cable modems [DOCSIS], where all IP traffic + is placed into the specified TS stream. MAC filtering (and/or + Section filtering in MPE) may be used to differentiate subnetworks. + +4.1.1. MPEG-2 Cable Networks + + Cable networks use a different transmission scheme for downstream + (head-end to cable modem) and upstream (cable modem to head-end) + transmissions. + + IP/Ethernet packets are sent (on the downstream) to the cable + modem(s) encapsulated in MPEG-2 TS Packets sent on a single well- + known TS Logical Channel (PID). There is no use of in-band + signalling tables. On the upstream, the common approach is to use + Ethernet framing, rather than IP/Ethernet over MPEG-2, although other + proprietary schemes also continue to be used. + + + + + +Fairhurst & Montpetit Informational [Page 15] + +RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007 + + + Until the deployment of DOCSIS and EuroDOCSIS, most address + resolution schemes for IP traffic in cable networks were proprietary, + and did not usually employ a table-based address resolution method. + Proprietary methods continue to be used in some cases where cable + modems require interaction. In this case, equipment at the head-end + may act as gateways between the cable modem and the Internet. These + gateways receive L2 information and allocate an IP address. + + DOCSIS uses DHCP for IP client configuration. The Cable Modem + Terminal System (CMTS) provides a DHCP Server that allocates IP + addresses to DOCSIS cable modems. The MPEG-2 transmission network + provides a L2 bridged network to the cable modem (Section 1). This + usually acts as a DHCP Relay for IP devices [RFC2131], [RFC3046], and + [RFC3256]. Issues in deployment of IPv6 are described in [RFC4779]. + +4.2. MPEG-2 Table-Based Address Resolution + + The information about the set of MPEG-2 Transport Streams carried + over a TS Multiplex can be distributed via SI/PSI Tables. These + tables are usually sent periodically (Section 4). This design + requires access to and processing of the SI Table information by each + Receiver [ETSI-SI], [ETSI-SI1]. This scheme reflects the complexity + of delivering and coordinating the various Transport Streams + associated with multimedia TV. A TS Multiplex may provide AR + information for IP services by integrating additional information + into the existing control tables or by transmitting additional SI + Tables that are specific to the IP service. + + Examples of MPEG-2 Table usage that allows an MPEG-2 Receiver to + identify the appropriate PID and the multiplex associated with a + specific IP address include: + + (i) IP/MAC Notification Table (INT) in the DVB Data standard + [ETSI-DAT]. This provides unidirectional address resolution of + IPv4/IPv6 multicast addresses to an MPEG-2 TS. + + (ii) Application Information Table (AIT) in the Multimedia Home + Platform (MHP) specifications [ETSI-MHP]. + + (iii) Multicast Mapping Table (MMT) is an MPEG-2 Table employed by + some DVB-RCS systems to provide unidirectional address + resolution of IPv4 multicast addresses to an MPEG-2 TS. + + The MMT and AIT are used for specific applications, whereas the INT + [ETSI-DAT] is a more general DVB method that supports MAC, IPv4, and + IPv6 AR when used in combination with the other MPEG-2 tables + (Section 4). + + + + +Fairhurst & Montpetit Informational [Page 16] + +RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007 + + +4.2.1. IP/MAC Notification Table (INT) and Its Usage + + The INT provides a set of descriptors to specify addressing in a DVB + network. The use of this method is specified for Multiprotocol + Encapsulation (MPE) [ETSI-DAT]. It provides a method for carrying + information about the location of IP/L2 flows within a DVB network. + A Platform_ID identifies the addressing scope for a set of IP/L2 + streams and/or Receivers. A Platform may span several Transport + Streams carried by one or multiple TS Multiplexes and represents a + single IP network with a harmonized address space (scope). This + allows for the coexistence of several independent IP/MAC address + scopes within an MPEG-2 Network. + + The INT allows both fully-specified IP addresses and prefix matching + to reduce the size of the table (and hence enhance signalling + efficiency). An IPv4/IPv6 "subnet mask" may be specified in full + form or by using a slash notation (e.g., /127). IP multicast + addresses can be specified with or without a source (address or + range), although if a source address is specified, then only the + slash notation may be used for prefixes. + + In addition, for identification and security descriptors, the + following descriptors are defined for address binding in INT tables: + + (i) target_MAC_address_descriptor: A descriptor to describe a + single or set of MAC addresses (and their mask). + + (ii) target_MAC_address_range_descriptor: A descriptor that may be + used to set filters. + + (iii) target_IP_address_descriptor: A descriptor describing a single + or set of IPv4 unicast or multicast addresses (and their mask). + + (iv) target_IP_slash_descriptor: Allows definition and announcement + of an IPv4 prefix. + + (v) target_IP_source_slash_descriptor: Uses source and destination + addresses to target a single or set of systems. + + (vi) IP/MAC stream_location_descriptor: A descriptor that locates an + IP/MAC stream in a DVB network. + + The following descriptors provide corresponding functions for IPv6 + addresses: + + target_IPv6_address_descriptor + target_IPv6_slash_descriptor + and target_IPv6_source_slash_descriptor + + + +Fairhurst & Montpetit Informational [Page 17] + +RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007 + + + 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. + + A Multicast Mapping Table (MMT) may be carried in an MPEG-2 control + table that associates a set of multicast addresses with the + corresponding PID values [MMT]. This table allows a DVB-RCS Forward + Link Subsystem (FLSS) to specify the mapping of IPv4 and IPv6 + multicast addresses to PID values within a specific TS Multiplex. + Receivers (DVB-RCS Return Channel Satellite Terminals (RCSTs)) may + use this table to determine the PID values associated with an IP + multicast flow that it requires to receive. The MMT is specified by + the SatLabs Forum [MMT] and is not currently a part of the DVB-RCS + specification. + +4.2.3. Application Information Table (AIT) and Its Usage + + The DVB Multimedia Home Platform (MHP) specification [ETSI-MHP] does + not define a specific AR function. However, an Application + Information Table (AIT) is defined that allows MHP Receivers to + receive a variety of control information. The AIT uses an MPEG-2 + signalling table, providing information about data broadcasts, the + required activation state of applications carried by a broadcast + stream, etc. This information allows a broadcaster to request that a + Receiver change the activation state of an application, and to direct + + + + + +Fairhurst & Montpetit Informational [Page 18] + +RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007 + + + applications to receive specific multicast packet flows (using IPv4 + or IPv6 descriptors). In MHP, AR is not seen as a specific function, + but as a part of a wider configuration and control function. + +4.2.4. Address Resolution in ATSC + + ATSC [ATSC-A54A] defines a system that allows transmission of IP + packets within an MPEG-2 Network. An MPEG-2 Program (defined by the + PMT) may contain one or more applications [ATSC-A90] that include IP + multicast streams [ATSC-A92]. IP multicast data are signalled in the + PMT using a stream_type indicator of value 0x0D. A MAC address list + descriptor [SCTE-1] may also be included in the PMT. + + The approach focuses on applications that serve the transmission + network. A method is defined that uses MPEG-2 SI Tables to bind the + IP multicast media streams and the corresponding Session Description + Protocol (SDP) announcement streams to particular MPEG-2 Program + Elements. Each application constitutes an independent network. The + MPEG-2 Network boundaries establish the IP addressing scope. + +4.2.5. Comparison of SI/PSI Table Approaches + + The MPEG-2 methods based on SI/PSI meet the specified requirements of + the groups that created them and each has their strength: the INT in + terms of flexibility and extensibility, the MMT in its simplicity, + and the AIT in its extensibility. However, they exhibit scalability + constraints, represent technology specific solutions, and do not + fully adopt IP-centric approaches that would enable easier use of the + MPEG-2 bearer as a link technology within the wider Internet. + +4.3. IP-Based Address Resolution for TS Logical Channels + + As MPEG-2 Networks evolve to become multi-service networks, the use + of IP protocols is becoming more prevalent. Most MPEG-2 Networks now + use some IP protocols for operations and control and data delivery. + Address resolution information could also be sent using IP transport. + At the time of writing there is no standards-based IP-level AR + protocol that supports the MPEG-2 TS. + + There is an opportunity to define an IP-level method that could use + an IP multicast protocol over a well-known IP multicast address to + resolve an IP address to a TS Logical Channel (i.e., a Transport + Stream). The advantages of using an IP-based address resolution + include: + + + + + + + +Fairhurst & Montpetit Informational [Page 19] + +RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007 + + + (i) Simplicity: + The AR mechanism does not require interpretation of L2 tables; + this is an advantage especially in the growing market share for + home network and audio/video networked entities. + + (ii) Uniformity: + An IP-based protocol can provide a common method across + different network scenarios for both IP to MAC address mappings + and mapping to TS Logical Channels (PID value associated with a + Stream). + + (iii) Extensibility: + IP-based AR mechanisms allow an independent evolution of the AR + protocol. This includes dynamic methods to request address + resolution and the ability to include other L2 information + (e.g., encryption keys). + + (iv) Integration: + The information exchanged by IP-based AR protocols can easily + be integrated as a part of the IP network layer, simplifying + support for AAA, policy, Operations and Management (OAM), + mobility, configuration control, etc., that combine AR with + 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 associated + with the TS Logical Channels during the multiplexing operation + (Section 4). This makes the method unsuitable for use in + deployed broadcast TV networks [RFC4259]. + + (ii) IP-based methods can introduce concerns about the integrity of + the information and authentication of the sender [RFC4259]. + (These concerns are also applicable to MPEG-2 Table methods, + but in this case the information is confined to the L2 network, + or parts of the network where gateway devices isolate the + MPEG-2 devices from the larger Internet creating virtual MPEG-2 + private networks.) IP-based solutions should therefore + implement security mechanisms that may be used to authenticate + the sender and verify the integrity of the AR information as a + part of a larger security framework. + + An IP-level method could use an IP multicast protocol running an AR + Server (see also Section 5.4) over a well-known (or discovered) IP + multicast address. To satisfy the requirement for scalability to + networks with a large number of systems (Section 1), a single packet + needs to transport multiple AR records and define the intended scope + + + +Fairhurst & Montpetit Informational [Page 20] + +RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007 + + + for each address. Methods that employ prefix matching are desirable + (e.g., where a range of source/destination addresses are matched to a + single entry). It can also be beneficial to use methods that permit + a range of IP addresses to be mapped to a set of TS Logical Channels + (e.g., a hashing technique similar to the mapping of IP Group + Destination Addresses to Ethernet MAC addresses [RFC1112] [RFC2464]). + +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 + neighbor/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 bidirectional 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) [RFC4346]. The router + ignores any ARP RESPONSEs not associated with clients using the + secure tunnels. Therefore, only legitimate ARP RESPONSEs are used + + + + +Fairhurst & Montpetit Informational [Page 21] + +RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007 + + + 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 each client + typically only listens to a restricted set of group destination + addresses and little traffic is usually sent in each group. + Therefore, Layer 2 AR for MPEG-2 Networks must support this in a + scalable manner. + + A large number of ND messages may cause a large demand for performing + asymmetric operations. The base ND protocol limits the rate at which + multicast responses to solicitations can be sent. Configurations may + need to be tuned when operating with large numbers of Receivers. + + The default parameters specified in the ND protocol [RFC2461] can + introduce interoperability problems (e.g., a failure to resolve when + the link RTT (round-trip time) exceed 3 seconds) and performance + degradation (duplicate ND messages with a link RTT > 1 second) when + used in networks where the link RTT is significantly larger than + experienced by Ethernet LANs. Tuning of the protocol parameters + (e.g., RTR_SOLICITATION_INTERVAL) is therefore recommended when using + network links with appreciable delay (Section 6.3.2 of [RFC2461]). + + 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. In addition, SEND does not require the configuration + of per-host keys and can coexist with the use of both SEND and + insecure ND on the same link. + + The ND Protocol is also used by IPv6 systems to perform other + functions beyond address resolution, including Router Solicitation / + Advertisement, Duplicate Address Detection (DAD), Neighbor + Unreachability Detection (NUD), and Redirect. These functions are + useful for hosts, even when address resolution is not required. + +5.1. Unidirectional Links Supporting Unidirectional Connectivity + + MPEG-2 Networks may provide a Unidirectional 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. + + + + + + + +Fairhurst & Montpetit Informational [Page 22] + +RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007 + + + /-----\ + MPEG-2 Uplink /MPEG-2 \ + ###################( Network ) + # \ / + +----#------+ \--.--/ + | Network | | + | Provider + v MPEG-2 Downlink + +-----------+ | + +-----v------+ + | MPEG-2 | + | Receiver | + +------------+ + + Figure 3: Unidirectional connectivity + + The ARP and ND protocols require bidirectional L2/L3 connectivity. + They do not provide an appropriate method to resolve the remote + (destination) address in a unidirectional 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. Unidirectional Links with Bidirectional Connectivity + + Bidirectional connectivity may be realized using a unidirectional + link in combination with another network path. Common combinations + are a Feed link using MPEG-2 satellite transmission and a return link + using terrestrial network infrastructure. This topology is often + known as a Hybrid network and has asymmetric network routing. + + /-----\ + MPEG-2 uplink /MPEG-2 \ + ###################( Network ) + # \ / + +----#------+ \--.--/ + | Network | | + | Provider +-<-+ v MPEG-2 downlink + +-----------+ | | + | +-----v------+ + +--<<--+ MPEG-2 | + Return | Receiver | + Path +------------+ + + Figure 4: Bidirectional connectivity + + + + +Fairhurst & Montpetit Informational [Page 23] + +RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007 + + + The Unidirectional 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 unidirectional routing from the + IP and upper layer protocols by providing a L2 tunnelling mechanism + that emulates a bidirectional 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 unidirectional links employ wireless technology for the + forward (Feed) link, 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 minimize 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 recognizes 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 encapsulation format also permits + packets to be sent without specifying a MAC/NPA address, where + this is desirable (Section 6.1 and 6.5). + + (ii) A Receiver needs the Feed Router MAC/NPA address. + + 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. + + + + + + +Fairhurst & Montpetit Informational [Page 24] + +RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007 + + + (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 the 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. Bidirectional Links + + Bidirectional 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. + + + + + + + + + +Fairhurst & Montpetit Informational [Page 25] + +RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007 + + +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 (mapping the IP address to the L2 address). + + 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/server processing 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 optimization to conserve L2 bandwidth). + + Equivalent methods could provide IPv6 AR. Procedures for + intercepting ND messages are defined in [RFC4389]. To perform an AR + Server function, the AR information must also be cached. A caching + AR proxy stores the system state within a middle-box device. This + resembles a classic man-in-the-middle security attack; interactions + with SEND are described in [SP-ND]. + + Methods are needed to purge stale AR data from the cache. The + consistency of the cache must also be considered when the Receiver + bindings can change (e.g., IP mobility, network topology changes, or + intermittent Receiver connectivity). In these cases, the use of old + (stale) information can result in IP packets being directed to an + inappropriate L2 address, with consequent packet loss. + + 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 + + + + +Fairhurst & Montpetit Informational [Page 26] + +RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007 + + + this function (Section 4). AR Servers can also be implemented using + non-IETF AR protocols to provide the AR information required by + Receivers. + +5.5. DHCP Tuning + + DHCP [RFC2131] and DHCPv6 [RFC3315] may be used over MPEG-2 Networks + with bidirectional connectivity. 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 the allocation of network addresses to systems. + + The configuration of DHCP Servers and DHCP Clients should take into + account the local link round trip delay (possibly including the + additional delay from bridging, e.g., using UDLR). A large number of + clients can 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 an 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 the 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 [ETSI-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]. + + + + + + +Fairhurst & Montpetit Informational [Page 27] + +RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007 + + + The L2 group addressing method specified in [RFC1112] and [RFC2464] + can result in more than one IP destination address being mapped 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. Therefore, senders may independently + select an IP group destination address that could map to the same L2 + address if forwarded onto the same L2 link. The resulting addressing + overlap at L2 can increase the volume of traffic forwarded to L3, + where it then needs to be filtered. + + 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 an 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. + +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. To avoid forwarding loops, RFC 3077 notes that a + Receiver needs to be configured with appropriate filter rules to + ensure that it discards packets that originate from an attached + network and are later received over the Feed link. + + When the encapsulation includes an MAC/NPA source address, re- + broadcast 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 [RFC4605]), 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 encapsulation formats also do not include an MAC/NPA source + address (Table 1). 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 + + + +Fairhurst & Montpetit Informational [Page 28] + +RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007 + + + all-zero IP source address (e.g., BOOTP (bootstrap protocol) + [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. + +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 summarizes the options for + both MPE ([ETSI-DAT], [ATSC-A90]) and ULE [RFC4326] encapsulations. + + [RFC4840] describes issues and concerns that may arise when a link + can support multiple encapsulations. In particular, it identifies + problems that arise when end hosts that belong to the same IP network + employ different incompatible encapsulation methods. An Encapsulator + must therefore use only one method (e.g., ULE or MPE) to support a + single IP network (i.e., set of IPv4 systems sharing the same subnet + broadcast address or same IPv6 prefix). All Receivers in an IP + network must receive all IP packets that use a broadcast (directed to + all systems in the IP network) or a local-scope multicast address + (Section 3). Packets with these addresses are used by many IP-based + protocols including service discovery, IP AR, and routing protocols. + Systems that fail to receive these packets can suffer connectivity + failure or incorrect behaviour (e.g., they may be unable to + participate in IP-based discovery, configuration, routing, and + announcement protocols). Consistent delivery can be ensured by + transmitting link-local multicast or broadcast packets using the same + Stream that is used for unicast packets directed to this network. A + Receiver could simultaneously use more than one L2 AR mechanism. + This presents a potential conflict when the Receiver receives two + different bindings for the same identifier. When multiple systems + advertise AR bindings for the same identifiers (e.g., Encapsulators), + they must ensure that the advertised information is consistent. + Conflicts may also arise when L2 protocols duplicate the functions of + IP-based AR mechanisms. + + In ULE, the bridging format may be used in combination with the + normal mode to address packets to a Receiver (all ULE Receivers are + required to implement both methods). Frames carrying IP packets + using the ULE Bridging mode, that have a destination address + corresponding to the MAC address of the Receiver and have an IP + address corresponding to a Receiver interface, will be delivered to + the IP stack of the Receiver. All bridged IP multicast and broadcast + frames will also be copied to the IP stack of the Receiver. + + + +Fairhurst & Montpetit Informational [Page 29] + +RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007 + + + Receivers must filter (discard) frames that are received with a + source address that matches an address of the Receiver itself + [802.1D]. It must also prevent forwarding frames already sent on a + connected network. For each network interface, it must therefore + filter received frames where the frame source address matches a + unicast destination address associated with a different network + interface [802.1D]. + + +-------------------------------+--------+----------------------+ + | | 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 with LLC/SNAP&Bridging | 38 | x | x | x | + +-------------------------------+--------+-------+-------+------+ + + Table 1: L2 Support and Overhead (x =supported, - =not supported) + + The remainder of the section describes IETF-specified AR methods for + use with these encapsulation formats. Most of these methods rely on + bidirectional communications (see Sections 5.1, 5.2, and 5.3 for a + discussion of this). + +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 + L3 filtering of packets based on their IP destination address + [RFC4326]. This requires careful consideration of the network + topology when a Receiver is an IP router, or delivers data to an IP + router (a simple case where this is permitted arises in the + connection of stub networks at a Receiver that have no connectivity + to other networks). Since there is no MAC/NPA address in the SNDU, + ARP and the ND protocol are not required for AR. + + 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. + + + + +Fairhurst & Montpetit Informational [Page 30] + +RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007 + + + Even when not used for AR, the ND protocol may still be required to + support DAD, and other IPv6 network-layer functions. This protocol + uses a block of IPv6 multicast addresses, which need to be carried by + the L2 network. However, since this encapsulation format does not + provide a MAC source address, there are topologies (e.g., Section + 5.6.1) where a system can not differentiate DAD packets that were + originally sent by itself and were re-broadcast, from those that may + have been sent by another system with the same L3 address. + Therefore, DAD can not be used with this encapsulation format in + topologies where this L2 forwarding may occur. + +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 (hardware) 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 + multicast addresses, which need to be carried by the L2 network. The + protocol uses a block of IPv6 multicast addresses, which need to be + carried by the L2 network. However, since this encapsulation format + does not provide a MAC source address, there are topologies (e.g., + Section 5.6.1) where a system can not differentiate DAD packets that + were originally sent by itself and were re-broadcast, from those that + may have been sent by another system with the same L3 address. + Therefore, DAD can not be used with this encapsulation format in + topologies where this L2 forwarding may occur. + +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 (Sub-Network Access Protocol) format of MPE provides an + EtherType field and therefore may support ARP [RFC826]. There is no + specification to define how this is performed. No MAC source address + is present in the SNDU, although the protocol communicates the source + MAC address in the ARP record payload of any query messages that it + generates. + + + + +Fairhurst & Montpetit Informational [Page 31] + +RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007 + + + The IPv6 ND protocol is supported using The LLC/SNAP format of MPE. + This requires specific multicast addresses to be carried by the L2 + network. The IPv6 ND protocol is supported. The protocol uses a + block of IPv6 multicast addresses, which need to be carried by the L2 + network. However, since this encapsulation format does not provide a + MAC source address, there are topologies (e.g., Section 5.6.1) where + a system can not differentiate DAD packets that were originally sent + by itself and were re-broadcast, from those that may have been sent + by another system with the same L3 address. Therefore, DAD can not + be used with this encapsulation format in topologies where this L2 + forwarding may occur. + +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 + precede this Extension, 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 a 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 + configured MAC destination address filter. ARP and ND messages may + be carried within a PDU that is bridged by this encapsulation format. + Where the topology may result in subsequent reception of re- + broadcast copies of multicast frames that were originally sent by a + Receiver (e.g., Section 5.6.1), the system must discard frames that + are received with a source address that it used in frames sent from + the same interface [802.1D]. This prevents duplication on the + bridged network (e.g., this would otherwise invoke DAD). + +6.6. ULE with Bridging Header Extension and NPA Address (D=0) + + The combination of an 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 + + + +Fairhurst & Montpetit Informational [Page 32] + +RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007 + + + encapsulation format. Where the topology may result in the + subsequent reception of re-broadcast copies of multicast frames, that + were originally sent by a Receiver (e.g., Section 5.6.1), the system + must discard frames that are received with a source address that it + used in frames sent from the same interface [802.1D]. This prevents + duplication on the bridged network (e.g., this would otherwise invoke + DAD). + +6.7. MPE with 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. There is currently no formal description + of the Receiver processing for this encapsulation format. 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. Where the topology may result in a + subsequent reception of re-broadcast copies of multicast frames, that + were originally sent by a Receiver (e.g., Section 5.6.1), the system + must discard frames that are received with a source address that it + used in frames sent from the same interface [802.1D]. This prevents + duplication on the bridged network (e.g., this would otherwise invoke + DAD). + +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 + signalling tables (e.g., AIT in MHP, the IP Notification Table, INT, + + + + +Fairhurst & Montpetit Informational [Page 33] + +RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007 + + + of DVB and the DVB-RCS Multicast Mapping Table, and 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 of 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 unauthorized 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 protocols can also be protected by the use of L2 security methods + (e.g., Encryption of the ULE SNDU [IPDVB-SEC]). When these methods + are used, the security of ARP and ND can be comparable to that of a + private LAN: A Receiver will only accept ARP or ND transmissions from + the set of peer senders that share a common group encryption and + common group authentication key provided by the L2 key management. + + AR Servers (Section 5.4) are susceptible to the same kind of security + issues as end 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 + distinguish such proxies from unwanted man-in-the-middle attackers. + This document does not introduce any new mechanisms for the + + + + +Fairhurst & Montpetit Informational [Page 34] + +RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007 + + + protection of these AR functions (e.g., authenticating servers, or + defining AR Servers that interoperate with the SEND protocol + [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 (summarized in "Experiments with RFC 3077", + July 2003). + +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 Organization (ISO), 2000. + + [RFC826] Plummer, D., "Ethernet Address Resolution Protocol: Or + Converting Network Protocol Addresses to 48.bit + Ethernet Address for Transmission on Ethernet + Hardware", STD 37, RFC 826, November 1982. + + [RFC1112] Deering, S., "Host extensions for IP multicasting", STD + 5, RFC 1112, August 1989. + + + + + +Fairhurst & Montpetit Informational [Page 35] + +RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007 + + + [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. + + [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., + and M. Carney, "Dynamic Host Configuration Protocol for + IPv6 (DHCPv6)", RFC 3315, July 2003. + + [RFC3736] Droms, R., "Stateless Dynamic Host Configuration + Protocol (DHCP) Service for IPv6", RFC 3736, April + 2004. + + [RFC4326] Fairhurst, G. and B. Collini-Nocker, "Unidirectional + Lightweight Encapsulation (ULE) for Transmission of IP + Datagrams over an MPEG-2 Transport Stream (TS)", RFC + 4326, December 2005. + +10.2. Informative References + + [802.1D] IEEE 802.1D, "IEEE Standard for Local and Metropolitan + Area Networks: Media Access Control (MAC) Bridges", + IEEE, 2004. + + [802.3] IEEE 802.3, "Local and metropolitan area networks- + Specific requirements Part 3: Carrier sense multiple + access with collision detection (CSMA/CD) access method + and physical layer specifications", IEEE Computer + Society, (also ISO/IEC 8802-3), 2002. + + [ATSC] A/53C, "ATSC Digital Television Standard", Advanced + Television Systems Committee (ATSC), Doc. A/53C, 2004. + + [ATSC-A54A] 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. + + + +Fairhurst & Montpetit Informational [Page 36] + +RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007 + + + [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-DVBS] EN 301 421,"Digital Video Broadcasting (DVB); + Modulation and Coding for DBS satellite systems at + 11/12 GHz", 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). + + [ETSI-SI1] TR 101 162, "Digital Video Broadcasting (DVB); + Allocation of Service Information (SI) codes for DVB + systems", European Telecommunications Standards + Institute (ETSI). + + [IPDVB-SEC] H. Cruickshank, S. Iyengar, L. Duquerroy, P. Pillai, + "Security requirements for the Unidirectional + Lightweight Encapsulation (ULE) protocol", Work in + Progress, May 2007. + + [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 + Organization (ISO), 2002. + + [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 Organization (ISO), 1998. + + [MMT] "SatLabs System Recommendations, Part 1, General + Specifications", Version 2.0, SatLabs Forum, 2006. + http://satlabs.org/pdf/ + SatLabs_System_Recommendations_v2.0_general.pdf. + + + + +Fairhurst & Montpetit Informational [Page 37] + +RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007 + + + [RFC951] Croft, W. and J. Gilmore, "Bootstrap Protocol", RFC + 951, September 1985. + + [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. + + [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. + + + + + +Fairhurst & Montpetit Informational [Page 38] + +RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007 + + + [RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., + Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and + L. Wood, "Advice for Internet Subnetwork Designers", + BCP 89, RFC 3819, July 2004. + + [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, + "SEcure Neighbor Discovery (SEND)", RFC 3971, March + 2005. + + [RFC4259] Weis, B., "The Use of RSA/SHA-1 Signatures within + Encapsulating Security Payload (ESP) and Authentication + Header (AH)", RFC 4359, January 2006. + + [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer + Security (TLS) Protocol Version 1.1", RFC 4346, April + 2006. + + [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor + Discovery Proxies (ND Proxy)", RFC 4389, April 2006. + + [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, + "Protocol Independent Multicast - Sparse Mode (PIM-SM): + Protocol Specification (Revised)", RFC 4601, August + 2006. + + [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, + "Internet Group Management Protocol (IGMP) / Multicast + Listener Discovery (MLD)-Based Multicast Forwarding + ("IGMP/MLD Proxying")", RFC 4605, August 2006. + + [RFC4779] Asadullah, S., Ahmed, A., Popoviciu, C., Savola, P., + and J. Palet, "ISP IPv6 Deployment Scenarios in + Broadband Access Networks", RFC 4779, January 2007. + + [RFC4840] Aboba, B., Davies, E., and D. Thaler, "Multiple + Encapsulation Methods Considered Harmful", RFC 4840, + April 2007. + + [SCTE-1] "IP Multicast for Digital MPEG Networks", SCTE DVS + 311r6, March 2002. + + [SP-ND] Daley, G., "Securing Proxy Neighbour Discovery Problem + Statement", Work in Progress, February 2005. + + + + + + + + +Fairhurst & Montpetit Informational [Page 39] + +RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007 + + +Authors' Addresses + + Godred Fairhurst + Department of Engineering + University of Aberdeen + Aberdeen, AB24 3UE + UK + + EMail: gorry@erg.abdn.ac.uk + URL: 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 + + EMail: mmontpetit@motorola.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Fairhurst & Montpetit Informational [Page 40] + +RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2007). + + 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. + + 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, THE IETF TRUST 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. + +Intellectual Property + + 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. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Fairhurst & Montpetit Informational [Page 41] + |