than a one-to-one association using a protocol. In Ethernet, the
sender maps an IP address to an L2 MAC address, and the Receiver uses
the same mapping to determine the L2 address to set an L2
hardware/software filter entry.
A typical sequence of actions for the dynamic case is:
L3) Populate the IP L3 membership tables at the Receiver.
L3) Receivers send/forward IP L3 membership tables to the Hub
L3) Dynamic/static forwarding at hub/upstream router of IP L3
groups
L2) Populate the IP AR tables at the encapsulator gateway
(i.e., Map IP L3 mcast groups to L2 PIDs)
L2) Distribute the AR information to Receivers
L2) Set Receiver L2 multicast filters for IP groups in the
membership table.
To be flexible, AR must associate a TS Logical Channel (PID) not only
with a group address, but possibly also a QoS class and other
appropriate MPEG-2 TS attributes. Explicit per group AR to
individual L2 addresses is to be avoided.
\
|
+---+----+ +---------+
| Tuner |---+TS Table | . . . .
+---+----+ +---------+ .
| - .
+--------+ +---------+ .
| deMux |---+PID Table|........
+---+----+ +---------+ :
| - :
+--------+ +---------+ +------------+
|MPE/ULE |---+AR Cache-|---+ L2 Table |
+---+----+ +---------+ +------------+
| | |
+---+----+ +---+-----+ +---+----+
| IP | | AR | |IGMP/MLD|
+---+----+ +---+-----+ +---+----+
| | |
*------------+------------+
Figure 7: Receiver Processing Architecture
6.2. Multicast Address Scoping
As in unicast, it is important to recognize the context (scope)
within which a multicast IP address is resolved, to prevent packets
from one addressed scope leaking into other scopes.
Examples of overlapping IP multicast address assignments include:
(i) 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].
(ii) Scoped multicast addresses [RFC2365] [RFC 2375]. Forwarding
of these addresses is controlled by the scope associated
with the address. The addresses are only valid with an
addressed area (e.g. the 239/8 [RFC2365]).
(iii) Other non-IP protocols may also view sets of MAC multicast
addresses as link-local, and may produce unexpected results
if distributed across several private networks.
IP packets with these addresses must not be allowed to travel outside
their intended scope (see Section 5.3). Performing multicast AR at
the IP level can enable providers to offer independently scoped
addresses and would need to use multiple Multicast AR servers, one
per multicast domain.
6.3. Requirements for Multicast over MPEG-2
The requirements for supporting multicast include, but are not
restricted to:
(i) Encapsulating multicast packets for transmission using an
MPEG-2 TS.
(ii) Mapping IP multicast groups to the underlying MPEG-2 TS
Logical Channel (PID) and the MPEG-2 TS Multiplex.
(iii) Providing AR information to allow a Receiver to locate an
IP multicast flow within an MPEG-2 TS Multiplex.
(iv) Error Reporting.
7. Summary
This document describes the architecture for a set of protocols to
perform efficient and flexible support for IP network services over
networks built upon the MPEG-2 Transport Stream (TS). It also
describes existing approaches. The focus is on IP networking, the
mechanisms that are used, and their applicability to supporting IP
unicast and multicast services.
The requirements for a new encapsulation of IPv4 and IPv6 packets is
described, outlining the limitations of current methods and the need
for a streamlined IP-centric approach.
The architecture also describes MPEG-2 Address Resolution (AR)
procedures to allow dynamic configuration of the sender and Receiver
using an MPEG-2 transmission link/network. These support IPv4 and
IPv6 services in both the unicast and multicast modes. Resolution
protocols will support IP packet transmission using both the
Multiprotocol Encapsulation (MPE), which is currently widely
deployed, and also any IETF-defined encapsulation (e.g., ULE
[IPDVB-ULE]).
8. Security Considerations
When the MPEG-2 transmission network is not using a wireline network,
the normal security issues relating to the use of wireless links for
transport of Internet traffic should be considered [RFC3819].
End-to-end security (including confidentiality, authentication,
integrity and access control) is closely associated with the end user
assets that are protected. This close association cannot be ensured
when providing security mechanisms only within a subnetwork (e.g., an
MPEG-2 Transmission Network). Several security mechanisms that can
be used end-to-end have already been deployed in the general Internet
and are enjoying increasing use. Important examples include:
- Transport Layer Security (TLS), which is primarily used to
protect web commerce;
- Pretty Good Privacy (PGP) and S/MIME, primarily used to protect
and authenticate email and software distributions;
- Secure Shell (SSH), used to secure remote access and file
transfer;
- IPsec, a general purpose encryption and authentication mechanism
above IP that can be used by any IP application.
However, subnetwork security is also important [RFC3819] and should
be encouraged, on the principle that it is better than the default
situation, which all too often is no security at all. Users of
especially vulnerable subnets (such as radio/broadcast networks
and/or shared media Internet access) often have control over, at
most, one endpoint - usually a client - and therefore cannot enforce
the use of end-to-end mechanisms.
A related role for subnetwork security is to protect users against
traffic analysis, i.e., identifying the communicating parties (by IP
or MAC address) and determining their communication patterns, even
when their actual contents are protected by strong end-to-end
security mechanisms. (This is important for networks such as
broadcast/radio, where eavesdropping is easy.)
Encryption performed at the Transport Stream (encrypting the payload
of all TS-Packets with the same PID) encrypts/scrambles all parts of
the SNDU, including the layer 2 MAC/NPA address. Encryption at the
section level in MPE may also optionally encrypt the layer 2 MAC/NPA
address in addition to the PDU data [ETSI-DAT]. In both cases,
encryption of the MAC/NPA address requires a Receiver to decrypt all
encrypted data, before it can then filter the PDUs with the set of
MAC/NPA addresses that it wishes to receive. This method also has
the drawback that all Receivers must share a common encryption key.
Encryption of the MPE MAC address is therefore not permitted in some
systems (e.g., [ETSI-DVBRCS]).
Where it is possible for an attacker to inject traffic into the
subnetwork control plane, subnetwork security can additionally
protect the subnetwork assets. This threat must specifically be
considered for the protocols used for subnetwork control functions
(e.g., address resolution, management, configuration). Possible
threats include theft of service and denial of service; shared media
subnets tend to be especially vulnerable to such attacks [RFC3819].
Appropriate security functions must therefore be provided for IPDVB
control protocols [RFC3819], particularly when the control functions
are provided above the IP-layer using IP-based protocols. Internet
level security mechanisms (e.g., IPsec) can mitigate such threats.
In general, End-to-End security is recommended for users of any
communication path, especially when it includes a wireless/radio or
broadcast link, where a range of security techniques already exist.
Specification of security mechanisms at the application layer, or
within the MPEG-2 transmission network, are the concerns of
organisations beyond the IETF. The complexity of any such security
mechanisms should be considered carefully so that it will not unduly
impact IP operations.
8.1. Link Encryption
Link level encryption of IP traffic is commonly used in
broadcast/radio links to supplement End-to-End security (e.g.,
provided by TLS, SSH, Open PGP, S/MIME, IPsec). The encryption and
key exchange methods vary significantly, depending on the intended
application. For example, DVB-S/DVB-RCS operated by Access Network
Operators may wish to provide their customers (Internet Service
Providers, ISP) with security services. Common security services
are: terminal authentication and data confidentiality (for unicast
and multicast) between an encapsulation gateway and Receivers. A
common objective is to provide the same level of privacy as
terrestrial links. An ISP may also wish to provide end-to-end
security services to the end-users (based on well-known mechanisms
such as IPsec).
Therefore, it is important to understand that both security solutions
(Access Network Operators to ISP and ISP to end-users) may coexist.
MPE supports optional link encryption [ETSI-DAT]. A pair of bits
within the MPE protocol header indicate whether encryption
(scrambling) is used. For encrypted PDUs, the header bits indicate
which of a pair of previously selected encryption keys is to be used.
It is recommended that any new encapsulation defined by the IETF
allows Transport Stream encryption and also supports optional link
level encryption/authentication of the SNDU payload. In ULE
[IPDVB-ULE], this may be provided in a flexible way using Extension
Headers. This requires definition of a mandatory header extension,
but has the advantage that it decouples specification of the security
functions from the encapsulation functions. This method also
supports encryption of the NPA/MAC addresses.
9. IANA Considerations
A set of protocols that meet these requirements will require the IANA
to make assignments. This document in itself, however, does not
require any IANA involvement.
10. Acknowledgements
The authors wish to thank Isabel Amonou, Torsten Jaekel, Pierre
Loyer, Luoma Juha-Pekka, and Rod Walsh for their detailed inputs. We
also wish to acknowledge the input provided by the members of the
IETF ipdvb WG.
11. References
11.1. Normative References
[ISO-MPEG] ISO/IEC DIS 13818-1:2000, "Information Technology;
Generic Coding of Moving Pictures and Associated Audio
Information Systems", International Standards
Organisation (ISO).
[ETSI-DAT] EN 301 192, "Digital Video Broadcasting (DVB); DVB
Specifications for Data Broadcasting", European
Telecommunications Standards Institute (ETSI).
11.2. Informative References
[ATSC] A/53C, "ATSC Digital Television Standard", Advanced
Television Systems Committee (ATSC), Doc. A/53C, 2004.
[ATSC-DAT] A/90, "ATSC Data Broadcast Standard", Advanced
Television Systems Committee (ATSC), Doc. A/090, 2000.
[ATSC-DATG] A/91, "Recommended Practice: Implementation Guidelines
for the ATSC Data Broadcast Standard", Advanced
Television Systems Committee (ATSC), Doc. A/91, 2001.
[ATSC-A92] A/92, "Delivery of IP Multicast Sessions over ATSC
Data Broadcast", Advanced Television Systems Committee
(ATSC), Doc. A/92, 2002.
[ATSC-G] A/54A, "Guide to the use of the ATSC Digital
Television Standard", Advanced Television Systems
Committee (ATSC), Doc. A/54A, 2003.
[ATSC-PSIP-TC] A/65B, "Program and System Information Protocol for
Terrestrial Broadcast and Cable", Advanced Television
Systems Committee (ATSC), Doc. A/65B, 2003.
[ATSC-S] A/80, "Modulation and Coding Requirements for Digital
TV (DTV) Applications over Satellite", Advanced
Television Systems Committee (ATSC), Doc. A/80, 1999.
[CLC99] Clausen, H., Linder, H., and Collini-Nocker, B.,
"Internet over Broadcast Satellites", IEEE Commun.
Mag. 1999, pp.146-151.
[ETSI-BSM] TS 102 292, "Satellite Earth Stations and Systems
(SES); Broadband Satellite Multimedia Services and
Architectures; Functional Architecture for IP
Interworking with BSM networks", European
Telecommunications Standards Institute (ETSI).
[ETSI-DVBC] EN 300 800, "Digital Video Broadcasting (DVB); DVB
interaction channel for Cable TV distribution systems
(CATV)", European Telecommunications Standards
Institute (ETSI).
[ETSI-DVBRCS] EN 301 790, "Digital Video Broadcasting (DVB);
Interaction channel for satellite distribution
systems", European Telecommunications Standards
Institute (ETSI).
[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-DVBS2] EN 302 207, "Second generation framing structure,
channel coding and modulation systems for
Broadcasting, Interactive Services,News Gathering and
Other Broadband Satellite Applications", European
Telecommunications Standards Institute (ETSI).
[ETSI-DVBT] EN 300 744, "Digital Video Broadcasting (DVB); Framing
structure, channel coding and modulation for digital
terrestrial television (DVB-T)", European
Telecommunications Standards Institute (ETSI).
[ETSI-IPDC] "IP Datacast Specification", DVB Interim Specification
CNMS 1026 v1.0.0,(Work in Progress), April 2004.
[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-RC] ETS 300 802, "Digital Video Broadcasting (DVB);
Network-independent protocols for DVB interactive
services", European Telecommunications Standards
Institute (ETSI).
[ETSI-SI] EN 300 468, "Digital Video Broadcasting (DVB);
Specification for Service Information (SI) in DVB
systems", European Telecommunications Standards
Institute (ETSI).
[IPDVB-ULE] Fairhurst, G. and B. Collini-Nocker, "Unidirectional
Lightweight Encapsulation (ULE) for transmission of IP
datagrams over an MPEG-2 Transport Stream", Work in
Progress, June 2005.
[IPDVB-AR] Fairhurst, G. and M-J. Montpetit, "Address Resolution
for IP datagrams over MPEG-2 networks", Work in
Progress, 2005.
[ISO-AUD] ISO/IEC 13818-3:1995, "Information technology; Generic
coding of moving pictures and associated audio
information; Part 3: Audio", International Standards
Organisation (ISO).
[ISO-DSMCC] ISO/IEC IS 13818-6, "Information technology; Generic
coding of moving pictures and associated audio
information; Part 6: Extensions for DSM-CC",
International Standards Organisation (ISO).
[ISO-VID] ISO/IEC DIS 13818-2:1998, "Information technology;
Generic coding of moving pictures and associated audio
information; Video", International Standards
Organisation (ISO).
[ITU-AAL5] ITU-T I.363.5, "B-ISDN ATM Adaptation Layer
Specification Type AAL5", International Standards
Organisation (ISO), 1996.
[LLC] ISO/IEC 8802.2, "Information technology;
Telecommunications and information exchange between
systems; Local and metropolitan area networks;
Specific requirements; Part 2: Logical Link Control",
International Standards Organisation (ISO), 1998.
[MMUSIC-IMG] Nomura, Y., Walsh, R., Luoma, J-P., Ott, J., and H.
Schulzrinne, "Requirements for Internet Media Guides",
Work in Progress, June 2004.
[OPEN-CABLE] "Open Cable Application Platform Specification; OCAP
2.0 Profile", OC-SP-OCAP2.0-I01-020419, Cable Labs,
April 2002.
[RFC1112] Deering, S., "Host extensions for IP multicasting",
STD 5, RFC 1112, August 1989.
[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.
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast
Listener Discovery (MLD) for IPv6", RFC 2710, October
1999.
[RFC2507] Degermark, M., Nordgren, B., and S. Pink, "IP Header
Compression", RFC 2507, February 1999.
[RFC3077] Duros, E., Dabbous, W., Izumiyama, H., Fujii, N., and
Y. Zhang, "A Link-Layer Tunneling Mechanism for
Unidirectional Links", RFC 3077, March 2001.
[RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima,
H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren,
T., Le, K., Liu, Z., Martensson, A., Miyazaki, A.,
Svanbro, K., Wiebke, T., Yoshimura, T., and H. Zheng,
"RObust Header Compression (ROHC): Framework and four
profiles: RTP, UDP, ESP, and uncompressed", RFC 3095,
July 2001.
[RFC3171] Albanna, Z., Almeroth, K., Meyer, D., and M. Schipper,
"IANA Guidelines for IPv4 Multicast Address
Assignments", BCP 51, RFC 3171, August 2001.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and
A. Thyagarajan, "Internet Group Management Protocol,
Version 3", RFC 3376, October 2002.
[RFC3569] Bhattacharyya, S., "An Overview of Source-Specific
Multicast (SSM)", RFC 3569, July 2003.
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D.,
Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J.,
and L. Wood, "Advice for Internet Subnetwork
Designers", BCP 89, RFC 3819, July 2004 .
Appendix A: MPEG-2 Encapsulation Mechanisms
Transmitting packet data over an MPEG-2 transmission network requires
that individual PDUs (e.g., IPv4, IPv6 packets, or bridged Ethernet
Frames) are encapsulated using a convergence protocol. The following
encapsulations are currently standardized for MPEG-2 transmission
networks:
(i) Multi-Protocol Encapsulation (MPE).
The MPE specification of DVB [ETSI-DAT] uses private
Sections for the transport of IP packets and uses
encapsulation that is similar to the IEEE LAN/MAN standards
[LLC]. Data packets are encapsulated in datagram sections
that are compliant with the DSMCC section format for private
data. Some Receivers may exploit section processing
hardware to perform a first-level filtering of the packets
that arrive at the Receiver.
This encapsulation makes use of a MAC-level Network Point of
Attachment address. The address format conforms to the
ISO/IEEE standards for LAN/MAN [LLC]. The 48-bit MAC
address field contains the MAC address of the destination;
it is distributed over six 8-bit fields, labelled
MAC_address_1 to MAC_address_6. The MAC_address_1 field
contains the most significant byte of the MAC address, while
MAC_address_6 contains the least significant byte. How many
of these bytes are significant is optional and defined by
the value of the broadcast descriptor table [ETSI-DAT] sent
separately over another MPEG-2 TS within the TS multiplex.
MPE is currently a widely deployed scheme. Due to
Investments in existing systems, usage is likely to continue
in current and future MPEG-2 Transmission Networks. ATSC