RFC4259 日本語訳
4259 A Framework for Transmission of IP Datagrams over MPEG-2Networks. M.-J. Montpetit, G. Fairhurst, H. Clausen, B.Collini-Nocker, H. Linder. November 2005. (Format: TXT=100423 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group M.-J. Montpetit
Request for Comments: 4259 Motorola Connected Home Solutions
Category: Informational G. Fairhurst
University of Aberdeen
H. Clausen
TIC Systems
B. Collini-Nocker
H. Linder
University of Salzburg
November 2005
ワーキンググループM.Jをネットワークでつないでください。 Montpetitはコメントのために以下を要求します。 4259年のモトローラコネクテッドホームソリューションカテゴリ: ザルツブルグ2005年11月の情報のG.のシステムB.Collini-ノッカーH.ランデールFairhurstアバディーン大学H.クローゼンチック大学
A Framework for Transmission of IP Datagrams over MPEG-2 Networks
MPEG-2つのネットワークの上のIPデータグラムの送信のためのフレームワーク
Status of This Memo
このメモの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
Abstract
要約
This document describes an architecture for the transport of IP Datagrams over ISO MPEG-2 Transport Streams (TS). The MPEG-2 TS has been widely accepted not only for providing digital TV services but also as a subnetwork technology for building IP networks. Examples of systems using MPEG-2 include the Digital Video Broadcast (DVB) and Advanced Television Systems Committee (ATSC) Standards for Digital Television.
このドキュメントはIPデータグラムの輸送のためにISO MPEG-2Transport Streams(TS)の上でアーキテクチャについて説明します。 MPEG-2TSがデジタルテレビサービスを提供すると認められただけではなく、ビルIPネットワークのためのサブネットワーク技術としても広く認められました。 MPEG-2を使用するシステムに関する例はDigital TelevisionのDigital Video Broadcast(DVB)とAdvanced Television Systems Committee(ATSC)規格を含んでいます。
The document identifies the need for a set of Internet standards defining the interface between the MPEG-2 Transport Stream and an IP subnetwork. It suggests a new encapsulation method for IP datagrams and proposes protocols to perform IPv6/IPv4 address resolution, to associate IP packets with the properties of the Logical Channels provided by an MPEG-2 TS.
ドキュメントはMPEG-2Transport StreamとIPサブネットワークとのインタフェースを定義する1セットのインターネット標準の必要性を特定します。 それは、IPデータグラムのために新しいカプセル化メソッドを示して、IPv6/IPv4アドレス解決を実行するためにプロトコルを提案します、Logical Channelsの資産がMPEG-2TSによって提供されている副IPパケットに。
Montpetit, et al. Informational [Page 1] RFC 4259 IP Transport over MPEG-2 Networks November 2005
Montpetit、他 情報[1ページ]のRFC4259IP輸送はMPEG-2の上で2005年11月をネットワークでつなぎます。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Salient Features of the Architecture .......................4
2. Conventions Used in This Document ...............................4
3. Architecture ....................................................8
3.1. MPEG-2 Transmission Networks ...............................8
3.2. TS Logical Channels .......................................10
3.3. Multiplexing and Re-Multiplexing ..........................12
3.4. IP Datagram Transmission ..................................13
3.5. Motivation ................................................14
4. Encapsulation Protocol Requirements ............................16
4.1. Payload Unit Delimitation .................................17
4.2. Length Indicator ..........................................18
4.3. Next Level Protocol Type ..................................19
4.4. L2 Subnet Addressing ......................................19
4.5. Integrity Check ...........................................21
4.6. Identification of Scope. ..................................21
4.7. Extension Headers .........................................21
4.8. Summary of Requirements for Encapsulation .................22
5. Address Resolution Functions ...................................22
5.1. Address Resolution for MPEG-2 .............................23
5.2. Scenarios for MPEG AR .....................................25
5.2.1. Table-Based AR over MPEG-2 .........................25
5.2.2. Table-Based AR over IP .............................26
5.2.3. Query/Response AR over IP ..........................26
5.3. Unicast Address Scoping ...................................26
5.4. AR Authentication .........................................27
5.5. Requirements for Unicast AR over MPEG-2 ...................28
6. Multicast Support ..............................................28
6.1. Multicast AR Functions ....................................29
6.2. Multicast Address Scoping .................................30
6.3. Requirements for Multicast over MPEG-2 ....................31
7. Summary ........................................................31
8. Security Considerations ........................................32
8.1. Link Encryption ...........................................33
9. IANA Considerations ............................................34
10. Acknowledgements ..............................................34
11. References ....................................................34
11.1. Normative References .....................................34
11.2. Informative References ...................................34
Appendix A ........................................................39
1. 序論…3 1.1. アーキテクチャに関する特徴…4 2. このドキュメントで中古のコンベンション…4 3. アーキテクチャ…8 3.1. MPEG-2つの送電網…8 3.2. t論理チャネル…10 3.3. 多重送信して、再多重送信します…12 3.4. IPデータグラム送信…13 3.5. 動機…14 4. カプセル化プロトコル要件…16 4.1. 有効搭載量ユニット区切り…17 4.2. 長さのインディケータ…18 4.3. 次の平らなプロトコルタイプ…19 4.4. L2サブネットアドレシング…19 4.5. 保全チェック…21 4.6. 範囲の識別。 ..................................21 4.7. 拡大ヘッダー…21 4.8. カプセル化のための要件の概要…22 5. 解決機能を扱ってください…22 5.1. MPEG-2のために解決を扱ってください…23 5.2. MPEG ARのためのシナリオ…25 5.2.1. テーブルベースのAR、MPEG-2以上…25 5.2.2. IPの上のテーブルベースのAR…26 5.2.3. IPの上の質問/応答AR…26 5.3. ユニキャストアドレスの見ること…26 5.4. AR認証…27 5.5. ユニキャストARのための要件、MPEG-2以上…28 6. マルチキャストサポート…28 6.1. マルチキャストARは機能します…29 6.2. マルチキャストアドレスの見ること…30 6.3. マルチキャストのための要件、MPEG-2以上…31 7. 概要…31 8. セキュリティ問題…32 8.1. 暗号化をリンクしてください…33 9. IANA問題…34 10. 承認…34 11. 参照…34 11.1. 標準の参照…34 11.2. 有益な参照…34 付録A…39
Montpetit, et al. Informational [Page 2] RFC 4259 IP Transport over MPEG-2 Networks November 2005
Montpetit、他 情報[2ページ]のRFC4259IP輸送はMPEG-2の上で2005年11月をネットワークでつなぎます。
1. Introduction
1. 序論
This document identifies requirements and an architecture for the transport of IP Datagrams over ISO MPEG-2 Transport Streams [ISO-MPEG]. The prime focus is the efficient and flexible delivery of IP services over those subnetworks that use the MPEG-2 Transport Stream (TS).
このドキュメントはIPデータグラムの輸送のためにISO MPEG-2Transport Streams[ISO-MPEG]の上で要件とアーキテクチャを特定します。 主要な焦点は効率的でフレキシブルなMPEG-2Transport Stream(TS)を使用するそれらのサブネットワークの上のIPサービスの配送です。
The architecture is designed to be compatible with services based on MPEG-2, for example the Digital Video Broadcast (DVB) architecture, the Advanced Television Systems Committee (ATSC) system [ATSC, ATSC-G], and other similar MPEG-2-based transmission systems. Such systems typically provide unidirectional (simplex) physical and link layer standards, and have been defined for a wide range of physical media (e.g., Terrestrial TV [ETSI-DVBT, ATSC-PSIP-TC], Satellite TV [ETSI-DVBS, ETSI-DVBS2, ATSC-S], Cable Transmission [ETSI-DVBC, ATSC-PSIP-TC, OPEN-CABLE], and data transmission over MPEG-2 [ETSI-MHP].
アーキテクチャは、MPEG-2に基づくサービスと互換性があるように設計されています; 伝動装置そのようなシステムは単方向(シンプレクス)に物理的、そして、リンクレイヤ規格を通常提供します、そして、さまざまな物理的なメディアのために定義されてください、そうした。例えば、Digital Video Broadcast(DVB)アーキテクチャ、ATSC-Gの、そして、もう一方同様のAdvanced Television Systems Committee(ATSC)システムATSC、MPEG2ベース、(e; g.、Terrestrial TV ETSI-DVBT、ATSC-PSIP-TC、Satellite TV ETSI-DVBS、ETSI-DVBS2、ATSC-S、Cable Transmission ETSI-DVBC、ATSC-PSIP-TC、オープン-CABLE、およびMPEG-2の上のデータ伝送ETSI-MHP。
+-+-+-+-+------+------------+---+--+--+---------+
|T|V|A|O| O | | O |S |O | |
|e|i|u|t| t | | t |I |t | |
|l|d|d|h| h | IP | h | |h | Other |
|e|e|i|e| e | | e |T |e |protocols|
|t|o|o|r| r | | r |a |r | native |
|e| | | | | | |b | | over |
|x| | | | | +---+----+-+ |l | |MPEG-2 TS|
|t| | | | | | | MPE | |e | | |
| | | | | +--+---+ +------+ | | | |
| | | | | | AAL5 |ULE|Priv. | | | | |
+-+-+-+-+---+------+ | +-+--+--+ |
| PES | ATM | |Sect. |Section| |
+-------+----------+---+------+-------+---------+
| MPEG-2 TS |
+---------+-------+----------------+------------+
|Satellite| Cable | Terrestrial TV | Other PHY |
+---------+-------+----------------+------------+
+-+-+-+-+------+------------+---+--+--+---------+ |T|V|A|O| O| | O|S|O| | |e|i|u|t| t| | t|I|t| | |l|d|d|h| h| IP| h| |h| 他| |e|e|i|e| e| | e|T|e|プロトコル| |t|o|o|r| r| | r|a|r| ネイティブ| |e| | | | | | |b| | 終わる| |x| | | | | +---+----+-+ |l| |MPEG-2t| |t| | | | | | | MPE| |e| | | | | | | | +--+---+ +------+ | | | | | | | | | | AAL5|ウレ|Priv。 | | | | | +-+-+-+-+---+------+ | +-+--+--+ | | PES| 気圧| |セクト。 |セクション| | +-------+----------+---+------+-------+---------+ | MPEG-2t| +---------+-------+----------------+------------+ |衛星| ケーブル| 地球のテレビ| 他のPHY| +---------+-------+----------------+------------+
Figure 1: Overview of the MPEG-2 protocol stack
図1: MPEG-2プロトコル・スタックの概要
Although many MPEG-2 systems carry a mixture of data types, MPEG-2 components may be, and are, also used to build IP-only networks. Standard system components offer advantages of improved interoperability and larger deployment. However, some MPEG-2 networks do not implement all parts of a DVB / ATSC system, and may, for instance, support minimal, or no, signalling of Service Information (SI) tables.
多くのMPEG-2台のシステムがデータ型の混合物を運びますが、MPEG-2つのコンポーネントが、あるかもしれなくて、あって、また、IPだけネットワークを造るのにおいて使用されています。 標準のシステムの部品は改良された相互運用性と、より大きい展開の利点を示します。 そして、しかしながら、いくつかのMPEG-2つのネットワークがDVB / ATSCシステムのすべての部分を実装するというわけではない、例えば、サポート最小量、いいえかもしれない(Service情報(SI)テーブルの合図)。
Montpetit, et al. Informational [Page 3] RFC 4259 IP Transport over MPEG-2 Networks November 2005
Montpetit、他 情報[3ページ]のRFC4259IP輸送はMPEG-2の上で2005年11月をネットワークでつなぎます。
1.1. Salient Features of the Architecture
1.1. アーキテクチャに関する特徴
The architecture defined in this document describes a set of protocols that support transmission of IP packets over the MPEG-2 TS. Key characteristics of these networks are that they may provide link-level broadcast capability, and that many supported applications require access to a very large number of subnetwork nodes.
本書では定義されたアーキテクチャはMPEG-2TSの上でIPパケットのトランスミッションをサポートする1セットのプロトコルについて説明します。 これらのネットワークの主要な特性はリンク・レベル放送能力を提供するかもしれなくて、アプリケーションであるとサポートされた多くが非常に多くのサブネットワークノードへのアクセスを必要とするということです。
Some, or all, of these protocols may also be applicable to other subnetworks, e.g., other MPEG-2 transmission networks, regenerative satellite links [ETSI-BSM], and some types of broadcast wireless links. The key goals of the architecture are to reduce complexity when using the system, while improving performance, increasing flexibility for IP services, and providing opportunities for better integration with IP services.
また、これらのプロトコルのいくつか、またはすべても他のサブネットワークに適切であるかもしれない、例えば、他のMPEG-2つの送電網、再生式衛星中継[ETSI-BSM]、および何人かのタイプの放送ワイヤレスはリンクされます。 アーキテクチャの主要な目標はシステムを使用するとき、性能を向上させている間、複雑さを減少させることです、IPサービスのために柔軟性を増強して、より良い統合の機会にIPサービスを提供して。
Since a majority of MPEG-2 transmission networks are bandwidth- limited, encapsulation protocols must therefore add minimal overhead to ensure good link efficiency while providing adequate network services. They also need to be simple to minimize processing, robust to errors and security threats, and extensible to a wide range of services.
MPEG-2つの送電網の大部分が制限された帯域幅であるので、したがって、カプセル化プロトコルは適切なネットワーク・サービスを提供している間、良いリンク効率を確実にするために最小量のオーバーヘッドを加えなければなりません。 また、彼らは、処理を最小にする簡単で、誤りと軍事的脅威に強健で、さまざまなサービスに広げることができる必要があります。
In MPEG-2 systems, TS Logical Channels, are identified by their PID and provide multiplexing, addressing, and error reporting. The TS Logical Channel may also be used to provide Quality of Service (QoS). Mapping functions are required to relate TS Logical Channels to IP addresses, to map TS Logical Channels to IP-level QoS, and to associate IP flows with specific subnetwork capabilities. An important feature of the architecture is that these functions may be provided in a dynamic way, allowing transparent integration with other IP-layer protocols. Collectively, these will form an MPEG-2 TS Address Resolution (AR) protocol suite [IPDVB-AR].
MPEG-2台のシステム、TS Logical Channelsに、マルチプレクシング、アドレシング、および誤り報告は、彼らのPIDによって特定されて、供給されています。 また、TS Logical Channelは、Service(QoS)のQualityを提供するのに使用されるかもしれません。 マッピング機能が、IPアドレスにTS Logical Channelsに関連して、IP-レベルQoSにTS Logical Channelsを写像して、特定のサブネットワーク能力にIP流れを関連づけるのに必要です。 アーキテクチャの重要な特徴はダイナミックな方法でこれらの機能を提供するかもしれないということです、他のIP-層のプロトコルによるわかりやすい統合を許容して。 これらはMPEG-2TS Address Resolution(AR)プロトコル群[IPDVB-AR]をまとめて、形成するでしょう。
2. Conventions Used in This Document
2. 本書では使用されるコンベンション
Adaptation Field: An optional variable-length extension field of the fixed-length TS Packet header, intended to convey clock references and timing and synchronization information as well as stuffing over an MPEG-2 Multiplex [ISO-MPEG].
適合分野: 時計参照、タイミング、および同期情報を伝えることを意図して、MPEG-2Multiplexの上で[ISO-MPEG]を詰める固定長TS Packetヘッダーの任意の可変長の拡大分野。
ATSC: Advanced Television Systems Committee [ATSC]. A framework and a set of associated standards for the transmission of video, audio, and data using the ISO MPEG-2 standard [ISO-MPEG].
ATSC: 高品位テレビシステム委員会[ATSC]。 フレームワークとISO MPEG-2規格[ISO-MPEG]を使用するビデオ、オーディオ、およびデータの伝達のための1セットの関連規格。
DSM-CC: Digital Storage Media Command and Control [ISO-DSMCC]. A format for transmission of data and control information defined by the ISO MPEG-2 standard that is carried in an MPEG-2 Private Section.
DSM-CC: デジタル蓄積メディアは、[ISO-DSMCC]を命令して、制御します。 MPEG-2兵士のセクションで運ばれるISO MPEG-2規格によって定義されたデータと制御情報の伝達のための形式。
Montpetit, et al. Informational [Page 4] RFC 4259 IP Transport over MPEG-2 Networks November 2005
Montpetit、他 情報[4ページ]のRFC4259IP輸送はMPEG-2の上で2005年11月をネットワークでつなぎます。
DVB: Digital Video Broadcast [ETSI-DVBC, ETSI-DVBRCS, ETSI-DVBS]. A framework and set of associated standards published by the European Telecommunications Standards Institute (ETSI) for the transmission of video, audio, and data, using the ISO MPEG-2 Standard [ISO-MPEG].
DVB: デジタルビデオは[ETSI-DVBC、ETSI-DVBRCS、ETSI-DVBS]を放送しました。 ヨーロッパのTelecommunications Standards Institute(ETSI)によって関連規格のフレームワークとセットはビデオ、オーディオ、およびデータの伝達のために発行されました、ISO MPEG-2Standard[ISO-MPEG]を使用して。
Encapsulator: A network device that receives PDUs and formats these into Payload Units (known here as SNDUs) for output as a stream of TS Packets.
Encapsulator: 出力のためにTS Packetsの流れとして有効搭載量Units(ここで、SNDUsとして知られている)にPDUsを受けて、これらをフォーマットするネットワークデバイス。
Forward Direction: The dominant direction of data transfer over a network path. Data transfer in the forward direction is called "forward transfer". Packets travelling in the forward direction follow the forward path through the IP network.
順方向: ネットワーク経路の上のデータ転送の優位な方向。 順方向へのデータ転送は「前進の転送」と呼ばれます。 順方向に移動するパケットはIPネットワークを通してフォワードパスに続きます。
MAC: Medium Access and Control. The link layer header of the Ethernet IEEE 802 standard of protocols, consisting of a 6B destination address, 6B source address, and 2B type field (see also NPA).
Mac: 中型のアクセスとコントロール。 プロトコルのイーサネットIEEE802規格のリンクレイヤヘッダー、6B送付先アドレス、6Bソースアドレス、および2Bから成るのは分野をタイプします(また、NPAを見てください)。
MPE: Multiprotocol Encapsulation [ETSI-DAT, ATSC-DAT, ATSC-DATG]. A scheme that encapsulates PDUs, forming a DSM-CC Table Section. Each Section is sent in a series of TS Packets using a single TS Logical Channel.
MPE: Multiprotocolカプセル化[ETSI-DAT、ATSC-DAT、ATSC-DATG]。 DSM-CC Tableセクションを形成して、PDUsをカプセル化する体系。 一連のTS Packetsで独身のTS Logical Channelを使用することで各セクションを送ります。
MPEG-2: A set of standards specified by the Motion Picture Experts Group (MPEG), and standardized by the International Standards Organisation (ISO) [ISO-MPEG].
MPEG-2: エムペグ(MPEG)によって指定されて、国際Standards Organisation(ISO)[ISO-MPEG]によって標準化された1セットの規格。
NPA: Network Point of Attachment. Addresses primarily used for station (Receiver) identification within a local network (e.g., IEEE MAC address). An address may identify individual Receivers or groups of Receivers.
NPA: 接着点をネットワークでつないでください。 アドレスはステーション(受信機)に主として企業内情報通信網(例えば、IEEE MACアドレス)の中の識別を使用しました。 アドレスはReceiversの個々のReceiversかグループを特定するかもしれません。
PAT: Program Association Table [ISO-MPEG]. An MPEG-2 PSI control table that associates program numbers with the PID value used to send the corresponding PMT. The PAT is sent using the well-known PID value of zero.
パット: 協会テーブル[ISO-MPEG]をプログラムしてください。 PID値にプログラム番号を関連づけるMPEG-2PSI制御卓は以前はよく対応するPMTを送りました。PATにゼロのよく知られるPID値を使用させます。
PDU: Protocol Data Unit. Examples of a PDU include Ethernet frames, IPv4 or IPv6 datagrams, and other network packets.
PDU: データ単位について議定書の中で述べてください。 PDUに関する例はイーサネットフレームかIPv4かIPv6データグラムと、他のネットワークパケットを含んでいます。
PES: Packetized Elementary Stream [ISO-MPEG]. A format of MPEG-2 TS packet payload usually used for video or audio information.
PES: 基本のストリーム[ISO-MPEG]をPacketizedしました。 通常、ビデオに使用されるMPEG-2TSパケットペイロードかオーディオ情報の形式。
PID: Packet Identifier [ISO-MPEG]. A 13 bit field carried in the header of TS Packets. This is used to identify the TS Logical Channel to which a TS Packet belongs [ISO-MPEG]. The TS Packets forming the parts of a Table Section, PES, or other Payload Unit must
PID: パケット識別子[ISO-MPEG]。 13ビットの野原はTS Packetsのヘッダーで運ばれました。 これは、TS Packetが属するTS Logical Channel[ISO-MPEG]を特定するのに使用されます。 Tableセクションの部分を形成するTS Packets、PES、または他の有効搭載量Unitはそうしなければなりません。
Montpetit, et al. Informational [Page 5] RFC 4259 IP Transport over MPEG-2 Networks November 2005
Montpetit、他 情報[5ページ]のRFC4259IP輸送はMPEG-2の上で2005年11月をネットワークでつなぎます。
all carry the same PID value. The all 1s PID value indicates a Null TS Packet introduced to maintain a constant bit rate of a TS Multiplex. There is no required relationship between the PID values used for TS Logical Channels transmitted using different TS Multiplexes.
すべてが同じPID値を運びます。 1PIDの値はTS Multiplexの固定ビットレートを維持するために導入されたNull TS Packetを示します。 異なったTS Multiplexesを使用することで伝えられたTS Logical Channelsに使用されるPID値の間のどんな必要な関係もありません。
PMT: Program Map Table. An MPEG-2 PSI control table that associates the PID values used by the set of TS Logical Channels/Streams that comprise a program [ISO-MPEG]. The PID value which is used to send the PMT for a specific program is defined by an entry in the PAT.
PMT: 地図テーブルをプログラムしてください。 プログラム[ISO-MPEG]を包括するTS Logical Channels/ストリームのセットによって使用されたPID値を関連づけるMPEG-2PSI制御卓。 具体的計画のためにPMTを送るのに使用されるPID値はPATでエントリーで定義されます。
PP: Payload Pointer [ISO-MPEG]. An optional one byte pointer that directly follows the TS Packet header. It contains the number of bytes between the end of the TS Packet header and the start of a Payload Unit. The presence of the Payload Pointer is indicated by the value of the PUSI bit in the TS Packet header. The Payload Pointer is present in DSM-CC and Table Sections; it is not present in TS Logical Channels that use the PES-format.
pp: 有効搭載量指針[ISO-MPEG]。 直接TS Packetヘッダーに続く1バイトの任意の指針。 それはTS Packetヘッダーの端と有効搭載量Unitの始まりの間のバイト数を含んでいます。 有効搭載量Pointerの存在はTS PacketヘッダーのPUSIビットの価値によって示されます。 有効搭載量PointerはDSM-CCとTableセクションに存在しています。 それはPES-形式を使用するTS Logical Channelsに存在していません。
Private Section: A syntactic structure constructed in accordance with Table 2-30 of [ISO-MPEG]. The structure may be used to identify private information (i.e., not defined by [ISO-MPEG]) relating to one or more elementary streams, or a specific MPEG-2 program, or the entire TS. Other Standards bodies (e.g., ETSI, ATSC) have defined sets of table structures using the private_section structure. A Private Section is transmitted as a sequence of TS Packets using a TS Logical Channel. A TS Logical Channel may carry sections from more than one set of tables.
私設のセクション: [ISO-MPEG]のTable2-30によると、構成された統語構造。 構造は、1つ以上の基本のストリーム、特定のMPEG-2プログラム、または全体のTSに関連しながら個人情報(すなわち、[ISO-MPEG]が定義されない)を特定するのに使用されるかもしれません。 他のStandardsボディー(例えば、ETSI、ATSC)は、個人的な_セクション構造を使用することでテーブル構造のセットを定義しました。 兵士のセクションは、TS Packetsの系列としてTS Logical Channelを使用することで伝えられます。 TS Logical Channelは1セット以上のテーブルからセクションを運ぶかもしれません。
PSI: Program Specific Information [ISO-MPEG]. PSI is used to convey information about services carried in a TS Multiplex. It is carried in one of four specifically identified table section constructs [ISO-MPEG], see also SI Table.
psi: 特殊情報[ISO-MPEG]をプログラムしてください。 PSIは、TS Multiplexで提供されたサービスに関して情報を伝達するのに使用されます。 SI Tableも、それが4個の明確に特定されたテーブルセクション構造物[ISO-MPEG]の1つで運ばれるのを見ます。
PU: Payload Unit. A sequence of bytes sent using a TS. Examples of Payload Units include: an MPEG-2 Table Section or a ULE SNDU.
Pu: 有効搭載量単位。 バイトの系列は、TSを使用することで発信しました。 有効搭載量Unitsに関する例は: MPEG-2はセクションかウレSNDUをテーブルの上に置きます。
PUSI: Payload_Unit_Start_Indicator [ISO-MPEG]. A single bit flag carried in the TS Packet header. A PUSI value of zero indicates that the TS Packet does not carry the start of a new Payload Unit. A PUSI value of one indicates that the TS Packet does carry the start of a new Payload Unit. In ULE, a PUSI bit set to 1 also indicates the presence of a one byte Payload Pointer (PP).
PUSI: 有効搭載量_ユニット_は_インディケータ[ISO-MPEG]を始めます。 ただ一つの噛み付いている旗はTS Packetヘッダーで運ばれました。 ゼロのPUSI値は、TS Packetが新しい有効搭載量Unitの始まりを運ばないのを示します。 1のPUSI値は、TS Packetが新しい有効搭載量Unitの始まりを運ぶのを示します。 また、ULEでは、1に設定されたPUSIビットは1バイトの有効搭載量Pointer(PP)の存在を示します。
Receiver: A piece of equipment that processes the signal from a TS Multiplex and performs filtering and forwarding of encapsulated PDUs to the network-layer service (or bridging module when operating at the link layer).
受信機: それがTS Multiplexから信号を処理して、フィルタリングと推進を実行する1つの設備がネットワーク層サービスにPDUsをカプセル化しました(リンクレイヤで作動するとき、モジュールをブリッジして)。
Montpetit, et al. Informational [Page 6] RFC 4259 IP Transport over MPEG-2 Networks November 2005
Montpetit、他 情報[6ページ]のRFC4259IP輸送はMPEG-2の上で2005年11月をネットワークでつなぎます。
SI Table: Service Information Table [ISO-MPEG]. In this document, this term describes a table that is used to convey information about the services carried in a TS Multiplex, that has been defined by another standards body. A Table may consist of one or more Table Sections, however all sections of a particular SI Table must be carried over a single TS Logical Channel [ISO-MPEG].
SIテーブル: 情報テーブル[ISO-MPEG]を調整してください。 本書では、今期はTS Multiplexで提供されたサービスに関して情報を伝達するのに使用されて、別の標準化団体によって定義されたテーブルについて説明します。 Tableは1つ以上のTableセクションから成るかもしれなくて、しかしながら、独身のTS Logical Channel[ISO-MPEG]の上まで特定のSI Tableのすべてのセクションを運ばなければなりません。
SNDU: Sub-Network Data Unit. An encapsulated PDU sent as an MPEG-2 Payload Unit.
SNDU: サブネットワークデータ単位。 カプセル化されたPDUはMPEG-2有効搭載量Unitとして発信しました。
STB: Set-Top Box. A consumer equipment (Receiver) for reception of digital TV services.
STB: セットトップボックス。 デジタルテレビサービスのレセプションのための消費者設備(受信機)。
Table Section: A Payload Unit carrying all or a part of an SI or PSI Table [ISO-MPEG].
セクションをテーブルの上に置いてください: SIのすべてか一部を運ぶ有効搭載量UnitかPSI Table[ISO-MPEG]。
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 reference model. See also TS Logical Channel and TS Multiplex.
t: MPEG-2レベルにおけるトランスミッションのメソッドがTS Packetsを使用して、Stream[ISO-MPEG]を輸送してください。 それはISO/OSI参照モデルのレベル2を表します。 また、TS Logical ChannelとTS Multiplexを見てください。
TS Header: The 4-byte header of a TS Packet [ISO-MPEG].
tヘッダー: TS Packet[ISO-MPEG]の4バイトのヘッダー。
TS Logical Channel: Transport Stream Logical Channel. In this document, this term identifies a channel at the MPEG-2 level [ISO-MPEG]. It exists at level 2 of the ISO/OSI reference model. All packets sent over a TS Logical Channel carry the same PID value (this value is unique within a specific TS Multiplex). According to MPEG-2, some TS Logical Channels are reserved for specific signalling. Other standards (e.g., ATSC, DVB) also reserve specific TS Logical Channels.
t論理チャネル: ストリーム論理チャネルを輸送してください。 本書では、今期はMPEG-2レベル[ISO-MPEG]でチャンネルを特定します。 それはISO/OSI参照モデルのレベル2で存在しています。 TS Logical Channelの上に送られたすべてのパケットが同じPID値を運びます(この値は特定のTS Multiplexの中でユニークです)。 MPEG-2に従って、いくつかのTS Logical Channelsが特定の合図のために予約されます。 また、他の規格(例えば、ATSC、DVB)は特定のTS Logical Channelsを予約します。
TS Multiplex: In this document, this term defines a set of MPEG-2 TS Logical Channels sent over a single lower layer connection. This may be a common physical link (i.e., a transmission at a specified symbol rate, FEC setting, and transmission frequency) or an encapsulation provided by another protocol layer (e.g., Ethernet, or RTP over IP). The same TS Logical Channel may be repeated over more than one TS Multiplex (possibly associated with a different PID value), for example to redistribute the same multicast content to two terrestrial TV transmission cells.
tは多重送信されます: 本書では、今期は単独の下層接続の上に送られたMPEG-2TS Logical Channelsの1セットを定義します。 これは、一般的な物理的なリンク(すなわち、指定されたシンボルレート、FEC設定、および伝染率でのトランスミッション)か別のプロトコル層で提供されたカプセル化であるかもしれません(例えば、イーサネット、またはIPの上のRTP)。 同じTS Logical Channelは、例えば2つの地球のテレビのトランスミッションセルに同じマルチキャスト内容を再配付するために1TS Multiplex(ことによると異なったPID値に関連している)の上で繰り返されるかもしれません。
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 overhead including an Adaptation Field, encryption details and time stamp information to synchronize a set of related TS Logical Channels. 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.
tパケット: データの固定長188B単位はTS Multiplex[ISO-MPEG]を移動しました。 各TS Packetは4Bヘッダー、および関連するTS Logical Channelsの1セットを同期させるようにAdaptation Field、暗号化の詳細、およびタイムスタンプ情報を含む任意のオーバーヘッドを運びます。 また、それはTS_セルと呼ばれます。 各TS Packetは、独身のTS Logical Channelにそれを関連づけるためにPID値を運びます。
Montpetit, et al. Informational [Page 7] RFC 4259 IP Transport over MPEG-2 Networks November 2005
Montpetit、他 情報[7ページ]のRFC4259IP輸送はMPEG-2の上で2005年11月をネットワークでつなぎます。
ULE: Unidirectional Lightweight Encapsulation (ULE) [IPDVB-ULE]. A scheme that encapsulates PDUs, into SNDUs that are sent in a series of TS Packets using a single TS Logical Channel.
ウレ: 単方向のライト級カプセル化(ウレ)[IPDVB-ULE。] 一連のTS Packetsで独身のTS Logical Channelを使用することで送られるSNDUsにPDUsをカプセル化する体系。
3. Architecture
3. アーキテクチャ
The following sections introduce the components of the MPEG-2 Transmission Network and relate these to a networking framework.
以下のセクションは、MPEG-2Transmission Networkの部品を導入して、ネットワークフレームワークにこれらに関連します。
3.1. MPEG-2 Transmission Networks
3.1. MPEG-2つの送電網
There are many possible topologies for MPEG-2 Transmission Networks. A number of example scenarios are briefly described below, and the following text relates specific functions to this set of scenarios.
MPEG-2Transmission Networksのための多くの可能なtopologiesがあります。 多くの例のシナリオが以下で簡潔に説明されます、そして、以下のテキストはこのセットのシナリオに具体的な機能に関連します。
A) 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 [MMUSIC-IMG, ETSI-IPDC]. Such networks typically contain two components: the contribution feed and the broadcast part. Contribution feeds provide communication from a typically small number of individual sites (usually at high quality) to the Hub of a broadcast network. The traffic carried on contribution feeds is typically encrypted, and is usually processed prior to being resent on the Broadcast part of the network. The Broadcast part uses a star topology centered on the Hub to reach a typically large number of down-stream Receivers. Although such networks may provide IP transmission, they do not necessarily provide access to the public Internet.
a) テレビとRadio Deliveryを放送してください。BroadcastテレビとRadio Deliveryシナリオにおける主体サービスは、Digitalテレビ、そして/または、Radioとそれらの関連データ[MMUSIC-IMG、ETSI-IPDC]です。 そのようなネットワークは2つのコンポーネントを通常含んでいます: 貢献給送と放送は離れています。 貢献給送は通常少ない数の個々のサイト(通常高い品質における)から放送網のHubまでコミュニケーションを提供します。 貢献給送で運ばれたトラフィックは、通常暗号化されて、通常、ネットワークのBroadcast部分で再送する前に、処理されます。 Broadcast部分は多くの川下のReceiversに達するようにHubの中心に置かれたスタートポロジーを使用します。 そのようなネットワークはIPトランスミッションを提供するかもしれませんが、それらは必ず公共のインターネットへのアクセスを提供するというわけではありません。
B) Broadcast Networks used as an ISP Another scenario resembles that above, but includes the provision of IP services providing access to the public Internet. The IP traffic in this scenario is typically not related to the digital TV/Radio content, and the service may be operated by an independent operator such as unidirectional file delivery or bidirectional ISP access. The IP service must adhere to the full system specification used for the broadcast transmission, including allocation of PIDs and generation of appropriate MPEG-2 control information (e.g., DVB and ATSC SI tables).
B) 上でそれに類似していますが、ISP Anotherシナリオが公共のインターネットへのアクセスを提供するIPサービスについて支給を含んでいて使用されるNetworksを放送してください。 このシナリオのIPトラフィックはデジタルテレビ/ラジオ内容に通常関連しません、そして、サービスは単方向のファイル配送か双方向のISPアクセサリーなどの独立しているオペレータによって操作されるかもしれません。 IPサービスは放送送信に使用される完全なシステム仕様を固く守らなければなりません、PIDsと世代の適切なMPEG-2制御情報(例えば、DVBとATSC SIテーブル)の配分を含んでいて。
C) Unidirectional Star IP Scenario The Unidirectional Star IP Scenario utilizes a Hub station to provide a data network delivering a common bit stream to typically medium- sized groups of Receivers. MPEG-2 transmission technology provides the forward direction physical and link layers for this transmission; the return link (if required) is provided by other means. IP
C) 単方向Star IP Scenario Unidirectional Star IP Scenarioは、通常Receiversの媒体の大きさで分けられたグループに一般的なビットストリームを提供しながらデータ網を提供するのにHubステーションを利用します。 MPEG-2トランスミッション技術はこのトランスミッションのために物理的、そして、リンク層を順方向に提供します。 (必要なら、)他の手段でリターンリンクを提供します。 IP
Montpetit, et al. Informational [Page 8] RFC 4259 IP Transport over MPEG-2 Networks November 2005
Montpetit、他 情報[8ページ]のRFC4259IP輸送はMPEG-2の上で2005年11月をネットワークでつなぎます。
services typically form the main proportion of the transmission traffic. Such networks do not necessarily implement the MPEG-2 control plane, i.e., PSI/SI tables.
サービスはトランスミッショントラフィックの主な割合を通常形成します。 そのようなネットワークは必ずすなわち、MPEG-2制御飛行機、PSI/SIにテーブルを実装するというわけではありません。
D) Datacast Overlay The Datacast Overlay scenario employs MPEG-2 physical and link layers to provide additional connectivity such as unidirectional multicast to supplement an existing IP-based Internet service. Examples of such a network includes IP Datacast to mobile wireless receivers [MMUSIC-IMG].
D) シナリオが既存のIPベースのインターネットのサービスを補うために単方向のマルチキャストなどの追加接続性を提供するのに物理的、そして、リンクMPEG-2つの層を使うDatacast Overlay Datacast Overlay。 そのようなネットワークに関する例はモバイルワイヤレスの受信機[MMUSIC-IMG]にIP Datacastを含んでいます。
E) Point-to-Point Links Point-to-Point connectivity may be provided using a pair of transmit and receive interfaces supporting the MPEG-2 physical and link layers. Typically, the transmission from a sender is received by only one or a small number of Receivers. Examples include the use of transmit/receive DVB-S terminals to provide satellite links between ISPs utilising BGP routing.
E) 1組を使用するのが接続性に提供されるかもしれない指すポイントのリンクスのPointからポイントはMPEG-2が物理的、そして、リンク層であるとサポートするインタフェースを送受信します。 通常、1かReceiversの少ない数だけで送付者からのトランスミッションを受けます。 例が使用を含んでいる、DVB-S端末を伝えるか、または受けて、BGPルーティングを利用するISPの間の衛星中継を提供してください。
F) Two-Way IP Networks Two-Way IP networks are typically satellite-based and star-based utilising a Hub station to deliver a common bit stream to medium- sized groups of receivers. A bidirectional service is provided over a common air-interface. The transmission technology in the forward direction at the physical and link layers is MPEG-2, which may also be used in the return direction. Such systems also usually include a control plane element to manage the (shared) return link capacity. A concrete example is the DVB-RCS system [ETSI-DVBRCS]. IP services typically form the main proportion of the transmission traffic.
F) 2方法のIP Networks Two-道のIPネットワークは、受信機の媒体の大きさで分けられたグループに一般的なビットストリームを提供するのにHubステーションを利用することで衛星通常を拠点としていて星のを拠点としています。 一般的な空気インタフェースの上に双方向のサービスを提供します。 物理的、そして、リンク層の順方向へのトランスミッション技術はMPEG-2です。(また、その2はリターン方向に使用されるかもしれません)。 また、通常、そのようなシステムは、(共有される)のリターンリンク容量を管理するためにコントロール飛行機要素を含んでいます。 具体的な実例はDVB-RCSシステム[ETSI-DVBRCS]です。 IPサービスはトランスミッショントラフィックの主な割合を通常形成します。
Scenarios A-D employ unidirectional MPEG-2 Transmission Networks. For satellite-based networks, these typically have a star topology, with a central Hub providing service to large numbers of down-stream Receivers. Terrestrial networks may employ several transmission Hubs, each serving a particular coverage cell with a community of Receivers.
シナリオA-Dは単方向MPEG-2Transmission Networksを使います。 これらには、衛星を拠点とするネットワークのために、スタートポロジーが通常あります、中央のHubが多くの川下のReceiversに対するサービスを提供していて。 それぞれ特定の適用範囲セルにReceiversの共同体を供給して、地球のネットワークは数個トランスミッションHubsを使うかもしれません。
From an IP viewpoint, the service is typically either unidirectional multicast, or a bidirectional service in which some complementary link technology (e.g., modem, Local Multipoint Distribution Service (LMDS), General Packet Radio Service (GPRS)) is used to provide the return path from Receivers to the Internet. In this case, routing could be provided using UniDirectional Link Routing (UDLR) [RFC3077].
IP観点から、通常、サービスは、何らかの補足的なリンク技術(例えば、モデム、Local Multipoint Distribution Service(LMDS)、汎用パケット無線システム(GPRS))がReceiversからインターネットまでリターンパスを提供するのに使用される単方向のマルチキャストか双方向のサービスのどちらかです。 この場合、UniDirectional Linkルート設定(UDLR)[RFC3077]を使用することでルーティングを提供できるでしょう。
Note that only Scenarios A-B actually carry MPEG-2 video and audio (intended for reception by digital Set Top Boxes (STBs)) as the primary traffic. The other scenarios are IP-based data networks and need not necessarily implement the MPEG-2 control plane.
Scenarios A-Bだけが実際に、プライマリトラフィックとしてMPEG-2のビデオとオーディオ(レセプションのために、デジタルSet Top Boxes(STBs)によって意図される)を運ぶことに注意してください。 他のシナリオは、IPベースのデータ網であり、必ずMPEG-2制御飛行機を実装しなければならないというわけではありません。
Montpetit, et al. Informational [Page 9] RFC 4259 IP Transport over MPEG-2 Networks November 2005
Montpetit、他 情報[9ページ]のRFC4259IP輸送はMPEG-2の上で2005年11月をネットワークでつなぎます。
Scenarios E-F provide two-way connectivity using the MPEG-2 Transmission Network. Such networks provide direct support for bidirectional protocols above and below the IP layer.
シナリオE-Fは、MPEG-2Transmission Networkを使用することで両用接続性を提供します。 そのようなネットワークは層とIP層の下における双方向のプロトコルのダイレクトサポートを提供します。
The complete MPEG-2 transmission network may be managed by a transmission service operator. In such cases, the assignment of addresses and TS Logical Channels at Receivers are usually under the control of the service operator. Examples include a TV operator (Scenario A), or an ISP (Scenarios B-F). MPEG-2 transmission networks are also used for private networks. These typically involve a smaller number of Receivers and do not require the same level of centralized control. Examples include companies wishing to connect DVB-capable routers to form links within the Internet (Scenario B).
完全なMPEG-2送電網はトランスミッションサービスオペレータによって経営されるかもしれません。 そのような場合、ReceiversのアドレスとTS Logical Channelsの課題が通常サービスオペレータのコントロールの下にあります。 例はテレビのオペレータ(シナリオA)、またはISP(シナリオB-F)を含んでいます。 また、MPEG-2つの送電網が私設のネットワークに使用されます。 これらは、Receiversの、より少ない数に通常かかわって、同じレベルの集中制御を必要としません。 例はインターネット(シナリオB)の中でリンクを形成するためにDVBできるルータを接続したがっている会社を含んでいます。
3.2. TS Logical Channels
3.2. t論理チャネル
An MPEG-2 Transport Multiplex offers a number of parallel channels, which are known here as TS Logical Channels. Each TS Logical 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 13 bit field; thus, the number of available channels ranges from 0 to 8191 decimal or 0x1FFF in hexadecimal, some of which are reserved for transmission of SI tables. Non-reserved TS Logical 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, ETSI-DAT, ATSC-DAT]. The value 8191 decimal (0x1FFF) indicates a null packet that is used to maintain the physical bearer bit rate when there are no other MPEG-2 TS packets to be sent.
MPEG-2Transport Multiplexは多くの平行なチャンネルを提供します。(チャンネルはTS Logical Channelsとしてここで知られています)。 各TS Logical ChannelはそれぞれのMPEG-2TS Packetのヘッダーで運ばれるPacket ID(PID)値によって唯一特定されます。 PID値は13ビットの分野です。 したがって、利用可能なチャンネルの数は0〜8191の小数か0x1FFFから16進で変化します。その或るものはSIテーブルのトランスミッションのために予約されます。 非予約されたTS Logical Channelsは、オーディオ[ISO-AUD]、ビデオ[ISO-VID]、IPパケット[ISO-DSMCC、ETSI-DAT、ATSC-DAT]、または他のデータ[ISO-DSMCC、ETSI-DAT、ATSC-DAT]を運ぶのに使用されるかもしれません。 値8191の小数(0x1FFF)は送られる他のMPEG-2つのTSパケットが全くないとき、物理的な運搬人ビット伝送速度を維持するのに使用されるヌルパケットを示します。
Montpetit, et al. Informational [Page 10] RFC 4259 IP Transport over MPEG-2 Networks November 2005
Montpetit、他 情報[10ページ]のRFC4259IP輸送はMPEG-2の上で2005年11月をネットワークでつなぎます。
TS-LC-A-1 /---\--------------------/---\
\ / \ / \
\ | | | |
TS-LC-A-2 ----------- | | -------------
-------------------- | | -------------
| | | |
/-------- / | -------------
/ \----/-------------------\----/
TS-LC-A-3/ MPEG-2 TS MUX A
/
TS-LC /
------------X
\ TS-LC-B-3 /---\------------------------/---\
\ / \ / \
\ | | | |
TS-LC-B-2 \----------- | | ---------
-------------------- | | ---------
| | | |
/-------- / | ---------
/ \----/-----------------------\----/
/ MPEG-2 TS MUX B
TS-LC-B-1
t-LC-A-1/---\--------------------/---\ \ / \ / \ \ | | | | t-LC-A-2----------- | | ------------- -------------------- | | ------------- | | | | /-------- / | ------------- / \----/-------------------\----/のt-LC-A-3の/のMPEG-2tの多重化装置は/t-LC/です。------------X\t-LC-B-3/---\------------------------/---\ \ / \ / \ \ | | | | t-LC-B-2\----------- | | --------- -------------------- | | --------- | | | | /-------- / | --------- / \----/-----------------------\----//MPEG-2t多重化装置B t-LC-B-1
Figure 2: Example showing MPEG-2 TS Logical Channels carried
Over 2 MPEG-2 TS Multiplexes.
図2: MPEG-2TS Logical Channelsを示している例がOver2MPEG-2TS Multiplexesを運びました。
TS Logical Channels are independently numbered on each MPEG-2 TS Multiplex (MUX). In most cases, the data sent over the TS Logical Channels will differ for different multiplexes. Figure 2 shows a set of TS Logical Channels sent using two MPEG-2 TS Multiplexes (A and B).
TS Logical ChannelsはそれぞれのMPEG-2TS Multiplex(多重化装置)で独自に付番されます。 多くの場合、TS Logical Channelsの上に送られたデータは異なったマルチプレックスのために異なるでしょう。 図2は、TS Logical Channelsの1セットが2MPEG-2TS Multiplexes(AとB)を使用することで発信したのを示します。
There are cases where the same data may be distributed over two or more multiplexes (e.g., some SI tables; multicast content that needs to be received by Receivers tuned to either MPEG-2 TS; unicast data where the Receiver may be in either/both of two potentially overlapping MPEG-2 transmission cells). In figure 2, each multiplex 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 common to both MPEG-2 TS Multiplexes (i.e., TS-LC-A-3 and TS-LC-B-3 carry identical content).
ケースが同じデータが2個以上のマルチプレックス(例えばいくつかのSIテーブル; MPEG-2TSに波長を合わせたReceiversによって受け取られる必要があるマルチキャスト内容; Receiverが潜在的にMPEG-2つのトランスミッションセルを重ね合わせる/の2の両方にあるかもしれないユニキャストデータ)の上に分配されるかもしれないところにあります。 図では、2、各マルチプレックスは3MPEG-2TS Logical Channelsを運びます。 これらのTS Logical Channelsは異なるかもしれないか(TS-LC-A-1、TS-LC-A-2、TS-LC-B-2、TS-LC-B-1)、または両方のMPEG-2TS Multiplexesに共通であるかもしれません(すなわち、TS-LC-A-3とTS-LC-B-3は同じ内容を運びます)。
As can been seen, there are similarities between the way PIDs are used and the operation of virtual channels in ATM. However, unlike ATM, a PID defines a unidirectional broadcast channel and not a point-to-point link. Contrary to ATM, there is, as yet, no specified
見られた缶として、PIDsが使用されている方法とATMでの事実上のチャンネルの操作の間には、類似性があります。 しかしながら、ATMと異なって、PIDはポイントツーポイント接続ではなく、単方向の放送チャンネルを定義します。 ATMとは逆に、ありました、まだ、いいえは指定していました。
Montpetit, et al. Informational [Page 11] RFC 4259 IP Transport over MPEG-2 Networks November 2005
Montpetit、他 情報[11ページ]のRFC4259IP輸送はMPEG-2の上で2005年11月をネットワークでつなぎます。
standard interface for MPEG-2 connection setup, or for signaling mappings of IP flows to PIDs, or to set the Quality of Service, QoS, assigned to a TS Logical Channel.
MPEG-2接続設定か、PIDsへのIP流れに関するシグナリングマッピングかService、TS Logical Channelに割り当てられたQoSのQualityを設定する標準インターフェース。
3.3. Multiplexing and Re-Multiplexing
3.3. 多重送信して、再多重送信します。
In a simple example, one or more TS Logical Channels are processed by an MPEG-2 multiplexor, resulting in a TS Multiplex. The TS Multiplex is forwarded over a physical bearer towards one or more Receivers (Figure 3).
簡単な例では、1TS Logical ChannelsがMPEG-2マルチプレクサーによって処理されます、TS Multiplexをもたらして。 1Receivers(図3)に向かった物理的な運搬人の上にTS Multiplexを送ります。
In a more complex example, the same TS may be fed to multiple MPEG-2 multiplexors and these may, in turn, feed other MPEG-2 multiplexors (remultiplexing). Remultiplexing may occur in several places (and is common in Scenarios A and B of Section 3.1). One example is a satellite that provides on-board processing of the TS packets, multiplexing the TS Logical Channels received from one or more uplink physical bearers (TS Multiplex) to one (or more in the case of broadcast/multicast) down-link physical bearer (TS Multiplex). As part of the remultiplexing process, a remultiplexor may renumber the PID values associated with one or more TS Logical Channels to prevent clashes between input TS Logical Channels with the same PID carried on different input multiplexes. It may also modify and/or insert new SI data into the control plane.
より複雑な例では、複数のMPEG-2個のマルチプレクサーへ同じTSを供給するかもしれません、そして、これらは順番に、他のMPEG-2個のマルチプレクサー(再多重送信)を供給するかもしれません。 Remultiplexingは方々に(そして、セクション3.1のScenarios AとBでは、一般的である)起こるかもしれません。 1つの例がTSパケットの車載処理を提供する衛星です、1人以上のアップリンクの物理的な運搬人(TS Multiplex)から物理的な1人(またはさらに放送/マルチキャストの場合で)のダウンリンク運搬人(TS Multiplex)まで受け取られたTS Logical Channelsを多重送信して。 再多重送信プロセスの一部として、「再-マルチプレクサー」は、同じPIDが異なった入力マルチプレックスの上で運ばれている状態で入力TS Logical Channelsでの衝突を防ぐために1TS Logical Channelsに関連しているPID値に番号を付け替えさせるかもしれません。 また、それは、新しいSIデータを制御飛行機に変更する、そして/または、挿入するかもしれません。
In all cases, the final result is a "TS Multiplex" that is transmitted over the physical bearer towards the Receiver.
すべての場合では、最終的な結果はReceiverに向かった物理的な運搬人の上に伝えられる「tマルチプレックス」です。
Montpetit, et al. Informational [Page 12] RFC 4259 IP Transport over MPEG-2 Networks November 2005
Montpetit、他 情報[12ページ]のRFC4259IP輸送はMPEG-2の上で2005年11月をネットワークでつなぎます。
+------------+ +------------+
| IP | | IP |
| End Host | | End Host |
+-----+------+ +------------+
| ^
+------------>+---------------+ |
+ IP | |
+-------------+ Encapsulator | |
SI-Data | +------+--------+ |
+-------+-------+ |MPEG-2 TS Logical Channel |
| MPEG-2 | | |
| SI Tables | | |
+-------+-------+ ->+------+--------+ |
| -->| MPEG-2 | . . .
+------------>+ Multiplexor | |
MPEG-2 TS +------+--------+ |
Logical Channel |MPEG-2 TS Mux |
| |
Other ->+------+--------+ |
MPEG-2 -->+ MPEG-2 | |
TS --->+ Multiplexor | |
---->+------+--------+ |
|MPEG-2 TS Mux |
| |
+------+--------+ +------+-----+
|Physical Layer | | MPEG-2 |
|Modulator +---------->+ Receiver |
+---------------+ MPEG-2 +------------+
TS Mux
+------------+ +------------+ | IP| | IP| | 終わりのホスト| | 終わりのホスト| +-----+------+ +------------+ | ^ +------------>+---------------+ | + IP| | +-------------+ Encapsulator| | SIデータ| +------+--------+ | +-------+-------+ |MPEG-2tの論理チャネル| | MPEG-2| | | | SIテーブル| | | +-------+-------+>+------+--------+ | | -->| MPEG-2| . . . +------------>+マルチプレクサー| | MPEG-2t+------+--------+ | 論理チャネル|MPEG-2tのMux| | | 他の>+------+--------+ | MPEG-2-->+MPEG-2| | t--->+マルチプレクサー| | ---->+------+--------+ | |MPEG-2tのMux| | | +------+--------+ +------+-----+ |物理的な層| | MPEG-2| |変調器+---------->+受信機| +---------------+ MPEG-2+------------+ t Mux
Figure 3: An example configuration for a unidirectional
Service for IP transport over MPEG-2
図3: IPのためのServiceがMPEG-2以上を輸送する単方向の間の例の構成
3.4. IP Datagram Transmission
3.4. IPデータグラム送信
Packet data for transmission over an MPEG-2 Transport Multiplex is passed to an Encapsulator, sometimes known as a Gateway. This receives Protocol Data Units, PDUs, such as Ethernet frames or IP packets, and formats each into a Sub-Network Data Unit, SNDU, by adding an encapsulation header and trailer (see Section 4). The SNDUs are subsequently fragmented into a series of TS Packets.
MPEG-2Transport Multiplexの上のトランスミッションのためのパケットデータはゲートウェイとして時々知られているEncapsulatorに通過されます。 これはプロトコルData Unitsを受けます、PDUs、イーサネットフレームやIPパケットや、それぞれSub-ネットワークData Unitへの形式などのように、SNDU、カプセル化ヘッダーとトレーラを加えることによって(セクション4を見てください)。 SNDUsは次に、一連のTS Packetsに断片化されます。
To receive IP packets over an MPEG-2 TS Multiplex, a Receiver needs to identify the specific TS Multiplex (physical link) and also 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; therefore, a Receiver must filter (accept) IP packets sent with a number of PID values, and must independently reassemble each SNDU.
MPEG-2TS Multiplexの上にIPパケットを受けるために、Receiverは、特定のTS Multiplex(物理的なリンク)とTS Logical Channel(論理的なリンクのPID値)も特定する必要があります。 多くのMPEG-2TS Logical ChannelsがSNDUsを運ぶのは、一般的です。 したがって、Receiverは多くのPID値と共に送られたIPパケットをフィルターにかけなければならなくて(受け入れます)、独自に各SNDUを組み立て直さなければなりません。
Montpetit, et al. Informational [Page 13] RFC 4259 IP Transport over MPEG-2 Networks November 2005
Montpetit、他 情報[13ページ]のRFC4259IP輸送はMPEG-2の上で2005年11月をネットワークでつなぎます。
A Receiver that simultaneously receives from several TS Logical Channels must filter other unwanted TS Logical Channels by employing, for example, specific hardware support. Packets for one IP flow (i.e., a specific combination of IP source and destination 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 modem implementations, and multiple PIDs must be allowed in the architecture. Many current hardware filters limit the maximum number of active PIDs (e.g., 32), although if needed, future systems may reasonably be expected to support more.
同時に数個のTS Logical Channelsから受信するReceiverは、例えば、特定のハードウェアサポートを使うことによって、他の求められていないTS Logical Channelsをフィルターにかけなければなりません。 1つのIP流動(すなわち、IPソースと送付先アドレスの特定の組み合わせ)のためのパケットに同じPIDを使用させなければなりません。 いくつかのケーブルモデム実装のようにすべてのIPパケットが独身のPIDで運ばれると思うべきでなくて、アーキテクチャで複数のPIDsを許容しなければなりません。 多くの現在のハードウェアフィルタがアクティブなPIDs(例えば、32)の最大数を制限します、必要であるなら、将来のシステムが以上をサポートすると合理的に予想されるかもしれませんが。
In some cases, Receivers may need to select TS Logical Channels from a number of simultaneously active TS Multiplexes. To do this, they need multiple physical receive interfaces (e.g., radio frequency (RF) front-ends and demodulators). Some applications also envisage the concurrent reception of IP Packets over other media that may not necessarily use MPEG-2 transmission.
いくつかの場合、Receiversは、多くの同時にアクティブなTS MultiplexesからTS Logical Channelsを選択する必要があるかもしれません。 これをするために、彼らは物理的に倍数を必要とします。インタフェース(例えば、無線周波数(RF)フロントエンドと復調)を受けてください。 また、いくつかのアプリケーションが必ずMPEG-2送信を使用するかもしれないというわけではない他のメディアの上でIP Packetsの同時発生のレセプションを考えます。
Bidirectional (duplex) transmission can be provided using an MPEG-2 Transmission Network by using one of a number of alternate return channel schemes [ETSI-RC]. Duplex IP paths may also be supported using non-MPEG-2 return links (e.g., in Scenarios B-D of section 3.1). One example of such an application is that of UniDirectional Link Routing, UDLR [RFC3077].
多くの代替の帰路チャンネル体系[ETSI-RC]の1つを使用することによってMPEG-2Transmission Networkを使用することで双方向(重複の)のトランスミッションを提供できます。 また、重複のIP経路は、非MPEGの2リターンリンク(例えば、セクション3.1のScenarios B-Dの)を使用することでサポートされるかもしれません。 そのようなアプリケーションに関する1つの例がUniDirectional Linkルート設定、UDLR[RFC3077]のものです。
3.5. Motivation
3.5. 動機
The network layer protocols to be supported by this architecture include:
このアーキテクチャによってサポートされるネットワーク層プロトコルは:
(i) IPv4 Unicast packets, destined for a single end host
(i) シングルエンドのホストのために運命づけられたIPv4 Unicastパケット
(ii) IPv4 Broadcast packets, sent to all end systems in an IP
network
IPネットワークにおけるすべてのエンドシステムに送られた(ii)IPv4 Broadcastパケット
(iii) IPv4 Multicast packets
(iii)IPv4 Multicastパケット
(iv) IPv6 Unicast packets, destined for a single end host
シングルエンドのホストのために運命づけられた(iv)IPv6 Unicastパケット
(v) IPv6 Multicast packets
(v) IPv6 Multicastパケット
(vi) Packets with compressed IPv4 / IPv6 packet headers (e.g.,
[RFC2507, RFC3095])
圧縮されたIPv4 / IPv6パケットのヘッダーがいる(vi)パケット(例えば[RFC2507、RFC3095])
(vii) Bridged Ethernet frames
イーサネットフレームであるとブリッジされた(vii)
(viii) Other network protocol packets (MPLS, potential new protocols)
(viii) 他のネットワーク・プロトコルパケット(MPLS、潜在的新しいプロトコル)
Montpetit, et al. Informational [Page 14] RFC 4259 IP Transport over MPEG-2 Networks November 2005
Montpetit、他 情報[14ページ]のRFC4259IP輸送はMPEG-2の上で2005年11月をネットワークでつなぎます。
The architecture will provide:
アーキテクチャは提供されるでしょう:
(i) Guidance on which MPEG-2 features are pre-requisites for the
IP service, and identification of any optional fields that
impact performance/correct operation.
(i) MPEG-2つの特徴が性能/正しい操作に影響を与えるIPサービスのための前提条件と、どんな任意の分野の識別である指導。
(ii) Standards to provide an efficient and flexible encapsulation
scheme that may be easily implemented in an Encapsulator or
Receiver. The payload encapsulation requires a type field for
the SNDU to indicate the type of packet and a mechanism to
signal which encapsulation is used on a certain PID.
効率的でフレキシブルなカプセル化体系にそれを提供する(ii)規格はEncapsulatorかReceiverで容易に実装されるかもしれません。SNDUが、どのカプセル化に合図するかパケットとメカニズムのタイプが、あるPIDで使用されるのを示すように、ペイロードカプセル化はタイプ分野を必要とします。
(iii) Standards to associate a particular IP address with a Network
Point of Attachment (NPA) that could or may not be a MAC
Address. This process resembles the IPv4 Address Resolution
Protocol, ARP, or IPv6 Neighbor Discovery, ND, protocol
[IPDVB-AR]. In addition, the standard will be compatible with
IPv6 autoconfiguration.
特定のIPを関連づける(iii)規格はAttachmentのNetwork Pointと共にマックーアドレスであることができたか、マックーアドレスでないかもしれない(NPA)を扱います。 このプロセスはIPv4 Address Resolutionプロトコル、ARP、またはIPv6 Neighborディスカバリー、ノースダコタ、プロトコル[IPDVB-AR]に類似しています。 さらに、規格はIPv6自動構成と互換性があるでしょう。
(iv) Standards to associate an MPEG-2 TS interface with one or more
specific TS Logical Channels (PID, TS Multiplex). Bindings
are required for both unicast transmission, and multicast
reception. In the case of IPv4, this must also support
network broadcast. To make the schemes robust to loss and
state changes within the MPEG-2 transmission network, a soft-
state approach may prove desirable.
MPEG-2TSを関連づける(iv)規格は1特定のTS Logical Channels(PID、TS Multiplex)に連結します。 結合がユニキャスト送信とマルチキャストレセプションの両方に必要です。 また、IPv4の場合では、これはネットワーク放送をサポートしなければなりません。 MPEG-2送電網の中で損失に強健な体系と状態を変化にするように、柔らかい州のアプローチは望ましいと判明するかもしれません。
(v) Standards to associate the capabilities of an MPEG-2 TS
Logical Channel with IP flows. This includes mapping of QoS
functions, such as IP QoS/DSCP and RSVP, to underlying MPEG-2
TS QoS, multi-homing and mobility. This capability could be
associated by the AR standard proposed above.
(v) MPEG-2TS Logical Channelの能力をIP流れに関連づける規格。 これは基本的なMPEG-2TS QoSへのIP QoS/DSCPやRSVPなどのQoS機能に関するマッピング、マルチホーミング、および移動性を含んでいます。 上で提案されたAR規格でこの能力を関連づけることができました。
(vi) Guidance on Security for IP transmission over MPEG-2. The
framework must permit use of IPsec and clearly identify any
security issues concerning the specified protocols. The
security issues need to consider two cases: unidirectional
transfer (in which communication is only from the sending IP
end host to the receiving IP end host) and bidirectional
transfer. Consideration should also be given to security of
the TS Multiplex: the need for closed user groups and the use
of MPEG-2 TS encryption.
IPトランスミッションのためのSecurityにおける(vi)指導、MPEG-2の上で。 フレームワークは、IPsecの使用を可能にして、指定されたプロトコルに関して明確にどんな安全保障問題も特定しなければなりません。 安全保障問題は、2つのケースを考える必要があります: 単方向の転送(送付IP終わりのホストだけから受信IP終わりのホストまでコミュニケーションがそこにある)と双方向の転送。 また、TS Multiplexのセキュリティに対して考慮を払うべきです: クローズド・ユーザ・グループの必要性とMPEG-2TS暗号化の使用。
(vii) Management of the IP transmission, including standardized SNMP
MIBs and error reporting procedures. The need for and scope
of this is to be determined.
標準化されたSNMP MIBsと手順を報告する誤りを含む(vii)IP管理トランスミッション。 この必要性と範囲は断固とすることになっています。
Montpetit, et al. Informational [Page 15] RFC 4259 IP Transport over MPEG-2 Networks November 2005
Montpetit、他 情報[15ページ]のRFC4259IP輸送はMPEG-2の上で2005年11月をネットワークでつなぎます。
The specified architecture and techniques should be suited to a range of systems employing the MPEG-2 TS, and may also suit other (sub)networks offering similar transfer capabilities.
指定されたアーキテクチャとテクニックは、MPEG-2TSを使うさまざまなシステムに合うべきであり、また、同様の転送能力を提供する他の(潜水艦)ネットワークに合うかもしれません。
The following section, 4, describes encapsulation issues. Sections 5 and 6 describe address resolution issues for unicast and multicast, respectively.
以下のセクション(4)はカプセル化問題について説明します。 セクション5と6はユニキャストとマルチキャストのためにそれぞれアドレス解決問題について説明します。
4. Encapsulation Protocol Requirements
4. カプセル化プロトコル要件
This section identifies requirements and provides examples of mechanisms that may be used to perform the encapsulation of IPv4/v6 unicast and multicast packets over MPEG-2 Transmission Networks.
このセクションは、要件を特定して、MPEG-2Transmission Networksの上でIPv4/v6ユニキャストとマルチキャストパケットのカプセル化を実行するのに使用されるかもしれないメカニズムに関する例を提供します。
A network device, known as an Encapsulator receives PDUs (e.g., IP Packets or Ethernet frames) and formats these into Subnetwork Data Units, SNDUs. An encapsulation (or convergence) protocol transports each SNDU over the MPEG-2 TS service and provides the appropriate mechanisms to deliver the encapsulated PDU to the Receiver IP interface.
ネットワークデバイスEncapsulatorがPDUs(例えば、IP Packetsかイーサネットフレーム)を受けて、Subnetwork Data Units(SNDUs)にこれらをフォーマットするので知られていて、 カプセル化(または、集合)プロトコルは、MPEG-2TSサービスの上で各SNDUを輸送して、Receiver IPインタフェースにカプセル化されたPDUを提供するために適切な手段を提供します。
In forming an SNDU, the encapsulation protocol typically adds header fields that carry protocol control information, such as the length of SNDU, Receiver address, multiplexing information, payload type, sequence numbers, etc. The SNDU payload is typically followed by a trailer, which carries an Integrity Check (e.g., Cyclic Redundancy Check, CRC). Some protocols also add additional control information and/or padding to or after the trailer (figure 4).
SNDUを形成する際に、カプセル化プロトコルはプロトコル制御情報を運ぶヘッダーフィールドを通常加えます、SNDUの長さなどのように、Receiverアドレス、情報、ペイロードタイプ、一連番号などを多重送信して トレーラはSNDUペイロードを通常支えています。(それは、Integrity Check(例えば、Cyclic Redundancy Check、CRC)を乗せます)。 また、いくつかのプロトコルがトレーラかトレーラ(4について計算する)の後に追加制御情報、そして/または、詰め物を加えます。
+--------+-------------------------+-----------------+
| Header | PDU | Integrity Check |
+--------+-------------------------+-----------------+
<--------------------- SNDU ------------------------->
+--------+-------------------------+-----------------+ | ヘッダー| PDU| 保全チェック| +--------+-------------------------+-----------------+ <。--------------------- SNDU------------------------->。
Figure 4: Encapsulation of a subnetwork PDU (e.g., IPv4 or IPv6
packet) to form an MPEG-2 Payload Unit.
図4: MPEG-2有効搭載量Unitを形成するサブネットワークPDU(例えば、IPv4かIPv6パケット)のカプセル化。
Examples of existing encapsulation/convergence protocols include ATM AAL5 [ITU-AAL5] and MPEG-2 MPE [ETSI-DAT].
既存のカプセル化/集合プロトコルに関する例はATM AAL5[ITU-AAL5]とMPEG-2MPE[ETSI-DAT]を含んでいます。
When required, an SNDU may be fragmented across a number of TS Packets (figure 5).
必要であると、SNDUは多くのTS Packets(5について計算する)の向こう側に断片化されるかもしれません。
Montpetit, et al. Informational [Page 16] RFC 4259 IP Transport over MPEG-2 Networks November 2005
Montpetit、他 情報[16ページ]のRFC4259IP輸送はMPEG-2の上で2005年11月をネットワークでつなぎます。
+-----------------------------------------+
|Encap Header|SubNetwork Data Unit (SNDU) |
+-----------------------------------------+
/ / \ \
/ / \ \
/ / \ \
+------+----------+ +------+----------+ +------+----------+
|MPEG-2| MPEG-2 |..|MPEG-2| MPEG-2 |...|MPEG-2| MPEG-2 |
|Header| Payload | |Header| Payload | |Header| Payload |
+------+----------+ +------+----------+ +------+----------+
+-----------------------------------------+ |Encapヘッダー|サブネットワークデータ単位(SNDU)| +-----------------------------------------+ / / \ \ / / \ \ / / \ \ +------+----------+ +------+----------+ +------+----------+ |MPEG-2| MPEG-2|..|MPEG-2| MPEG-2|...|MPEG-2| MPEG-2| |ヘッダー| 有効搭載量| |ヘッダー| 有効搭載量| |ヘッダー| 有効搭載量| +------+----------+ +------+----------+ +------+----------+
Figure 5: Encapsulation of a PDU (e.g., IP packet) into a
Series of MPEG-2 TS Packets. Each TS Packet carries
a header with a common Packet ID (PID) value denoting
the MPEG-2 TS Logical Channel.
図5: MPEG-2TS PacketsのSeriesへのPDU(例えば、IPパケット)のカプセル化。 各TS Packetは一般的なPacket ID(PID)値がMPEG-2TS Logical Channelを指示しているヘッダーを運びます。
The DVB family of standards currently defines a mechanism for transporting an IP packet, or Ethernet frame using the Multi-Protocol Encapsulation (MPE) [ETSI-DAT]. An equivalent scheme is also supported in ATSC [ATSC-DAT, ATSC-DATG]. It allows transmission of IP packets or (by using LLC) Ethernet frames by encapsulation within a Table Section (with the format used by the control plane associated with the MPEG-2 transmission). The MPE specification includes a set of optional header components and requires decoding of the control headers. This processing is suboptimal for Internet traffic, since it incurs significant receiver processing overhead and some extra link overhead [CLC99].
規格のDVBファミリーは、現在、IPパケット、またはMulti-プロトコルEncapsulation(MPE)[ETSI-DAT]を使用するイーサネットフレームを輸送するためにメカニズムを定義します。 また、同等な体系はATSC[ATSC-DAT、ATSC-DATG]でサポートされます。 それはTableセクション(形式がMPEG-2送信に関連している制御飛行機によって使用されている)の中にカプセル化でIPパケットか(LLCを使用するのによる)イーサネットフレームのトランスミッションを許容します。 MPE仕様は、1セットの任意のヘッダーの部品を含んで、コントロールヘッダーに解読するのを必要とします。 重要な受信機処理オーバヘッドと何らかの付加的なリンクオーバーヘッド[CLC99]を被るので、インターネットトラフィックにおいて、この処理は準最適です。
The existing standards carry heritage from legacy implementations. These have reflected the limitations of technology at the time of their deployment (e.g., design decisions driven by audio/video considerations rather than IP networking requirements). IPv6, MPLS, and other network-layer protocols are not natively supported. Together, these justify the development of a new encapsulation that will be truly IP-centric. Carrying IP packets over a TS Logical Channel involves several convergence protocol functions. This section briefly describes these functions and highlights the requirements for a new encapsulation.
既存の規格はレガシー実装から遺産を運びます。 これらは彼らの展開(例えば要件をネットワークでつなぐIPよりむしろオーディオ/ビデオ問題によって動かされたデザイン決定)時点で、技術の制限を反映しました。 IPv6、MPLS、および他のネットワーク層プロトコルはネイティブにサポートされません。 これらは本当に、IP中心になる新しいカプセル化の開発を一緒に、正当化します。 TS Logical Channelの上までIPパケットを運ぶと、いくつかの集合プロトコル機能がかかわります。 このセクションは、簡潔にこれらの機能について説明して、新しいカプセル化のための要件を強調します。
4.1. Payload Unit Delimitation
4.1. 有効搭載量ユニット区切り
MPEG-2 indicates the start of a Payload Unit (PU) in a new TS Packet with a "payload_unit_start_indicator" (PUSI) [ISO-MPEG] carried in the 4B TS Packet header. The PUSI is a 1 bit flag that has normative meaning [ISO-MPEG] for TS Packets that carry PES Packets or PSI/SI data.
「ペイロード_ユニット_スタート_インディケータ」(PUSI)[ISO-MPEG]が4B TS Packetヘッダーで運ばれている状態で、MPEG-2は新しいTS Packetの有効搭載量Unit(PU)の始まりを示します。 PUSIはPES Packetsを運ぶTS PacketsかPSI/SIデータのための標準の意味[ISO-MPEG]がある1ビットの旗です。
Montpetit, et al. Informational [Page 17] RFC 4259 IP Transport over MPEG-2 Networks November 2005
Montpetit、他 情報[17ページ]のRFC4259IP輸送はMPEG-2の上で2005年11月をネットワークでつなぎます。
When the payload of a TS Packet contains PES data, a PUSI value of '1' indicates the TS Packet payload starts with the first byte of a PES Packet. A value of '0' indicates that no PES Packet starts in the TS Packet. If the PUSI is set to '1', then one, and only one, PES Packet starts in the TS Packet.
TS PacketのペイロードがPESデータを含んでいると、'1'のPUSI値は、TS PacketペイロードがPES Packetの最初のバイトから始まるのを示します。 '0'の値は、どんなPES PacketもTS Packetで始まらないのを示します。 PUSIが'1'、次に、1、および1つだけに用意ができているなら、PES PacketはTS Packetで始まります。
When the payload of the TS Packet contains PSI data, a PUSI value of '1' indicates the first byte of the TS Packet payload carries a Payload Pointer (PP) that indicates the position of the first byte of the Payload Unit (Table Section) being carried; if the TS Packet does not carry the first byte of a Table Section, the PUSI is set to '0', indicating that no Payload Pointer is present.
TS PacketのペイロードがPSIデータを含んでいると、'1'のPUSI値は、TS Packetペイロードの最初のバイトが運ばれる有効搭載量Unit(テーブルセクション)の最初のバイトの位置を示す有効搭載量Pointer(PP)を運ぶのを示します。 TS PacketがTableセクションの最初のバイトを運ばないなら、PUSIは'0'に用意ができています、どんな有効搭載量Pointerも存在していないのを示して。
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 been corrupted or lost in the transmission. In which case, the payload is discarded until the next TS Packet is received with a PUSI value of '1'.
このPUSIビットを使用して、TS Packetの最初の有効搭載量Unitの始まりはまさにReceiverによって知られています、そのTS Packetがトランスミッションで崩壊するか、またはなくされていない場合。 その場合、ペイロードは'1'のPUSI値で次のTS Packetを受け取るまで捨てられます。
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 be sent in a TS Packet. In addition, it should allow an IP Encapsulator to insert padding when there is an incomplete TS Packet payload. A mechanism needs to be identified to differentiate this padding from the case where another encapsulated SNDU follows.
カプセル化は、同じTS Packetに1SNDUを梱包するのを許容するべきであり、TS Packetで送ることができるSNDUsの数を制限するべきではありません。 不完全なTS Packetペイロードがあるとき、さらに、IP Encapsulatorはそれで詰め物を挿入するはずであることができます。 メカニズムは、SNDUであるとカプセル化された別ののが続くケースとこの詰め物を区別するために特定される必要があります。
A combination of the PUSI and a Length Indicator (see below) allows an efficient MPEG-2 convergence protocol to receive accurate delineation of packed SNDUs. The MPEG-2 standard [ISO-MPEG] does not specify how private data should use the PUSI bit.
PUSIとLength Indicator(以下を見る)の組み合わせで、効率的なMPEG-2集合プロトコルは詰まっているSNDUsの正確な輪郭描写を受けることができます。 MPEG-2規格[ISO-MPEG]は個人的なデータがどうPUSIビットを使用するべきであるかを指定しません。
4.2. Length Indicator
4.2. 長さのインディケータ
Most services using MPEG-2 include a length field in the Payload Unit header to allow the Receiver to identify the end of a Payload Unit (e.g., PES Packet, Section, or an SNDU).
MPEG-2を使用するほとんどのサービスが、Receiverが有効搭載量Unit(例えば、PES Packet、セクション、またはSNDU)の端を特定するのを許容するために有効搭載量Unitヘッダーの長さの分野を含んでいます。
When parts of more than two Payload Units are carried in the same TS Packet, only the start of the first is indicated by the Payload Pointer. Placement of a Length Indicator in the encapsulation header allows a Receiver to determine the number of bytes until the start of the next encapsulated SNDU. This placement also provides the opportunity for the Receiver to pre-allocate an appropriate-sized memory buffer to receive the reassembled SNDU.
2有効搭載量Unitsの部分が同じTS Packetで運ばれるとき、1つの番目ものの始まりが有効搭載量Pointerによって示されます。 カプセル化ヘッダーのLength Indicatorのプレースメントで、Receiverは次のカプセル化されたSNDUの始まりまでバイト数を測定できます。 また、このプレースメントはReceiverが組み立て直されたSNDUを受け取るために適切サイズのメモリ・バッファをあらかじめ割り当てる機会を提供します。
A Length Indicator is required, and should be carried in the encapsulation header. This should support SNDUs of at least the MTU size offered by Ethernet (currently 1500 bytes). Although the IPv4
Length Indicatorは必要であり、カプセル化ヘッダーで運ばれるべきです。 これは少なくともイーサネット(現在の1500バイト)によって提供されたMTUサイズのSNDUsをサポートするべきです。 IPv4です。
Montpetit, et al. Informational [Page 18] RFC 4259 IP Transport over MPEG-2 Networks November 2005
Montpetit、他 情報[18ページ]のRFC4259IP輸送はMPEG-2の上で2005年11月をネットワークでつなぎます。
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 speed links are often limited by the packet forwarding rate of 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 uncommon in the core of the current Internet. This would seem a suitable maximum size for an MPEG-2 transmission network.
そして、パケット・フォーマットが最大64KBのサイズのIPパケットを可能にするIPv6、そのようなパケットは現在のインターネットでめったに見られません。 高速リンクがしばしばルータのパケット伝送速度によって制限されるので、インターネットコアルータが1500バイトより大きい値をMTUにサポートする傾向がありました。 16KBの値は現在のインターネットのコアで珍しくはありません。 これはMPEG-2送電網に関して適当な最大サイズに見えるでしょう。
4.3. Next Level Protocol Type
4.3. 次の平らなプロトコルタイプ
Any IETF-defined encapsulation protocol should identify the payload type being transported (e.g., to differentiate IPv4, IPv6, etc). Most protocols use a type field to identify a specific process at the next higher layer that is the originator or the recipient of the payload (SNDU). This method is used by IPv4, IPv6, and also by the original Ethernet protocol (DIX). OSI uses the concept of a 'Selector' for this, (e.g., in the IEEE 802/ISO 8802 standards for CSMA/CD [LLC]; although in this case, a SNAP (subnetwork access protocol) header is also required for IP packets.
どんなIETFによって定義されたカプセル化プロトコルも輸送される(例えばIPv4、IPv6などを差別化する)ペイロードタイプを特定するべきです。 ほとんどのプロトコルが、ペイロード(SNDU)の創始者か受取人である次の、より高い層で特定のプロセスを特定するのにタイプ分野を使用します。 IPv4、IPv6とオリジナルのイーサネットプロトコル(DIX)によってもこのメソッドは使用されます。 OSIがこれに'セレクタ'の概念を使用する、(例えば、8802年のCSMA/CD[LLC]のIEEE802/ISO規格で; この場合、しかし、また、SNAP(サブネットワークアクセス・プロトコル)ヘッダーがIPパケットに必要です。
A Next Level Protocol Type field is also required if compression (e.g., Robust Header Compression [RFC3095]) is supported. No compression method has currently been defined that is directly applicable to this architecture, however the ROHC framework defines a number of header compression techniques that may yield considerable improvement in throughput on links that have a limited capacity. Since many MPEG-2 Transmission Networks are wireless, the ROHC framework will be directly applicable for many applications. The benefit of ROHC is greatest for smaller SNDUs but does imply the need for additional processing at the Receiver to expand the received compressed packets. The selected type field should contain sufficient code points to support this technique.
また、圧縮(例えば、Robust Header Compression[RFC3095])がサポートされるなら、Next LevelプロトコルType分野が必要です。 直接このアーキテクチャに適切などんな圧縮方法も現在、定義されていなくて、しかしながら、ROHCフレームワークは収容数の限界を持っているリンクに関するスループットでかなりの改良をもたらすかもしれない多くのヘッダー圧縮のテクニックを定義します。 多くのMPEG-2Transmission Networksがワイヤレスであるので、ROHCフレームワークは直接多くのアプリケーションに適切になるでしょう。 ROHCの利益は、より小さいSNDUsに最もすばらしいのですが、Receiverでの追加処理が容認された圧縮されたパケットを広くする必要性を含意します。 選択されたタイプ分野はこのテクニックをサポートできるくらいのコード・ポイントを含むべきです。
It is thus a requirement to include a Next Level Protocol Type field in the encapsulation header. Such a field should specify values for at least IPv4, IPv6, and must allow for other values (e.g., MAC-level bridging).
その結果、それはカプセル化ヘッダーのNext LevelプロトコルType分野を含んでいるという要件です。 そのような分野は、少なくともIPv4のための値、IPv6を指定するべきであり、他の値(例えば、MAC-レベルのブリッジする)を考慮しなければなりません。
4.4. L2 Subnet Addressing
4.4. L2サブネットアドレシング
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 primarily intended as a unidirectional (simplex) broadcast system. A TS Packet stream carries either tables or one PES Packet stream (i.e., compressed video or audio). Individual Receivers are not addressable at this level.
MPEG-2では、TS Packetヘッダーで運ばれたPIDは、SIテーブルの助けと個々のサービスを同一視するのに使用されます。 これは単方向の(シンプレクス)放送システムとして主として意図しました。 TS Packetストリームはテーブルか1つのPES Packetストリーム(すなわち、圧縮されたビデオかオーディオ)のどちらかを運びます。 個々のReceiversはこのレベルでアドレス可能ではありません。
Montpetit, et al. Informational [Page 19] RFC 4259 IP Transport over MPEG-2 Networks November 2005
Montpetit、他 情報[19ページ]のRFC4259IP輸送はMPEG-2の上で2005年11月をネットワークでつなぎます。
IPv4 and IPv6 allocate addresses to end hosts and intermediate systems (routers). Each system (or interface) is identified by a globally assigned address. ISO uses the concept of a hierarchically structured Network Service Access Point (NSAP) address to identify an end host user process in an Internet environment.
IPv4とIPv6は、ホストと中間システム(ルータ)を終わらせるためにアドレスを割り当てます。 各システム(連結する)はグローバルに割り当てられたアドレスによって特定されます。 ISOは、インターネット環境における終わりのホストユーザ・プロセスを特定するのに階層的で構造化されたNetwork Service Access Point(NSAP)アドレスの概念を使用します。
Within a local network, a completely different set of addresses for the Network Point of Attachment (NPA) is used; frequently these NPA addresses are referred to as Medium Access Control, MAC-level addresses. In the Internet they are also called hardware addresses. Whereas network layer addresses are used for routing, NPA addresses are primarily used for Receiver identification.
企業内情報通信網の中では、Attachment(NPA)のNetwork Pointのための完全に異なったアドレスは使用されています。 頻繁に、これらのNPAアドレスはMedium Access Control、MAC-レベルアドレスと呼ばれます。 また、インターネットでは、それらはハードウェア・アドレスと呼ばれます。 ネットワーク層アドレスはルーティングに使用されますが、NPAアドレスはReceiver識別に主として使用されます。
Receivers may use the NPA of a received SNDU to reject unwanted unicast packets within the (software) interface driver at the Receiver, but must also perform forwarding checks based on the IP address. IP multicast and broadcast may also filter using the NPA, but Receivers must also filter unwanted packets at the network 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 IP address may map to the same NPA). If a separate NPA address is not required, the IP address is sufficient for both functions.
Receivers may use the NPA of a received SNDU to reject unwanted unicast packets within the (software) interface driver at the Receiver, but must also perform forwarding checks based on the IP address. IP multicast and broadcast may also filter using the NPA, but Receivers must also filter unwanted packets at the network 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 IP address may map to the same NPA). If a separate NPA address is not required, the IP address is sufficient for both functions.
If it is required to address an individual Receiver in an MPEG-2 transport system, this can be achieved either at the network level (IP address) or via a hardware-level NPA address (MAC-address). If both addresses are used, they must be mapped in either a static or a dynamic way (e.g., by an address resolution process). A similar requirement may also exist to identify the PID and TS multiplex on which services are carried.
If it is required to address an individual Receiver in an MPEG-2 transport system, this can be achieved either at the network level (IP address) or via a hardware-level NPA address (MAC-address). If both addresses are used, they must be mapped in either a static or a dynamic way (e.g., by an address resolution process). A similar requirement may also exist to identify the PID and TS multiplex on which services are carried.
Using an NPA address in an MPEG-2 TS may enhance security, in that a particular PDU may be targeted for a particular Receiver by specifying the corresponding Receiver NPA address. However, this is only a weak form of security, since the NPA filtering is often reconfigurable (frequently performed in software), and may be modified by a user to allow reception of specified (or all) packets, similar to promiscuous mode operation in Ethernet. If security is required, it should be applied at another place (e.g., link encryption, authentication of address resolution, IPsec, transport level security and/or application level security).
Using an NPA address in an MPEG-2 TS may enhance security, in that a particular PDU may be targeted for a particular Receiver by specifying the corresponding Receiver NPA address. However, this is only a weak form of security, since the NPA filtering is often reconfigurable (frequently performed in software), and may be modified by a user to allow reception of specified (or all) packets, similar to promiscuous mode operation in Ethernet. If security is required, it should be applied at another place (e.g., link encryption, authentication of address resolution, IPsec, transport level security and/or application level security).
There are also cases where the use of an NPA is required (e.g., where a system operates as a router) and, if present, this should be carried in an encapsulation header where it may be used by Receivers as a pre-filter to discard unwanted SNDUs. The addresses allocated do not need to conform to the IEEE MAC address format. There are many cases where an NPA is not required, and network layer filtering
There are also cases where the use of an NPA is required (e.g., where a system operates as a router) and, if present, this should be carried in an encapsulation header where it may be used by Receivers as a pre-filter to discard unwanted SNDUs. The addresses allocated do not need to conform to the IEEE MAC address format. There are many cases where an NPA is not required, and network layer filtering
Montpetit, et al. Informational [Page 20] RFC 4259 IP Transport over MPEG-2 Networks November 2005
Montpetit, et al. Informational [Page 20] RFC 4259 IP Transport over MPEG-2 Networks November 2005
may be used. Therefore, a new encapsulation protocol should support an optional NPA.
may be used. Therefore, a new encapsulation protocol should support an optional NPA.
4.5. Integrity Check
4.5. Integrity Check
For the IP service, the probability of undetected packet error should be small (or negligible) [RFC3819]. Therefore, there is a need for a strong integrity check (e.g., Cyclic Redundancy Check or CRC) to verify correctness of a received PDU [RFC3819]. Such checks should be sufficient to detect incorrect operation of the encapsulator and Receiver (including reassembly errors following loss/corruption of TS Packets), in addition to protecting from loss and/or corruption by the transmission network (e.g., multiplexors and links).
For the IP service, the probability of undetected packet error should be small (or negligible) [RFC3819]. Therefore, there is a need for a strong integrity check (e.g., Cyclic Redundancy Check or CRC) to verify correctness of a received PDU [RFC3819]. Such checks should be sufficient to detect incorrect operation of the encapsulator and Receiver (including reassembly errors following loss/corruption of TS Packets), in addition to protecting from loss and/or corruption by the transmission network (e.g., multiplexors and links).
Mechanisms exist in MPEG-2 Transmission Networks that may assist in detecting loss (e.g., the 4-bit continuity counter included in the MPEG-2 TS Packet header).
Mechanisms exist in MPEG-2 Transmission Networks that may assist in detecting loss (e.g., the 4-bit continuity counter included in the MPEG-2 TS Packet header).
An encapsulation must provide a strong integrity check for each IP packet. The requirements for usage of a link CRC are provided in [RFC3819]. To ease hardware implementation, this check should 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 adequate protection for larger payloads.
An encapsulation must provide a strong integrity check for each IP packet. The requirements for usage of a link CRC are provided in [RFC3819]. To ease hardware implementation, this check should 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 adequate protection for larger payloads.
4.6. Identification of Scope.
4.6. Identification of Scope.
The MPE section header contains information that could be used by the Receiver to identify the scope of the (MAC) address carried as an NPA, and to prevent TS Packets intended for one scope from being received by another. Similar functionality may be achieved by ensuring that only 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 multiple TS Logical Channels.
The MPE section header contains information that could be used by the Receiver to identify the scope of the (MAC) address carried as an NPA, and to prevent TS Packets intended for one scope from being received by another. Similar functionality may be achieved by ensuring that only 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 multiple TS Logical Channels.
4.7. Extension Headers
4.7. Extension Headers
The evolution of the Internet service may require additional functions in the future. A flexible protocol should therefore provide a way to introduce new features when required, without having to provide additional out-of-band configuration.
The evolution of the Internet service may require additional functions in the future. A flexible protocol should therefore provide a way to introduce new features when required, without having to provide additional out-of-band configuration.
IPv6 introduced the concept of extension headers that carry extra information necessary/desirable for certain subnetworks. The DOCSIS cable specification also allows a MAC header to carry extension headers to build operator-specific services. Thus, it is a requirement for the new encapsulation to allow extension headers.
IPv6 introduced the concept of extension headers that carry extra information necessary/desirable for certain subnetworks. The DOCSIS cable specification also allows a MAC header to carry extension headers to build operator-specific services. Thus, it is a requirement for the new encapsulation to allow extension headers.
Montpetit, et al. Informational [Page 21] RFC 4259 IP Transport over MPEG-2 Networks November 2005
Montpetit, et al. Informational [Page 21] RFC 4259 IP Transport over MPEG-2 Networks November 2005
4.8. Summary of Requirements for Encapsulation
4.8. Summary of Requirements for Encapsulation
The main requirements for an IP-centric encapsulation include:
The main requirements for an IP-centric encapsulation include:
- support of IPv4 and IPv6 packets
- support for Ethernet encapsulated packets
- flexibility to support other IP formats and protocols (e.g.,
ROHC, MPLS)
- easy implementation using either hardware or software
processing
- low overhead/managed overhead
- a fully specified algorithm that allows a sender to pack
multiple packets per SNDU and to easily locate packet
fragments
- extensibility
- compatibility with legacy deployments
- ability to allow link encryption, when required
- capability to support a full network architecture including
data, control, and management planes
- support of IPv4 and IPv6 packets - support for Ethernet encapsulated packets - flexibility to support other IP formats and protocols (e.g., ROHC, MPLS) - easy implementation using either hardware or software processing - low overhead/managed overhead - a fully specified algorithm that allows a sender to pack multiple packets per SNDU and to easily locate packet fragments - extensibility - compatibility with legacy deployments - ability to allow link encryption, when required - capability to support a full network architecture including data, control, and management planes
5. Address Resolution Functions
5. Address Resolution Functions
Address Resolution (AR) provides a mechanism that associates layer 2 (L2) information with the IP address of a system [IPDVB-AR]. Many L2 technologies employ unicast AR at the sender: an IP system wishing to send an IP packet encapsulates it and places it into an L2 frame. It then identifies the appropriate L3 adjacency (e.g., next hop router, end host) and determines the appropriate L2 adjacency (e.g., MAC address in Ethernet) to which the frame should be sent so that the packet gets across the L2 link.
Address Resolution (AR) provides a mechanism that associates layer 2 (L2) information with the IP address of a system [IPDVB-AR]. Many L2 technologies employ unicast AR at the sender: an IP system wishing to send an IP packet encapsulates it and places it into an L2 frame. It then identifies the appropriate L3 adjacency (e.g., next hop router, end host) and determines the appropriate L2 adjacency (e.g., MAC address in Ethernet) to which the frame should be sent so that the packet gets across the L2 link.
The L2 addresses discovered using AR are normally recorded in a data structure known as the arp/neighbor cache. The results of previous AR requests are usually cached. Further AR protocol exchanges may be required as communication proceeds to update or re-initialize the client cache state contents (i.e., purge/refresh the contents). For stability, and to allow network topology changes and client faults, the cache contents are normally "soft state"; that is, they are aged with respect to time and old entries are removed.
The L2 addresses discovered using AR are normally recorded in a data structure known as the arp/neighbor cache. The results of previous AR requests are usually cached. Further AR protocol exchanges may be required as communication proceeds to update or re-initialize the client cache state contents (i.e., purge/refresh the contents). For stability, and to allow network topology changes and client faults, the cache contents are normally "soft state"; that is, they are aged with respect to time and old entries are removed.
In some cases (e.g., ATM, X.25, MPEG-2 and many more), AR involves finding other information than the MAC address. This includes identifying other parameters required for L2 transmission, such as channel IDs (VCs in X.25, VCIs in ATM, or PIDs in MPEG-2 TS).
In some cases (e.g., ATM, X.25, MPEG-2 and many more), AR involves finding other information than the MAC address. This includes identifying other parameters required for L2 transmission, such as channel IDs (VCs in X.25, VCIs in ATM, or PIDs in MPEG-2 TS).
Montpetit, et al. Informational [Page 22] RFC 4259 IP Transport over MPEG-2 Networks November 2005
Montpetit, et al. Informational [Page 22] RFC 4259 IP Transport over MPEG-2 Networks November 2005
Address resolution has different purposes for unicast and multicast. Multicast address resolution is not required for many L2 networks, but is required where MPEG-2 transmission networks carry IP multicast packets using more than one TS Logical Channel.
Address resolution has different purposes for unicast and multicast. Multicast address resolution is not required for many L2 networks, but is required where MPEG-2 transmission networks carry IP multicast packets using more than one TS Logical Channel.
5.1. Address Resolution for MPEG-2
5.1. Address Resolution for MPEG-2
There are three elements to the L2 information required to perform AR before an IP packet is sent over an MPEG-2 TS. These are:
There are three elements to the L2 information required to perform AR before an IP packet is sent over an MPEG-2 TS. These are:
(i) A Receiver ID (e.g., a 6B MAC/NPA address).
(ii) A PID or index to find a PID.
(iii) Tuner information (e.g., Transmit Frequency of the
physical layer of a satellite/broadcast link
(i) A Receiver ID (e.g., a 6B MAC/NPA address). (ii) A PID or index to find a PID. (iii) Tuner information (e.g., Transmit Frequency of the physical layer of a satellite/broadcast link
Elements (ii) and (iii) need to be de-referenced when the MPEG-2 Transmission Network includes (re)multiplexors that renumber the PID values of the TS Logical Channels that they process. In MPEG-2 [ISO-MPEG], this dereferencing is via indexes to the information (i.e., the Program Map Table, PMT, which is itself indexed via the Program Association Table, PAT). (Note that PIDs are not intended to be end-to-end identifiers.) However, although remultiplexing is common in broadcast TV networks (scenarios A and B), many private networks do not need to employ multiplexors that renumber PIDs (see Section 3.3).
Elements (ii) and (iii) need to be de-referenced when the MPEG-2 Transmission Network includes (re)multiplexors that renumber the PID values of the TS Logical Channels that they process. In MPEG-2 [ISO-MPEG], this dereferencing is via indexes to the information (i.e., the Program Map Table, PMT, which is itself indexed via the Program Association Table, PAT). (Note that PIDs are not intended to be end-to-end identifiers.) However, although remultiplexing is common in broadcast TV networks (scenarios A and B), many private networks do not need to employ multiplexors that renumber PIDs (see Section 3.3).
The third element (iii) allows an AR client to resolve to a different MPEG TS Multiplex. This is used when there are several channels that may be used for communication (i.e., multiple outbound/inbound links). In a mesh system, this could be used to determine connectivity. This AR information is used in two ways at a Receiver:
The third element (iii) allows an AR client to resolve to a different MPEG TS Multiplex. This is used when there are several channels that may be used for communication (i.e., multiple outbound/inbound links). In a mesh system, this could be used to determine connectivity. This AR information is used in two ways at a Receiver:
(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 L2 filters to let traffic pass to the IP layer. This is
used for unicast, and IPv4 subnet broadcast.
(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 L2 filters to let traffic pass to the IP layer. This is used for unicast, and IPv4 subnet broadcast.
(ii) AR resolves an IP multicast address to the (MPEG TS Multiplex,
PID, MAC/NPA address), and allows the Receiver to set L2 filters
enabling traffic to pass to the IP layer. A Receiver in an
MPEG-2 TS Transmission Network needs to resolve the PID value
and the tuning (if present) associated with a TS Logical Channel
and (at least for unicast) the destination Receiver NPA address.
(ii) AR resolves an IP multicast address to the (MPEG TS Multiplex, PID, MAC/NPA address), and allows the Receiver to set L2 filters enabling traffic to pass to the IP layer. A Receiver in an MPEG-2 TS Transmission Network needs to resolve the PID value and the tuning (if present) associated with a TS Logical Channel and (at least for unicast) the destination Receiver NPA address.
A star topology MPEG-2 TS transmission network is illustrated below, with two Receivers receiving a forward broadcast channel sent by a Hub. (A mesh system has some additional cases.) The forward broadcast channel consists of a "TS Multiplex" (a single physical
A star topology MPEG-2 TS transmission network is illustrated below, with two Receivers receiving a forward broadcast channel sent by a Hub. (A mesh system has some additional cases.) The forward broadcast channel consists of a "TS Multiplex" (a single physical
Montpetit, et al. Informational [Page 23] RFC 4259 IP Transport over MPEG-2 Networks November 2005
Montpetit, et al. Informational [Page 23] RFC 4259 IP Transport over MPEG-2 Networks November 2005
bearer) allowing communication with the terminals. These communicate using a set of return channels.
bearer) allowing communication with the terminals. These communicate using a set of return channels.
Forward broadcast
MPEG-2 TS \
----------------X /-----\
/ / \
| Receiver|
/----------+ A |
/ \ /
/-----\ / \-----/
/ \ /
| Hub |/
| +\ /-----\
\ / \ / \
\-----/ \ | Receiver|
\-----------+ B |
\ /
\-----/
Forward broadcast MPEG-2 TS \ ----------------X /-----\ / / \ | Receiver| /----------+ A | / \ / /-----\ / \-----/ / \ / | Hub |/ | +\ /-----\ \ / \ / \ \-----/ \ | Receiver| \-----------+ B | \ / \-----/
Figure 6: MPEG-2 Transmission Network with 2 Receivers
Figure 6: MPEG-2 Transmission Network with 2 Receivers
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
system that is at the Hub;
(1) A system at a Receiver, A, needs to resolve an address of a system that is at the Hub;
(2) A system at a Receiver, A, needs to resolve an address that is at
another Receiver, B;
(2) A system at a Receiver, A, needs to resolve an address that is at another Receiver, B;
(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 MPEG TS Multiplex, PID, MAC/NPA address for sending unicast,
IPv4 subnet broadcast and multicast packets.
(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 MPEG TS Multiplex, PID, MAC/NPA address for sending unicast, IPv4 subnet broadcast and multicast packets.
If the Hub is an IP router, then case (1) and (2) are the same: The host at the Receiver does not know the difference. In these cases, the address to be determined is the L2 address of the device at the Hub to which the IP packet should be forwarded, which then relays the IP packet back to the forward (broadcast) MPEG-2 channel after AR (case 3).
If the Hub is an IP router, then case (1) and (2) are the same: The host at the Receiver does not know the difference. In these cases, the address to be determined is the L2 address of the device at the Hub to which the IP packet should be forwarded, which then relays the IP packet back to the forward (broadcast) MPEG-2 channel after AR (case 3).
If the Hub is an L2 bridge, then case 2 still has to relay the IP packet back to the outbound MPEG-2 channel. The AR protocol needs to resolve the specific Receiver L2 MAC address of B, but needs to send this on an L2 channel to the Hub. This requires Receivers to be informed of the L2 address of other Receivers.
If the Hub is an L2 bridge, then case 2 still has to relay the IP packet back to the outbound MPEG-2 channel. The AR protocol needs to resolve the specific Receiver L2 MAC address of B, but needs to send this on an L2 channel to the Hub. This requires Receivers to be informed of the L2 address of other Receivers.
Montpetit, et al. Informational [Page 24] RFC 4259 IP Transport over MPEG-2 Networks November 2005
Montpetit, et al. Informational [Page 24] RFC 4259 IP Transport over MPEG-2 Networks November 2005
An end host connected to the Hub needs to use the AR protocol to resolve the Receiver terminal MAC/NPA address. This requires the AR server at the Hub to be informed of the L2 addresses of other Receivers.
An end host connected to the Hub needs to use the AR protocol to resolve the Receiver terminal MAC/NPA address. This requires the AR server at the Hub to be informed of the L2 addresses of other Receivers.
5.2. Scenarios for MPEG AR
5.2. Scenarios for MPEG AR
An AR protocol may transmit AR information in three distinct ways:
An AR protocol may transmit AR information in three distinct ways:
(i) An MPEG-2 signalling table transmitted at the MPEG-2 level
(e.g., within the control plane using a Table);
(i) An MPEG-2 signalling table transmitted at the MPEG-2 level (e.g., within the control plane using a Table);
(ii) An MPEG-2 signalling table transmitted at the IP level (no
implementations of this are known);
(ii) An MPEG-2 signalling table transmitted at the IP level (no implementations of this are known);
(iii) An address resolution protocol transported over IP (as in ND
for IPv6)
(iii) An address resolution protocol transported over IP (as in ND for IPv6)
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-Muxes and the use of re-multiplexors, e.g., Digital
Terrestrial, Satellite TV broadcast multiplexes. Many such
systems employ remultiplexors that modify the PID values
associated with TS Logical Channels as they pass through the
MPEG-2 transmission network (as in Scenario A of Section 3.1).
(i) Multiple TS-Muxes and the use of re-multiplexors, e.g., Digital Terrestrial, Satellite TV broadcast multiplexes. Many such systems employ remultiplexors that modify the PID values associated with TS Logical Channels as they pass through the MPEG-2 transmission network (as in Scenario A of Section 3.1).
(ii) Tuner configuration(s) that are fixed or controlled by some
other process. In these systems, the PID value associated with
a TS Logical Channel may be known by the Sender.
(ii) Tuner configuration(s) that are fixed or controlled by some other process. In these systems, the PID value associated with a TS Logical Channel may be known by the Sender.
(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 systems, the PID value of a TS Logical Channel may be
known by the Sender.
(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 systems, the PID value of a TS Logical Channel may be known by the Sender.
5.2.1. Table-Based AR over MPEG-2
5.2.1. Table-Based AR over MPEG-2
In current deployments of MPEG-2 networks, information about the set of MPEG-2 TS Logical Channels carried over a TS Multiplex is usually distributed via tables (service information, SI) sent using channels assigned a specific (well-known) set of PIDs. This was originally designed for audio/video distribution to STBs. This design requires access to the control plane by processing the SI table information (carried in MPEG-2 section format [ISO-DSMCC]). The scheme reflects the complexity of delivering and coordinating the various TS Logical Channels associated with a multimedia TV program.
In current deployments of MPEG-2 networks, information about the set of MPEG-2 TS Logical Channels carried over a TS Multiplex is usually distributed via tables (service information, SI) sent using channels assigned a specific (well-known) set of PIDs. This was originally designed for audio/video distribution to STBs. This design requires access to the control plane by processing the SI table information (carried in MPEG-2 section format [ISO-DSMCC]). The scheme reflects the complexity of delivering and coordinating the various TS Logical Channels associated with a multimedia TV program.
Montpetit, et al. Informational [Page 25] RFC 4259 IP Transport over MPEG-2 Networks November 2005
Montpetit, et al. Informational [Page 25] RFC 4259 IP Transport over MPEG-2 Networks November 2005
One possible requirement to provide TS multiplex and PID information for IP services is to integrate additional information into the existing MPEG-2 tables, or to define additional tables specific to the IP service. The DVB INT and the A/92 Specification from ATSC [ATSC-A92] are examples of the realization of such a solution.
One possible requirement to provide TS multiplex and PID information for IP services is to integrate additional information into the existing MPEG-2 tables, or to define additional tables specific to the IP service. The DVB INT and the A/92 Specification from ATSC [ATSC-A92] are examples of the realization of such a solution.
5.2.2. Table-Based AR over IP
5.2.2. Table-Based AR over IP
AR information could be carried over a TS data channel (e.g., using an IP protocol similar to the Service Announcement Protocol, SAP). Implementing this independently of the SI tables would ease implementation, by allowing it to operate on systems where IP processing is performed in a software driver. It may also allow the technique to be more easily adapted to other similar delivery networks. It also is advantageous for networks that use the MPEG-2 TS, but do not necessarily support audio/video services and therefore do not need to provide interoperability with TV equipment (e.g., links used solely for connecting IP (sub)networks).
AR information could be carried over a TS data channel (e.g., using an IP protocol similar to the Service Announcement Protocol, SAP). Implementing this independently of the SI tables would ease implementation, by allowing it to operate on systems where IP processing is performed in a software driver. It may also allow the technique to be more easily adapted to other similar delivery networks. It also is advantageous for networks that use the MPEG-2 TS, but do not necessarily support audio/video services and therefore do not need to provide interoperability with TV 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, or based on IPv6 Neighbor Advertisements of the ND protocol). The AR protocol may operate over an MPEG-2 TS Logical Channel using a previously agreed PID (e.g., configured, or communicated using a SI 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 is very tolerant to failures. To find an address, a system sends a "query" to the network, and the "target" (or its proxy) replies.
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 protocol may operate over an MPEG-2 TS Logical Channel using a previously agreed PID (e.g., configured, or communicated using a SI 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 is very tolerant to failures. To find an address, a system sends a "query" to the network, and the "target" (or its proxy) replies.
5.3. Unicast Address Scoping
5.3. Unicast Address Scoping
In some cases, an MPEG-2 Transmission Network may support multiple IP networks. When this is the case, it is important to recognize the context (scope) within which an address is resolved, to prevent packets from one addressed scope from leaking into other scopes.
In some cases, an MPEG-2 Transmission Network may support multiple IP networks. When this is the case, it is important to recognize the context (scope) within which an address is resolved, to prevent packets from one addressed scope from leaking into other scopes.
An example of overlapping IP address assignments is the use of private unicast addresses (e.g., in IPv4, 10/8 prefix; 172.16/12 prefix; 192.168/16 prefix). These should be confined to the area to which they are addressed.
An example of overlapping IP address assignments is the use of private unicast addresses (e.g., in IPv4, 10/8 prefix; 172.16/12 prefix; 192.168/16 prefix). These should be confined to the area to which they are addressed.
There is also a requirement for multicast address scoping (Section 6.2).
There is also a requirement for multicast address scoping (Section 6.2).
Montpetit, et al. Informational [Page 26] RFC 4259 IP Transport over MPEG-2 Networks November 2005
Montpetit, et al. Informational [Page 26] RFC 4259 IP Transport over MPEG-2 Networks November 2005
IP packets with these addresses must not be allowed to travel outside their intended scope, and may cause unexpected behaviour if allowed to do so. In addition, overlapping address assignments can arise when using level 2 NPA addresses:
IP packets with these addresses must not be allowed to travel outside their intended scope, and may cause unexpected behaviour if allowed to do so. In addition, overlapping address assignments can arise when using level 2 NPA addresses:
(i) The NPA address must be unique within the TS Logical Channel.
Universal IEEE MAC addresses used in Ethernet LANs are
globally unique. If the NPA addresses are not globally
unique, the same NPA address may be re-used by Receivers in
different addressed areas.
(i) The NPA address must be unique within the TS Logical Channel. Universal IEEE MAC addresses used in Ethernet LANs are globally unique. If the NPA addresses are not globally unique, the same NPA address may be re-used by Receivers in different addressed areas.
(ii) The NPA broadcast address (all 1s MAC address). Traffic with
this address should be confined to one addressed area.
(ii) The NPA broadcast address (all 1s MAC address). Traffic with this address should be confined to one addressed area.
Reception of unicast packets destined for another addressed area may lead to an increase in the rate of received packets by systems connected via the network. IP end hosts normally filter received unicast IP packets based on their assigned IP address. Reception of the additional network traffic may contribute to processing load but should not lead to unexpected protocol behaviour. However, it does introduce a potential Denial of Service (DoS) opportunity.
Reception of unicast packets destined for another addressed area may lead to an increase in the rate of received packets by systems connected via the network. IP end hosts normally filter received unicast IP packets based on their assigned IP address. Reception of the additional network traffic may contribute to processing load but should not lead to unexpected protocol behaviour. However, it does introduce a potential Denial of Service (DoS) opportunity.
When the Receiver acts as an IP router, the receipt of such an IP packet may lead to unexpected protocol behaviour. This also provides a security vulnerability since arbitrary packets may be passed to the IP layer.
When the Receiver acts as an IP router, the receipt of such an IP packet may lead to unexpected protocol behaviour. This also provides a security vulnerability since arbitrary packets may be passed to the IP layer.
5.4. AR Authentication
5.4. AR Authentication
In many AR designs, authentication has been overlooked because of the wired nature of most existing IP networks, which makes it easy to control hosts that are physically connected [RFC3819]. With wireless connections, this is changing: unauthorized hosts actually can claim L2 resources. The address resolution client (i.e., Receiver) may also need to verify the integrity and authenticity of the AR information that it receives. There are trust relationships both ways: clients need to know they have a valid server and that the resolution is valid. Servers should perform authorisation before they allow an L2 address to be used.
In many AR designs, authentication has been overlooked because of the wired nature of most existing IP networks, which makes it easy to control hosts that are physically connected [RFC3819]. With wireless connections, this is changing: unauthorized hosts actually can claim L2 resources. The address resolution client (i.e., Receiver) may also need to verify the integrity and authenticity of the AR information that it receives. There are trust relationships both ways: clients need to know they have a valid server and that the resolution is valid. Servers should perform authorisation before they allow an L2 address to be used.
The MPEG-2 Transmission Network may also require access control to prevent unauthorized use of the TS Multiplex; however, this is an orthogonal issue to address resolution.
The MPEG-2 Transmission Network may also require access control to prevent unauthorized use of the TS Multiplex; however, this is an orthogonal issue to address resolution.
Montpetit, et al. Informational [Page 27] RFC 4259 IP Transport over MPEG-2 Networks November 2005
Montpetit, et al. Informational [Page 27] RFC 4259 IP Transport over MPEG-2 Networks November 2005
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
requires definition of the frequency of update and volume of
AR traffic generated.
(i) Use of a table-based approach to promote AR scaling. This requires definition of the frequency of update and volume of AR traffic generated.
(ii) Mechanisms to install AR information at the server
(unsolicited registration).
(ii) Mechanisms to install AR information at the server (unsolicited registration).
(iii) Mechanisms to verify AR information held at the server
(solicited responses). Appropriate timer values need to be
defined.
(iii) Mechanisms to verify AR information held at the server (solicited responses). Appropriate timer values need to be defined.
(iv) An ability to purge client AR information (after IP network
renumbering, etc.).
(iv) An ability to purge client AR information (after IP network 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.
6. Multicast Support
6. Multicast Support
This section addresses specific issues concerning IPv4 and IPv6 multicast [RFC1112] over MPEG-2 Transmission Networks. The primary goal of multicast support will be efficient filtering of IP multicast packets by the Receiver, and the mapping of IPv4 and IPv6 multicast addresses [RFC3171] to the associated PID value and TS Multiplex.
This section addresses specific issues concerning IPv4 and IPv6 multicast [RFC1112] over MPEG-2 Transmission Networks. The primary goal of multicast support will be efficient filtering of IP multicast packets by the Receiver, and the mapping of IPv4 and IPv6 multicast addresses [RFC3171] to the associated PID value and TS Multiplex.
The design should permit a large number of active multicast groups, and should minimize the processing load at the Receiver when filtering and forwarding IP multicast packets. For example, schemes that may be easily implemented in hardware would be beneficial, since these may relieve drivers and operating systems from discarding unwanted multicast traffic [RFC3819].
The design should permit a large number of active multicast groups, and should minimize the processing load at the Receiver when filtering and forwarding IP multicast packets. For example, schemes that may be easily implemented in hardware would be beneficial, since these may relieve drivers and operating systems from discarding unwanted multicast traffic [RFC3819].
Multicast mechanisms are used at more than one protocol level. The upstream router feeding the MPEG-2 Encapsulator may forward multicast traffic on the MPEG-2 TS Multiplex using a static or dynamic set of groups. When static forwarding is used, the set of IP multicast groups may also be configured or set using SNMP, Telnet, etc. A Receiver normally uses either an IP group management protocol (IGMP [RFC3376] for IPv4 or MLD [RFC2710][RFC3810] for IPv6) or a multicast routing protocol to establish tables that it uses to dynamically enable local forwarding of received groups. In a dynamic case, this
Multicast mechanisms are used at more than one protocol level. The upstream router feeding the MPEG-2 Encapsulator may forward multicast traffic on the MPEG-2 TS Multiplex using a static or dynamic set of groups. When static forwarding is used, the set of IP multicast groups may also be configured or set using SNMP, Telnet, etc. A Receiver normally uses either an IP group management protocol (IGMP [RFC3376] for IPv4 or MLD [RFC2710][RFC3810] for IPv6) or a multicast routing protocol to establish tables that it uses to dynamically enable local forwarding of received groups. In a dynamic case, this
Montpetit, et al. Informational [Page 28] RFC 4259 IP Transport over MPEG-2 Networks November 2005
Montpetit, et al. Informational [Page 28] RFC 4259 IP Transport over MPEG-2 Networks November 2005
group membership information is fed back to the sender to enable it to start sending new groups and (if required) to update the tables that it produces for multicast AR.
group membership information is fed back to the sender to enable it to start sending new groups and (if required) to update the tables that it produces for multicast AR.
Appropriate procedures need to identify the correct action when the same multicast group is available on more than one TS Logical Channel. This could arise when different end hosts act as senders to contribute IP packets with the same IP group destination address. The correct behaviour for SSM [RFC3569] addresses must also be considered. It may also arise when a sender duplicates the same IP group over several TS Logical Channels (or even different TS Multiplexes), and in this case a Receiver may potentially receive more than one copy of the same packet. At the IP level, the host/router may be unaware of this duplication.
Appropriate procedures need to identify the correct action when the same multicast group is available on more than one TS Logical Channel. This could arise when different end hosts act as senders to contribute IP packets with the same IP group destination address. The correct behaviour for SSM [RFC3569] addresses must also be considered. It may also arise when a sender duplicates the same IP group over several TS Logical Channels (or even different TS Multiplexes), and in this case a Receiver may potentially receive more than one copy 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 summarized as:
The functions required for multicast AR may be summarized as:
(i) The Sender needs to know the L2 mapping of a multicast group. (ii) The Receiver needs to know the L2 mapping of a multicast group.
(i) The Sender needs to know the L2 mapping of a multicast group. (ii) The Receiver needs to know the L2 mapping of a multicast group.
In the Internet, multicast AR is normally a mapping function rather than a one-to-one association using a protocol. In Ethernet, the sender maps an IP address to an L2 MAC address, and the Receiver uses the same mapping to determine the L2 address to set an L2 hardware/software filter entry.
In the Internet, multicast AR is normally a mapping function rather than a one-to-one association using a protocol. In Ethernet, the sender maps an IP address to an L2 MAC address, and the Receiver uses the same mapping to determine the L2 address to set an L2 hardware/software filter entry.
A typical sequence of actions for the dynamic case is:
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
groups
L3) Dynamic/static forwarding at hub/upstream router of IP L3 groups
L2) Populate the IP AR tables at the encapsulator gateway
(i.e., Map IP L3 mcast groups to L2 PIDs)
L2) Populate the IP AR tables at the encapsulator gateway (i.e., Map IP L3 mcast groups to L2 PIDs)
L2) Distribute the AR information to Receivers
L2) Distribute the AR information to Receivers
L2) Set Receiver L2 multicast filters for IP groups in the
membership table.
L2) Set Receiver L2 multicast filters for IP groups in the membership table.
Montpetit, et al. Informational [Page 29] RFC 4259 IP Transport over MPEG-2 Networks November 2005
Montpetit, et al. Informational [Page 29] RFC 4259 IP Transport over MPEG-2 Networks November 2005
To be flexible, AR must associate a TS Logical Channel (PID) not only with a group address, but possibly also a QoS class and other appropriate MPEG-2 TS attributes. Explicit per group AR to individual L2 addresses is to be avoided.
To be flexible, AR must associate a TS Logical Channel (PID) not only with a group address, but possibly also a QoS class and other appropriate MPEG-2 TS attributes. Explicit per group AR to individual L2 addresses is to be avoided.
\
|
+---+----+ +---------+
| Tuner |---+TS Table | . . . .
+---+----+ +---------+ .
| - .
+--------+ +---------+ .
| deMux |---+PID Table|........
+---+----+ +---------+ :
| - :
+--------+ +---------+ +------------+
|MPE/ULE |---+AR Cache-|---+ L2 Table |
+---+----+ +---------+ +------------+
| | |
+---+----+ +---+-----+ +---+----+
| IP | | AR | |IGMP/MLD|
+---+----+ +---+-----+ +---+----+
| | |
*------------+------------+
\ | +---+----+ +---------+ | Tuner |---+TS Table | . . . . +---+----+ +---------+ . | - . +--------+ +---------+ . | deMux |---+PID Table|........ +---+----+ +---------+ : | - : +--------+ +---------+ +------------+ |MPE/ULE |---+AR Cache-|---+ L2 Table | +---+----+ +---------+ +------------+ | | | +---+----+ +---+-----+ +---+----+ | IP | | AR | |IGMP/MLD| +---+----+ +---+-----+ +---+----+ | | | *------------+------------+
Figure 7: Receiver Processing Architecture
Figure 7: Receiver Processing Architecture
6.2. Multicast Address Scoping
6.2. Multicast Address Scoping
As in unicast, it is important to recognize the context (scope) within which a multicast IP address is resolved, to prevent packets from one addressed scope leaking into other scopes.
ユニキャストのように、マルチキャストIPアドレスが他の範囲に漏れる範囲であると扱われたものからパケットを防ぐために決議されている文脈(範囲)を認識するのは重要です。
Examples of overlapping IP multicast address assignments include:
重なっているIPマルチキャストアドレス課題に関する例は:
(i) Local scope multicast addresses. These are
only valid within the local area (examples for IPv4
include: 224.0.0/24; 224.0.1/24). Similar cases
exist for some IPv6 multicast addresses [RFC2375].
(i) ローカルの範囲マルチキャストアドレス。 これらは局部の中で有効であるだけです。(IPv4のための例は224.0に.0/24;224.0にである:.1 /24)。 類例はいくつかのIPv6マルチキャストアドレス[RFC2375]のために存在しています。
(ii) Scoped multicast addresses [RFC2365] [RFC 2375]. Forwarding
of these addresses is controlled by the scope associated
with the address. The addresses are only valid with an
addressed area (e.g. the 239/8 [RFC2365]).
(ii)はマルチキャストアドレス[RFC2365][RFC2375]を見ました。 これらのアドレスの推進はアドレスに関連している範囲によって制御されます。 アドレスは扱われた領域(例えば、239/8[RFC2365])によって有効であるだけです。
(iii) Other non-IP protocols may also view sets of MAC multicast
addresses as link-local, and may produce unexpected results
if distributed across several private networks.
(iii) 他の非IPプロトコルは、また、MACマルチキャストアドレスのセットがリンク地方であるとみなして、いくつかの私設のネットワークの向こう側に分配されるなら、予期しなかった結果を生産するかもしれません。
Montpetit, et al. Informational [Page 30] RFC 4259 IP Transport over MPEG-2 Networks November 2005
Montpetit、他 情報[30ページ]のRFC4259IP輸送はMPEG-2の上で2005年11月をネットワークでつなぎます。
IP packets with these addresses must not be allowed to travel outside their intended scope (see Section 5.3). Performing multicast AR at the IP level can enable providers to offer independently scoped addresses and would need to use multiple Multicast AR servers, one per multicast domain.
これらのアドレスがあるIPパケットにそれらの意図している範囲の外を旅行させてはいけません(セクション5.3を見てください)。 レベルが、プロバイダーが独自に提供するのを可能にすることができるIPでマルチキャストARを実行するのは、アドレスを見て、複数のMulticast ARサーバ(マルチキャストドメインあたり1つ)を使用する必要があるでしょう。
6.3. Requirements for Multicast over MPEG-2
6.3. マルチキャストのための要件、MPEG-2以上
The requirements for supporting multicast include, but are not restricted to:
含んでいますが、マルチキャストをサポートするための要件は制限されません:
(i) Encapsulating multicast packets for transmission using an
MPEG-2 TS.
(i) トランスミッションのためにMPEG-2TSを使用することでマルチキャストパケットをカプセルに入れること。
(ii) Mapping IP multicast groups to the underlying MPEG-2 TS
Logical Channel (PID) and the MPEG-2 TS Multiplex.
(ii) 基本的なMPEG-2TS Logical Channel(PID)とMPEG-2TS MultiplexにIPマルチキャストグループを写像します。
(iii) Providing AR information to allow a Receiver to locate an
IP multicast flow within an MPEG-2 TS Multiplex.
(iii) ReceiverがMPEG-2TS Multiplexの中でIPマルチキャスト流動の場所を見つけるのを許容するために情報をARに供給します。
(iv) Error Reporting.
(iv)誤り報告。
7. Summary
7. 概要
This document describes the architecture for a set of protocols to perform efficient and flexible support for IP network services over networks built upon the MPEG-2 Transport Stream (TS). It also describes existing approaches. The focus is on IP networking, the mechanisms that are used, and their applicability to supporting IP unicast and multicast services.
1セットのプロトコルがMPEG-2Transport Stream(TS)に造られたネットワークの上のIPネットワーク・サービスの効率的でフレキシブルなサポートを実行するように、このドキュメントはアーキテクチャについて説明します。 また、それは既存のアプローチについて説明します。 焦点がIPネットワーク、使用されたメカニズム、およびIPユニキャストとマルチキャストサービスをサポートすることへの彼らの適用性にあります。
The requirements for a new encapsulation of IPv4 and IPv6 packets is described, outlining the limitations of current methods and the need for a streamlined IP-centric approach.
IPv4とIPv6パケットの新しいカプセル化のための要件は説明されます、流線型のIP中心のアプローチの現在のメソッドと必要性の制限について概説して。
The architecture also describes MPEG-2 Address Resolution (AR) procedures to allow dynamic configuration of the sender and Receiver using an MPEG-2 transmission link/network. These support IPv4 and IPv6 services in both the unicast and multicast modes. Resolution protocols will support IP packet transmission using both the Multiprotocol Encapsulation (MPE), which is currently widely deployed, and also any IETF-defined encapsulation (e.g., ULE [IPDVB-ULE]).
また、アーキテクチャは、MPEG-2トランスミッションリンク/ネットワークを使用することで送付者とReceiverの動的設定を許容するためにMPEG-2Address Resolution(AR)手順について説明します。 これらは、ユニキャストとマルチキャストモードの両方でIPv4とIPv6がサービスであるとサポートします。 解決プロトコルは、IPパケット伝送使用が現在広く配布されるMultiprotocol Encapsulation(MPE)とどんなIETFによって定義されたまたカプセル化(例えば、ウレ[IPDVB-ULE])について両方であるともサポートするでしょう。
Montpetit, et al. Informational [Page 31] RFC 4259 IP Transport over MPEG-2 Networks November 2005
Montpetit、他 情報[31ページ]のRFC4259IP輸送はMPEG-2の上で2005年11月をネットワークでつなぎます。
8. Security Considerations
8. セキュリティ問題
When the MPEG-2 transmission network is not using a wireline network, the normal security issues relating to the use of wireless links for transport of Internet traffic should be considered [RFC3819].
MPEG-2送電網がワイヤーラインネットワークを使用していないとき、ワイヤレスのリンクのインターネットトラフィックの輸送の使用に関連する正常な安全保障問題は[RFC3819]であると考えられるべきです。
End-to-end security (including confidentiality, authentication, integrity and access control) is closely associated with the end user assets that are protected. This close association cannot be ensured when providing security mechanisms only within a subnetwork (e.g., an MPEG-2 Transmission Network). Several security mechanisms that can be used end-to-end have already been deployed in the general Internet and are enjoying increasing use. Important examples include:
終わりから終わりへのセキュリティ(秘密性、認証、保全、およびアクセスコントロールを含んでいる)は密接に保護されるエンドユーザ資産に関連づけられます。 サブネットワーク(例えば、MPEG-2Transmission Network)だけの中でセキュリティー対策を提供するとき、この近接結合を確実にすることができません。 中古の終わりから終わりであるかもしれない数個のセキュリティー対策が、一般的なインターネットで既に配布されて、使用を増強するのを楽しんでいます。 重要な例は:
- Transport Layer Security (TLS), which is primarily used to
protect web commerce;
- Layer Security(TLS)を輸送してください。(Layer Securityはウェブ商業を保護するのに主として使用されます)。
- Pretty Good Privacy (PGP) and S/MIME, primarily used to protect
and authenticate email and software distributions;
- メールとソフトウェア配を保護して、認証するのに主として使用されるプリティ・グッド・プライバシ(PGP)とS/MIME。
- Secure Shell (SSH), used to secure remote access and file
transfer;
- 遠隔アクセスとファイル転送を保証するのに使用されるシェル(SSH)を機密保護してください。
- IPsec, a general purpose encryption and authentication mechanism
above IP that can be used by any IP application.
- どんなIPアプリケーションでも使用できるIPの上のIPsec、汎用の暗号化、および認証機構。
However, subnetwork security is also important [RFC3819] and should be encouraged, on the principle that it is better than the default situation, which all too often is no security at all. Users of especially vulnerable subnets (such as radio/broadcast networks and/or shared media Internet access) often have control over, at most, one endpoint - usually a client - and therefore cannot enforce the use of end-to-end mechanisms.
しかしながら、サブネットワークセキュリティは、また、重要であり[RFC3819]、奨励されるべきです、それがあまりにも頻繁に全くセキュリティでないデフォルト状況より良いという原則で。 特に被害を受け易いサブネット(ラジオ/放送網、そして/または、共有されたメディアインターネット・アクセスなどの)のユーザは、大部分でしばしば1つの終点(通常クライアント)を管理して、したがって、終わりから終わりへのメカニズムの使用を実施できません。
A related role for subnetwork security is to protect users against traffic analysis, i.e., identifying the communicating parties (by IP or MAC address) and determining their communication patterns, even when their actual contents are protected by strong end-to-end security mechanisms. (This is important for networks such as broadcast/radio, where eavesdropping is easy.)
すなわち、交信を特定するのはパーティーへ行きます、そして、(IPかMACアドレスで)サブネットワークセキュリティのための関連する役割がトラヒック分析に対してユーザを保護することであり、彼らのコミュニケーションを決定するのは型に基づいて作ります、彼らの実際の内容が終わりから終わりへの強いセキュリティー対策によって保護さえされるとき。(盗聴が簡単である放送/ラジオなどのネットワークに、これは重要です。)
Encryption performed at the Transport Stream (encrypting the payload of all TS-Packets with the same PID) encrypts/scrambles all parts of the SNDU, including the layer 2 MAC/NPA address. Encryption at the section level in MPE may also optionally encrypt the layer 2 MAC/NPA address in addition to the PDU data [ETSI-DAT]. In both cases, encryption of the MAC/NPA address requires a Receiver to decrypt all encrypted data, before it can then filter the PDUs with the set of
Transport Stream(同じPIDと共にすべてのTS-パケットのペイロードを暗号化する)で実行された暗号化は、SNDUのすべての部分に暗号化するか、またはスクランブルをかけります、2MAC/NPAが扱う層を含んでいて。 また、MPEのセクションレベルにおける暗号化は任意にPDUデータ[ETSI-DAT]に加えた層2のMAC/NPAアドレスを暗号化するかもしれません。 どちらの場合も、MAC/NPAアドレスの暗号化は、Receiverがそれの前の次に缶がセットがあるPDUsをフィルターにかけるすべての暗号化されたデータを解読するのを必要とします。
Montpetit, et al. Informational [Page 32] RFC 4259 IP Transport over MPEG-2 Networks November 2005
Montpetit、他 情報[32ページ]のRFC4259IP輸送はMPEG-2の上で2005年11月をネットワークでつなぎます。
MAC/NPA addresses that it wishes to receive. This method also has the drawback that all Receivers must share a common encryption key. Encryption of the MPE MAC address is therefore not permitted in some systems (e.g., [ETSI-DVBRCS]).
それが受け取りたがっているMAC/NPAアドレス。 また、このメソッドには、すべてのReceiversの必須のシェアのa一般的な暗号化が合わせる欠点があります。 したがって、MPE MACアドレスの暗号化はいくつかのシステム(例えば、[ETSI-DVBRCS])で受入れられません。
Where it is possible for an attacker to inject traffic into the subnetwork control plane, subnetwork security can additionally protect the subnetwork assets. This threat must specifically be considered for the protocols used for subnetwork control functions (e.g., address resolution, management, configuration). Possible threats include theft of service and denial of service; shared media subnets tend to be especially vulnerable to such attacks [RFC3819].
攻撃者がサブネットワーク制御飛行機にトラフィックを注ぐのが、可能であるところでは、サブネットワークセキュリティはさらに、サブネットワーク資産を保護できます。 サブネットワークコントロール機能(例えば、アドレス解決、管理、構成)に使用されるプロトコルのために明確にこの脅威を考えなければなりません。 可能な脅威はサービスの窃盗とサービスの否定を含んでいます。 共有されたメディアサブネットは、そのような攻撃[RFC3819]に特に被害を受け易い傾向があります。
Appropriate security functions must therefore be provided for IPDVB control protocols [RFC3819], particularly when the control functions are provided above the IP-layer using IP-based protocols. Internet level security mechanisms (e.g., IPsec) can mitigate such threats.
したがって、IPDVB制御プロトコル[RFC3819]に適切なセキュリティ機能を提供しなければなりません、特にIPベースのプロトコルを使用することでIP-層の上にコントロール機能を提供するとき。 インターネットレベルセキュリティー対策(例えば、IPsec)はそのような脅威を緩和できます。
In general, End-to-End security is recommended for users of any communication path, especially when it includes a wireless/radio or broadcast link, where a range of security techniques already exist. Specification of security mechanisms at the application layer, or within the MPEG-2 transmission network, are the concerns of organisations beyond the IETF. The complexity of any such security mechanisms should be considered carefully so that it will not unduly impact IP operations.
一般に、Endから終わりへのセキュリティはどんな通信路のユーザのためにも推薦されます、特にワイヤレス/ラジオか放送リンク(さまざまなセキュリティのテクニックが既に存在している)を含んでいると。 応用層における、または、MPEG-2送電網の中のセキュリティー対策の仕様はIETFを超えた機構の関心です。 どんなそのようなセキュリティー対策の複雑さも、IP操作に過度に影響を与えないように、慎重に考えられるべきです。
8.1. Link Encryption
8.1. リンク暗号化
Link level encryption of IP traffic is commonly used in broadcast/radio links to supplement End-to-End security (e.g., provided by TLS, SSH, Open PGP, S/MIME, IPsec). The encryption and key exchange methods vary significantly, depending on the intended application. For example, DVB-S/DVB-RCS operated by Access Network Operators may wish to provide their customers (Internet Service Providers, ISP) with security services. Common security services are: terminal authentication and data confidentiality (for unicast and multicast) between an encapsulation gateway and Receivers. A common objective is to provide the same level of privacy as terrestrial links. An ISP may also wish to provide end-to-end security services to the end-users (based on well-known mechanisms such as IPsec).
IPトラフィックのリンク・レベル暗号化は、Endから終わりへのセキュリティ(例えば、TLS、SSH、オープンPGP、S/MIME、IPsecが提供される)を補うのに放送/ラジオリンクで一般的に使用されます。 意図しているアプリケーションによって、暗号化と主要な交換メソッドはかなり異なります。 例えば、Access Network Operatorsによって操作されたDVB-S/DVB-RCSは彼らの顧客(インターネットサービスプロバイダ、ISP)をセキュリティー・サービスに提供したがっているかもしれません。 共通の安全保障サービスは以下の通りです。 カプセル化ゲートウェイとReceiversの間の端末の認証とデータの機密性(ユニキャストとマルチキャストのための)。 共通の目的は地球のリンクへの同じレベルのプライバシーを提供することです。 また、ISPは終わりから終わりへのエンドユーザ(IPsecなどのよく知られるメカニズムに基づいています)へのセキュリティー・サービスを提供したがっているかもしれません。
Therefore, it is important to understand that both security solutions (Access Network Operators to ISP and ISP to end-users) may coexist.
したがって、両方のセキュリティソリューション(ISPへのアクセスNetwork OperatorsとエンドユーザへのISP)が共存するかもしれないのを理解しているのは重要です。
Montpetit, et al. Informational [Page 33] RFC 4259 IP Transport over MPEG-2 Networks November 2005
Montpetit、他 情報[33ページ]のRFC4259IP輸送はMPEG-2の上で2005年11月をネットワークでつなぎます。
MPE supports optional link encryption [ETSI-DAT]. A pair of bits within the MPE protocol header indicate whether encryption (scrambling) is used. For encrypted PDUs, the header bits indicate which of a pair of previously selected encryption keys is to be used.
MPEは、任意のリンク暗号化が[ETSI-DAT]であるとサポートします。 MPEプロトコルヘッダーの中の1組のビットは、暗号化(スクランブルをかける)が使用されているかどうかを示します。 暗号化されたPDUsに関しては、ヘッダービットは、1組の以前に選択された暗号化キーのどれが使用されていることになっているかを示します。
It is recommended that any new encapsulation defined by the IETF allows Transport Stream encryption and also supports optional link level encryption/authentication of the SNDU payload. In ULE [IPDVB-ULE], this may be provided in a flexible way using Extension Headers. This requires definition of a mandatory header extension, but has the advantage that it decouples specification of the security functions from the encapsulation functions. This method also supports encryption of the NPA/MAC addresses.
IETFによって定義されたどんな新しいカプセル化も、Transport Stream暗号化を許容して、また、任意のリンク・レベルがSNDUペイロードの暗号化/認証であるとサポートするのは、お勧めです。 ウレ[IPDVB-ULE]に、Extension Headersを使用することでこれをフレキシブルな方法で提供するかもしれません。 これは、義務的なヘッダー拡大を定義に要求しますが、それが仕様の衝撃を吸収する利点を持っています。カプセル化機能からのセキュリティ機能。 また、このメソッドはNPA/MACアドレスの暗号化をサポートします。
9. IANA Considerations
9. IANA問題
A set of protocols that meet these requirements will require the IANA to make assignments. This document in itself, however, does not require any IANA involvement.
これらの必要条件を満たす1セットのプロトコルは、IANAが課題をするのを必要とするでしょう。 しかしながら、このドキュメントは本来少しのIANAかかわり合いも必要としません。
10. Acknowledgements
10. 承認
The authors wish to thank Isabel Amonou, Torsten Jaekel, Pierre Loyer, Luoma Juha-Pekka, and Rod Walsh for their detailed inputs. We also wish to acknowledge the input provided by the members of the IETF ipdvb WG.
作者は彼らの詳細な入力についてイサベルAmonou、Torsten Jaekel、ピアーLoyer、Luomaユハ-ペッカ、およびRodウォルシュに感謝したがっています。 また、IETF ipdvb WGのメンバーによって提供された入力を承諾したいと思います。
11. References
11. 参照
11.1. Normative References
11.1. 引用規格
[ISO-MPEG] ISO/IEC DIS 13818-1:2000, "Information Technology;
Generic Coding of Moving Pictures and Associated Audio
Information Systems", International Standards
Organisation (ISO).
[ISO-MPEG]ISO/IECは13818-1をけなします: 2000、「情報技術」 「映画と関連オーディオ情報システムのジェネリックコード化」、世界規格機構(ISO)。
[ETSI-DAT] EN 301 192, "Digital Video Broadcasting (DVB); DVB
Specifications for Data Broadcasting", European
Telecommunications Standards Institute (ETSI).
[ETSI-DAT] アン301 192、「(DVB)を放送するデジタルビデオ」。 ヨーロッパのテレコミュニケーション規格は、「データ・ブロードキャスティングのためのDVB仕様」と設けます(ETSI)。
11.2. Informative References
11.2. 有益な参照
[ATSC] A/53C, "ATSC Digital Television Standard", Advanced
Television Systems Committee (ATSC), Doc. A/53C, 2004.
[ATSC] Doc、「ATSCのデジタルテレビジョン標準規格」という/53Cはテレビジョン方式委員会(ATSC)を進めました。 /53C、2004。
[ATSC-DAT] A/90, "ATSC Data Broadcast Standard", Advanced
Television Systems Committee (ATSC), Doc. A/090, 2000.
[ATSC-DAT] Doc、「ATSCデータ放送規格」という/90はテレビジョン方式委員会(ATSC)を進めました。 /090、2000。
Montpetit, et al. Informational [Page 34] RFC 4259 IP Transport over MPEG-2 Networks November 2005
Montpetit、他 情報[34ページ]のRFC4259IP輸送はMPEG-2の上で2005年11月をネットワークでつなぎます。
[ATSC-DATG] A/91, "Recommended Practice: Implementation Guidelines
for the ATSC Data Broadcast Standard", Advanced
Television Systems Committee (ATSC), Doc. A/91, 2001.
[ATSC-DATG] /91、「習慣は推薦されました」。 Doc、「ATSCデータ放送規格のための実施要綱」はテレビジョン方式委員会(ATSC)を進めました。 /91、2001。
[ATSC-A92] A/92, "Delivery of IP Multicast Sessions over ATSC
Data Broadcast", Advanced Television Systems Committee
(ATSC), Doc. A/92, 2002.
[ATSC-A92] Doc、「ATSCデータの上のIPマルチキャストセッションの配送は放送した」という/92はテレビジョン方式委員会(ATSC)を進めました。 /92、2002。
[ATSC-G] A/54A, "Guide to the use of the ATSC Digital
Television Standard", Advanced Television Systems
Committee (ATSC), Doc. A/54A, 2003.
[ATSC-G] /54A、「ATSC Digital Television Standardの使用へのガイド」、Advanced Television Systems Committee(ATSC)、Doc。 /54A、2003。
[ATSC-PSIP-TC] A/65B, "Program and System Information Protocol for
Terrestrial Broadcast and Cable", Advanced Television
Systems Committee (ATSC), Doc. A/65B, 2003.
/65B、「プログラムとシステム情報は地球の放送とケーブルのために議定書を作ること」が進めた[ATSC-PSIP-Tc]テレビジョン方式委員会(ATSC)、Doc。 /65B、2003。
[ATSC-S] A/80, "Modulation and Coding Requirements for Digital
TV (DTV) Applications over Satellite", Advanced
Television Systems Committee (ATSC), Doc. A/80, 1999.
[ATSC-S] Doc、「衛星の上のデジタルテレビ(DTV)のアプリケーションのための変調とコード化要件」という/80はテレビジョン方式委員会(ATSC)を進めました。 /80、1999。
[CLC99] Clausen, H., Linder, H., and Collini-Nocker, B.,
"Internet over Broadcast Satellites", IEEE Commun.
Mag. 1999, pp.146-151.
[CLC99] クローゼン、H.、ランデール、H.、およびCollini-ノッカー、B.、「放送衛星の上のインターネット」、IEEE Commun。 雑誌。 1999、pp.146-151。
[ETSI-BSM] TS 102 292, "Satellite Earth Stations and Systems
(SES); Broadband Satellite Multimedia Services and
Architectures; Functional Architecture for IP
Interworking with BSM networks", European
Telecommunications Standards Institute (ETSI).
[ETSI-BSM]t102 292と、「衛星地上局とシステム(SES)」。 広帯域の衛星マルチメディアサービスとアーキテクチャ。 「BSMネットワークがあるIP Interworkingのための機能的なArchitecture」、ヨーロッパのTelecommunications Standards Institute(ETSI)。
[ETSI-DVBC] EN 300 800, "Digital Video Broadcasting (DVB); DVB
interaction channel for Cable TV distribution systems
(CATV)", European Telecommunications Standards
Institute (ETSI).
[ETSI-DVBC]アン300 800、「(DVB)を放送するデジタルビデオ」。 「ケーブルTV流通制度のためのDVB相互作用チャンネル(CATV)」、ヨーロッパのTelecommunications Standards Institute(ETSI)。
[ETSI-DVBRCS] EN 301 790, "Digital Video Broadcasting (DVB);
Interaction channel for satellite distribution
systems", European Telecommunications Standards
Institute (ETSI).
[ETSI-DVBRCS]アン301 790、「(DVB)を放送するデジタルビデオ」。 「衛星流通制度のための相互作用チャンネル」、ヨーロッパのTelecommunications Standards Institute(ETSI)。
[ETSI-DVBS] EN 301 421,"Digital Video Broadcasting (DVB);
Modulation and Coding for DBS satellite systems at
11/12 GHz", European Telecommunications Standards
Institute (ETSI).
[ETSI-DVBS]アン301 421、「(DVB)を放送するデジタルビデオ」。 「11/12ギガヘルツにおけるDBSサテライト・システムのための変調とCoding」、ヨーロッパのTelecommunications Standards Institute(ETSI)。
Montpetit, et al. Informational [Page 35] RFC 4259 IP Transport over MPEG-2 Networks November 2005
Montpetit、他 情報[35ページ]のRFC4259IP輸送はMPEG-2の上で2005年11月をネットワークでつなぎます。
[ETSI-DVBS2] EN 302 207, "Second generation framing structure,
channel coding and modulation systems for
Broadcasting, Interactive Services,News Gathering and
Other Broadband Satellite Applications", European
Telecommunications Standards Institute (ETSI).
[ETSI-DVBS2]EN302 207、「Broadcasting、Interactive Services、News Gathering、およびOther Broadband Satellite Applicationsの構造、チャンネル・コーディング、および変調システムを縁どる二世」、ヨーロッパのTelecommunications Standards Institute(ETSI)。
[ETSI-DVBT] EN 300 744, "Digital Video Broadcasting (DVB); Framing
structure, channel coding and modulation for digital
terrestrial television (DVB-T)", European
Telecommunications Standards Institute (ETSI).
[ETSI-DVBT]アン300 744、「(DVB)を放送するデジタルビデオ」。 「地上波デジタル・テレビジョン(DVB-T)のための構造、チャンネル・コーディング、および変調を縁どっています」、ヨーロッパのTelecommunications Standards Institute(ETSI)。
[ETSI-IPDC] "IP Datacast Specification", DVB Interim Specification
CNMS 1026 v1.0.0,(Work in Progress), April 2004.
[ETSI-IPDC]「IP Datacast仕様」、DVBの当座の仕様CNMS1026v1.0.0、(進行中の仕事)、2004年4月。
[ETSI-MHP] TS 101 812, "Digital Video Broadcasting (DVB);
Multimedia Home Platform (MHP) Specification", v1.2.1,
European Telecommunications Standards Institute
(ETSI), June 2002.
[ETSI-MHP]t101 812、「(DVB)を放送するデジタルビデオ」。 「マルチメディアホームPlatform(MHP)仕様」、v1.2.1、ヨーロッパのTelecommunications Standards Institute(ETSI)、2002年6月。
[ETSI-RC] ETS 300 802, "Digital Video Broadcasting (DVB);
Network-independent protocols for DVB interactive
services", European Telecommunications Standards
Institute (ETSI).
[ETSI-RC]ETS300 802、「(DVB)を放送するデジタルビデオ」。 「DVB双方向サービスのためのネットワークから独立しているプロトコル」、ヨーロッパのTelecommunications Standards Institute(ETSI)。
[ETSI-SI] EN 300 468, "Digital Video Broadcasting (DVB);
Specification for Service Information (SI) in DVB
systems", European Telecommunications Standards
Institute (ETSI).
[ETSI-SI] アン300 468、「(DVB)を放送するデジタルビデオ」。 「DVBシステムのService情報(SI)のための仕様」、ヨーロッパのTelecommunications Standards Institute(ETSI)。
[IPDVB-ULE] Fairhurst, G. and B. Collini-Nocker, "Unidirectional
Lightweight Encapsulation (ULE) for transmission of IP
datagrams over an MPEG-2 Transport Stream", Work in
Progress, June 2005.
[IPDVB-ULE] Progress(2005年6月)のFairhurstとG.とB.Collini-ノッカー、「MPEG-2Transport Streamの上のIPデータグラムのトランスミッションのための単方向のライト級Encapsulation(ULE)」Work。
[IPDVB-AR] Fairhurst, G. and M-J. Montpetit, "Address Resolution
for IP datagrams over MPEG-2 networks", Work in
Progress, 2005.
[IPDVB-AR] Fairhurst、G.、およびM J。 Montpetit、「MPEG-2つのネットワークの上のIPデータグラムのためのアドレスResolution」、Progress、2005のWork。
[ISO-AUD] ISO/IEC 13818-3:1995, "Information technology; Generic
coding of moving pictures and associated audio
information; Part 3: Audio", International Standards
Organisation (ISO).
[ISO-AUD] ISO/IEC13818-3:1995、「情報技術」。 映画と関連オーディオ情報のジェネリックコード化。 パート3: 「オーディオ」の、そして、国際の規格機構(ISO)。
[ISO-DSMCC] ISO/IEC IS 13818-6, "Information technology; Generic
coding of moving pictures and associated audio
information; Part 6: Extensions for DSM-CC",
International Standards Organisation (ISO).
[ISO-DSMCC]ISO/IECは13818-6、「情報技術」です。 映画と関連オーディオ情報のジェネリックコード化。 パート6: 「DSM-CCのための拡大」、世界規格機構(ISO)。
Montpetit, et al. Informational [Page 36] RFC 4259 IP Transport over MPEG-2 Networks November 2005
Montpetit、他 情報[36ページ]のRFC4259IP輸送はMPEG-2の上で2005年11月をネットワークでつなぎます。
[ISO-VID] ISO/IEC DIS 13818-2:1998, "Information technology;
Generic coding of moving pictures and associated audio
information; Video", International Standards
Organisation (ISO).
[ISO-VID] ISO/IEC DIS13818-2:1998、「情報技術」。 映画と関連オーディオ情報のジェネリックコード化。 「ビデオ」、世界規格機構(ISO)。
[ITU-AAL5] ITU-T I.363.5, "B-ISDN ATM Adaptation Layer
Specification Type AAL5", International Standards
Organisation (ISO), 1996.
[ITU-AAL5] ITU-T I.363.5、「B-ISDN気圧適合層の仕様タイプAAL5"、世界規格機構(ISO)、1996。」
[LLC] ISO/IEC 8802.2, "Information technology;
Telecommunications and information exchange between
systems; Local and metropolitan area networks;
Specific requirements; Part 2: Logical Link Control",
International Standards Organisation (ISO), 1998.
[LLC] ISO/IEC8802.2、「情報技術」。 システムの間のテレコミュニケーションと情報交換。 地方とメトロポリタンエリアネットワーク。 決められた一定の要求。 第2部: 「論理的なリンク制御」、世界規格機構(ISO)、1998。
[MMUSIC-IMG] Nomura, Y., Walsh, R., Luoma, J-P., Ott, J., and H.
Schulzrinne, "Requirements for Internet Media Guides",
Work in Progress, June 2004.
[MMUSIC-IMG]野村、Y.、ウォルシュ、R.、J-P.とオット、J.とH.Schulzrinne、「インターネットメディアガイドのための要件」というLuomaは進行中(2004年6月)で働いています。
[OPEN-CABLE] "Open Cable Application Platform Specification; OCAP
2.0 Profile", OC-SP-OCAP2.0-I01-020419, Cable Labs,
April 2002.
[開いているケーブルの] 「ケーブルアプリケーションプラットホーム仕様を開いてください」。 「OCAP2.0プロフィール」、OC-SP-OCAP2.0-I01-020419、ケーブルラボ、2002年4月。
[RFC1112] Deering, S., "Host extensions for IP multicasting",
STD 5, RFC 1112, August 1989.
[RFC1112] デアリング、S.、「IPマルチキャスティングのためのホスト拡大」、STD5、RFC1112、1989年8月。
[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP
23, RFC 2365, July 1998.
[RFC2365] マイヤー、D.、「行政上見られたIPマルチキャスト」、BCP23、RFC2365、1998年7月。
[RFC2375] Hinden, R. and S. Deering, "IPv6 Multicast Address
Assignments", RFC 2375, July 1998.
[RFC2375] HindenとR.とS.デアリング、「IPv6マルチキャストアドレス課題」、RFC2375、1998年7月。
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast
Listener Discovery (MLD) for IPv6", RFC 2710, October
1999.
[RFC2710] デアリング、S.、フェナー、W.、およびB.ハーバーマン、「IPv6"、RFC2710、1999年10月のためのマルチキャストリスナー発見(MLD)。」
[RFC2507] Degermark, M., Nordgren, B., and S. Pink, "IP Header
Compression", RFC 2507, February 1999.
[RFC2507] デーゲルマルクとM.とNordgren、B.とS.ピンク、「IPヘッダー圧縮」、RFC2507、1999年2月。
[RFC3077] Duros, E., Dabbous, W., Izumiyama, H., Fujii, N., and
Y. Zhang, "A Link-Layer Tunneling Mechanism for
Unidirectional Links", RFC 3077, March 2001.
[RFC3077] Duros、E.、Dabbous、W.、Izumiyama、H.、藤井、N.、およびY.チャン、「単方向の間のリンクレイヤトンネリングメカニズムはリンクします」、RFC3077、2001年3月。
Montpetit, et al. Informational [Page 37] RFC 4259 IP Transport over MPEG-2 Networks November 2005
Montpetit、他 情報[37ページ]のRFC4259IP輸送はMPEG-2の上で2005年11月をネットワークでつなぎます。
[RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima,
H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren,
T., Le, K., Liu, Z., Martensson, A., Miyazaki, A.,
Svanbro, K., Wiebke, T., Yoshimura, T., and H. Zheng,
"RObust Header Compression (ROHC): Framework and four
profiles: RTP, UDP, ESP, and uncompressed", RFC 3095,
July 2001.
[RFC3095] ボルマン、C.、バーマイスター、C.、デーゲルマルク、M.、福島、H.、ハンヌ、H.、イェンソン、L-E.、Hakenberg、R.、コーレン、T.、Le、K.、リュウ、Z.、Martensson、A.、宮崎、A.、Svanbro、K.、Wiebke、T.、Yoshimura、T.、およびH.ツェン、「体力を要しているヘッダー圧縮(ROHC):」 フレームワークと4個のプロフィール: 「RTP、超能力であって、解凍されたUDP」、RFC3095、7月2001日
[RFC3171] Albanna, Z., Almeroth, K., Meyer, D., and M. Schipper,
"IANA Guidelines for IPv4 Multicast Address
Assignments", BCP 51, RFC 3171, August 2001.
[RFC3171] Albanna、Z.、Almeroth、K.、マイヤー、D.、およびM.シペール、「IPv4マルチキャストのためのIANAガイドラインは課題を扱います」、BCP51、RFC3171、2001年8月。
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and
A. Thyagarajan, "Internet Group Management Protocol,
Version 3", RFC 3376, October 2002.
[RFC3376] カイン、B.とデアリングとS.とKouvelasとI.とフェナー、B.とA.Thyagarajan、「インターネット集団経営は議定書を作ります、バージョン3インチ、RFC3376、2002年10月。」
[RFC3569] Bhattacharyya, S., "An Overview of Source-Specific
Multicast (SSM)", RFC 3569, July 2003.
[RFC3569]Bhattacharyya、2003年7月のS.、「ソース特有のマルチキャスト(SSM)の概要」RFC3569。
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
そして、[RFC3810]ビーダ、R.、L.コスタ、「IPv6"、RFC3810、2004年6月のためのマルチキャストリスナー発見バージョン2(MLDv2)。」
[RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D.,
Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J.,
and L. Wood, "Advice for Internet Subnetwork
Designers", BCP 89, RFC 3819, July 2004 .
[RFC3819]KarnとP.とボルマンとC.とFairhurstとG.とグロースマンとD.とラドウィグとR.とMahdaviとJ.とモンテネグロとG.と接触、J.とL.木、「インターネットサブネットワークデザイナーのためのアドバイス」BCP89、RFC3819(2004年7月)。
Montpetit, et al. Informational [Page 38] RFC 4259 IP Transport over MPEG-2 Networks November 2005
Montpetit、他 情報[38ページ]のRFC4259IP輸送はMPEG-2の上で2005年11月をネットワークでつなぎます。
Appendix A: MPEG-2 Encapsulation Mechanisms
付録A: MPEG-2つのカプセル化メカニズム
Transmitting packet data over an MPEG-2 transmission network requires that individual PDUs (e.g., IPv4, IPv6 packets, or bridged Ethernet Frames) are encapsulated using a convergence protocol. The following encapsulations are currently standardized for MPEG-2 transmission networks:
MPEG-2送電網の上にパケットデータを送るのは、個々のPDUs(例えば、IPv4、IPv6パケット、またはブリッジしているイーサネットFrames)が集合プロトコルを使用することでカプセル化されるのを必要とします。 以下のカプセル化は現在、MPEG-2つの送電網のために標準化されます:
(i) Multi-Protocol Encapsulation (MPE).
(i) マルチプロトコルカプセル化(MPE)。
The MPE specification of DVB [ETSI-DAT] uses private
Sections for the transport of IP packets and uses
encapsulation that is similar to the IEEE LAN/MAN standards
[LLC]. Data packets are encapsulated in datagram sections
that are compliant with the DSMCC section format for private
data. Some Receivers may exploit section processing
hardware to perform a first-level filtering of the packets
that arrive at the Receiver.
DVB[ETSI-DAT]のMPE仕様は、IPパケットの輸送に私設のセクションを使用して、IEEE LAN/MAN規格[LLC]と同様のカプセル化を使用します。 データ・パケットは個人的なデータにおいて、DSMCCセクション形式で言いなりになっているデータグラム部分でカプセルに入れられます。 いくつかのReceiversが、Receiverに到着するパケットの最初に、レベルフィルタリングを実行するのにセクション処理ハードウェアを利用するかもしれません。
This encapsulation makes use of a MAC-level Network Point of
Attachment address. The address format conforms to the
ISO/IEEE standards for LAN/MAN [LLC]. The 48-bit MAC
address field contains the MAC address of the destination;
it is distributed over six 8-bit fields, labelled
MAC_address_1 to MAC_address_6. The MAC_address_1 field
contains the most significant byte of the MAC address, while
MAC_address_6 contains the least significant byte. How many
of these bytes are significant is optional and defined by
the value of the broadcast descriptor table [ETSI-DAT] sent
separately over another MPEG-2 TS within the TS multiplex.
このカプセル化はAttachmentアドレスのMAC-レベルNetwork Pointを利用します。 アドレス形式はLAN/MAN[LLC]のISO/IEEE規格に従います。 48ビットのMACアドレス・フィールドは目的地のMACアドレスを含んでいます。 それはMAC_アドレス_1からMAC_アドレス_6とラベルされた6つの8ビットの分野の上に分配されます。 MAC_アドレス_1分野はMACアドレスの最も重要なバイトを含んでいますが、MAC_アドレス_6は最も重要でないバイトを含んでいます。 これらのバイトのいくつが重要であるかは、任意であり、TSマルチプレックスの中の別のMPEG-2TSの上で別々に送られた放送記述子テーブル[ETSI-DAT]の値によって定義されます。
MPE is currently a widely deployed scheme. Due to
Investments in existing systems, usage is likely to continue
in current and future MPEG-2 Transmission Networks. ATSC
provides a scheme similar to MPE [ATSC-DAT] with some small
differences.
現在、MPEは広く配布している体系です。 既存のシステムへの投資のため、用法は現在の、そして、将来のMPEG-2Transmission Networksで継続的でありそうです。 ATSCはMPE[ATSC-DAT]と同様の体系をいくつかの小さい違いに提供します。
(ii) Data Piping.
(ii)データ配管。
The Data Piping profile [ETSI-DAT] is a minimum overhead,
simple and flexible profile that makes no assumptions
concerning the format of the data being sent. In this
profile, the Receiver is intended to provide PID filtering,
packet reassembly according to [ETSI-SI], error detection,
and optional Conditional Access (link encryption).
Data Pipingプロフィール[ETSI-DAT]は送られるデータの形式に関して仮定を全くしない最小の頭上の、そして、簡単でフレキシブルなプロフィールです。 このプロフィールでは、ReceiverがPIDフィルタリング、[ETSI-SI]に従ったパケット再アセンブリ、誤り検出、および任意のConditional Access(リンク暗号化)を提供することを意図します。
Montpetit, et al. Informational [Page 39] RFC 4259 IP Transport over MPEG-2 Networks November 2005
Montpetit、他 情報[39ページ]のRFC4259IP輸送はMPEG-2の上で2005年11月をネットワークでつなぎます。
The specification allows the user data stream to be
unstructured or organized into packets. The specific
structure is transparent to the Receiver. It may conform to
any protocol, e.g., IP, Ethernet, NFS, FDDI, MPEG-2 PES,
etc.
仕様は、ユーザデータ・ストリームが不統一であり、パケットに有機化せられるのを許容します。 特定の構造はReceiverに見え透いています。それはどんなプロトコル、例えば、IP、イーサネット、NFS、FDDI、MPEG-2PESなどにも従うかもしれません。
(iii) Data Streaming.
(iii)データストリーミング。
The data broadcast specification profile [ETSI-DAT] for PES
tunnels (Data Streaming) supports unicast and multicast data
services that require a stream-oriented delivery of data
packets. This encapsulation maps an IP packet into a single
PES Packet payload.
PESトンネル(データStreaming)のためのデータ放送仕様プロフィール[ETSI-DAT]は、ユニキャストとマルチキャストデータがデータ・パケットのストリーム指向の配送を必要とするサービスであるとサポートします。 このカプセル化はただ一つのPES PacketペイロードにIPパケットを写像します。
Two different types of PES headers can be selected via the
stream_id values [ISO-MPEG]. The private_stream_2 value
permits the use of the short PES header with limited
overhead, while the private_stream_1 value makes available
the scrambling control and the timing and clock reference
features of the PES layer.
ストリーム_イド値[ISO-MPEG]で2つの異なったタイプのPESヘッダーを選ぶことができます。 個人的な_ストリーム_2値は限られたオーバーヘッドがある脆いPESヘッダーの使用を可能にします、PES層のスクランブルをかけるコントロール、タイミング、および時計参照機能は個人的な_ストリーム_1値で利用可能になりますが。
Montpetit, et al. Informational [Page 40] RFC 4259 IP Transport over MPEG-2 Networks November 2005
Montpetit、他 情報[40ページ]のRFC4259IP輸送はMPEG-2の上で2005年11月をネットワークでつなぎます。
Authors' Addresses
作者のアドレス
Marie J. Montpetit Motorola Connected Home Solutions 45 Hayden Avenue 4th Floor Lexington MA 02130 USA
マリーJ.Montpetitモトローラのコネクテッドホーム解決45のヘイデンのアベニューの4階のレキシントンMA02130米国
EMail: mmontpetit@motorola.com
メール: mmontpetit@motorola.com
Godred Fairhurst Department of Engineering University of Aberdeen Aberdeen, AB24 3UE UK
アバディーンアバディーンのGodred Fairhurst工学部大学、AB24 3UEイギリス
EMail: gorry@erg.abdn.ac.uk Web: http://www.erg.abdn.ac.uk/users/gorry
メール: gorry@erg.abdn.ac.uk ウェブ: http://www.erg.abdn.ac.uk/users/gorry
Horst D. Clausen TIC Systems Lawrence, Kansas
地塁D.クローゼンチックSystemsローレンス(カンザス)
EMail: h.d.clausen@ieee.org
メール: h.d.clausen@ieee.org
Bernhard Collini-Nocker Department of Scientific Computing University of Salzburg Jakob Haringer Str. 2 5020 Salzburg Austria
ザルツブルグジェイコブハーリンガーStrの科学計算大学のバーンハードCollini-ノッカー部。 2 5020年のザルツブルグオーストリア
EMail: bnocker@cosy.sbg.ac.at Web: http://www.network-research.org
メール: bnocker@cosy.sbg.ac.at ウェブ: http://www.network-research.org
Hilmar Linder Department of Scientific Computing University of Salzburg Jakob Haringer Str. 2 5020 Salzburg Austria
ザルツブルグジェイコブハーリンガーStrの科学計算大学のHilmarランデール部。 2 5020年のザルツブルグオーストリア
EMail: hlinder@cosy.sbg.ac.at Web: http://www.network-research.org
メール: hlinder@cosy.sbg.ac.at ウェブ: http://www.network-research.org
Montpetit, et al. Informational [Page 41] RFC 4259 IP Transport over MPEG-2 Networks November 2005
Montpetit、他 情報[41ページ]のRFC4259IP輸送はMPEG-2の上で2005年11月をネットワークでつなぎます。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Montpetit, et al. Informational [Page 42]
Montpetit、他 情報[42ページ]
一覧
スポンサーリンク
