draft-ietf-ipdvb-arch-01.txt   draft-ietf-ipdvb-arch-02.txt 
Internet Engineering Task Force M.J. Montpetit ed. Ôªø Internet Engineering Task Force M.J. Montpetit ed.
Internet Draft MJMontpetit.com, USA Internet Draft MJMontpetit.com, USA
Document: draft-ietf-ipdvb-arch-01.txt Gorry Fairhurst Document: draft-ietf-ipdvb-arch-02.txt Gorry Fairhurst
University of Aberdeen, U.K. University of Aberdeen, U.K.
Horst D. Clausen Horst D. Clausen
TIC Systems,USA
Bernhard Collini-Nocker Bernhard Collini-Nocker
Hilmar Linder Hilmar Linder
University of Salzburg, Austria University of Salzburg, Austria
Category: Informational December 2004
Category: Informational September 2004
A Framework for transmission of IP datagrams over MPEG-2 Networks A Framework for transmission of IP datagrams over MPEG-2 Networks
Status of this Memo Status of this Memo
By submitting this Internet-Draft, we certify that any applicable By submitting this Internet-Draft, we certify that any applicable
patent or other IPR claims of which we are aware have been patent or other IPR claims of which we are aware have been
disclosed, or will be disclosed, and any of which we become aware disclosed, or will be disclosed, and any of which we become aware
will be disclosed, in accordance with RFC 3668. will be disclosed, in accordance with RFC 3668.
By submitting this Internet-Draft, we accept the provisions of By submitting this Internet-Draft, we accept the provisions of
Section 3 of RFC 3667 (BCP 78). Section 3 of RFC 3667 (BCP 78).
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet other groups may also distribute working documents as
Drafts. Internet-Drafts are draft documents valid for a maximum of Internet-Drafts.
six months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts Internet-Drafts are draft documents valid for a maximum of six
as reference material or to cite them other than as "work in months and may be updated, replaced, or obsoleted by other
progress." The list of current Internet-Drafts can be accessed at documents at any time. It is inappropriate to use
http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet Internet-Drafts as reference material or to cite them other
Draft Shadow Directories can be accessed at than as "work in progress".
http://www.ietf.org/shadow.html. The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright (C) The Internet Society (2004), All Rights Reserved Copyright (C) The Internet Society (2004), All Rights Reserved
Abstract Abstract
This document describes an architecture for the transport of IP This document describes an architecture for the transport of IP
Datagrams over ISO MPEG-2 Transport Streams (TS). The MPEG-2 TS has Datagrams over ISO MPEG-2 Transport Streams (TS). The MPEG-2 TS has
been widely accepted not only for providing digital TV services, has been widely accepted not only for providing digital TV services
but also as a subnetwork technology for building IP networks. but also as a subnetwork technology for building IP networks.
Examples of systems using MPEG-2 include the Digital Video Examples of systems using MPEG-2 include the Digital Video
Broadcast (DVB) and Advanced Television Systems Committee (ATSC) Broadcast (DVB) and Advanced Television Systems Committee (ATSC)
Standards for Digital Television. Standards for Digital Television.
The document identifies the need for a set of Internet standards The document identifies the need for a set of Internet standards
defining the interface between the MPEG-2 Transport Stream and an defining the interface between the MPEG-2 Transport Stream and an
IP subnetwork. It suggests a new encapsulation method for IP IP subnetwork. It suggests a new encapsulation method for IP
datagrams and proposes protocols to perform IPv6/IPv4 address datagrams and proposes protocols to perform IPv6/IPv4 address
resolution, to associate IP packets with the properties of the resolution, to associate IP packets with the properties of the
Logical Channels provided by an MPEG-2 TS. Logical Channels provided by an MPEG-2 TS.
INTERNET DRAFT Architecture for IP transport over MPEG-2 Networks INTERNET DRAFT Architecture for IP transport over MPEG-2 Networks
September 2004 December 2004
Table of Contents Table of Contents
1. Introduction 1. Introduction
1.1 Salient Features of the Architecture 1.1 Salient Features of the Architecture
2. Conventions Used in This Document 2. Conventions Used in This Document
3. Architecture 3. Architecture
3.1 MPEG-2 Transmission Networks 3.1 MPEG-2 Transmission Networks
3.2 TS Logical Channels 3.2 TS Logical Channels
3.3 Multiplexing and Re-Multiplexing 3.3 Multiplexing and Re-Multiplexing
skipping to change at page 3, line 6 skipping to change at page 3, line 6
9. Acknowledgments 9. Acknowledgments
10. References 10. References
10.1 Normative References 10.1 Normative References
10.2 Informative References 10.2 Informative References
11. Author's Addresses 11. Author's Addresses
12. IPR Notices 12. IPR Notices
13. Copyright Statements 13. Copyright Statements
14. IANA Considerations 14. IANA Considerations
INTERNET DRAFT Architecture for IP transport over MPEG-2 Networks INTERNET DRAFT Architecture for IP transport over MPEG-2 Networks
September 2004 December 2004
[***RFC Editor Note: Remove following text prior to publication***]
Change Notice: Change Notice:
- v00 Original ipdvb WG Version - v00 Original ipdvb WG Version
Document has been shortened and focussed. Document has been shortened and focused.
Some annexe material has been removed. Some annexe material has been removed.
Restructured to describe the full framework. Restructured to describe the full framework.
New text describing the various scenarios. New text describing the various scenarios.
Text added on various issues including compatibility Text added on various issues including compatibility
with services on DVB and ATSC (and different physical links). with services on DVB and ATSC (and different physical links).
- v01 Revised version following IETF-60 discussions - v01 Revised version following IETF-60 discussions
Removed redundant AR info and clarify AR reqs. Removed redundant AR info and clarify AR reqs.
Multicast address scoping moved to section on Multicast address scoping moved to section on
multicast AR. multicast AR.
Removed examples in AR appendix. Removed examples in AR appendix.
Added a small description of "e2e" management requirements. Added a small description of "e2e" management requirements.
Updated reference list. Updated reference list.
Updated terminology to agree with that in ULE Spec. Updated terminology to agree with that in ULE Spec.
Review by all authors to fix last known inconsistencies. Review by all authors to fix last known inconsistencies.
- v02 Revised version following WGLC discussions
Updated figure 1.
Fixed author's affiliation.
Fixed remaining typos and inconsistencies in page numbering.
Added DVB-S2, Open Cable and MHP references.
Removed a controversial paragraph in the Appendix.
[***RFC Editor Note: End of text to be removed***]
INTERNET DRAFT Architecture for IP transport over MPEG-2 Networks INTERNET DRAFT Architecture for IP transport over MPEG-2 Networks
September 2004 December 2004
1. Introduction 1. Introduction
This document identifies requirements and an architecture for This document identifies requirements and an architecture for
transport of IP Datagrams over ISO MPEG-2 Transport Streams [MPEG2]. transport of IP Datagrams over ISO MPEG-2 Transport Streams [MPEG2].
The prime focus is the efficient and flexible delivery of IP The prime focus is the efficient and flexible delivery of IP
services over those subnetworks that use the MPEG-2 transport services over those subnetworks that use the MPEG-2 Transport
stream. Stream (TS).
The architecture is designed to be compatible with services The architecture is designed to be compatible with services
based on MPEG-2, for example the Digital Video Broadcast (DVB) based on MPEG-2, for example the Digital Video Broadcast (DVB)
architecture, the Advanced Television Systems Committee (ATSC) architecture, the Advanced Television Systems Committee (ATSC)
system [ATSC; ATSC-G], and other similar MPEG-2 based transmission system [ATSC; ATSC-G], and other similar MPEG-2 based transmission
systems. Such systems typically provide unidirectional (simplex) systems. Such systems typically provide unidirectional (simplex)
physical and link layer standards, and have been defined for a wide physical and link layer standards, and have been defined for a wide
range of physical media (e.g. Terrestrial TV [ETSI-DVBT; ATSC-PSIP- range of physical media (e.g. Terrestrial TV [ETSI-DVBT; ATSC-PSIP-
TC], Satellite TV [ETSI-DVBS; ATSC-S] and Cable Transmission [ETSI- TC], Satellite TV [ETSI-DVBS; ETSI-DVBS2, ATSC-S] and Cable
DVBC; ATSC-PSIP-TC]). Transmission [ETSI-DVBC; ATSC-PSIP-TC; OPEN-CABLE] and data
transmission over MPEG-2 [ETSI-MHP].
+---------+-+-+-+-+------+--------+---+--+--+ +-+-+-+-+------+------------+---+--+--+---------+
| |T|V|A|O| O | | O |S |O | |T|V|A|O| O | | O |S |O | |
| |e|i|u|t| t | | t |I |t | |e|i|u|t| t | | t |I |t | |
| |l|d|d|h| h | IP | h | |h | |l|d|d|h| h | IP | h | |h | Other |
|Protocols|e|e|i|e| e | | e |T |e | |e|e|i|e| e | | e |T |e |protocols|
|native |t|o|o|r| r | | r |a |r | |t|o|o|r| r | | r |a |r | native |
|over |e| | | | | | |b | | |e| | | | | | |b | | over |
|MPEG-2 TS|x| | | | | +----+-+ |l | | |x| | | | | +---+----+-+ |l | |MPEG-2 TS|
| |t| | | | | | MPE | |e | | |t| | | | | | | MPE | |e | | |
| | | | | | +--+---+------+ | | | | | | | | +--+---+ +------+ | | | |
| | | | | | | AAL5 |Priv. | | | | | | | | | | AAL5 |ULE|Priv. | | | | |
| +-+-+-+-+---+------+ +-+--+--+ +-+-+-+-+---+------+ | +-+--+--+ |
| | PES | ATM |Sect. |Section| | PES | ATM | |Sect. |Section| |
+---------+-------+----------+------+-------+ +-------+----------+---+------+-------+---------+
| MPEG-2 TS | | MPEG-2 TS |
+---------+-------+-------+-----------------+ +---------+-------+----------------+------------+
|Satellite| Cable | D-TV | Other PHY | |Satellite| Cable | Terrestrial TV | Other PHY |
+---------+-------+-------+-----------------+ +---------+-------+----------------+------------+
Figure 1: Overview of the MPEG-2 protocol stack Figure 1: Overview of the MPEG-2 protocol stack
Although many MPEG-2 systems carry a mixture of data types, MPEG-2 Although many MPEG-2 systems carry a mixture of data types, MPEG-2
components may, and are, also used to build IP-only networks. components may, and are, also used to build IP-only networks.
Standard system components offer advantages of improved Standard system components offer advantages of improved
interoperability and larger deployment. However, often, MPEG-2 interoperability and larger deployment. However, often, MPEG-2
networks do not implement all parts of a DVB / ATSC system, networks do not implement all parts of a DVB / ATSC system,
and may for instance support minimal, or no, signalling of and may for instance support minimal, or no, signalling of
Service Information (SI) tables. Service Information (SI) tables.
INTERNET DRAFT Architecture for IP transport over MPEG-2 Networks INTERNET DRAFT Architecture for IP transport over MPEG-2 Networks
September 2004 December 2004
1.1 Salient Features of the Architecture 1.1 Salient Features of the Architecture
The architecture defined in this document describes a set of The architecture defined in this document describes a set of
protocols that support transmission of IP packets over the MPEG-2 protocols that support transmission of IP packets over the MPEG-2
TS. Key characteristics of these networks are that they may TS. Key characteristics of these networks are that they may
Provide link-level broadcast capability, and that many supported provide link-level broadcast capability, and that many supported
applications require access to a very large number of subnetwork applications require access to a very large number of subnetwork
nodes. nodes.
Some or all of these protocols may also be applicable to other Some or all of these protocols may also be applicable to other
subnetworks, e.g., other MPEG-2 transmission networks, regenerative subnetworks, e.g., other MPEG-2 transmission networks, regenerative
satellite links [ETSI-BSM], and some types of broadcast wireless satellite links [ETSI-BSM], and some types of broadcast wireless
links. The key goals of the architecture are to reduce complexity links. The key goals of the architecture are to reduce complexity
when using the system, while improving performance, increasing when using the system, while improving performance, increasing
flexibility for IP services, and providing opportunities for better flexibility for IP services, and providing opportunities for better
integration with IP services. integration with IP services.
Since a majority of MPEG-2 transmission networks are Since a majority of MPEG-2 transmission networks are
bandwidth-limited, encapsulation protocols must therefore add bandwidth-limited, encapsulation protocols must therefore add
minimal overhead to ensure good link efficiency while providing minimal overhead to ensure good link efficiency while providing
adequate network services. They also need to be simple to minimize adequate network services. They also need to be simple to minimize
processing, robust to errors and security threats, and extensible processing, robust to errors and security threats, and extensible
to a wide range of services. to a wide range of services.
In MPEG-2 systems, TS Logical Channels provide multiplexing, In MPEG-2 systems, TS Logical Channels, identified by their PID
addressing, and error reporting. The TS Logical Channel may also be provide multiplexing, addressing, and error reporting. The TS
used to provide Quality of Service (QoS). Mapping functions are Logical Channel may also be used to provide Quality of Service
required to relate TS Logical Channels to IP addresses, to map TS (QoS). Mapping functions are required to relate TS Logical Channels
Logical Channels to IP-level QoS, and to associate IP flows with to IP addresses, to map TS Logical Channels to IP-level QoS, and to
specific subnetwork capabilities. An important feature of the associate IP flows with specific subnetwork capabilities. An
architecture is that these functions may be provided in a dynamic important feature of the architecture is that these functions may be
way, allowing transparent integration with other IP-layer provided in a dynamic way, allowing transparent integration with
protocols. Collectively, these will form a MPEG-2 TS address other IP-layer protocols. Collectively, these will form an MPEG-2
resolution protocol suite. TS address resolution protocol suite.
INTERNET DRAFT Architecture for IP transport over MPEG-2 Networks INTERNET DRAFT Architecture for IP transport over MPEG-2 Networks
September 2004 December 2004
2. Conventions Used In This Document 2. Conventions Used In This Document
Adaptation Field: An optional variable-length extension field of Adaptation Field: An optional variable-length extension field of
the fixed-length TS Packet header, intended to convey clock the fixed-length TS Packet header, intended to convey clock
references and timing and synchronization information as well as references and timing and synchronization information as well as
stuffing over an MPEG-2 Multiplex [ISO-MPEG]. stuffing over an MPEG-2 Multiplex [ISO-MPEG].
ATSC: Advanced Television Systems Committee [ATSC]. A framework ATSC: Advanced Television Systems Committee [ATSC]. A framework
and a set of associated standards for the transmission of video, and a set of associated standards for the transmission of video,
skipping to change at page 6, line 46 skipping to change at page 6, line 46
follow the forward path through the IP network. follow the forward path through the IP network.
MAC: Medium Access and Control. The link layer header of the MAC: Medium Access and Control. The link layer header of the
Ethernet IEEE 802 standard of protocols, consisting of a 6B Ethernet IEEE 802 standard of protocols, consisting of a 6B
destination address, 6B source address, and 2B type field (see destination address, 6B source address, and 2B type field (see
also NPA). also NPA).
MPE: Multiprotocol Encapsulation [ETSI-DAT; ATSC-DAT ; ATSC-DATG]. MPE: Multiprotocol Encapsulation [ETSI-DAT; ATSC-DAT ; ATSC-DATG].
A scheme that encapsulates PDUs, forming a DSM-CC Table Section. A scheme that encapsulates PDUs, forming a DSM-CC Table Section.
Each Section is sent in a series of TS Packets using a single TS Each Section is sent in a series of TS Packets using a single TS
logical Channel. Logical Channel.
MPEG-2: A set of standards specified by the Motion Picture MPEG-2: A set of standards specified by the Motion Picture
Experts Group (MPEG), and standardized by the International Experts Group (MPEG), and standardized by the International
Standards Organisation (ISO) [ISO-MPEG]. Standards Organisation (ISO) [ISO-MPEG].
NPA: Network Point of Attachment. Addresses primarily used for NPA: Network Point of Attachment. Addresses primarily used for
station (Receiver) identification within a local network (e.g. station (Receiver) identification within a local network (e.g.
IEEE MAC address). IEEE MAC address).
INTERNET DRAFT Architecture for IP transport over MPEG-2 Networks INTERNET DRAFT Architecture for IP transport over MPEG-2 Networks
September 2004 December 2004
PES: Packetized Elementary Stream. A format of MPEG-2 TS packet PES: Packetized Elementary Stream. A format of MPEG-2 TS packet
payload usually used for video or audio information in MPEG-2 payload usually used for video or audio information in MPEG-2
[ISO-MPEG]. [ISO-MPEG].
PID: Packet Identifier. A 13 bit field carried in the header of TS PID: Packet Identifier. A 13 bit field carried in the header of TS
Packets. This is used to identify the TS Logical Channel to which a Packets. This is used to identify the TS Logical Channel to which a
TS Packet belongs [ISO-MPEG]. The TS Packets forming the parts of a TS Packet belongs [ISO-MPEG]. The TS Packets forming the parts of a
Table Section, PES, or other payload unit must all carry the same Table Section, PES, or other payload unit must all carry the same
PID value. The all 1s PID value (0x1FFF in hexadecimal) indicates PID value. The all 1s PID value (0x1FFF in hexadecimal) indicates
skipping to change at page 8, line 6 skipping to change at page 8, line 6
SI TABLE: Service Information Table. In this document, the term is SI TABLE: Service Information Table. In this document, the term is
used to describe any table used to convey information about the used to describe any table used to convey information about the
service carried in a TS Multiplex (e.g. [ISO-MPEG]). SI tables are service carried in a TS Multiplex (e.g. [ISO-MPEG]). SI tables are
carried in MPEG-2 Private Sections. carried in MPEG-2 Private Sections.
SNDU: Subnetwork Data Unit. An encapsulated PDU sent as an MPEG-2 SNDU: Subnetwork Data Unit. An encapsulated PDU sent as an MPEG-2
Payload Unit. Payload Unit.
INTERNET DRAFT Architecture for IP transport over MPEG-2 Networks INTERNET DRAFT Architecture for IP transport over MPEG-2 Networks
September 2004 December 2004
STB: Set-Top Box. A consumer equipment (Receiver) for reception of STB: Set-Top Box. A consumer equipment (Receiver) for reception of
digital TV services. digital TV services.
TABLE SECTION: A Payload Unit carrying a part of a MPEG-2 SI Table. TABLE SECTION: A Payload Unit carrying a part of a MPEG-2 SI Table.
TS: Transport Stream [ISO-MPEG], a method of transmission at the TS: Transport Stream [ISO-MPEG], a method of transmission at the
MPEG-2 level using TS Packets; it represents level 2 of the ISO/OSI MPEG-2 level using TS Packets; it represents level 2 of the ISO/OSI
reference model. See also TS Logical Channel and TS Multiplex. reference model. See also TS Logical Channel and TS Multiplex.
skipping to change at page 8, line 37 skipping to change at page 8, line 37
TS MULTIPLEX: A set of MPEG-2 TS Logical Channels sent over a single TS MULTIPLEX: A set of MPEG-2 TS Logical Channels sent over a single
common physical link (i.e. a transmission at a specified symbol common physical link (i.e. a transmission at a specified symbol
rate, FEC setting, and transmission frequency). The same TS Logical rate, FEC setting, and transmission frequency). The same TS Logical
Channel may be repeated over more than one TS Multiplex, for example Channel may be repeated over more than one TS Multiplex, for example
to redistribute the same multicast content to two terrestrial TV to redistribute the same multicast content to two terrestrial TV
transmission cells. transmission cells.
TS PACKET: A fixed-length 188B unit of data sent over a TS Multiplex TS PACKET: A fixed-length 188B unit of data sent over a TS Multiplex
[ISO-MPEG]. Each TS Packet carries a 4B header, plus optional [ISO-MPEG]. Each TS Packet carries a 4B header, plus optional
overhead including an Adaptation Field, encryption details and time overhead including an Adaptation Field, encryption details and time
stamp information to synchronise a set of related Transport Streams. stamp information to synchronise a set of related TSs.
It is also referred to as a TS_cell. Each TS packet carries a PID It is also referred to as a TS_cell. Each TS packet carries a PID
value to associate it with a single TS Logical Channel. value to associate it with a single TS Logical Channel.
INTERNET DRAFT Architecture for IP transport over MPEG-2 Networks INTERNET DRAFT Architecture for IP transport over MPEG-2 Networks
September 2004 December 2004
3. Architecture 3. Architecture
The following sections introduce the components of the MPEG-2 The following sections introduce the components of the MPEG-2
Transmission Network and relate these to a networking framework. Transmission Network and relate these to a networking framework.
3.1 MPEG-2 Transmission Networks 3.1 MPEG-2 Transmission Networks
There are many possible topologies for the MPEG-2 Transmission There are many possible topologies for MPEG-2 Transmission
Networks. A number of example scenarios are briefly described Networks. A number of example scenarios are briefly described
below, and the following text relates specific functions to this below, and the following text relates specific functions to this
set of scenarios. set of scenarios.
A) Broadcast TV and Radio Delivery A) Broadcast TV and Radio Delivery
The principal service in the Broadcast TV and Radio Delivery The principal service in the Broadcast TV and Radio Delivery
scenario is Digital TV and/or Radio and their associated data [ID- scenario is Digital TV and/or Radio and their associated data [ID-
MMUSIC-IMG, ETSI-IPDC]. Such networks typically contain two MMUSIC-IMG, ETSI-IPDC]. Such networks typically contain two
components: the contribution feed and the broadcast part. components: the contribution feed and the broadcast part.
Contribution feeds provide communication from a typically small Contribution feeds provide communication from a typically small
skipping to change at page 9, line 48 skipping to change at page 9, line 48
in this scenario is typically not related to the digital TV/Radio in this scenario is typically not related to the digital TV/Radio
content, and the service may be operated by an independent operator content, and the service may be operated by an independent operator
such as uni-directional file delivery or bi-directional ISP access. such as uni-directional file delivery or bi-directional ISP access.
The IP service must adhere to the full system specification used The IP service must adhere to the full system specification used
for the broadcast transmission, including allocation of PIDs, and for the broadcast transmission, including allocation of PIDs, and
generation of appropriate MPEG-2 control information (e.g. DVB and generation of appropriate MPEG-2 control information (e.g. DVB and
ATSC SI tables). ATSC SI tables).
C) Uni-directional Star IP Scenario C) Uni-directional Star IP Scenario
The Uni-directional Star IP Scenario utilises a Hub station to The Uni-directional Star IP Scenario utilises a Hub station to
provide a data network delivering a common bit stream to provide a data network delivering a common bit stream to typically
medium-sized groups of Receivers. MPEG-2 transmission technology medium-sized groups of Receivers. MPEG-2 transmission technology
provides the forward direction physical and link layers for this provides the forward direction physical and link layers for this
transmission, the return link (if required) is provided by other transmission, the return link (if required) is provided by other
means. IP services typically form the main proportion of the means. IP services typically form the main proportion of the
transmission traffic. Such networks do not necessarily implement transmission traffic. Such networks do not necessarily implement
the MPEG-2 control plane, i.e. PSI/SI tables. the MPEG-2 control plane, i.e. PSI/SI tables.
INTERNET DRAFT Architecture for IP transport over MPEG-2 Networks INTERNET DRAFT Architecture for IP transport over MPEG-2 Networks
September 2004 December 2004
D) Data-cast Overlay D) Datacast Overlay
The Data-cast Overlay scenario employs MPEG-2 physical and link The Datacast Overlay scenario employs MPEG-2 physical and link
layers to provide additional connectivity such as uni-directional layers to provide additional connectivity such as uni-directional
multicast to supplement an existing IP-based Internet service. multicast to supplement an existing IP-based Internet service.
Examples of such a network includes IP Datacast to mobile wireless Examples of such a network includes IP Datacast to mobile wireless
receivers [ID-MMUSIC-IMG]. receivers [ID-MMUSIC-IMG].
E) Point-to-Point Links E) Point-to-Point Links
Point-to-Point connectivity may be provided using a pair of Point-to-Point connectivity may be provided using a pair of
transmit and receive interfaces supporting the MPEG-2 physical and transmit and receive interfaces supporting the MPEG-2 physical and
link layers. Typically the transmission from a sender is received link layers. Typically the transmission from a sender is received
by only one or a small number of Receivers. Examples by only one or a small number of Receivers. Examples
skipping to change at page 11, line 6 skipping to change at page 11, line 6
Note that only Scenarios A-B actually carry MPEG-2 video and audio Note that only Scenarios A-B actually carry MPEG-2 video and audio
intended for reception by digital Set Top Boxes (STBs) as the intended for reception by digital Set Top Boxes (STBs) as the
primary traffic. The other scenarios are IP-based data networks and primary traffic. The other scenarios are IP-based data networks and
need not necessarily implement the MPEG-2 control plane. need not necessarily implement the MPEG-2 control plane.
Scenarios E-F provide two-way connectivity using the MPEG-2 Scenarios E-F provide two-way connectivity using the MPEG-2
Transmission Network. Such networks provide direct support for Transmission Network. Such networks provide direct support for
bi-directional protocols above and below the IP layer. bi-directional protocols above and below the IP layer.
INTERNET DRAFT Architecture for IP transport over MPEG-2 Networks INTERNET DRAFT Architecture for IP transport over MPEG-2 Networks
September 2004 December 2004
The complete MPEG-2 transmission network may be managed by a The complete MPEG-2 transmission network may be managed by a
transmission service operator. In such cases, the assignment of transmission service operator. In such cases, the assignment of
addresses and TS Logical Channels at Receivers are usually under addresses and TS Logical Channels at Receivers are usually under
the control of the service operator. Examples include a TV the control of the service operator. Examples include a TV
operator (Scenario A), or an ISP (Scenarios B-F). MPEG-2 operator (Scenario A), or an ISP (Scenarios B-F). MPEG-2
transmission networks are also used for private networks. These transmission networks are also used for private networks. These
typically involve a smaller number of Receivers and do not require typically involve a smaller number of Receivers and do not require
the same level of centralised control. Examples include companies the same level of centralised control. Examples include companies
wishing to connect DVB-capable routers to form links within the wishing to connect DVB-capable routers to form links within the
Internet (Scenario B). Internet (Scenario B).
3.2 TS Logical Channels 3.2 TS Logical Channels
An MPEG-2 Transport Multiplex offers a number of parallel channels, An MPEG-2 Transport Multiplex offers a number of parallel channels,
which are known here as TS Logical Channels. Each TS Logical which are known here as TS Logical Channels. Each TS Logical
Channel is uniquely identified by the Packet ID, PID, value that is Channel is uniquely identified by the Packet ID, PID, value that is
Carried in the header of each MPEG-2 TS Packet. The PID value is a carried in the header of each MPEG-2 TS Packet. The PID value is a
13 bit field and, thus the number of available channels ranges from 13 bit field and, thus the number of available channels ranges from
0 to 8191 decimal or 0x1FFF in hexadecimal, some of which being 0 to 8191 decimal or 0x1FFF in hexadecimal, some of which are
reserved for transmission of SI tables. Non-reserved TS Logical reserved for transmission of SI tables. Non-reserved TS Logical
Channels may be used to carry audio [ISO-AUD], video [ISO-VID], IP Channels may be used to carry audio [ISO-AUD], video [ISO-VID], IP
packets [ISO-DSMCC; ETSI-DAT; ATSC-DAT],or other data [ISO-DSMCC; packets [ISO-DSMCC; ETSI-DAT; ATSC-DAT],or other data [ISO-DSMCC;
ETSI-DAT; ATSC-DAT]. The value 8191 decimal(0x1FFF) indicates a null ETSI-DAT; ATSC-DAT]. The value 8191 decimal(0x1FFF) indicates a null
packet, used to maintain the physical bearer bit rate when there are packet, used to maintain the physical bearer bit rate when there are
no other MPEG-2 TS packets to be sent. no other MPEG-2 TS packets to be sent.
TS-LC-A-1 /---\--------------------/---\ TS-LC-A-1 /---\--------------------/---\
\ / \ / \ \ / \ / \
\ | | | | \ | | | |
skipping to change at page 12, line 6 skipping to change at page 12, line 6
| | | | | | | |
/-------- / | --------- /-------- / | ---------
/ \----/-----------------------\----/ / \----/-----------------------\----/
/ MPEG-2 TS MUX B / MPEG-2 TS MUX B
TS-LC-B-1 TS-LC-B-1
Figure 2: Example showing MPEG-2 TS Logical Channels carried Figure 2: Example showing MPEG-2 TS Logical Channels carried
Over 2 MPEG-2 TS Multiplexes. Over 2 MPEG-2 TS Multiplexes.
INTERNET DRAFT Architecture for IP transport over MPEG-2 Networks INTERNET DRAFT Architecture for IP transport over MPEG-2 Networks
September 2004 December 2004
TS Logical Channels are independently numbered on each MPEG-2 TS TS Logical Channels are independently numbered on each MPEG-2 TS
Multiplex (MUX). In most cases the data sent over the TS Logical Multiplex (MUX). In most cases the data sent over the TS Logical
Channels will differ for different multiplexes. Figure 2 Channels will differ for different multiplexes. Figure 2
shows a set of TS Logical Channels sent using two MPEG-2 TS shows a set of TS Logical Channels sent using two MPEG-2 TS
Multiplexes (A and B). Multiplexes (A and B).
There are cases where the same data may be distributed over two or There are cases where the same data may be distributed over two or
more multiplexes (e.g., some SI tables; multicast content which more multiplexes (e.g., some SI tables; multicast content which
needs to be received by Receivers tuned to either MPEG-2 TS; unicast needs to be received by Receivers tuned to either MPEG-2 TS; unicast
skipping to change at page 12, line 29 skipping to change at page 12, line 29
carries 3 MPEG-2 TS Logical Channels. These TS Logical Channels may carries 3 MPEG-2 TS Logical Channels. These TS Logical Channels may
differ (TS-LC-A-1, TS-LC-A-2, TS-LC-B-2, TS-LC-B-1), or may be differ (TS-LC-A-1, TS-LC-A-2, TS-LC-B-2, TS-LC-B-1), or may be
common to both MPEG-2 TS Multiplexes (i.e. TS-LC-A-3 and TS-LC-B-3 common to both MPEG-2 TS Multiplexes (i.e. TS-LC-A-3 and TS-LC-B-3
carry identical content). carry identical content).
As can been seen, there are similarities between the way PIDs As can been seen, there are similarities between the way PIDs
are used and the operation of virtual channels in ATM. However, are used and the operation of virtual channels in ATM. However,
unlike ATM, a PID defines a unidirectional broadcast channel and not unlike ATM, a PID defines a unidirectional broadcast channel and not
a point-to-point link. Contrary to ATM, there is, as yet, no a point-to-point link. Contrary to ATM, there is, as yet, no
specified standard interface for MPEG-2 connection setup, or for specified standard interface for MPEG-2 connection setup, or for
signalling mappings of IP flows to PIDs, or to set the Quality of signaling mappings of IP flows to PIDs, or to set the Quality of
Service, QoS, assigned to a TS Logical Channel. Service, QoS, assigned to a TS Logical Channel.
3.3 Multiplexing and Re-Multiplexing 3.3 Multiplexing and Re-Multiplexing
In a simple example, one or more TS are processed by a MPEG-2 In a simple example, one or more TS are processed by a MPEG-2
multiplexor resulting in a TS Multiplex. The TS Multiplex is multiplexor resulting in a TS Multiplex. The TS Multiplex is
forwarded over a physical bearer towards one or more Receivers forwarded over a physical bearer towards one or more Receivers
(figure 3). (figure 3).
In a more complex example, the same TS may be fed to multiple MPEG-2 In a more complex example, the same TS may be fed to multiple MPEG-2
skipping to change at page 13, line 6 skipping to change at page 13, line 6
part of the remultiplexing process, a remultiplexor may renumber the part of the remultiplexing process, a remultiplexor may renumber the
PID values associated with one or more TS Logical Channels to PID values associated with one or more TS Logical Channels to
prevent clashes between input TS Logical Channels with the same PID prevent clashes between input TS Logical Channels with the same PID
carried on different input multiplexes. It may also modify and/or carried on different input multiplexes. It may also modify and/or
insert new SI data into the control plane. insert new SI data into the control plane.
In all cases, the final result is a "TS Multiplex" which is In all cases, the final result is a "TS Multiplex" which is
transmitted over the physical bearer towards the Receiver. transmitted over the physical bearer towards the Receiver.
INTERNET DRAFT Architecture for IP transport over MPEG-2 Networks INTERNET DRAFT Architecture for IP transport over MPEG-2 Networks
September 2004 December 2004
+------------+ +------------+ +------------+ +------------+
| IP | | IP | | IP | | IP |
| End Host | | End Host | | End Host | | End Host |
+-----+------+ +------------+ +-----+------+ +------------+
| ^ | ^
+------------>+---------------+ | +------------>+---------------+ |
+ IP | | + IP | |
+-------------+ Encapsulator | | +-------------+ Encapsulator | |
SI-Data | +------+--------+ | SI-Data | +------+--------+ |
skipping to change at page 14, line 6 skipping to change at page 14, line 6
SNDUs are subsequently fragmented into a series of TS Packets. SNDUs are subsequently fragmented into a series of TS Packets.
To receive IP packets over a MPEG-2 TS Multiplex, a Receiver To receive IP packets over a MPEG-2 TS Multiplex, a Receiver
needs to identify the specific TS Multiplex (physical link) and also needs to identify the specific TS Multiplex (physical link) and also
the TS Logical Channel (the PID value of a logical link). It is the TS Logical Channel (the PID value of a logical link). It is
common for a number of MPEG-2 TS Logical Channels to carry SNDUs, common for a number of MPEG-2 TS Logical Channels to carry SNDUs,
and a Receiver must therefore filter (accept) IP packets sent with a and a Receiver must therefore filter (accept) IP packets sent with a
number of PID values, and must independently reassemble each SNDU. number of PID values, and must independently reassemble each SNDU.
INTERNET DRAFT Architecture for IP transport over MPEG-2 networks INTERNET DRAFT Architecture for IP transport over MPEG-2 networks
September 2004 December 2004
A Receiver that simultaneously receives from several TS Logical A Receiver that simultaneously receives from several TS Logical
Channels, must filter other unwanted TS Logical Channels by Channels, must filter other unwanted TS Logical Channels by
employing for example specific hardware support. Packets for one IP employing for example specific hardware support. Packets for one IP
flow (i.e. a specific combination of IP source and destination flow (i.e. a specific combination of IP source and destination
addresses) must be sent using the same PID. It should not be assumed addresses) must be sent using the same PID. It should not be assumed
that all IP packets are carried on a single PID, as in some cable that all IP packets are carried on a single PID, as in some cable
modem implementations, and multiple PIDs must be allowed in the modem implementations, and multiple PIDs must be allowed in the
architecture. Many current hardware filters limit the maximum number architecture. Many current hardware filters limit the maximum number
of active PIDs (e.g. 32), although if needed, future systems may of active PIDs (e.g. 32), although if needed, future systems may
skipping to change at page 15, line 6 skipping to change at page 15, line 6
(i) Guidance on which MPEG-2 features are pre-requisites for the IP (i) Guidance on which MPEG-2 features are pre-requisites for the IP
service, and identification of any optional fields that impact service, and identification of any optional fields that impact
performance/correct operation. performance/correct operation.
(ii) Standards to provide an efficient and flexible encapsulation (ii) Standards to provide an efficient and flexible encapsulation
scheme that may be easily implemented in an Encapsulator or scheme that may be easily implemented in an Encapsulator or
Receiver. The payload encapsulation requires a type field for Receiver. The payload encapsulation requires a type field for
the SNDU to indicate the type of packet and a mechanism to the SNDU to indicate the type of packet and a mechanism to
signal which encapsulation is used on a certain PID. signal which encapsulation is used on a certain PID.
INTERNET DRAFT Architecture for IP transport over MPEG-2 networks INTERNET DRAFT Architecture for IP transport over MPEG-2 networks
September 2004 December 2004
(iii) Standards to associate a particular IP address with a Network (iii) Standards to associate a particular IP address with a Network
Point of Attachment (NPA) that could or may not be a MAC Point of Attachment (NPA) that could or may not be a MAC
Address. This process resembles the IPv4 Address Resolution Address. This process resembles the IPv4 Address Resolution
Protocol, ARP, or IPv6 Neighbour Discovery, ND, protocol [AR- Protocol, ARP, or IPv6 Neighbour Discovery, ND, protocol [AR-
DRAFT]. In addition, the standard will be compatible with IPv6 DRAFT]. In addition, the standard will be compatible with IPv6
autoconfiguration. autoconfiguration.
(iv) Standards to associate a MPEG-2 TS interface with one or more (iv) Standards to associate a MPEG-2 TS interface with one or more
specific TS Logical Channels (PID, TS Multiplex). Bindings are specific TS Logical Channels (PID, TS Multiplex). Bindings are
required for both unicast transmission, and multicast required for both unicast transmission, and multicast
skipping to change at page 15, line 40 skipping to change at page 15, line 40
transfer (in which communication is only from the sending IP transfer (in which communication is only from the sending IP
end host to the receiving IP end host) and bi-directional end host to the receiving IP end host) and bi-directional
transfer. Consideration should also be given to security of the transfer. Consideration should also be given to security of the
TS Multiplex: the need for closed user groups and the use of TS Multiplex: the need for closed user groups and the use of
MPEG-2 TS encryption. MPEG-2 TS encryption.
(vii) Management of the IP transmission, including standardised SNMP (vii) Management of the IP transmission, including standardised SNMP
MIBs and error reporting procedures. The need for and scope of MIBs and error reporting procedures. The need for and scope of
this is to be determined. this is to be determined.
The specified architecture and techniques should be suited to a The specified architecture and techniques should be suited to a
Range of systems employing the MPEG-2 TS, and may also suit other range of systems employing the MPEG-2 TS, and may also suit other
(sub)networks offering similar transfer capabilities. (sub)networks offering similar transfer capabilities.
The following section, 4, describes encapsulation issues. The following section, 4, describes encapsulation issues.
Sections 6 and 7 describe address resolution issues for unicast and Sections 6 and 7 describe address resolution issues for unicast and
Multicast respectively. multicast respectively.
INTERNET DRAFT Architecture for IP transport over MPEG-2 networks INTERNET DRAFT Architecture for IP transport over MPEG-2 networks
September 2004 December 2004
4. Encapsulation Protocol Requirements 4. Encapsulation Protocol Requirements
This section identifies requirements and provides examples of This section identifies requirements and provides examples of
mechanisms that may be used to perform the encapsulation of IPv4/v6 mechanisms that may be used to perform the encapsulation of IPv4/v6
unicast and multicast packets over MPEG-2 Transmission Networks. unicast and multicast packets over MPEG-2 Transmission Networks.
A network device, known as an Encapsulator receives PDUs (e.g. IP A network device, known as an Encapsulator receives PDUs (e.g. IP
Packets or Ethernet frames) and formats these Subnetwork Data Units, Packets or Ethernet frames) and formats these into Subnetwork Data
SNDUs. An encapsulation (or convergence) protocol transports each Units,SNDUs. An encapsulation (or convergence) protocol transports
SNDU over the MPEG-2 TS service and provides the appropriate each SNDU over the MPEG-2 TS service and provides the appropriate
mechanisms to deliver the encapsulated PDU to the Receiver IP mechanisms to deliver the encapsulated PDU to the Receiver IP
interface. interface.
In forming a SNDU, the encapsulation protocol typically adds In forming a SNDU, the encapsulation protocol typically adds
header fields that carry protocol control information, such header fields that carry protocol control information, such
as the length of SNDU, Receiver address, multiplexing information, as the length of SNDU, Receiver address, multiplexing information,
payload type, sequence numbers etc. The SNDU payload is typically payload type, sequence numbers etc. The SNDU payload is typically
followed by a trailer, which carries an Integrity Check (e.g., followed by a trailer, which carries an Integrity Check (e.g.,
Cyclic Redundancy Check, CRC). Some protocols also add additional Cyclic Redundancy Check, CRC). Some protocols also add additional
control information and/or padding to or after the trailer control information and/or padding to or after the trailer
(figure 4). (figure 4).
+--------+-------------------------+-----------------+ +--------+-------------------------+-----------------+
| Header | SNDU | Integrity Check | | Header | PDU | Integrity Check |
+--------+-------------------------+-----------------+ +--------+-------------------------+-----------------+
<--------------------- SNDU ------------------------->
Figure 4: Encapsulation of a subnetwork PDU (e.g. IPv4 or IPv6 Figure 4: Encapsulation of a subnetwork PDU (e.g. IPv4 or IPv6
packet) to form an MPEG-2 Payload Unit. packet) to form an MPEG-2 Payload Unit.
Examples of existing encapsulation/convergence protocols include Examples of existing encapsulation/convergence protocols include
ATM AAL5 [ITU-AAL5], and MPEG-2 MPE [ETSI-DAT]. ATM AAL5 [ITU-AAL5], and MPEG-2 MPE [ETSI-DAT].
When required, a SNDU may be fragmented across a number of TS When required, a SNDU may be fragmented across a number of TS
Packets (figure 5). Packets (figure 5).
+-----------------------------------------+ +-----------------------------------------+
|Encap Header| SubNetwork DU | |Encap Header|SubNetwork Data Unit (SNDU) |
+-----------------------------------------+ +-----------------------------------------+
/ / \ \ / / \ \
/ / \ \ / / \ \
/ / \ \ / / \ \
+------+----------+ +------+----------+ +------+----------+ +------+----------+ +------+----------+ +------+----------+
|MPEG-2| MPEG-2 |..|MPEG-2| MPEG-2 |...|MPEG-2| MPEG-2 | |MPEG-2| MPEG-2 |..|MPEG-2| MPEG-2 |...|MPEG-2| MPEG-2 |
|Header| Payload | |Header| Payload | |Header| Payload | |Header| Payload | |Header| Payload | |Header| Payload |
+------+----------+ +------+----------+ +------+----------+ +------+----------+ +------+----------+ +------+----------+
Figure 5: Encapsulation of an SNDU (e.g., IP packet) into a Figure 5: Encapsulation of an PDU (e.g., IP packet) into a
Series of MPEG-2 TS Packets (each TS Packet carries a header Series of MPEG-2 TS Packets. Each TS Packet carries a header
with a common Packet ID, PID, value denoting the MPEG-2 TS with a common Packet ID (PID) value denoting the MPEG-2 TS
Logical Channel). Logical Channel.
INTERNET DRAFT Architecture for IP transport over MPEG-2 networks INTERNET DRAFT Architecture for IP transport over MPEG-2 networks
September 2004 December 2004
The DVB family of standards currently defines a mechanism for The DVB family of standards currently defines a mechanism for
transporting an IP packet, or Ethernet frame using the transporting an IP packet, or Ethernet frame using the
Multi-Protocol Encapsulation (MPE) [ETSI-DAT]. This scheme is also Multi-Protocol Encapsulation (MPE) [ETSI-DAT]. An equivalent scheme
supported in ATSC [ATSC-DAT; ATSC-DATG]. It allows transmission is also supported in ATSC [ATSC-DAT; ATSC-DATG]. It allows
of IP packets or (by using LLC) Ethernet frames by encapsulation transmission of IP packets or (by using LLC) Ethernet frames by
within a Table Section (with the format used by the control plane encapsulation within a Table Section (with the format used by the
associated with the MPEG-2 transmission). The MPE specification control plane associated with the MPEG-2 transmission). The MPE
includes a set of optional header components and requires specification includes a set of optional header components and
decoding of the control headers. This processing is suboptimal requires decoding of the control headers. This processing is
for Internet traffic, since it incurs significant receiver suboptimal for Internet traffic, since it incurs significant
processing overhead and some extra link overhead [CLC99]. receiver processing overhead and some extra link overhead [CLC99].
The existing standards carry heritage from legacy implementations. The existing standards carry heritage from legacy implementations.
These have reflected the limitations of technology at the time of These have reflected the limitations of technology at the time of
their deployment (v.g. design decisions driven by audio/video their deployment (v.g. design decisions driven by audio/video
considerations rather than IP networking requirements). IPv6, MPLS, considerations rather than IP networking requirements). IPv6, MPLS,
and other network-layer protocols are not natively supported. and other network-layer protocols are not natively supported.
Together, these justify the development of a new encapsulation Together, these justify the development of a new encapsulation
that will be truly IP-centric. Carrying IP packets over a TS that will be truly IP-centric. Carrying IP packets over a TS
Logical Channel involves several convergence protocol functions. Logical Channel involves several convergence protocol functions.
This section briefly describes these functions and highlights the This section briefly describes these functions and highlights the
skipping to change at page 18, line 6 skipping to change at page 18, line 6
does not carry the first byte of a Table Section, the PUSI is set to does not carry the first byte of a Table Section, the PUSI is set to
'0', indicating that no Payload Pointer is present. '0', indicating that no Payload Pointer is present.
Using this PUSI bit, the start of the first Payload Unit in a TS Using this PUSI bit, the start of the first Payload Unit in a TS
Packet is exactly known by the Receiver, unless that TS Packet has Packet is exactly known by the Receiver, unless that TS Packet has
been corrupted or lost in the transmission. In which case, the been corrupted or lost in the transmission. In which case, the
payload is discarded until the next TS Packet is received with a payload is discarded until the next TS Packet is received with a
PUSI value of '1'. PUSI value of '1'.
INTERNET DRAFT Architecture for IP transport over MPEG-2 networks INTERNET DRAFT Architecture for IP transport over MPEG-2 networks
September 2004 December 2004
The encapsulation should allow packing of more than one SNDU into The encapsulation should allow packing of more than one SNDU into
the same TS Packet and should not limit the number of SNDUs that can the same TS Packet and should not limit the number of SNDUs that can
be sent in a TS Packet. In addition, it should allow an IP be sent in a TS Packet. In addition, it should allow an IP
Encapsulator to insert padding when there is an incomplete TS Packet Encapsulator to insert padding when there is an incomplete TS Packet
payload. A mechanism needs to be identified to differentiate this payload. A mechanism needs to be identified to differentiate this
padding from the case where another encapsulated SNDU follows. padding from the case where another encapsulated SNDU follows.
A combination of the PUSI and a Length Indicator (see below) allows A combination of the PUSI and a Length Indicator (see below) allows
an efficient MPEG-2 convergence protocol to receive accurate an efficient MPEG-2 convergence protocol to receive accurate
skipping to change at page 18, line 47 skipping to change at page 18, line 47
and IPv6 packet format permits an IP packet of size up to 64 KB, and IPv6 packet format permits an IP packet of size up to 64 KB,
such packets are seldom seen on the current Internet. Since high such packets are seldom seen on the current Internet. Since high
speed links are often limited by the packet forwarding rate of speed links are often limited by the packet forwarding rate of
routers, there has been a tendency for Internet core routers to routers, there has been a tendency for Internet core routers to
support MTU values larger than 1500 bytes. A value of 16 KB is not support MTU values larger than 1500 bytes. A value of 16 KB is not
uncommon in the core of the current Internet. This would seem a uncommon in the core of the current Internet. This would seem a
suitable maximum size for an MPEG-2 transmission network. suitable maximum size for an MPEG-2 transmission network.
4.3 Next Level Protocol Type 4.3 Next Level Protocol Type
A key feature of the new encapsulation is to identify the type of A key feature of the required encapsulation is to identify the
payload being transported (e.g., to differentiate IPv4, IPv6 etc). payload type being transported (e.g. to differentiate IPv4, IPv6,
Most protocols use a type field to identify a specific process at etc). Most protocols use a type field to identify a specific
the next higher layer that is the originator or the recipient of the process at the next higher layer that is the originator or the
payload (SNDU). This method is used by IPv4, IPv6, and also by the recipient of the payload (SNDU). This method is used by IPv4,
original Ethernet protocol (DIX). OSI uses the concept of a IPv6, and also by the original Ethernet protocol (DIX). OSI
'Selector' for this, (e.g. in the IEEE 802/ISO 8802 standards for uses the concept of a 'Selector' for this, (e.g. in the IEEE
CSMA/CD [LLC], although in this case a SNAP (subnetwork access 802/ISO 8802 standards for CSMA/CD [LLC], although in this
protocol) header is also required for IP packets. case a SNAP (subnetwork access protocol) header is also
required for IP packets.
A Next Level Protocol Type field is also required if compression
(e.g. Robust Header Compression [RFCROHC]) is supported. No
INTERNET DRAFT Architecture for IP transport over MPEG-2 networks INTERNET DRAFT Architecture for IP transport over MPEG-2 networks
September 2004 December 2004
A Next Level Protocol Type field is also required if compression
(e.g. Robust Header Compression [RFCROHC]) is supported. No
compression method has currently been defined that is directly compression method has currently been defined that is directly
applicable to this architecture, however the ROHC framework applicable to this architecture, however the ROHC framework
defines a number of header compression techniques that may yield defines a number of header compression techniques that may yield
considerable improvement in throughput on links which have a limited considerable improvement in throughput on links which have a limited
capacity. capacity. Since many MPEG-2 Transmission Networks are wireless,
the ROHC framework will be directly applicable for many
Since many MPEG-2 Transmission Networks are wireless, the ROHC applications. The benefit of ROHC is greatest for smaller SNDUs
framework will be directly applicable for many applications. The but does imply the need for additional processing at the Receiver
benefit of ROHC is greatest for smaller SNDUs but does not imply to expand the received compressed packets. The selected type
the need for additional processing at the Receiver to expand the field should contain sufficient code points to support this
received compressed packets. The selected type field should contain technique.
sufficient code points to support this technique.
It is thus a requirement to include a Next Level Protocol Type field It is thus a requirement to include a Next Level Protocol Type field
in the encapsulation header. Such a field should specify values for in the encapsulation header. Such a field should specify values for
at least IPv4, IPv6, and must allow for other values (e.g., MAC- at least IPv4, IPv6, and must allow for other values (e.g., MAC-
level bridging). level bridging).
4.4 L2 Subnet Addressing 4.4 L2 Subnet Addressing
In MPEG-2, the PID carried in the TS Packet header is used to In MPEG-2, the PID carried in the TS Packet header is used to
identify individual services with the help of SI tables. This was identify individual services with the help of SI tables. This was
skipping to change at page 19, line 51 skipping to change at page 19, line 52
Within a local network a completely different set of addresses for Within a local network a completely different set of addresses for
the Network Point of Attachment (NPA) is used; frequently these NPA the Network Point of Attachment (NPA) is used; frequently these NPA
addresses are referred to as Medium Access Control, MAC-level addresses are referred to as Medium Access Control, MAC-level
addresses. In the Internet they are also called hardware addresses. addresses. In the Internet they are also called hardware addresses.
Whereas network layer addresses are used for routing, NPA addresses Whereas network layer addresses are used for routing, NPA addresses
are primarily used for Receiver identification. are primarily used for Receiver identification.
Receivers may use the NPA of a received SNDU to reject unwanted Receivers may use the NPA of a received SNDU to reject unwanted
unicast packets within the (software) interface driver at the unicast packets within the (software) interface driver at the
Receiver, but must also perform forwarding checks based on the IP Receiver, but must also perform forwarding checks based on the IP
address. IP multicast and broadcast may also filter based using the address. IP multicast and broadcast may also filter using the
NPA, but Receivers must also filter unwanted packets at the network NPA, but Receivers must also filter unwanted packets at the network
layer based on source and destination IP addresses. This does not layer based on source and destination IP addresses. This does not
imply that each IP address must map to a unique NPA (more than one imply that each IP address must map to a unique NPA (more than one
IP address may map to the same NPA). If a separate NPA address is IP address may map to the same NPA). If a separate NPA address is
not required, the IP address is sufficient for both functions. not required, the IP address is sufficient for both functions.
INTERNET DRAFT Architecture for IP transport over MPEG-2 networks INTERNET DRAFT Architecture for IP transport over MPEG-2 networks
September 2004 December 2004
If it is required to address an individual Receiver in an MPEG-2 If it is required to address an individual Receiver in an MPEG-2
transport system, this can be achieved either at the network level transport system, this can be achieved either at the network level
(IP address) or via a hardware-level NPA address (MAC-address). If (IP address) or via a hardware-level NPA address (MAC-address). If
both addresses used, they must be mapped either in a static or a both addresses used, they must be mapped either in a static or a
dynamic way (e.g., by an address resolution process). A similar dynamic way (e.g., by an address resolution process). A similar
requirement may also exist to identify the PID and TS multiplex on requirement may also exist to identify the PID and TS multiplex on
which services are carried. which services are carried.
Using an NPA address in a MPEG-2 TS may enhance security, in that Using an NPA address in a MPEG-2 TS may enhance security, in that
skipping to change at page 20, line 29 skipping to change at page 20, line 29
however only a weak form of security, since the NPA filtering is however only a weak form of security, since the NPA filtering is
often reconfigurable (frequently performed in software), and may be often reconfigurable (frequently performed in software), and may be
modified by a user to allow reception of specified (or all) packets, modified by a user to allow reception of specified (or all) packets,
similar to promiscuous mode operation in Ethernet. If security is similar to promiscuous mode operation in Ethernet. If security is
required, it should be applied at another place (e.g. link required, it should be applied at another place (e.g. link
encryption, authentication of address resolution, IPSEC, transport encryption, authentication of address resolution, IPSEC, transport
level security and/or application level security). level security and/or application level security).
There are also cases where the use of a NPA is required (e.g. where There are also cases where the use of a NPA is required (e.g. where
a system operates as a router) and if present this should be carried a system operates as a router) and if present this should be carried
in encapsulation header where it may be used by Receivers as a in an encapsulation header where it may be used by Receivers as a
pre-filter to discard unwanted SNDUs. The addresses allocated do not pre-filter to discard unwanted SNDUs. The addresses allocated do not
need to conform to the IEEE MAC address format. There are many cases need to conform to the IEEE MAC address format. There are many cases
where a NPA is not required, and network layer filtering may be where a NPA is not required, and network layer filtering may be
used. A new encapsulation protocol should therefore support an used. A new encapsulation protocol should therefore support an
optional NPA. optional NPA.
4.5 Integrity Check 4.5 Integrity Check
For the IP service, the probability of undetected packet error For the IP service, the probability of undetected packet error
should be small (or negligible) [RFC3819]. There is therefore should be small (or negligible) [RFC3819]. There is therefore
skipping to change at page 21, line 6 skipping to change at page 21, line 6
MPEG-2 TS Packet header). MPEG-2 TS Packet header).
An encapsulation must provide a strong integrity check for each An encapsulation must provide a strong integrity check for each
IP packet. The requirements for usage of a link CRC are provided IP packet. The requirements for usage of a link CRC are provided
in [RFC3819]. To ease hardware implementation, this check should in [RFC3819]. To ease hardware implementation, this check should
be carried in a trailer following the SNDU. A CRC-32 is sufficient be carried in a trailer following the SNDU. A CRC-32 is sufficient
for operation with up to a 12 KB payload, and may still provide for operation with up to a 12 KB payload, and may still provide
adequate protection for larger payloads. adequate protection for larger payloads.
INTERNET DRAFT Architecture for IP transport over MPEG-2 networks INTERNET DRAFT Architecture for IP transport over MPEG-2 networks
September 2004 December 2004
4.6 Identification of Scope. 4.6 Identification of Scope.
The MPE section header contains information that could be used by The MPE section header contains information that could be used by
The Receiver to identify the scope of the (MAC) address carried as a The Receiver to identify the scope of the (MAC) address carried as a
NPA, and prevent TS Packets intended for one scope to be received by NPA, and prevent TS Packets intended for one scope being received by
another. Similar functionality may be achieved by ensuring that only another. Similar functionality may be achieved by ensuring that only
IP packets that do not have overlapping scope are sent on the same IP packets that do not have overlapping scope are sent on the same
TS Logical Channel. In some cases, this may imply the use of TS Logical Channel. In some cases, this may imply the use of
multiple TS Logical Channels. multiple TS Logical Channels.
4.7 Extension Headers 4.7 Extension Headers
The evolution of the Internet service may in future require The evolution of the Internet service may in future require
additional functions. A flexible protocol should therefore provide a additional functions. A flexible protocol should therefore provide a
way to introduce new features when required, without having to way to introduce new features when required, without having to
skipping to change at page 22, line 6 skipping to change at page 22, line 6
- a fully specified algorithm that allows a sender to pack - a fully specified algorithm that allows a sender to pack
multiple packets per SNDU and to easily locate packet multiple packets per SNDU and to easily locate packet
fragments fragments
- extensibility - extensibility
- compatibility with legacy deployments - compatibility with legacy deployments
- ability to allow link encryption, when required - ability to allow link encryption, when required
- capability to support a full network architecture including - capability to support a full network architecture including
data, control and management planes data, control and management planes
INTERNET DRAFT Architecture for IP transport over MPEG-2 networks INTERNET DRAFT Architecture for IP transport over MPEG-2 networks
September 2004 December 2004
5. Address Resolution Functions 5. Address Resolution Functions
Address Resolution (AR) provides a mechanism that associates L2 Address Resolution (AR) provides a mechanism that associates L2
information with the IP address of a system. Many L2 technologies information with the IP address of a system. Many L2 technologies
employ unicast AR at the sender: an IP system wishing to send an IP employ unicast AR at the sender: an IP system wishing to send an IP
packet encapsulates it and places it into a L2 frame. It then packet encapsulates it and places it into a L2 frame. It then
identifies the appropriate L3 adjacency (e.g. next hop router, end identifies the appropriate L3 adjacency (e.g. next hop router, end
host) and determines the appropriate L2 adjacency (e.g. MAC address host) and determines the appropriate L2 adjacency (e.g. MAC address
in Ethernet) to which the frame should be sent so that the packet in Ethernet) to which the frame should be sent so that the packet
skipping to change at page 22, line 54 skipping to change at page 22, line 54
(i) A Receiver ID (e.g. a 6B MAC/NPA address). (i) A Receiver ID (e.g. a 6B MAC/NPA address).
(ii) A PID or index to find a PID. (ii) A PID or index to find a PID.
(iii) Tuner information (e.g. Transmit Frequency of the (iii) Tuner information (e.g. Transmit Frequency of the
physical layer of a satellite/broadcast link physical layer of a satellite/broadcast link
Elements (ii) and (iii) need to be de-referenced via indexes to the Elements (ii) and (iii) need to be de-referenced via indexes to the
Service Information (i.e. the Program Map Table, PMT) when the Service Information (i.e. the Program Map Table, PMT) when the
MPEG-2 Transmission Network includes remultiplexors that renumber MPEG-2 Transmission Network includes remultiplexors that renumber
the PID values of the TS Logical Channels that they process. (Note the PID values of the TS Logical Channels that they process. (Note
that PIDs are not intended to be end-to-end identifiers). However, that PIDs are not intended to be end-to-end identifiers). However,
although such use is common in broadcast TV networks, many private although remultiplexing is common in broadcast TV networks
networks do not need to employ multiplexors that renumber PIDs (scenarios A and B), many private networks do not need to employ
(see section 3.2). multiplexors that renumber PIDs (see section 3.2).
INTERNET DRAFT Architecture for IP transport over MPEG-2 networks INTERNET DRAFT Architecture for IP transport over MPEG-2 networks
September 2004 December 2004
The third element (iii) allows an AR client to resolve to a The third element (iii) allows an AR client to resolve to a
different MPEG TS Multiplex. This is used when there are several different MPEG TS Multiplex. This is used when there are several
channels that may be used for communication (i.e. multiple channels that may be used for communication (i.e. multiple
outbound/inbound links). In a mesh system, this could be used to outbound/inbound links). In a mesh system, this could be used to
determine connectivity. This AR information is used in two ways at a determine connectivity. This AR information is used in two ways at a
Receiver: Receiver:
(i) AR resolves an IP unicast or IPv4 broadcast address to the (MPEG (i) AR resolves an IP unicast or IPv4 broadcast address to the (MPEG
TS Multiplex, PID, MAC/NPA address). This allows the Receiver to set TS Multiplex, PID, MAC/NPA address). This allows the Receiver to set
L2 filters to let traffic pass to the IP layer. This is used for L2 filters to let traffic pass to the IP layer. This is used for
unicast, and IPv4 subnet broadcast unicast, and IPv4 subnet broadcast.
(ii) AR resolves an IP multicast address to the (MPEG TS Multiplex, (ii) AR resolves an IP multicast address to the (MPEG TS Multiplex,
PID, MAC/NPA address), and allows the Receiver to set L2 filters PID, MAC/NPA address), and allows the Receiver to set L2 filters
enabling traffic to pass to the IP layer. A Receiver in a MPEG-2 TS enabling traffic to pass to the IP layer. A Receiver in a MPEG-2 TS
Transmission Network needs to resolve the PID value and the tuning Transmission Network needs to resolve the PID value and the tuning
associated with a TS Logical Channel and (at least for unicast) (if present)associated with a TS Logical Channel and (at least for
the destination Receiver NPA address. unicast) the destination Receiver NPA address.
A star topology MPEG-2 TS transmission network is illustrated below, A star topology MPEG-2 TS transmission network is illustrated below,
with two Receivers receiving a forward broadcast channel sent by a with two Receivers receiving a forward broadcast channel sent by a
Hub. (A mesh system has some additional cases.) The forward Hub. (A mesh system has some additional cases.) The forward
broadcast channel consists of a "TS Multiplex" (a single physical broadcast channel consists of a "TS Multiplex" (a single physical
bearer) allowing communication with the terminals. These communicate bearer) allowing communication with the terminals. These communicate
using a set of return channels. using a set of return channels.
Forward broadcast Forward broadcast
MPEG-2 TS \ MPEG-2 TS \
skipping to change at page 24, line 6 skipping to change at page 24, line 6
| Hub |/ | Hub |/
| +\ /-----\ | +\ /-----\
\ / \ / \ \ / \ / \
\-----/ \ | Receiver| \-----/ \ | Receiver|
\-----------+ B | \-----------+ B |
\ / \ /
\-----/ \-----/
Figure 6: MPEG-2 Transmission Network with 2 Receivers Figure 6: MPEG-2 Transmission Network with 2 Receivers
INTERNET DRAFT Architecture for IP transport over MPEG-2 networks INTERNET DRAFT Architecture for IP transport over MPEG-2 networks
September 2004 December 2004
There are three possibilities for unicast AR: There are three possibilities for unicast AR:
(1) A system at a Receiver, A, needs to resolve an address of a (1) A system at a Receiver, A, needs to resolve an address of a
system that is at the Hub; system that is at the Hub;
(2) A system at a Receiver, A, needs to resolve an address that is (2) A system at a Receiver, A, needs to resolve an address that is
at another Receiver, B; at another Receiver, B;
(3) A host at the Hub needs to resolve an address that is at a (3) A host at the Hub needs to resolve an address that is at a
Receiver. The sender (encapsulation gateway), uses AR to provide the Receiver. The sender (encapsulation gateway), uses AR to provide the
the MPEG TS Multiplex, PID, MAC/NPA address for sending unicast, the MPEG TS Multiplex, PID, MAC/NPA address for sending unicast,
skipping to change at page 25, line 6 skipping to change at page 25, line 6
There are three distinct cases in which AR may be used: There are three distinct cases in which AR may be used:
(i) Multiple TS-Mux and the use of re-multiplexors; e.g. Digital (i) Multiple TS-Mux and the use of re-multiplexors; e.g. Digital
Terrestrial, Satellite TV broadcast multiplexes. Many such systems Terrestrial, Satellite TV broadcast multiplexes. Many such systems
employ remultiplexors that modify the PID values associated with TS employ remultiplexors that modify the PID values associated with TS
Logical Channels as they pass through the MPEG-2 transmission Logical Channels as they pass through the MPEG-2 transmission
network (as in Scenario A of Section 3.1). network (as in Scenario A of Section 3.1).
INTERNET DRAFT Architecture for IP transport over MPEG-2 networks INTERNET DRAFT Architecture for IP transport over MPEG-2 networks
September 2004 December 2004
(ii) Tuner configuration(s) that are fixed or controlled by some (ii) Tuner configuration(s) that are fixed or controlled by some
other process. In these systems, the PID value associated with a TS other process. In these systems, the PID value associated with a TS
Logical Channel may be known by the Sender. Logical Channel may be known by the Sender.
(iii) A service run over one TS Mux (i.e., uses only one PID, for (iii) A service run over one TS Mux (i.e., uses only one PID, for
example DOCSIS and some current DVB-RCS multicast systems). In these example DOCSIS and some current DVB-RCS multicast systems). In these
systems, the PID value of a TS Logical Channel may be known by the systems, the PID value of a TS Logical Channel may be known by the
Sender. Sender.
5.2.1 Table-based AR over MPEG-2 5.2.1 Table-based AR over MPEG-2
skipping to change at page 25, line 54 skipping to change at page 25, line 54
therefore do not need to provide interoperability with TV therefore do not need to provide interoperability with TV
equipment (e.g. links used solely for connecting IP (sub)networks). equipment (e.g. links used solely for connecting IP (sub)networks).
5.2.3. Query/Response AR over IP 5.2.3. Query/Response AR over IP
A query/response protocol may be used at the IP level (similar to, A query/response protocol may be used at the IP level (similar to,
or based on IPv6 Neighbor Advertisements of the ND protocol). The AR or based on IPv6 Neighbor Advertisements of the ND protocol). The AR
protocol may operate over an MPEG-2 TS Logical Channel using a protocol may operate over an MPEG-2 TS Logical Channel using a
previously agreed PID (e.g. configured, or communicated using a SI previously agreed PID (e.g. configured, or communicated using a SI
table). In this case, the AR could be performed by the target system table). In this case, the AR could be performed by the target system
itself (as in arp and nd). This has good soft-state properties, and itself (as in ARP and ND). This has good soft-state properties, and
is very tolerant to failures. To find an address, a system sends a is very tolerant to failures. To find an address, a system sends a
"query" to the network, and the "target" (or its proxy) replies. "query" to the network, and the "target" (or its proxy) replies.
INTERNET DRAFT Architecture for IP transport over MPEG-2 networks INTERNET DRAFT Architecture for IP transport over MPEG-2 networks
September 2004 December 2004
5.3 Unicast Address Scoping 5.3 Unicast Address Scoping
In some case, an MPEG-2 Transmission Network may support multiple IP In some case, an MPEG-2 Transmission Network may support multiple IP
networks. If this is the case, it is important to recognise the networks. If this is the case, it is important to recognise the
context (scope) within which an address is resolved, to prevent context (scope) within which an address is resolved, to prevent
packets from one addressed scope leaking into other scopes. packets from one addressed scope leaking into other scopes.
An examples of overlapping IP address assignments is the use of An examples of overlapping IP address assignments is the use of
private unicast addresses (e.g. in IPv4, 10/8 prefix; private unicast addresses (e.g. in IPv4, 10/8 prefix;
skipping to change at page 26, line 29 skipping to change at page 26, line 29
There is also a requirement for multicast address scoping There is also a requirement for multicast address scoping
(section 6.2). (section 6.2).
IP packets with these addresses must not be allowed to travel IP packets with these addresses must not be allowed to travel
outside their intended scope, and may cause unexpected behaviour if outside their intended scope, and may cause unexpected behaviour if
allowed to do so. In addition, overlapping address assignments can allowed to do so. In addition, overlapping address assignments can
arise using level 2 NPA addresses: arise using level 2 NPA addresses:
(i) The NPA address must be unique within the TS Logical Channel. (i) The NPA address must be unique within the TS Logical Channel.
IEEE MAC addresses used in Ethernet LANs are globally unique. Universal IEEE MAC addresses used in Ethernet LANs are
If the NPA addresses are not globally unique, the same NPA globally unique. If the NPA addresses are not globally
address may be re-used by Receivers in different addressed unique, the same NPA address may be re-used by Receivers
areas. in different addressed areas.
(ii) The NPA broadcast address (all 1s MAC address). Traffic with (ii) The NPA broadcast address (all 1s MAC address). Traffic with
this address should be confined to one addressed area. this address should be confined to one addressed area.
(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.
Reception of unicast packets destined for another addressed area may Reception of unicast packets destined for another addressed area may
lead to an increase in the rate of received packets by systems lead to an increase in the rate of received packets by systems
connected via the network. IP end hosts normally filter received connected via the network. IP end hosts normally filter received
unicast IP packets based on their assigned IP address. Reception of unicast IP packets based on their assigned IP address. Reception of
the additional network traffic may contribute to processing load but the additional network traffic may contribute to processing load but
should not lead to unexpected protocol behaviour. It does however should not lead to unexpected protocol behaviour. It does however
introduce a potential Denial of Service (DoS) opportunity. introduce a potential Denial of Service (DoS) opportunity.
When the Receiver acts as an IP router, the receipt of such an IP When the Receiver acts as an IP router, the receipt of such an IP
packet may lead to unexpected protocol behaviour. This also provides packet may lead to unexpected protocol behaviour. This also provides
a security vulnerability since arbitrary packets may be passed to a security vulnerability since arbitrary packets may be passed to
the IP layer. the IP layer.
INTERNET DRAFT Architecture for IP transport over MPEG-2 networks INTERNET DRAFT Architecture for IP transport over MPEG-2 networks
September 2004 December 2004
5.4 AR Authentication 5.4 AR Authentication
In many AR designs authentication has been overlooked, because of In many AR designs authentication has been overlooked, because of
the wired nature of most existing IP networks, which makes it easy the wired nature of most existing IP networks, which makes it easy
to control hosts physically connected [RFC3819]. With wireless to control hosts physically connected [RFC3819]. With wireless
connections, this is changing: unauthorised hosts actually can connections, this is changing: unauthorised hosts actually can
claim L2 resources. The address resolution client (i.e. Receiver) claim L2 resources. The address resolution client (i.e. Receiver)
may also need to verify the integrity and authenticity of the may also need to verify the integrity and authenticity of the
AR information that it receives. There are trust relationships AR information that it receives. There are trust relationships
both ways: clients need to know they have a valid server and both ways: clients need to know they have a valid server and
that the resolution is valid. Servers should perform authorisation that the resolution is valid. Servers should perform authorisation
issue before they allow a L2 address to be used. before they allow a L2 address to be used.
The MPEG-2 Transmission Network may also require access control to The MPEG-2 Transmission Network may also require access control to
prevent unauthorised use of the TS Multiplex, however, this is prevent unauthorised use of the TS Multiplex, however, this is
an orthogonal issue to address resolution. an orthogonal issue to address resolution.
5.5 Requirements for Unicast AR over MPEG-2 5.5 Requirements for Unicast AR over MPEG-2
The requirement for AR over MPEG-2 networks include: The requirement for AR over MPEG-2 networks include:
(i) Use of a table-based approach to promote AR scaling. This
(i) Use of a table based approach to promote AR scaling. This
requires definition of the frequency of update and volume of requires definition of the frequency of update and volume of
AR traffic generated. AR traffic generated.
(ii) Mechanisms to install AR information at the server (ii) Mechanisms to install AR information at the server
(unsolicited registration). (unsolicited registration).
(iii) Mechanisms to verify AR information held at the server (iii) Mechanisms to verify AR information held at the server
(solicited responses). Appropriate timer values need to be (solicited responses). Appropriate timer values need to be
defined. defined.
(iv) An ability to purge client AR information (after IP network (iv) An ability to purge client AR information (after IP network
renumbering, etc.). renumbering, etc.).
(v) Support of IP subnetwork scoping. (v) Support of IP subnetwork scoping.
(vi) Appropriate security associations to authenticate the sender. (vi) Appropriate security associations to authenticate the sender.
INTERNET DRAFT Architecture for IP transport over MPEG-2 networks INTERNET DRAFT Architecture for IP transport over MPEG-2 networks
September 2004 December 2004
6. Multicast Support 6. Multicast Support
This section addresses specific issues concerning IPv4 and IPv6 This section addresses specific issues concerning IPv4 and IPv6
multicast [RFC1112] over MPEG-2 Transmission Networks. The primary multicast [RFC1112] over MPEG-2 Transmission Networks. The primary
goal of multicast support will be efficient filtering of IP goal of multicast support will be efficient filtering of IP
multicast packets by the Receiver, and the mapping of IPv4 and multicast packets by the Receiver, and the mapping of IPv4 and
IPv6 multicast addresses [RFC3171] onto the associated PID value IPv6 multicast addresses [RFC3171] to the associated PID value
and TS Multiplex. and TS Multiplex.
The design should permit a large number of active multicast groups, The design should permit a large number of active multicast groups,
and should minimise the processing load at the Receiver when and should minimise the processing load at the Receiver when
filtering and forwarding IP multicast packets. For example, schemes filtering and forwarding IP multicast packets. For example, schemes
that may be easily implemented in hardware would be beneficial, that may be easily implemented in hardware would be beneficial,
since these may relieve drivers and operating systems from since these may relieve drivers and operating systems from
discarding unwanted multicast traffic [RFC3819]. discarding unwanted multicast traffic [RFC3819].
Multicast mechanisms are used at more than one protocol level. The Multicast mechanisms are used at more than one protocol level. The
upstream router feeding the MPEG-2 Encapsulator may forward upstream router feeding the MPEG-2 Encapsulator may forward
multicast traffic on the MPEG-2 TS Multiplex using a static or multicast traffic on the MPEG-2 TS Multiplex using a static or
dynamic set of groups. When static forwarding is used, the set dynamic set of groups. When static forwarding is used, the set
of IP multicast groups may also be configured or set using SNMP, of IP multicast groups may also be configured or set using SNMP,
Telnet, etc. A Receiver normally uses either an IP group management Telnet, etc. A Receiver normally uses either an IP group management
protocol (IGMP [RFC 3376] for IPv4 or MLD [RFC2710][RFC3810] for protocol (IGMP [RFC 3376] for IPv4 or MLD [RFC2710][RFC3810] for
IPv6) or a multicast routing protocol to establish tables that it IPv6) or a multicast routing protocol to establish tables that it
uses to dynamically enable local forwarding of received groups. In uses to dynamically enable local forwarding of received groups. In
a dynamic case, this group membership information is fed-back to the a dynamic case, this group membership information is fed-back to the
Sender to enable it to start sending new groups and (if required) to sender to enable it to start sending new groups and (if required) to
Update the tables that it produces for multicast AR. update the tables that it produces for multicast AR.
Appropriate procedures need to identify the correct action when the Appropriate procedures need to identify the correct action when the
same multicast group is available on more than one TS Logical same multicast group is available on more than one TS Logical
Channel. This could arise when different end hosts act as senders Channel. This could arise when different end hosts act as senders
to contribute IP packets with the same IP group destination address. to contribute IP packets with the same IP group destination address.
The correct behaviour for SSM [RFC3569] addresses must also be The correct behaviour for SSM [RFC3569] addresses must also be
considered. considered. It may also arise when a sender duplicates the same IP
group over several TS Logical Channels (or even different TS
It may also arise when a sender duplicates the same IP group over Multiplexes), and in this case a Receiver may potentially receive
several TS Logical Channels (or even different TS Multiplexes), and more than one copy of the same packet. At the IP level, the
in this case a Receiver may potentially receive more than one copy host/router may be unaware of this duplication.
of the same packet. At the IP level, the host/router may be unaware
of this duplication.
6.1 Multicast AR Functions 6.1 Multicast AR Functions
The functions required for multicast AR may be summarised as: The functions required for multicast AR may be summarised as:
(i) The Sender needs to know L2 mapping of a multicast group. (i) The Sender needs to know L2 mapping of a multicast group.
(ii) The Receiver needs to know L2 mapping of a multicast group. (ii) The Receiver needs to know L2 mapping of a multicast group.
INTERNET DRAFT Architecture for IP transport over MPEG-2 networks INTERNET DRAFT Architecture for IP transport over MPEG-2 networks
September 2004 December 2004
In the Internet, multicast AR is normally a mapping function rather In the Internet, multicast AR is normally a mapping function rather
than a one-to-one association using a protocol. In Ethernet, the than a one-to-one association using a protocol. In Ethernet, the
sender maps an IP address to a L2 MAC address, and the Receiver uses sender maps an IP address to a L2 MAC address, and the Receiver uses
the same mapping to determine the L2 address to set a L2 the same mapping to determine the L2 address to set a L2
hardware/software filter entry. hardware/software filter entry.
A typical sequence of actions for the dynamic case is: A typical sequence of actions for the dynamic case is:
L3) Populate the IP L3 membership tables at the Receiver. L3) Populate the IP L3 membership tables at the Receiver.
L3) Receivers send/forward IP L3 membership tables to the Hub L3) Receivers send/forward IP L3 membership tables to the Hub
L3) Dynamic/static forwarding at hub/upstream router of IP L3 L3) Dynamic/static forwarding at hub/upstream router of IP L3
groups groups
L2) Populate the IP AR tables at the encapsulator gateway L2) Populate the IP AR tables at the encapsulator gateway
(i.e. Map IP L3 mcast groups to L2 (PIDs)) (i.e. Map IP L3 mcast groups to L2 PIDs)
L2) Distribute the AR information to Receivers L2) Distribute the AR information to Receivers
L2) Set Receiver L2 multicast filters for IP groups in the L2) Set Receiver L2 multicast filters for IP groups in the
membership table. membership table.
To be flexible AR must associate a TS Logical Channel (PID) not only 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 with a group address, but possibly also a QoS class, and other
appropriate MPEG-2 TS attributes. Explicit per group AR to appropriate MPEG-2 TS attributes. Explicit per group AR to
individual L2 addresses is to be avoided. individual L2 addresses is to be avoided.
\ \
skipping to change at page 30, line 6 skipping to change at page 30, line 6
+---+----+ +---------+ +------------+ +---+----+ +---------+ +------------+
| | | | | |
+---+----+ +---+-----+ +---+----+ +---+----+ +---+-----+ +---+----+
| IP | | AR | |IGMP/MLD| | IP | | AR | |IGMP/MLD|
+---+----+ +---+-----+ +---+----+ +---+----+ +---+-----+ +---+----+
| | | | | |
*------------+------------+ *------------+------------+
Figure 7: Receiver Processing Architecture Figure 7: Receiver Processing Architecture
INTERNET DRAFT Architecture for IP transport over MPEG-2 networks INTERNET DRAFT Architecture for IP transport over MPEG-2 networks
September 2004 December 2004
6.2 Multicast Address Scoping 6.2 Multicast Address Scoping
As in unicast, it is important to recognise the context (scope) As in unicast, it is important to recognise the context (scope)
within which a multicast IP address is resolved, to prevent within which a multicast IP address is resolved, to prevent
packets from one addressed scope leaking into other scopes. packets from one addressed scope leaking into other scopes.
Examples of overlapping IP multicast address assignments, include: Examples of overlapping IP multicast address assignments, include:
(i) Some multicast addresses, (e.g., scoped multicast addresses (i) Some multicast addresses, (e.g., scoped multicast addresses
skipping to change at page 30, line 21 skipping to change at page 30, line 21
within which a multicast IP address is resolved, to prevent within which a multicast IP address is resolved, to prevent
packets from one addressed scope leaking into other scopes. packets from one addressed scope leaking into other scopes.
Examples of overlapping IP multicast address assignments, include: Examples of overlapping IP multicast address assignments, include:
(i) Some multicast addresses, (e.g., scoped multicast addresses (i) Some multicast addresses, (e.g., scoped multicast addresses
[RFC2365] that may be used in private networks). These are [RFC2365] that may be used in private networks). These are
only valid within the addressed area (examples for IPv4 only valid within the addressed area (examples for IPv4
include: 239/8; 224.0.0/24; 224.0.1/24). Similar cases include: 239/8; 224.0.0/24; 224.0.1/24). Similar cases
exist for some IPv6 multicast addresses [RFC2375]. exist for some IPv6 multicast addresses [RFC2375].
(ii) Scoped multicast addresses. Forwarding of these addresses (ii) Scoped multicast addresses. Forwarding of these addresses
is controlled by the scope associated with the address. is controlled by the scope associated with the address.
(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 IP packets with these addresses must not be allowed to travel
outside their intended scope (se section 5.3). Performing multicast outside their intended scope (see section 5.3). Performing multicast
AR at the IP level can enable providers to offer independently AR at the IP level can enable providers to offer independently
scoped addresses and would need to use multiple Multicast AR scoped addresses and would need to use multiple Multicast AR
servers, one per multicast domain. servers, one per multicast domain.
6.3 Requirements for Multicast over MPEG-2 6.3 Requirements for Multicast over MPEG-2
The requirements for supporting multicast include, but are not The requirements for supporting multicast include, but are not
restricted to: restricted to:
(i) Encapsulating multicast packets for transmission using a (i) Encapsulating multicast packets for transmission using a
skipping to change at page 31, line 6 skipping to change at page 31, line 6
networks built upon the MPEG-2 Transport Stream (TS). It also networks built upon the MPEG-2 Transport Stream (TS). It also
describes existing approaches. The focus is on IP networking, the describes existing approaches. The focus is on IP networking, the
mechanisms that are used and their applicability to supporting IP mechanisms that are used and their applicability to supporting IP
unicast and multicast services. unicast and multicast services.
The requirements for a new encapsulation of IPv4 and IPv6 packets is The requirements for a new encapsulation of IPv4 and IPv6 packets is
described, outlining the limitations of current methods and the need described, outlining the limitations of current methods and the need
for a streamlined IP-centric approach. for a streamlined IP-centric approach.
INTERNET DRAFT Architecture for IP transport over MPEG-2 networks INTERNET DRAFT Architecture for IP transport over MPEG-2 networks
September 2004 December 2004
The architecture also describes MPEG-2 Address Resolution (AR) The architecture also describes MPEG-2 Address Resolution (AR)
procedures to allow dynamic configuration of the sender and Receiver procedures to allow dynamic configuration of the sender and Receiver
using an MPEG-2 transmission link/network. These support IPv4 and using an MPEG-2 transmission link/network. These support IPv4 and
IPv6 services in both the unicast and multicast modes. Resolution IPv6 services in both the unicast and multicast modes. Resolution
protocols will support IP packet transmission using both the protocols will support IP packet transmission using both the
Multiprotocol Encapsulation (MPE), which is currently Multiprotocol Encapsulation (MPE), which is currently
widely deployed, and also any IETF defined ULE encapsulation widely deployed, and also any IETF defined ULE encapsulation
[ID-IPDVB-ULE]. [ID-IPDVB-ULE].
skipping to change at page 32, line 6 skipping to change at page 32, line 6
cannot enforce the use of end-to-end mechanisms. cannot enforce the use of end-to-end mechanisms.
A related role for subnetwork security is to protect users against A related role for subnetwork security is to protect users against
traffic analysis, i.e., identifying the communicating parties (by IP traffic analysis, i.e., identifying the communicating parties (by IP
or MAC address) and determining their communication patterns, even or MAC address) and determining their communication patterns, even
when their actual contents are protected by strong end-to-end when their actual contents are protected by strong end-to-end
security mechanisms (this is important for networks such as security mechanisms (this is important for networks such as
broadcast/radio, where eaves-dropping is easy). broadcast/radio, where eaves-dropping is easy).
INTERNET DRAFT Architecture for IP transport over MPEG-2 networks INTERNET DRAFT Architecture for IP transport over MPEG-2 networks
September 2004 December 2004
Where it is possible for an attacker to inject traffic into the Where it is possible for an attacker to inject traffic into the
subnetwork control plane, subnetwork security can additionally subnetwork control plane, subnetwork security can additionally
protect the subnetwork assets. This threat must specifically be protect the subnetwork assets. This threat must specifically be
considered for the protocols used for subnetwork control functions considered for the protocols used for subnetwork control functions
(e.g. address resolution, management, configuration). Possible (e.g. address resolution, management, configuration). Possible
threats include theft of service and denial of service; shared media threats include theft of service and denial of service; shared media
subnets tend to be especially vulnerable to such attacks [RFC3819]. subnets tend to be especially vulnerable to such attacks [RFC3819].
Appropriate security functions must therefore be provided for ipdvb Appropriate security functions must therefore be provided for ipdvb
skipping to change at page 32, line 52 skipping to change at page 32, line 52
links. An ISP may also wish to provide end-to-end security services links. An ISP may also wish to provide end-to-end security services
to the end-users (based on the well known mechanisms such as IPSec). to the end-users (based on the well known mechanisms such as IPSec).
Therefore it is important to understand that both security solutions Therefore it is important to understand that both security solutions
(ANO-to-ISP and ISP-to-end users) may co-exist. (ANO-to-ISP and ISP-to-end users) may co-exist.
MPE supports optional link encryption using a pair of bits within MPE supports optional link encryption using a pair of bits within
the MPE protocol header to indicate the use of encryption. To the MPE protocol header to indicate the use of encryption. To
support optional link level encryption, it is recommended that a new support optional link level encryption, it is recommended that a new
encapsulation also supports optional encryption of the SNDU payload. encapsulation also supports optional encryption of the SNDU payload.
Furthermore, it may be desirable to encrypt/authenticate some/all of Furthermore, it may be desirable to encrypt/authenticate some/all of
the SNDU headers. The method of encryption and the way in which the SNDU headers. However, the specification must provide
keys are exchanged is beyond the scope of the ULE Specification. appropriate code points to allow such encryption to be implemented
However, the specification must provide appropriate code points to at the link layer.
allow such encryption to be implemented at the link layer.
INTERNET DRAFT Architecture for IP transport over MPEG-2 networks INTERNET DRAFT Architecture for IP transport over MPEG-2 networks
September 2004 December 2004
9. Acknowledgments 9. Acknowledgments
The authors wish to thank Isabel Amonou, Torsten Jaekel, Pierre The authors wish to thank Isabel Amonou, Torsten Jaekel, Pierre
Loyer, Luoma Juha-Pekka and and Rod Walsh for their detailed inputs. Loyer, Luoma Juha-Pekka and and Rod Walsh for their detailed inputs.
We also wish to acknowledge the input provided by the members of the We also wish to acknowledge the input provided by the members of
IETF ipdvb WG. the IETF ipdvb WG.
10. References 10. References
10.1 Normative References 10.1 Normative References
[ISO-MPEG] ISO/IEC DIS 13818-1:2000 "Information Technology; Generic [ISO-MPEG] ISO/IEC DIS 13818-1:2000 "Information Technology; Generic
Coding of Moving Pictures and Associated Audio Information Systems", Coding of Moving Pictures and Associated Audio Information Systems",
International Standards Organisation (ISO). International Standards Organisation (ISO).
[ETSI-DAT] EN 301 192 Specifications for Data Broadcasting, European [ETSI-DAT] EN 301 192 Specifications for Data Broadcasting, European
skipping to change at page 34, line 6 skipping to change at page 34, line 6
Committee (ATSC), Doc. A/65B, 2003. Committee (ATSC), Doc. A/65B, 2003.
[ATSC-S] A/80, "Modulation and Coding Requirements for Digital TV [ATSC-S] A/80, "Modulation and Coding Requirements for Digital TV
(DTV) Applications over Satellite", Advanced Television Systems (DTV) Applications over Satellite", Advanced Television Systems
Committee (ATSC), Doc. A/80, 1999. Committee (ATSC), Doc. A/80, 1999.
[CLC99] Clausen, H., Linder, H., and Collini-Nocker, B., "Internet [CLC99] Clausen, H., Linder, H., and Collini-Nocker, B., "Internet
over Broadcast Satellites", IEEE Commun. Mag. 1999, pp.146-151. over Broadcast Satellites", IEEE Commun. Mag. 1999, pp.146-151.
INTERNET DRAFT Architecture for IP transport over MPEG-2 networks INTERNET DRAFT Architecture for IP transport over MPEG-2 networks
September 2004 December 2004
[ETSI-DAT] EN 301 192 Specifications for Data Broadcasting, European [ETSI-DAT] EN 301 192, "Specifications for Data Broadcasting",
Telecommunications Standards Institute (ETSI). European Telecommunications Standards Institute (ETSI).
[ETSI-DVBC] EN 300 800 Digital Video Broadcasting (DVB); DVB [ETSI-DVBC] EN 300 800, "Digital Video Broadcasting (DVB); DVB
interaction channel for Cable TV distribution systems (CATV), interaction channel for Cable TV distribution systems (CATV)",
European Telecommunications Standards Institute (ETSI). European Telecommunications Standards Institute (ETSI).
[ETSI-DVBRCS] EN 301 790 Digital Video Broadcasting (DVB); [ETSI-DVBRCS] EN 301 790, "Digital Video Broadcasting (DVB);
Interaction channel for satellite distribution systems; European Interaction channel for satellite distribution systems", European
Telecommunications Standards Institute (ETSI). Telecommunications Standards Institute (ETSI).
[ETSI-DVBS] EN 301 421 Digital Video Broadcasting (DVB); Modulation [ETSI-DVBS] EN 301 421,"Digital Video Broadcasting (DVB);
and Coding for DBS satellite systems at 11/12 GHz, European Modulation and Coding for DBS satellite systems at 11/12 GHz,
Telecommunications Standards Institute (ETSI). European Telecommunications Standards Institute (ETSI).
[ETSI-DVBT] EN 300 744 Digital Video Broadcasting (DVB); Framing [ETSI-DVBS2] DCB, "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 structure, channel coding and modulation for digital terrestrial
television (DVB-T), European Telecommunications Standards Institute television (DVB-T)", European Telecommunications Standards
(ETSI). Institute (ETSI).
[ETSI-MHP] ETSI TS 101 812, "Digital Video Broadcasting (DVB);
Multimedia Home Platform (MHP) Specification", v1.2.1, European
Telecommunications Standards Institute (ETSI), June 2002.
[ETSI-IPDC] "IP Datacast Specification", DVB Interim Specification [ETSI-IPDC] "IP Datacast Specification", DVB Interim Specification
CNMS 1026 v1.0.0,(Work in Progress), April 2004. CNMS 1026 v1.0.0,(Work in Progress), April 2004.
[ID-IPDVB-ULE] Fairhurst, G., B. Collini-Nocker, "Ultra Lightweight [ID-IPDVB-ULE] Fairhurst, G., B. Collini-Nocker, "Ultra Lightweight
Encapsulation for transmission of IP datagrams over MPEG-2/DVB Encapsulation for transmission of IP datagrams over MPEG-2/DVB
networks", Internet Draft, draft-ipdvb-ule-01.txt, Work in Progress, networks", Internet Draft, draft-ipdvb-ule-01.txt, Work in Progress,
IPDVB WG. IPDVB WG.
[ID-IPDVB-AR] Fairhurst, G., M-J. Montpetit, "Address Resolution for [ID-IPDVB-AR] Fairhurst, G., M-J. Montpetit, "Address Resolution for
skipping to change at page 34, line 49 skipping to change at page 35, line 5
[ID-MMUSIC-IMG] Y. Nomura, R. Walsh, J-P. Luoma, J. Ott, H. [ID-MMUSIC-IMG] Y. Nomura, R. Walsh, J-P. Luoma, J. Ott, H.
Schulzrinne, "Protocol Requirements for Internet Media Guides", Schulzrinne, "Protocol Requirements for Internet Media Guides",
Internet Draft, draft-ietf-mmusic-img-req.txt, Work in Progress, Internet Draft, draft-ietf-mmusic-img-req.txt, Work in Progress,
MMUSIC WG. MMUSIC WG.
[ISO-AUD] ISO/IEC 13818-3:1995 "Information technology; Generic [ISO-AUD] ISO/IEC 13818-3:1995 "Information technology; Generic
coding of moving pictures and associated audio information; Part coding of moving pictures and associated audio information; Part
3: Audio", International Standards Organisation (ISO). 3: Audio", International Standards Organisation (ISO).
INTERNET DRAFT Architecture for IP transport over MPEG-2 networks
December 2004
[ISO-DSMCC] ISO/IEC IS 13818-6 "Information technology; Generic [ISO-DSMCC] ISO/IEC IS 13818-6 "Information technology; Generic
coding of moving pictures and associated audio information; Part coding of moving pictures and associated audio information; Part
6: Extensions for DSM-CC.", International Standards Organisation 6: Extensions for DSM-CC", International Standards Organisation
(ISO). (ISO).
[ISO-VID] ISO/IEC DIS 13818-2:1998 "Information technology; [ISO-VID] ISO/IEC DIS 13818-2:1998 "Information technology;
Generic coding of moving pictures and associated audio information; Generic coding of moving pictures and associated audio information;
Video", International Standards Organisation (ISO). Video", International Standards Organisation (ISO).
INTERNET DRAFT Architecture for IP transport over MPEG-2 networks
September 2004
[Ken87] Kent C.A., and J. C. Mogul, "Fragmentation Considered [Ken87] Kent C.A., and J. C. Mogul, "Fragmentation Considered
Harmful", Proc. ACM SIGCOMM, USA, CCR Vol.17, No.5, 1988, pp.390- Harmful", Proc. ACM SIGCOMM, USA, CCR Vol.17, No.5, 1988, pp.390-
401. 401.
[OPEN-CABLE] "Open Cable Application Platform Specification;
OCAP 2.0 Profile", OC-SP-OCAP2.0-I01-020419, Cable Labs, April
2002.
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, [RFC793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981. RFC 793, September 1981.
[RFC1112] Deering, S., "Host extensions for IP multicasting", [RFC1112] Deering, S., "Host extensions for IP multicasting",
STD 5, RFC 1112, August 1989. STD 5, RFC 1112, August 1989.
[RFC1122] B. Braden, ed., "Requirements for Internet Hosts - [RFC1122] B. Braden, ed., "Requirements for Internet Hosts -
Communication Layers", RFC 1122. Communication Layers", RFC 1122, October 1989.
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
November 1990. November 1990.
[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", [RFC2365] Meyer, D., "Administratively Scoped IP Multicast",
BCP 23, RFC 2365, July 1998. BCP 23, RFC 2365, July 1998.
[RFC2375] Hinden, R. and S. Deering, "IPv6 Multicast Address [RFC2375] Hinden, R. and S. Deering, "IPv6 Multicast Address
Assignments", RFC 2375, July 1998. Assignments", RFC 2375, July 1998.
skipping to change at page 35, line 47 skipping to change at page 36, line 5
and Y. Zhang, "A Link-Layer Tunneling Mechanism for and Y. Zhang, "A Link-Layer Tunneling Mechanism for
Unidirectional Links", RFC 3077, March 2001. Unidirectional Links", RFC 3077, March 2001.
[RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, [RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima,
H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K.,
Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T.,
Yoshimura, T., and H. Zheng, "RObust Header Compression (ROHC): Yoshimura, T., and H. Zheng, "RObust Header Compression (ROHC):
Framework and four profiles: RTP, UDP, ESP, and uncompressed ", Framework and four profiles: RTP, UDP, ESP, and uncompressed ",
RFC 3095, July 2001. RFC 3095, July 2001.
INTERNET DRAFT Architecture for IP transport over MPEG-2 networks
December 2004
[RFC3171] Albanna, Z., Almeroth, K., Meyer, D., and M. Schipper, [RFC3171] Albanna, Z., Almeroth, K., Meyer, D., and M. Schipper,
"IANA Guidelines for IPv4 Multicast Address Assignments", BCP 51, "IANA Guidelines for IPv4 Multicast Address Assignments", BCP 51,
RFC 3171, August 2001. RFC 3171, August 2001.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B.,
and A. Thyagarajan, "Internet Group Management Protocol, and A. Thyagarajan, "Internet Group Management Protocol,
Version 3", RFC 3376, October 2002. Version 3", RFC 3376, October 2002.
INTERNET DRAFT Architecture for IP transport over MPEG-2 networks RFC3569] Bhattacharyya, S., "An Overview of Source-Specific
September 2004-09-24
[RFC3569] Bhattacharyya, S., "An Overview of Source-Specific
Multicast (SSM)", RFC 3569, July 2003. Multicast (SSM)", RFC 3569, July 2003.
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC3819] Phil Karn, C. Borman, G Fairhurst, D. Grossman, R. Ludwig, [RFC3819] Phil Karn, C. Borman, G. Fairhurst, D. Grossman, R.
J. Mahdavi, G. Montenegro, J. Touch, L. Wood Advice for Internet Ludwig,J. Mahdavi, G. Montenegro, J. Touch, L. Wood, "Advice for
Subnetwork Designers, RFC 3819, BCP 89. Internet Subnetwork Designers", RFC 3819, BCP 89.
11. Authors' Addresses 11. Authors' Addresses
Marie J. Montpetit Marie J. Montpetit
MJMontpetit.com MJMontpetit.com
Email: marie@mjmontpetit.com Email: marie@mjmontpetit.com
Godred Fairhurst Godred Fairhurst
Department of Engineering Department of Engineering
University of Aberdeen University of Aberdeen
skipping to change at page 36, line 46 skipping to change at page 37, line 5
Bernhard Collini-Nocker Bernhard Collini-Nocker
Department of Scientific Computing Department of Scientific Computing
University of Salzburg University of Salzburg
Jakob Haringer Str. 2 Jakob Haringer Str. 2
5020 Salzburg 5020 Salzburg
Austria Austria
Email: bnocker@cosy.sbg.ac.at Email: bnocker@cosy.sbg.ac.at
Web: http://www.network-research.org Web: http://www.network-research.org
INTERNET DRAFT Architecture for IP transport over MPEG-2 networks
December 2004
Hilmar Linder Hilmar Linder
Department of Scientific Computing Department of Scientific Computing
University of Salzburg University of Salzburg
Jakob Haringer Str. 2 Jakob Haringer Str. 2
5020 Salzburg 5020 Salzburg
Austria Austria
Email: hlinder@cosy.sbg.ac.at Email: hlinder@cosy.sbg.ac.at
Web: http://www.network-research.org Web: http://www.network-research.org
INTERNET DRAFT Architecture for IP transport over MPEG-2 networks
September 2004
12. IPR Notices 12. IPR Notices
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights. it has made any independent effort to identify any such rights.
skipping to change at page 37, line 44 skipping to change at page 38, line 5
Disclaimer of Validity Disclaimer of Validity
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
INTERNET DRAFT Architecture for IP transport over MPEG-2 networks
December 2004
13. Copyright Statement 13. Copyright Statement
Copyright (C) The Internet Society (2004). This document is Copyright (C) The Internet Society (2004). This document is
subject to the rights, licenses and restrictions contained in subject to the rights, licenses and restrictions contained in
BCP 78, and except as set forth therein, the authors retain all BCP 78, and except as set forth therein, the authors retain all
their rights. their rights.
14. IANA Considerations 14. IANA Considerations
A set of protocols which meet these requirements, will require the A set of protocols which meet these requirements, will require the
IANA make assignments. This document in itself, however, does not IANA make assignments. This document in itself, however, does not
require any IANA involvement. require any IANA involvement.
INTERNET DRAFT Architecture for IP transport over MPEG-2 networks
September 2004
Appendix A: MPEG-2 Encapsulation Mechanisms Appendix A: MPEG-2 Encapsulation Mechanisms
To transmit packet data over an MPEG-2 transmission network requires To transmit packet data over an MPEG-2 transmission network requires
that individual SNDUs (e.g. IPv4, IPv6 packets, or bridged Ethernet that individual PDUs (e.g. IPv4, IPv6 packets, or bridged Ethernet
Frames) are encapsulated using a convergence protocol. The following Frames) are encapsulated using a convergence protocol. The following
encapsulations are currently standardised for MPEG-2 transmission encapsulations are currently standardised for MPEG-2 transmission
networks: networks:
(i) Multi-Protocol Encapsulation (MPE). (i) Multi-Protocol Encapsulation (MPE).
The Multi-Protocol Encapsulation, MPE, specification of DVB The Multi-Protocol Encapsulation, MPE, specification of DVB
[ETSI-DAT] uses private Sections for the transport of IP [ETSI-DAT] uses private Sections for the transport of IP
packets and uses encapsulation that is similar to the IEEE packets and uses encapsulation that is similar to the IEEE
LAN/MAN standards [LLC]. Data packets are encapsulated in LAN/MAN standards [LLC]. Data packets are encapsulated in
datagram sections that are compliant with the DSMCC section datagram sections that are compliant with the DSMCC section
format for private data. Some Receivers may exploit section format for private data. Some Receivers may exploit section
processing hardware to perform a first-level filter of the processing hardware to perform a first-level filter of the
packets that arrive at the Receiver. packets that arrive at the Receiver.
The section header also includes fields, which may be used
by a Receiver to filter datagrams assigned to the same TS
Logical Channel. This feature allows several logical
networks to be established without assigning PID values to
each of the services. Section filtering is especially well
suited for TV broadcast environments where remultiplexing
comes into play.
This encapsulation makes use of a MAC-level Network Point of This encapsulation makes use of a MAC-level Network Point of
Attachment address. The address format conforms to the Attachment address. The address format conforms to the
ISO/IEEE standards for LAN/MAN LLC]. The 48-bit MAC address ISO/IEEE standards for LAN/MAN [LLC]. The 48-bit MAC address
field contains the MAC address of the destination; it is field contains the MAC address of the destination; it is
distributed over six 8-bit fields, labelled MAC_address_1 to distributed over six 8-bit fields, labelled MAC_address_1 to
MAC_address_6. The MAC_address_1 field contains the most MAC_address_6. The MAC_address_1 field contains the most
significant byte of the MAC address, while MAC_address_6 significant byte of the MAC address, while MAC_address_6
contains the least significant byte. How many of these contains the least significant byte. How many of these
bytes are significant is optional and defined by the value bytes are significant is optional and defined by the value
of the broadcast descriptor table [SI-DAT] sent separately of the broadcast descriptor table [SI-DAT] sent separately
over another MPEG-2 TS within the TS multiplex. over another MPEG-2 TS within the TS multiplex.
MPE is currently a widely deployed scheme. Due to MPE is currently a widely deployed scheme. Due to
Investments in existing systems, usage is likely to continue Investments in existing systems, usage is likely to continue
in current and future MPEG-2 Transmission Networks. in current and future MPEG-2 Transmission Networks. ATSC
provides a scheme similar to MPE [ATSC-DAT] with some small
differences.
INTERNET DRAFT Architecture for IP transport over MPEG-2 networks
December 2004
(ii) Data Piping. (ii) Data Piping.
The Data Piping profile [ETSI-DAT] is a minimum overhead, The Data Piping profile [ETSI-DAT] is a minimum overhead,
simple and flexible profile that makes no assumptions simple and flexible profile that makes no assumptions
concerning the format of the data being sent. In this concerning the format of the data being sent. In this
profile, the Receiver is intended to provide PID filtering, profile, the Receiver is intended to provide PID filtering,
packet reassembly according to [DVB-SIDAT-368], error packet reassembly according to [DVB-SIDAT-368], error
detection and optional Conditional Access (link encryption). detection and optional Conditional Access (link encryption).
INTERNET DRAFT Architecture for IP transport over MPEG-2 networks
September 2004
The specification allows the user data stream to be The specification allows the user data stream to be
unstructured or organized into packets. The specific unstructured or organized into packets. The specific
structure is transparent to the Receiver. It may conform to structure is transparent to the Receiver. It may conform to
any protocol, e.g., IP, Ethernet, NFS, FDDI, MPEG-2 PES, any protocol, e.g., IP, Ethernet, NFS, FDDI, MPEG-2 PES,
etc. etc.
(iii) Data Streaming. (iii) Data Streaming.
The data broadcast specification profile [ETSI-DAT] for PES The data broadcast specification profile [ETSI-DAT] for PES
tunnels (Data Streaming) supports unicast and multicast data tunnels (Data Streaming) supports unicast and multicast data
 End of changes. 

This html diff was produced by rfcdiff 1.19, available from http://www.levkowetz.com/ietf/tools/rfcdiff/