RFC4326 日本語訳
4326 Unidirectional Lightweight Encapsulation (ULE) for Transmissionof IP Datagrams over an MPEG-2 Transport Stream (TS). G. Fairhurst,B. Collini-Nocker. December 2005. (Format: TXT=95422 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group G. Fairhurst
Request for Comments: 4326 University of Aberdeen
Category: Standards Track B. Collini-Nocker
University of Salzburg
December 2005
Fairhurstがコメントのために要求するワーキンググループG.をネットワークでつないでください: 4326年のアバディーン大学カテゴリ: 規格は2005年12月にザルツブルグのB.Collini-ノッカー大学を追跡します。
Unidirectional Lightweight Encapsulation (ULE) for
Transmission of IP Datagrams over an MPEG-2 Transport Stream (TS)
MPEG-2輸送の流れでのIPデータグラムの送信のための単方向のライト級カプセル化(ULE)(ts)
Status of This Memo
このメモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
Abstract
要約
The MPEG-2 Transport Stream (TS) has been widely accepted not only for providing digital TV services, but also as a subnetwork technology for building IP networks.
MPEG-2Transport Stream(TS)はデジタルテレビサービスを提供すると認められただけではなく、ビルIPネットワークのためのサブネットワーク技術としても広く認められました。
This document describes a Unidirectional Lightweight Encapsulation (ULE) mechanism for the transport of IPv4 and IPv6 Datagrams and other network protocol packets directly over the ISO MPEG-2 Transport Stream as TS Private Data. ULE specifies a base encapsulation format and supports an extension format that allows it to carry additional header information to assist in network/Receiver processing.
このドキュメントは、IPv4、IPv6データグラム、および他のネットワーク・プロトコルパケットの輸送のためにISO MPEG-2Transport Streamの直接上でUnidirectionalライト級Encapsulation(ULE)メカニズムをTS兵士のDataと説明します。 ULEはベースカプセル化形式を指定して、それがネットワーク/受信機処理を助けるために追加ヘッダー情報を運ぶことができる拡大形式を支持します。
Fairhurst & Collini-Nocker Standards Track [Page 1] RFC 4326 ULE for IP over MPEG-2/DVB December 2005
FairhurstとCollini-ノッカーStandardsはMPEG-2/DVBの上の2005年12月にIPのためにRFC4326ULEを追跡します[1ページ]。
Table of Contents
目次
1. Introduction ....................................................3
2. Conventions Used in This Document ...............................4
3. Description of the Method .......................................8
4. SNDU Format .....................................................9
4.1. Destination Address Absent (D) Field ......................10
4.2. Length Field ..............................................10
4.3. End Indicator .............................................10
4.4. Type Field ................................................10
4.4.1. Type 1: Next-Header Type Fields ....................11
4.4.2. Type 2: EtherType Compatible Type Fields ...........11
4.5. SNDU Destination Address Field ............................12
4.6. SNDU Trailer CRC ..........................................12
4.7. Description of SNDU Formats ...............................13
4.7.1. End Indicator ......................................14
4.7.2. IPv4 SNDU Encapsulation ............................14
4.7.3. IPv6 SNDU Encapsulation ............................15
5. Extension Headers ..............................................16
5.1. Test SNDU .................................................18
5.2. Bridged Frame SNDU Encapsulation ..........................18
5.3. Extension-Padding Optional Extension Header ...............21
6. Processing at the Encapsulator .................................22
6.1. SNDU Encapsulation ........................................22
6.2. Procedure for Padding and Packing .........................24
7. Receiver Processing ............................................25
7.1. Idle State ................................................26
7.1.1. Idle State Payload Pointer Checking ................26
7.2. Processing of a Received SNDU .............................26
7.2.1. Reassembly Payload Pointer Checking ................28
7.3. Other Error Conditions ....................................28
8. Summary ........................................................29
9. Acknowledgements ...............................................29
10. Security Considerations .......................................29
11. IANA Considerations ...........................................30
11.1. IANA Guidelines ..........................................30
12. References ....................................................31
12.1. Normative References .....................................31
12.2. Informative References ...................................32
Appendix A. SNDU Packing Examples .................................35
Appendix B. SNDU Encapsulation ....................................40
1. 序論…3 2. このドキュメントで中古のコンベンション…4 3. 方法の記述…8 4. SNDU形式…9 4.1. (D) 分野のない送付先アドレス…10 4.2. 長さの分野…10 4.3. インディケータを終わらせてください…10 4.4. 分野をタイプしてください…10 4.4.1. タイプ1: 次のヘッダータイプ分野…11 4.4.2. 2はタイプします: コンパチブルEtherTypeは分野をタイプします…11 4.5. SNDU目的地アドレス・フィールド…12 4.6. SNDUトレーラCRC…12 4.7. SNDU形式の記述…13 4.7.1. インディケータを終わらせてください…14 4.7.2. IPv4 SNDUカプセル化…14 4.7.3. IPv6 SNDUカプセル化…15 5. 拡大ヘッダー…16 5.1. SNDUをテストしてください…18 5.2. フレームSNDUカプセル化に橋を架けます…18 5.3. 拡大をそっと歩く任意の拡張ヘッダー…21 6. Encapsulatorでの処理…22 6.1. SNDUカプセル化…22 6.2. 詰め物のための手順とパッキング…24 7. 受信機処理…25 7.1. 状態を空費してください…26 7.1.1. 州の有効搭載量ポインタの照合を空費してください…26 7.2. 容認されたSNDUの処理…26 7.2.1. Reassembly有効搭載量ポインタの照合…28 7.3. 他のエラー条件…28 8. 概要…29 9. 承認…29 10. セキュリティ問題…29 11. IANA問題…30 11.1. IANAガイドライン…30 12. 参照…31 12.1. 標準の参照…31 12.2. 有益な参照…32 例を梱包する付録A.SNDU…35 付録B.SNDUカプセル化…40
Fairhurst & Collini-Nocker Standards Track [Page 2] RFC 4326 ULE for IP over MPEG-2/DVB December 2005
FairhurstとCollini-ノッカーStandardsはMPEG-2/DVBの上の2005年12月にIPのためにRFC4326ULEを追跡します[2ページ]。
1. Introduction
1. 序論
This document describes an encapsulation for the transport of IP datagrams, or other network-layer packets, over ISO MPEG-2 Transport Streams [ISO-MPEG2, RFC4259]. The encapsulation satisfies the requirement for a lightweight encapsulation defined in section 4 of [RFC4259]. The basic header provides the required set of protocol fields. Extension headers may also be defined. This header structure is significantly simpler to parse and process [SOOR05] than current alternative methods (e.g., MPE [ETSI-DAT], which builds upon the DSM-CC Table Section syntax [ISO-DSMCC]).
このドキュメントはIPデータグラム、または他のネットワーク層パケットの輸送のためにカプセル化について説明します、ISO MPEG-2Transport Streams[ISO-MPEG2、RFC4259]の上で。 カプセル化は[RFC4259]のセクション4で定義された軽量のカプセル化のための要件を満たします。 基本的なヘッダーは必要なセットのプロトコル野原を供給します。 また、拡張ヘッダーは定義されるかもしれません。 このヘッダー構造は分析して、処理するのは現在の別法(例えば、DSM-CC Tableセクション構文[ISO-DSMCC]を当てにするMPE[ETSI-DAT])よりかなり簡単です[SOOR05]。
The encapsulation is suited to 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 provide unidirectional (simplex) physical and link-layer standards. Support has been defined for a wide range of physical media (e.g., Terrestrial TV [ETSI-DVBT, ATSC-PSIP-TC], Satellite TV [ETSI-DVBS, ATSC-S], and Cable Transmission [ETSI-DVBC, ATSC-PSIP-TC]). Bi-directional (duplex) links may also be established using these standards (e.g., DVB defines a range of return channel technologies, including the use of two-way satellite links [ETSI-RCS]) and dial-up modem links [RFC3077].
カプセル化はMPEG-2に基づくサービスに合っています。 例えば、Advanced Television Systems Committee(ATSC)システム[ATSC、ATSC-G]の、そして、もう一方同様のDigital Video Broadcast(DVB)構造、MPEG2ベース、伝動装置そのようなシステムは単方向(シンプレクス)に物理的、そして、リンクレイヤ規格を提供します。 サポートはさまざまな物理的なメディア(例えば、Terrestrialテレビ[ETSI-DVBT、ATSC-PSIP-TC]、Satelliteテレビ[ETSI-DVBS、ATSC-S]、およびCable Transmission[ETSI-DVBC、ATSC-PSIP-TC])のために定義されました。 また、双方向(重複の)のリンクは、これらの規格(例えば、DVBはさまざまな帰路チャンネル技術を定義します、両用衛星中継[ETSI-RCS]の使用を含んでいて)とダイヤルアップモデムリンク[RFC3077]を使用することで設立されるかもしれません。
Protocol Data Units (PDUs), such as Ethernet Frames, IP datagrams, or other network-layer packets, used for transmission over an MPEG-2 Transport Multiplex are passed to an Encapsulator. This formats each PDU into a SubNetwork Data Unit (SNDU) by adding an encapsulation header and an integrity check trailer. The SNDU is fragmented into a series of one or more MPEG-2 Transport Stream (TS) Packets that are sent over a single TS Logical Channel.
Frames、IPデータグラム、または他のネットワーク層パケットがMPEG-2Transport Multiplexの上のトランスミッションに使用したイーサネットなどのプロトコルData Units(PDUs)はEncapsulatorに渡されます。 これは、カプセル化ヘッダーと保全チェックトレーラを加えることによって、SubNetwork Data Unit(SNDU)に各PDUをフォーマットします。 SNDUは独身のTS Logical Channelの上に送られる一連の1つ以上のMPEG-2Transport Stream(TS)パケットに断片化されます。
The MPEG-2 specification [ISO-MPEG2] requires that conformant TS Multiplexes provide Program Specific Information (PSI) for each stream in the TS Multiplex. Other MPEG-2-based transmission standards may also define Service Information (SI).
MPEG-2仕様[ISO-MPEG2]は、conformant TS MultiplexesがProgram Specific情報(PSI)をTS Multiplexの各流れに提供するのを必要とします。 他、MPEG2ベース、また、伝送規格はService情報(SI)を定義するかもしれません。
A format_identifier value has been registered for ULE [ULE1]. This 32 bit number has a hexadecimal value of 0x554C4531. Transport Streams that utilise the Programme Map Table (PMT) defined in ISO 13818-1 [ISO-MPEG2] and that use the ULE format defined in this document, SHOULD insert a descriptor with this value in the PMT ES_info descriptor loop. ULE Streams may also be identified by the stream_type value of 0x91 [ATSC-REG] in a SI/PSI Table [ISO_MPEG2].
形式_識別子値はULE[ULE1]のために示されました。 この32ビットの数には、0x554C4531の16進値があります。 ISO13818-1[ISO-MPEG2]で定義されたProgramme Map Table(PMT)を利用して、本書では定義されたULE書式を使用する輸送Streams、この値がPMT ES_インフォメーション記述子輪にある状態で、SHOULDは記述子を挿入します。 また、ULE StreamsはSI/PSI Table[ISO_MPEG2]の0×91[ATSC-REG]の流れ_タイプ値によって特定されるかもしれません。
This information may allow Receivers and Re-multiplexors [RFC4259] to locate a specific ULE Stream (i.e., the PID value of the TS Logical
ReceiversとRe-マルチプレクサー[RFC4259]がこの情報で特定のULE Streamの場所を見つけることができるかもしれない、(すなわち、TS LogicalのPID値
Fairhurst & Collini-Nocker Standards Track [Page 3] RFC 4326 ULE for IP over MPEG-2/DVB December 2005
FairhurstとCollini-ノッカーStandardsはMPEG-2/DVBの上の2005年12月にIPのためにRFC4326ULEを追跡します[3ページ]。
Channel that carries a ULE Stream). The conditions under which this information is required and the format in which it is to be provided are beyond the scope of this document. Addressing and mapping issues for ULE over MPEG-2 are also described in [IPDVB-AR].
ULE Streamを運ぶチャンネル) この情報が必要である状態とそれが提供されることになっている形式はこのドキュメントの範囲を超えています。 ULEのために問題を記述して、写像して、また、MPEG-2以上は[IPDVB-AR]で説明されます。
2. Conventions Used in This Document
2. 本書では使用されるコンベンション
The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
大文字で書かれたキーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
Other terms used in this document are defined below:
本書では使用される他の用語は以下で定義されます:
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-MPEG2].
適合分野: 時計参照、タイミング、および同期情報を伝えることを意図して、MPEG-2Multiplexの上で[ISO-MPEG2]を詰める固定長TS Packetヘッダーの任意の可変長の拡大分野。
AFC: Adaptation Field Control [ISO-MPEG2]. A pair of bits carried in the TS Packet header that signal the presence of the Adaptation Field and/or TS Packet payload.
AFC: 適合フィールド制御[ISO-MPEG2]。 1組のビットはAdaptation Field、そして/または、TS Packetペイロードの存在に合図する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.
ATSC: 高品位テレビシステム委員会[ATSC]。 枠組みとISO MPEG-2規格を使用するビデオ、オーディオ、およびデータの伝達のための1セットの関連規格。
b: bit. For example, one byte consists of 8b.
b: ビット。 例えば、1バイトは8bから成ります。
B: Byte. Groups of bytes are represented in Internet byte order.
B: バイト。 バイトのグループはインターネットバイトオーダーで代表されます。
DSM-CC: Digital Storage Media Command and Control [ISO-DSMCC]. A format for transmission of data and control information in an MPEG-2 Private Section, defined by the ISO MPEG-2 standard.
DSM-CC: デジタル蓄積メディアは、[ISO-DSMCC]を命令して、制御します。 データの伝達のための形式とISO MPEG-2規格によって定義されたMPEG-2兵士のセクションの制御情報。
DVB: Digital Video Broadcast. A framework and set of associated standards published by the European Telecommunications Standards Institute (ETSI) (e.g., [ETSI-DVBC, ETSI-DVBS, ETSI-DVBT]) for the transmission of video, audio, and data using the ISO MPEG-2 Standard [ISO-MPEG2].
DVB: デジタルビデオは放送されました。 ヨーロッパのTelecommunications Standards Institute(ETSI)(例えば、[ETSI-DVBC、ETSI-DVBS、ETSI-DVBT])によって関連規格の枠組みとセットは、ビデオ、オーディオ、およびデータの伝達のためにISO MPEG-2Standard[ISO-MPEG2]を使用することで発行されました。
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を受けて、これらをフォーマットするネットワーク装置。
End Indicator: A value that indicates to the Receiver that there are no further SNDUs present within the current TS Packet.
インディケータを終わらせてください: 現在のTS Packetの中の現在のSNDUsがこれ以上ないのをReceiverに示す値。
Fairhurst & Collini-Nocker Standards Track [Page 4] RFC 4326 ULE for IP over MPEG-2/DVB December 2005
FairhurstとCollini-ノッカーStandardsはMPEG-2/DVBの上の2005年12月にIPのためにRFC4326ULEを追跡します[4ページ]。
LLC: Logical Link Control [ISO-8802-2, IEEE-802.2]. A link-layer protocol defined by the IEEE 802 standard, which follows the Ethernet MAC Header.
LLC: 論理的なリンク制御[ISO-8802-2、IEEE-802.2]。 イーサネットMAC Headerに続くIEEE802規格によって定義されたリンク層プロトコル。
MAC: Medium Access Control [IEEE-802.3]. A link-layer protocol defined by the IEEE 802.3 standard (or by Ethernet v2 [DIX]).
Mac: 媒体アクセス制御[IEEE-802.3]。 IEEE802.3規格(またはイーサネットv2[DIX])によって定義されたリンク層プロトコル。
MAC Header: The link-layer header of the IEEE 802.3 standard [IEEE-802.3] or Ethernet v2 [DIX]. It consists of a 6B destination address, 6B source address, and 2B Type field (see also NPA, LLC).
MACヘッダー: IEEE802.3規格[IEEE-802.3]かイーサネットv2[DIX]のリンクレイヤヘッダー。 それは6B送付先アドレス、6Bソースアドレス、および2B Type分野から成ります(また、NPA、LLCを見てください)。
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/IEC 13818-1) [ISO-MPEG2], and ITU-T (in H.222 [ITU-H222]).
MPEG-2: エムペグ(MPEG)によって指定されて、国際Standards Organisation(ISO/IEC13818-1)[ISO-MPEG2]、およびITU-T(H.222[ITU-H222]の)によって標準化された1セットの規格。
Next-Header: A Type value indicating an Extension Header.
次のヘッダー: Extension Headerを示すType値。
NPA: Network Point of Attachment. In this document, refers to a 6-byte destination address (resembling an IEEE MAC address) within the MPEG-2 transmission network that is used to identify individual Receivers or groups of Receivers.
NPA: 接着点をネットワークでつないでください。 本書では、6バイトの送付先アドレス(IEEE MACアドレスに類似している)はReceiversの個々のReceiversかグループを特定するのに使用されるMPEG-2送電網の中で言及します。
Packing Threshold: A period of time an Encapsulator is willing to defer transmission of a partially filled TS-Packet to accumulate more SNDUs, rather than use Padding. After the Packet Threshold period, the Encapsulator uses Padding to send the partially filled TS-Packet.
パッキング敷居: EncapsulatorがPaddingを使用するよりむしろさらに多くのSNDUsを蓄積するために部分的にいっぱいにされたTS-パケットのトランスミッションを延期しても構わないと思う期間。 Packet Thresholdの期間の後に、Encapsulatorは、部分的にいっぱいにされたTS-パケットを送るのにPaddingを使用します。
Padding: A method that fills the remaining unused bytes in a TS Packet payload using the specific pattern of 0xFF.
詰め物: 0xFFの特定のパターンを使用することでTS Packetペイロードの残っている未使用のバイトをいっぱいにする方法。
Payload Unit, PU. 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をテーブルの上に置きます。
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 Steam [ISO-MPEG2]. A format of MPEG-2 TS packet payload usually used for video or audio information.
PES: 基本の蒸気[ISO-MPEG2]をPacketizedしました。 通常、ビデオに使用されるMPEG-2TSパケットペイロードかオーディオ情報の形式。
PID: Packet Identifier [ISO-MPEG2]. A 13-bit field carried in the header of TS Packets. This is used to identify the TS Logical Channel to which a TS Packet belongs [ISO-MPEG2]. The TS Packets
PID: パケット識別子[ISO-MPEG2]。 13ビットの野原はTS Packetsのヘッダーで運ばれました。 これは、TS Packetが属するTS Logical Channel[ISO-MPEG2]を特定するのに使用されます。 tパケット
Fairhurst & Collini-Nocker Standards Track [Page 5] RFC 4326 ULE for IP over MPEG-2/DVB December 2005
FairhurstとCollini-ノッカーStandardsはMPEG-2/DVBの上の2005年12月にIPのためにRFC4326ULEを追跡します[5ページ]。
forming the parts of a Table Section, PES, or other Payload Unit must all carry the same PID value. The all-zeros PID 0x0000 as well as other PID values are reserved for specific PSI/SI Tables [ISO-MPEG2]. The all-ones PID value 0x1FFF 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.
Tableセクション、PES、または他の有効搭載量Unitの部分を形成すると、同じPID値はすべて運ばれなければなりません。 他のPID値と同様にオールゼロPID0x0000は特定のPSI/SI Tables[ISO-MPEG2]のために予約されます。 オールものPIDの値の0x1FFFはTS Multiplexの固定ビットレートを維持するために導入されたNull TS Packetを示します。 異なったTS Multiplexesを使用することで伝えられたTS Logical Channelsに使用されるPID値の間のどんな必要な関係もありません。
PP: Payload Pointer [ISO-MPEG2]. An optional one-byte pointer that directly follows the 4-byte TS Packet header. It contains the number of bytes that follow the Payload Pointer, up to the start of the first Payload Unit (counted from the first byte of the TS Packet payload field, and excluding the PP field itself). 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, Table Sections, and ULE. It is not present in TS Logical Channels that use the PES-format.
pp: 有効搭載量ポインタ[ISO-MPEG2]。 直接4バイトのTS Packetヘッダーに続く任意の1バイトのポインタ。 それは有効搭載量Pointerに続くバイト数を含んでいます、最初の有効搭載量Unit(TS Packetペイロード分野と、PP分野自体を除く最初のバイトから、数える)の始まりまで。 有効搭載量Pointerの存在はTS PacketヘッダーのPUSIビットの価値によって示されます。 有効搭載量PointerはDSM-CC、Tableセクション、およびULEに存在しています。 それはPES-形式を使用するTS Logical Channelsに存在していません。
Private Section: A syntactic structure constructed in accordance with Table 2-30 of [ISO-MPEG2]. The structure may be used to identify private information (i.e., not defined by [ISO-MPEG2]) relating to one or more elementary streams, or a specific MPEG-2 program, or the entire Transport Stream. Other Standards bodies, e.g., ETSI, ATSC, have defined sets of table structures using the private_section structure. A Private Section is transmitted as a sequence of TS Packets using a TS Logical Channel. A TS Logical Channel may carry sections from more than one set of tables.
私設のセクション: [ISO-MPEG2]のTable2-30によると、構成された統語構造。 構造は、1つ以上の基本の流れ、特定のMPEG-2プログラム、または全体のTransport Streamに関連しながら個人情報(すなわち、[ISO-MPEG2]が定義されない)を特定するのに使用されるかもしれません。 他のStandardsボディー(例えば、ETSI、ATSC)は、個人的な_セクション構造を使用することでテーブル構造のセットを定義しました。 兵士のセクションは、TS Packetsの系列としてTS Logical Channelを使用することで伝えられます。 TS Logical Channelは1セット以上のテーブルからセクションを運ぶかもしれません。
PSI: Program Specific Information [ISO-MPEG2]. Tables used to convey information about the service carried in a TS Multiplex. The information is carried in one of four specifically identified Table Sections defined by MPEG-2 [ISO-MPEG2]. See also SI Table.
psi: 特殊情報[ISO-MPEG2]をプログラムしてください。 テーブルは以前はよくTS Multiplexで提供されたサービスに関して情報を伝達していました。 情報はMPEG-2[ISO-MPEG2]によって定義された4つの明確に特定されたTableセクションの1つで運ばれます。 また、SI Tableを見てください。
PU: Payload Unit.
Pu: 有効搭載量単位。
PUSI: Payload_Unit_Start_Indicator [ISO-MPEG2]. 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-MPEG2]を始めます。 単一のビット旗はTS Packetヘッダーで運ばれました。 ゼロのPUSI値は、TS Packetが新しい有効搭載量Unitの始まりを運ばないのを示します。 1のPUSI値は、TS Packetが新しい有効搭載量Unitの始まりを運ぶのを示します。 また、ULEでは、1に設定されたPUSIビットは1バイトの有効搭載量Pointer(PP)の存在を示します。
Receiver: Equipment that processes the signal from a TS Multiplex and performs filtering and forwarding of encapsulated PDUs to the network-layer service (or bridging module when operating at the link layer).
受信機: それがTS Multiplexから信号を処理して、フィルタリングと推進を実行する設備はネットワーク層サービスにPDUsを要約しました(リンクレイヤで作動するとき、モジュールに橋を架けて)。
Fairhurst & Collini-Nocker Standards Track [Page 6] RFC 4326 ULE for IP over MPEG-2/DVB December 2005
FairhurstとCollini-ノッカーStandardsはMPEG-2/DVBの上の2005年12月にIPのためにRFC4326ULEを追跡します[6ページ]。
SI Table: Service Information Table [ISO-MPEG2]. In this document, this term describes a table that is defined by another standards body to convey information about the services carried in a TS Multiplex. A Table may consist of one or more Table Sections; however, all sections of a particular SI Table must be carried over a single TS Logical Channel [ISO-MPEG2].
SIテーブル: 情報テーブル[ISO-MPEG2]を調整してください。 本書では、今期は別の標準化団体によって定義される、TS Multiplexで提供されたサービスに関して情報を伝達するテーブルについて説明します。 Tableは1つ以上のTableセクションから成るかもしれません。 しかしながら、独身のTS Logical Channel[ISO-MPEG2]の上まで特定のSI Tableのすべてのセクションを運ばなければなりません。
SNDU: SubNetwork Data Unit. An encapsulated PDU sent as an MPEG-2 Payload Unit.
SNDU: サブネットワークデータ単位。 要約のPDUはMPEG-2有効搭載量Unitとして発信しました。
Table Section: A Payload Unit carrying all or part of an SI or PSI Table [ISO-MPEG2].
セクションをテーブルの上に置いてください: すべてを運ぶ有効搭載量UnitかSIかPSI Table[ISO-MPEG2]の一部。
TS: Transport Stream [ISO-MPEG2], a method of transmission at the MPEG-2 level using TS Packets; it represents layer 2 of the ISO/OSI reference model. See also TS Logical Channel and TS Multiplex.
t: MPEG-2レベルにおけるトランスミッションの方法がTS Packetsを使用して、Stream[ISO-MPEG2]を輸送してください。 それはISO/OSI参照モデルの層2を表します。 また、TS Logical ChannelとTS Multiplexを見てください。
TS Header: The 4-byte header of a TS Packet [ISO-MPEG2]. Each 188B TS Packet incorporates a 4B header with the following fields (those referenced within this document are marked with *):
tヘッダー: TS Packet[ISO-MPEG2]の4バイトのヘッダー。 各188B TS Packetは以下の分野がある4Bヘッダーを組み込みます(このドキュメントの中に参照をつけられたそれらは*でマークされます):
Field Length Name/Purpose
(in bits)
フィールド長名前/目的(ビットの)
8b Synchronisation pattern equal to 0x47
*1b Transport Error Indicator
*1b Payload Unit Start Indicator (PUSI)
1b Transport Priority
*13b Packet IDentifier (PID)
2b Transport Scrambling Control
*2b Adaptation Field Control (AFC)
*4b Continuity Counter (CC)
0×47*1b Transport Error Indicator*1b有効搭載量Unit Start Indicator(PUSI)1b Transport Priority*13b Packet IDentifier(PID)2b Transport Scrambling Control*2b Adaptation Field Control(AFC)*4b Continuity Counterと等しい8b連動パターン(CC)
If the PUSI bit is set to a value of 1, there is one additional field following the TS packet header:
PUSIビットが1の値に設定されるなら、TSパケットのヘッダーに続く1つの追加分野があります:
*8b Payload Pointer (PP)
*8b有効搭載量ポインタ(pp)
TS Logical Channel: Transport Stream Logical Channel. In this document, this term identifies a channel at the MPEG-2 level [ISO-MPEG2]. 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). The term "Stream" is defined in MPEG-2 [ISO-MPEG2] to describe the content carried by a specific TS Logical Channel (see ULE Stream). Some PID values are reserved (by MPEG-2) for specific signalling. Other standards (e.g., ATSC, DVB) also reserve specific PID values.
t論理チャネル: 流れの論理チャネルを輸送してください。 本書では、今期はMPEG-2レベル[ISO-MPEG2]でチャンネルを特定します。 それはISO/OSI参照モデルのレベル2で存在しています。 TS Logical Channelの上に送られたすべてのパケットが同じPID値を運びます(この値は特定のTS Multiplexの中でユニークです)。 「流れ」という用語は、特定のTS Logical Channelによって運ばれた内容について説明するためにMPEG-2[ISO-MPEG2]で定義されます(ULE Streamを見てください)。 いくつかのPID値が特定の合図のために予約されます(MPEG-2つ)。 また、他の規格(例えば、ATSC、DVB)は特定のPID値を予約します。
Fairhurst & Collini-Nocker Standards Track [Page 7] RFC 4326 ULE for IP over MPEG-2/DVB December 2005
FairhurstとCollini-ノッカーStandardsはMPEG-2/DVBの上の2005年12月にIPのためにRFC4326ULEを追跡します[7ページ]。
TS Multiplex: In this document, this term defines a set of MPEG-2 TS Logical Channels sent over a single lower-layer connection. This may be a common physical link (i.e., a transmission at a specified symbol rate, FEC setting, and transmission frequency) or an encapsulation provided by another protocol layer (e.g., Ethernet, or RTP over IP). The same TS Logical Channel may be repeated over more than one TS Multiplex (possibly associated with a different PID value) [RFC4259]; for example, to redistribute the same multicast content to two terrestrial TV transmission cells.
tは多重送信されます: 本書では、今期は単独の下層接続の上に送られたMPEG-2TS Logical Channelsの1セットを定義します。 これは、一般的な物理的なリンク(すなわち、指定されたシンボルレート、FEC設定、および伝染率でのトランスミッション)か別のプロトコル層で提供されたカプセル化であるかもしれません(例えば、イーサネット、またはIPの上のRTP)。 同じTS Logical Channelは1TS Multiplex(ことによると異なったPID値に関連している)[RFC4259]の上で繰り返されるかもしれません。 例えば2つの地球のテレビのトランスミッションセルに同じマルチキャスト内容を再配付するために。
TS Packet: A fixed-length 188B unit of data sent over a TS Multiplex [ISO-MPEG2]. Each TS Packet carries a 4B header, plus optional overhead including an Adaptation Field, encryption details, and time stamp information to synchronise a set of related TS Logical Channels.
tパケット: データの固定長188B単位はTS Multiplex[ISO-MPEG2]を移動しました。 各TS Packetは4Bヘッダー、および関連するTS Logical Channelsがa設定していた状態で連動するようにAdaptation Field、暗号化の詳細、およびタイムスタンプ情報を含む任意のオーバーヘッドを運びます。
ULE Stream: An MPEG-2 TS Logical Channel that carries only ULE encapsulated PDUs. ULE Streams may be identified by definition of a stream_type in SI/PSI [ISO-MPEG2].
ULEは流れます: ULEだけを運ぶMPEG-2TS Logical ChannelはPDUsを要約しました。 ULE Streamsは定義上SI/PSI[ISO-MPEG2]の流れ_タイプに特定されるかもしれません。
3. Description of the Method
3. 方法の記述
PDUs (IP packets, Ethernet frames or packets from other network protocols) are encapsulated to form a Subnetwork Data Unit (SNDU). The SNDU is transmitted over an MPEG-2 transmission network either by being placed in the payload of a single TS Packet, or, if required, by being fragmented into a series of TS Packets. Where there is sufficient space, the method permits a single TS Packet to carry more than one SNDU (or part thereof), a practice sometimes known as Packing. All TS Packets comprising an SNDU MUST be assigned the same PID, and therefore form a part of the same TS Logical Channel.
PDUs(他のネットワーク・プロトコルからのIPパケット、イーサネットフレームまたはパケット)は、Subnetwork Data Unit(SNDU)を形成するために要約されます。 SNDUは、独身のTS Packetのペイロードに置かれるか、または必要なら、一連のTS Packetsに断片化されることによって、MPEG-2送電網の上に伝えられます。 十分なスペースがあるところでは、方法は、独身のTS Packetが1SNDU(または、それの部分)(Packingとして時々知られている習慣)を運ぶことを許可します。 SNDU MUSTを包括するすべてのTS Packetsが同じPIDが割り当てられて、したがって、同じTS Logical Channelの一部を形成します。
The ULE encapsulation is limited to TS private streams only. The header of each TS Packet carries a one-bit Payload Unit Start Indicator (PUSI) field. A PUSI field with a value of 1 indicates the start of at least one Payload Unit (SNDU) within the TS Packet payload. The semantics of the PUSI bit are defined for PES and PSI packets [ISO-MPEG2]; for private data, its use is not defined in the MPEG-2 Standard. Although ULE uses private data, the operation follows that of PSI packets. Hence, the following PUSI values are defined:
ULEカプセル化はTS陰流だけに制限されます。 それぞれのTS Packetのヘッダーは1ビットの有効搭載量Unit Start Indicator(PUSI)野原を運びます。 1の値があるPUSI分野はTS Packetペイロードの中に少なくとも1有効搭載量Unitの始まり(SNDU)を示します。 PUSIビットの意味論はPESとPSIパケット[ISO-MPEG2]のために定義されます。 個人的なデータに関しては、使用はMPEG-2Standardで定義されません。 ULEは個人的なデータを使用しますが、操作はPSIパケットのものに続きます。 したがって、以下のPUSI値は定義されます:
0: The TS Packet does NOT contain the start of an SNDU, but
contains the continuation, or end, of an SNDU;
0: SNDUでTS PacketがSNDUの始まりを含んでいませんが、継続を含むか、または終わってください。
1: The TS Packet contains the start of an SNDU, and a one byte
Payload Pointer follows the last byte of the TS Packet header.
1: TS PacketはSNDUの始まりを含んでいます、そして、1バイトの有効搭載量PointerはTS Packetヘッダーの最後のバイトに続きます。
Fairhurst & Collini-Nocker Standards Track [Page 8] RFC 4326 ULE for IP over MPEG-2/DVB December 2005
FairhurstとCollini-ノッカーStandardsはMPEG-2/DVBの上の2005年12月にIPのためにRFC4326ULEを追跡します[8ページ]。
If a Payload Unit (SNDU) finishes before the end of a TS Packet payload, but it is not intended to start another Payload Unit, a stuffing procedure (known as Padding) fills the remainder of the TS Packet payload with bytes with a value 0xFF [ISO-MPEG2].
有効搭載量Unit(SNDU)がTS Packetペイロードの端までに終わりますが、別の有効搭載量Unitを始動することを意図しないなら、詰め物の手順(Paddingとして、知られている)は値の0xFF[ISO-MPEG2]と共にバイトでTS Packetペイロードの残りを満たします。
A Receiver processing MPEG-2 Table Sections that receives a value of 0xFF in the first byte of a Table Section (table_Id) interprets this as Padding/Stuffing and silently discards the remainder of the TS Packet payload. The payload of the next TS Packet for the same TS Logical Channel will begin with a Payload Pointer of value 0x00, indicating that the next Payload Unit immediately follows the TS Packet header. The ULE protocol resembles this, but differs in the exact procedure (see the following sections).
Tableセクション(テーブル_Id)の最初のバイトにおける、0xFFの値を受けるMPEG-2つのTableセクションを処理するReceiverはこれがPadding/物質であると解釈して、静かにTS Packetペイロードの残りを捨てます。 同じTS Logical Channelのための次のTS Packetのペイロードは価値0x00の有効搭載量Pointerと共に始まるでしょう、次の有効搭載量UnitがすぐにTS Packetヘッダーに続くのを示して。 ULEプロトコルは、正確な手順においてこれに類似していますが、異なります(以下のセクションを見てください)。
The TS Packet Header also carries a two-bit Adaptation Field Control (AFC) value. This adaptation field may extend the TS Packet Header to carry timing and synchronisation information and may also be used to include stuffing bytes before a TS Packet payload. Adaptation Field stuffing is NOT used in this encapsulation method, and TS Packets from a ULE Encapsulator MUST be sent with an AFC value of '01'. For TS Logical Channels supporting ULE, Receivers MUST discard TS Packets that carry other AFC values.
また、TS Packet Headerは安っぽいAdaptation Field Control(AFC)値を運びます。 この適合分野は、タイミングと連動情報を運ぶためにTS Packet Headerを広げていて、また、TS Packetペイロードのバイト前で詰めるのを含むのに使用されるかもしれません。 このカプセル化方法で適合Field詰め物を使用しません、そして、'01'のAFC値と共にULE EncapsulatorからのTS Packetsを送らなければなりません。 ULEを支持するTS Logical Channelsに関しては、Receiversは他のAFC値を運ぶTS Packetsを捨てなければなりません。
4. SNDU Format
4. SNDU形式
PDUs are encapsulated using ULE to form an SNDU. (Each SNDU is an MPEG-2 Payload Unit.) The encapsulation format to be used for PDUs is illustrated below:
PDUsは、SNDUを形成するのにULEを使用することで要約されます。 (各SNDUはMPEG-2有効搭載量Unitです。) PDUsに使用されるべきカプセル化形式は以下で例証されます:
< ----------------------------- SNDU ----------------------------- > +-+-------------------------------------------------------+--------+ |D| Length | Type | Dest Address* | PDU | CRC-32 | +-+-------------------------------------------------------+--------+
<。----------------------------- SNDU----------------------------- >++-------------------------------------------------------+--------+ |D| 長さ| タイプ| Destアドレス*| PDU| CRC-32| +-+-------------------------------------------------------+--------+
Figure 1: SNDU Encapsulation (* optional Destination Address)
図1: SNDUカプセル化(*任意のDestination Address)
All multi-byte values in ULE (including the Length/End Indicator (4.2,4.3), Type (4.4), Destination Address (4.5), and Extension Headers (5)) are transmitted in network byte order (most significant byte first). The most significant bit of each byte is placed in the left-most position of the 8-bit field. Appendix A provides informative examples of usage.
すべてのマルチバイトがULEで評価する、(Indicator(4.2、4.3)、Type(4.4)、Destination Address(4.5)、およびExtension Headers(5))がネットワークバイトオーダーで伝えられるLength/終わりを含んでいる、(最も重要なバイト、1番目) それぞれのバイトの最も重要なビットは8ビットの分野の最も左の位置に置かれます。 付録Aは用法の有益な例を提供します。
Fairhurst & Collini-Nocker Standards Track [Page 9] RFC 4326 ULE for IP over MPEG-2/DVB December 2005
FairhurstとCollini-ノッカーStandardsはMPEG-2/DVBの上の2005年12月にIPのためにRFC4326ULEを追跡します[9ページ]。
4.1. Destination Address Absent (D) Field
4.1. (D) 分野のない送付先アドレス
The most significant bit of the Length field carries the value of the Destination Address Absent Field, the D-bit. A value of 0 indicates the presence of the Destination Address Field (see section 4.5). A value of 1 indicates that a Destination Address Field is not present.
Length分野の最も重要なビットはDestination Address Absent Fieldの値、D-ビットを運びます。 0の値はDestination Address Fieldの存在を示します(セクション4.5を見てください)。 1の値は、Destination Address Fieldが存在していないのを示します。
An End Indicator (4.3) MUST be sent with a D-bit value of 1. Other SNDUs MAY be sent with a D-bit value of 0 or 1. The default method SHOULD use a D-bit value of 0 (see section 4.5).
1のD-ビット値と共にEnd Indicator(4.3)を送らなければなりません。 0か1のD-ビット値と共に他のSNDUsを送るかもしれません。 デフォルト方法SHOULDは0のD-ビット値を使用します(セクション4.5を見てください)。
4.2. Length Field
4.2. 長さの分野
A 15-bit value that indicates the length, in bytes, of the SNDU counted from the byte following the Type field of the SNDU base header (figure 9) up to and including the CRC. This Length includes the size of any extension headers that may be present (section 5). Note the special case described in section 4.3.
CRCを含めてSNDUベースヘッダーのType野原に続いて、バイトから数えられたSNDUのバイトで表現される長さを示す(9について計算します)15ビットの値。 このLengthはどんな出席するかもしれない拡張ヘッダー(セクション5)のサイズも含んでいます。 セクション4.3で説明された特別なケースに注意してください。
4.3. End Indicator
4.3. エンドインディケータ
When the first two bytes following an SNDU have the value 0xFFFF, this denotes an End Indicator (i.e., all ones length combined with a D-bit value of 1). This indicates to the Receiver that there are no further SNDUs present within the current TS Packet (see section 6), and that no Destination Address Field is present. The value 0xFF has specific semantics in MPEG-2 framing, where it is used to indicate the presence of Padding. This use resembles [ISO-DSMCC].
SNDUに続く最初の2バイトが値の0xFFFFを持っているとき、これはEnd Indicatorを指示します(すなわちすべてのもの長さが1のD-ビット値に結合しました)。 これは現在のTS Packetの中の現在のSNDUsがこれ以上なくて(セクション6を見てください)、またどんなDestination Address Fieldも存在していないのをReceiverに示します。 値の0xFFには、MPEG-2縁どりにおける特定の意味論があります。そこでは、それが、Paddingの存在を示すのに使用されます。 この使用は[ISO-DSMCC]に類似しています。
4.4. Type Field
4.4. タイプ分野
The 16-bit Type field indicates the type of payload carried in an SNDU, or the presence of a Next-Header. The set of values that may be assigned to this field is divided into two parts, similar to the allocations for Ethernet.
16ビットのType分野はSNDUで運ばれたペイロードのタイプ、またはNext-ヘッダーの存在を示します。 この分野に割り当てられるかもしれない値のセットは2つの部品に分割されます、イーサネットのための配分と同様です。
EtherTypes were originally specified by Xerox under the Ethernet v2 Specification [DIX]. After specification of IEEE 802.3 [IEEE-802.3, ISO-8802-2], the set of EtherTypes less than 1536 (0x0600) assumed the role of a length indicator. Ethernet receivers use this feature to discriminate LLC format frames. Hence, any IEEE EtherType < 1536 indicates an LLC frame, and the actual value indicates the length of the LLC frame.
EtherTypesは元々、イーサネットv2 Specification[DIX]の下のゼロックスによって指定されました。 IEEE802.3[IEEE-802.3、ISO-8802-2]の仕様の後に、EtherTypes1536(0×0600)のセットは長さのインディケータの役割を引き受けました。 イーサネット受信機はLLC形式フレームを差別するこの特徴を使用します。 したがって、どんなIEEE EtherType<1536もLLCフレームを示します、そして、実価はLLCフレームの長さを示します。
There is a potential ambiguous case when a Receiver receives a PDU with two Length fields: The Receiver would need to validate the actual length and the Length field and ensure that inconsistent values are not propagated by the network. Specification of two
Receiverが2つのLength分野があるPDUを受けるとき、潜在的あいまいなケースがあります: Receiverは実際の長さとLength分野を有効にして、矛盾した値がネットワークによって伝播されないのを保証する必要があるでしょう。 2の仕様
Fairhurst & Collini-Nocker Standards Track [Page 10] RFC 4326 ULE for IP over MPEG-2/DVB December 2005
FairhurstとCollini-ノッカーStandardsはMPEG-2/DVBの上の2005年12月にIPのためにRFC4326ULEを追跡します[10ページ]。
independent Length fields is therefore undesirable. In the ULE header, this is avoided in the SNDU header by including only one length value, but bridging of LLC frames re-introduces this consideration (section 5.2).
したがって、Lengthがさばく独立者は望ましくありません。 ULEヘッダーでは、これはSNDUヘッダーでワンレン値だけを含んでいることによって、避けられますが、LLCフレームをブリッジするのはこの考慮(セクション5.2)を再導入します。
The Ethernet LLC mode of identification is not required in ULE, since the SNDU format always carries an explicit Length field, and therefore the procedure in ULE is modified, as below:
識別のイーサネットLLCモードはSNDU形式がいつも明白なLength野原を運んで、したがって、ULEの手順が変更されているので以下のULEで必要ではありません:
The first set of ULE Type field values comprise the set of values less than 1536 in decimal. These Type field values are IANA assigned (see section 4.4.1) and indicate the Next-Header.
値がセットを包括するULE Type分野の第一セットは小数における1536未満を評価します。 これらのType分野値は、割り当てられた(セクション4.4.1を見ます)IANAであり、Next-ヘッダーを示します。
The second set of ULE Type field values comprise the set of values greater than or equal to 1536 in decimal. In ULE, this value is identical to the corresponding type codes specified by the IEEE/DIX type assignments for Ethernet and recorded in the IANA EtherType registry.
2番目のセットのULE Type分野値は小数における値より多くの1536のセットを包括します。 ULEでは、この値はIEEE/DIXタイプ課題でイーサネットに指定されて、IANA EtherType登録に記録された対応するタイプコードと同じです。
4.4.1. Type 1: Next-Header Type Fields
4.4.1. タイプ1: 次のヘッダータイプ分野
The first part of the Type space corresponds to the values 0 to 1535 decimal. These values may be used to identify link-specific protocols and/or to indicate the presence of Extension Headers that carry additional optional protocol fields (e.g., a bridging encapsulation). Use of these values is co-ordinated by an IANA registry. The following types are defined in this document:
Typeスペースの最初の地域は1535小数への値0に対応しています。 これらの値は、リンク特有のプロトコルを特定して、追加任意のプロトコル野原(例えば、ブリッジするカプセル化)を運ぶExtension Headersの存在を示すのに使用されるかもしれません。 これらの値の使用はIANA登録によって調整されます。 以下のタイプは本書では定義されます:
0x0000: Test SNDU (see section 5.1)
0x0001: Bridged Frame (see section 5.2)
0x0100: Extension-Padding (see section 5.3)
0×0000: SNDU(セクション5.1を見る)0×0001をテストしてください: ブリッジしているFrame(セクション5.2を見る)0×0100: 拡大詰め物(セクション5.3を見ます)
The remaining values within the first part of the Type space are reserved for Next-Header values allocated by the IANA.
Typeスペースの最初の地域の中の残余価値はIANAによって割り当てられたNext-ヘッダー値のために予約されます。
4.4.2. Type 2: EtherType Compatible Type Fields
4.4.2. 2はタイプします: EtherType互換タイプ分野
The second part of the Type space corresponds to the values between 0x600 (1536 decimal) and 0xFFFF. This set of type assignments follows DIX/IEEE assignments (but excludes use of this field as a frame length indicator). All assignments in this space MUST use the values defined for IANA EtherType. The following two Type values are used as examples (taken from the IANA EtherTypes registry):
Typeスペースの第二部は0×600(1536小数)と0xFFFFの間の値に一致しています。 このセットのタイプ課題はディックス/IEEE課題(しかし、フレーム長さのインディケータとしてこの分野の使用を除く)に続きます。 このスペースのすべての課題がIANA EtherTypeのために定義された値を使用しなければなりません。 以下の2つのType値が例(IANA EtherTypes登録から、取る)として使用されます:
0x0800: IPv4 Payload (see section 4.7.2)
0x86DD: IPv6 Payload (see section 4.7.3)
0×0800: IPv4有効搭載量(セクション4.7.2を見る)0x86DD: IPv6有効搭載量(セクション4.7.3を見ます)
Fairhurst & Collini-Nocker Standards Track [Page 11] RFC 4326 ULE for IP over MPEG-2/DVB December 2005
FairhurstとCollini-ノッカーStandardsはMPEG-2/DVBの上の2005年12月にIPのためにRFC4326ULEを追跡します[11ページ]。
4.5. SNDU Destination Address Field
4.5. SNDU目的地アドレス・フィールド
The SNDU Destination Address Field is optional (see section 4.1). This field MUST be carried (i.e., D=0) for IP unicast packets destined to routers that are sent using shared links (i.e., where the same link connects multiple Receivers). A sender MAY omit this field (D=1) for an IP unicast packet and/or multicast packets delivered to Receivers that are able to utilise a discriminator field (e.g., the IPv4/IPv6 destination address, or a bridged MAC destination address), which, in combination with the PID value, could be interpreted as a Link-Level address.
SNDU Destination Address Fieldは任意です(セクション4.1を見てください)。 共有されたリンクが使用させられる(すなわち、同じリンクは複数のReceiversをどこに接続しますか)ルータに運命づけられたIPユニキャストパケットのためにこの野原を運ばなければなりません(すなわち、D=0)。 送付者はPID値と組み合わせてLink-レベルアドレスとして解釈できた弁別器分野(例えば、IPv4/IPv6送付先アドレス、またはブリッジしているMAC送付先アドレス)を利用できるReceiversに提供されたIPユニキャストパケット、そして/または、マルチキャストパケットのために、この分野(D=1)を省略するかもしれません。
When the SNDU header indicates the presence of an SNDU Destination Address field (i.e., D=0), a Network Point of Attachment (NPA) field directly follows the fourth byte of the SNDU header. NPA destination addresses are 6 Byte numbers, normally expressed in hexadecimal, used to identify the Receiver(s) in a MPEG-2 transmission network that should process a received SNDU. The value 0x00:00:00:00:00:00 MUST NOT be used as a destination address in an SNDU. The least significant bit of the first byte of the address is set to 1 for multicast frames, and the remaining bytes specify the link-layer multicast address. The specific value 0xFF:FF:FF:FF:FF:FF is the link broadcast address, indicating that this SNDU is to be delivered to all Receivers.
SNDUヘッダーがSNDU Destination Address分野(すなわち、D=0)の存在を示すとき、Attachment(NPA)分野のNetwork Pointは直接SNDUヘッダーの4番目のバイトに続きます。 NPA送付先アドレスは容認されたSNDUを処理するべきであるMPEG-2送電網でReceiver(s)を特定するのに使用される通常、16進で表された6つのByte番号です。 値、0×00:00:00、:、00:00:00、SNDUの送付先アドレスとして使用されてはいけません。 アドレスの最初のバイトの最下位ビットはマルチキャストフレームのために1に設定されます、そして、残っているバイトはリンクレイヤマルチキャストアドレスを指定します。 特定の値の0xFF: このSNDUがすべてのReceiversに提供されることになっているのを示して、FF:FF:FF:FF:FFはリンク放送アドレスです。
IPv4 packets carrying an IPv4 subnetwork broadcast address need to be delivered to all systems with the same network prefix. When a SNDU Destination Address is present (D=0), the value MUST be set to the NPA link broadcast address (0xFF:FF:FF:FF:FF:FF).
IPv4サブネットワーク放送演説を運ぶIPv4パケットは、同じネットワーク接頭語ですべてのシステムに提供される必要があります。 SNDU Destination Addressが存在しているとき(D=0)、NPAリンク放送アドレス(0xFF:FF:FF:FF:FF: FF)に値を設定しなければなりません。
When the PDU is an IP multicast packet and an SNDU Destination Address is present (D=0), the IP group destination address of the multicast packet MUST be mapped to the multicast SNDU Destination Address (following the method used to generate a destination MAC address in Ethernet). The method for mapping IPv4 multicast addresses is specified in [RFC1112]. The method for mapping IPv6 multicast addresses is specified in [RFC2464].
PDUがIPマルチキャストパケットであり、SNDU Destination Addressが存在しているとき(D=0)、マルチキャストパケットのIPグループ送付先アドレスをマルチキャストSNDU Destination Addressに写像しなければなりません(メソッドに従うのは、以前はよく目的地がイーサネットでMACアドレスであると生成していました)。 IPv4マルチキャストアドレスを写像するためのメソッドは[RFC1112]で指定されます。 IPv6マルチキャストアドレスを写像するためのメソッドは[RFC2464]で指定されます。
4.6. SNDU Trailer CRC
4.6. SNDUトレーラCRC
Each SNDU MUST carry a 32-bit CRC field in the last four bytes of the SNDU. This position eases CRC computation by hardware. The CRC-32 polynomial is to be used. Examples where this polynomial is also employed include Ethernet, DSM-CC section syntax [ISO-DSMCC], and AAL5 [ITU-3563]. This is a 32-bit value calculated according to the generator polynomial represented 0x104C11DB7 in hexadecimal:
各SNDU MUSTはSNDUの最後の4バイトにおける32ビットのCRC野原を運びます。 この位置はハードウェア的にCRC計算を緩和します。 CRC-32多項式は使用されていることです。 またこの多項式が使われる例はイーサネット、DSM-CCセクション構文[ISO-DSMCC]、およびAAL5[ITU-3563]を含んでいます。 これはジェネレータ多項式の表された0x104C11DB7によると、16進で計算された32ビットの値です:
x^32+x^26+x^23+x^22+x^16+x^12+x^11+x^10+x^8+x^7+x^5+x^4+x^2+x^1+x^0.
x^32+x^26+x^23+x^22+x^16+x^12+x^11+x^10+x^8+x^7+x^5+x^4+x^2+x^1+x^0.
Fairhurst & Collini-Nocker Standards Track [Page 12] RFC 4326 ULE for IP over MPEG-2/DVB December 2005
FairhurstとCollini-ノッカーStandardsはMPEG-2/DVBの上の2005年12月にIPのためにRFC4326ULEを追跡します[12ページ]。
The Encapsulator initialises the CRC-32 accumulator register to the value 0xFFFF FFFF. It then accumulates a transmit value for the CRC32 that includes all bytes from the start of the SNDU header to the end of the SNDU (excluding the 32-bit trailer holding the CRC-32), and places this in the CRC Field. In ULE, the bytes are processed in order of increasing position within the SNDU; the order of processing bits is NOT reversed. This use resembles, but is different from that in SCTP [RFC3309].
EncapsulatorはCRC-32アキュムレータレジスタを値の0xFFFF FFFFに初期化します。 次に、それはaを蓄積します。CRC FieldにSNDUの端(CRC-32を持ちながら、32ビットのトレーラを除く)、および場所へのSNDUヘッダーの始まりからすべてのバイト離れたところにこれを含んでいるCRC32のために値を送ってください。 ULEでは、SNDUの中で位置を増強することの順にバイトは処理されます。 処理ビットの注文を逆にしません。 SCTP[RFC3309]で類似していますが、この使用はそれと異なっています。
The Receiver performs an integrity check by independently calculating the same CRC value and comparing this with the transmitted value in the SNDU trailer. SNDUs that do not have a valid CRC are discarded, causing the Receiver to enter the Idle State.
Receiverは、同じ独自に計算のCRC値とSNDUトレーラで伝えられた値とこれを比べることによって、保全チェックを実行します。 ReceiverがIdle州に入ることを引き起こして、有効なCRCがないSNDUs捨てられます。
This description may be suited for hardware implementation, but this document does not imply any specific implementation. Software-based table-lookup or hardware-assisted software-based implementations are also possible. Appendix B provides an example of an Encapsulated PDU that includes the computed CRC-32 value.
この記述はハードウェア実装に合うかもしれませんが、このドキュメントはどんな特定の実装も含意しません。 また、ソフトウェアベースの索表かハードウェアで補助されたソフトウェアベースの実装も可能です。 付録Bは計算されたCRC-32値を含んでいるEncapsulated PDUに関する例を提供します。
The primary purpose of this CRC is to protect the SNDU (header and payload) from undetected reassembly errors and errors introduced by unexpected software/hardware operation while the SNDU is in transit across the MPEG-2 subnetwork and during processing at the Encapsulator and/or the Receiver. It may also detect the presence of uncorrected errors from the physical link (however, these may also be detected by other means, e.g., section 7.3).
このCRCのプライマリ目的はSNDUがトランジットMPEG-2サブネットワークのむこうで中である間に予期していなかったソフトウェア/ハードウェア操作で導入されたundetected reassembly誤りと誤りと処理の間、Encapsulator、そして/または、ReceiverにSNDU(ヘッダーとペイロード)を保護することです。また、それは、物理的なリンクから非修正の誤りの存在を検出するかもしれません(しかしながら、また、これらが他の手段で検出されるかもしれません、例えば、セクション7.3)。
4.7. Description of SNDU Formats
4.7. SNDU形式の記述
The format of an SNDU is determined by the combination of the Destination Address Absent bit (D) and the SNDU Type field. The simplest encapsulation places a PDU directly into an SNDU payload. Some Type 1 encapsulations may require additional header fields. These are inserted in the SNDU following the NPA destination address and directly preceding the PDU.
SNDUの形式はDestination Address Absentビット(D)の組み合わせとSNDU Type分野のそばで決定しています。 最も簡単なカプセル化は直接SNDUペイロードにPDUを置きます。 いくつかのType1カプセル化が追加ヘッダーフィールドを必要とするかもしれません。 これらは、NPA送付先アドレスに従うSNDUに直接PDUに先行しながら、挿入されます。
The following SNDU Formats are defined here:
以下のSNDU Formatsはここで定義されます:
End Indicator: The Receiver should enter the Idle State (4.7.1). IPv4 SNDU: The payload is a complete IPv4 datagram (4.7.2). IPv6 SNDU: The payload is a complete IPv6 datagram (4.7.3). Test SNDU: The payload will be discarded by the Receiver (5.1). Bridged SNDU: The payload carries a bridged MAC frame (5.2).
インディケータを終わらせてください: ReceiverがIdle州に入るはずである、(4.7 .1)。 IPv4 SNDU: ペイロードが完全なIPv4データグラムである、(4.7 .2)。 IPv6 SNDU: ペイロードが完全なIPv6データグラムである、(4.7 .3)。 SNDUをテストしてください: ペイロードはReceiver(5.1)によって捨てられるでしょう。 ブリッジしているSNDU: ペイロードはブリッジしているMACフレーム(5.2)を運びます。
Other formats may be defined through relevant assignments in the IEEE and IANA registries.
他の書式はIEEEとIANA登録の関連課題で定義されるかもしれません。
Fairhurst & Collini-Nocker Standards Track [Page 13] RFC 4326 ULE for IP over MPEG-2/DVB December 2005
FairhurstとCollini-ノッカーStandardsはMPEG-2/DVBの上の2005年12月にIPのためにRFC4326ULEを追跡します[13ページ]。
4.7.1. End Indicator
4.7.1. エンドインディケータ
The format of the End Indicator is shown in figure 2. This format MUST carry a D-bit value of 1.
End Indicatorの書式は2が中で計算するのが示されます。 この形式は1のD-ビット値を運ばなければなりません。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| 0x7FFF | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
= A sequence of zero or more bytes with a value 0xFF filling =
| the remainder of the TS Packet Payload |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| 0x7FFF| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | = ゼロの系列か値の0xFFが=をいっぱいにしているより多くのバイト| TS Packet有効搭載量の残り| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Format for a ULE End Indicator
図2: ULEエンドインディケータのための形式
4.7.2. IPv4 SNDU Encapsulation
4.7.2. IPv4 SNDUカプセル化
IPv4 datagrams are directly transported using one of the two standard SNDU structures, in which the PDU is placed directly in the SNDU payload. The two encapsulations are shown in Figures 3 and 4. (Note that in this, and the following figures, the IP datagram payload is of variable size and is directly followed by the CRC-32).
IPv4データグラムは、PDUが直接SNDUペイロードに置かれる2つの標準のSNDU構造の1つを使用することで直接輸送されます。 2つのカプセル化が図3と4に示されます。 (IPデータグラムペイロードがこれ、および以下の数字では、可変サイズがあって、CRC-32によって直接続かれていることに注意します。)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Length (15b) | Type = 0x0800 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Destination NPA Address (6B) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
= IPv4 datagram =
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (CRC-32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| 長さ(15b)| =0x0800をタイプしてください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 受信機送付先NPAアドレス(6B)| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | = IPv4データグラム=| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (CRC-32) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: SNDU Format for an IPv4 Datagram using L2 filtering (D=0)
図3: L2フィルタリングを使用するIPv4データグラムのためのSNDU Format(D=0)
Fairhurst & Collini-Nocker Standards Track [Page 14] RFC 4326 ULE for IP over MPEG-2/DVB December 2005
FairhurstとCollini-ノッカーStandardsはMPEG-2/DVBの上の2005年12月にIPのためにRFC4326ULEを追跡します[14ページ]。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Length (15b) | Type = 0x0800 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
= IPv4 datagram =
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (CRC-32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| 長さ(15b)| =0x0800をタイプしてください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | = IPv4データグラム=| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (CRC-32) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: SNDU Format for an IPv4 Datagram using L3 filtering (D=1)
図4: L3フィルタリングを使用するIPv4データグラムのためのSNDU Format(D=1)
4.7.3. IPv6 SNDU Encapsulation
4.7.3. IPv6 SNDUカプセル化
IPv6 datagrams are directly transported using one of the two standard SNDU structures, in which the PDU is placed directly in the SNDU payload. The two encapsulations are shown in Figures 5 and 6.
IPv6データグラムは、PDUが直接SNDUペイロードに置かれる2つの標準のSNDU構造の1つを使用することで直接輸送されます。 2つのカプセル化が図5と6に示されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Length (15b) | Type = 0x86DD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Destination NPA Address (6B) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
= IPv6 datagram =
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (CRC-32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| 長さ(15b)| =0x86DDをタイプしてください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 受信機送付先NPAアドレス(6B)| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | = IPv6データグラム=| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (CRC-32) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: SNDU Format for an IPv6 Datagram using L2 filtering (D=0)
図5: L2フィルタリングを使用するIPv6データグラムのためのSNDU Format(D=0)
Fairhurst & Collini-Nocker Standards Track [Page 15] RFC 4326 ULE for IP over MPEG-2/DVB December 2005
FairhurstとCollini-ノッカーStandardsはMPEG-2/DVBの上の2005年12月にIPのためにRFC4326ULEを追跡します[15ページ]。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Length (15b) | Type = 0x86DD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
= IPv6 datagram =
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (CRC-32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| 長さ(15b)| =0x86DDをタイプしてください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | = IPv6データグラム=| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (CRC-32) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: SNDU Format for an IPv6 Datagram using L3 filtering (D=1)
図6: L3フィルタリングを使用するIPv6データグラムのためのSNDU Format(D=1)
5. Extension Headers
5. 拡張ヘッダー
This section describes an extension format for the ULE encapsulation. In ULE, a Type field value less than 1536 decimal indicates an Extension Header. These values are assigned from a separate IANA registry defined for ULE.
このセクションはULEカプセル化のために拡大形式について説明します。 ULEでは、1536小数より少ないType分野価値はExtension Headerを示します。 これらの値はULEのために定義された別々のIANA登録から割り当てられます。
The use of a single Type/Next-Header field simplifies processing and eliminates the need to maintain multiple IANA registries. The cost is that each Extension Header requires at least 2 bytes. This is justified, on the basis of simplified processing and maintaining a simple lightweight header for the common case when no extensions are present.
ただ一つの次のType/ヘッダーフィールドの使用は、処理を簡素化して、複数のIANA登録を維持する必要性を排除します。 費用は各Extension Headerが少なくとも2バイトを必要とするということです。 どんな拡大も存在していないとき簡易型の処理とよくある例のために簡単なライト級のヘッダーを維持することに基づいてこれは正当化されます。
A ULE Extension Header is identified by a 16-bit value in the Type field. This field is organised as a 5-bit zero prefix, a 3-bit H-LEN field, and an 8-bit H-Type field, as follows:
ULE Extension HeaderはType分野の16ビットの値によって特定されます。 この分野は接頭語がなく、3ビットのH-LEN分野、および8ビットのH-タイプが以下の通りさばく5ビットとして構成されています:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0|H-LEN| H-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0|H-レン| H-タイプ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Structure of ULE Next-Header Field
図7: ULEの次のヘッダーの分野の構造
The H-LEN Assignment is described below:
H-LEN Assignmentは以下で説明されます:
0 Indicates a Mandatory Extension Header 1 Indicates an Optional Extension Header of length 2B (Type only) 2 Indicates an Optional Extension Header of length 4B (Type + 2B) 3 Indicates an Optional Extension Header of length 6B (Type + 4B) 4 Indicates an Optional Extension Header of length 8B (Type + 6B) 5 Indicates an Optional Extension Header of length 10B (Type + 8B)
0がa Mandatory Extension Header1Indicatesを示す、長さ2B(タイプ専用)2のIndicatesのOptional Extension Header、長さ4B(タイプ+2B)3のIndicatesのOptional Extension Header、長さ6B(タイプ+4B)4のIndicatesのOptional Extension Header、長さ8B(タイプ+6B)5のIndicatesのOptional Extension Header、長さの10BのOptional Extension Header(タイプ+8B)
Fairhurst & Collini-Nocker Standards Track [Page 16] RFC 4326 ULE for IP over MPEG-2/DVB December 2005
FairhurstとCollini-ノッカーStandardsはMPEG-2/DVBの上の2005年12月にIPのためにRFC4326ULEを追跡します[16ページ]。
>=6 The combined H-LEN and H-TYPE values indicate the EtherType
of a PDU that directly follows this Type field.
>=6 結合したH-LENとH-TYPE値は直接このType野原に続くPDUのEtherTypeを示します。
The H-LEN value indicates the total number of bytes in an Optional Extension Header (including the 2B Type field).
H-LEN値はOptional Extension Headerのバイトの総数を示します(2B Type分野を含んでいて)。
An H-LEN value of zero indicates a Mandatory Extension Header. Each Mandatory Extension Header has a pre-defined length that is not communicated in the H-LEN field. No additional limit is placed on the maximum length of a Mandatory Extension Header. A Mandatory Extension Header MAY modify the format or encoding of the enclosed PDU (e.g., to perform encryption and/or compression).
ゼロのH-LEN値はMandatory Extension Headerを示します。 各Mandatory Extension Headerには、H-LEN分野で伝えられない事前に定義された長さがあります。 どんな追加限界もMandatory Extension Headerの最大の長さに置かれません。 Mandatory Extension Headerは同封のPDU(例えば暗号化、そして/または、圧縮を実行する)の形式かコード化を変更するかもしれません。
The H-Type is a one-byte field that is either one of 256 Mandatory Header Extensions or one of 256 Optional Header Extensions. The set of currently permitted values for both types of Extension Headers are defined by an IANA Registry (section 15). Registry values for Optional Extensions are specified in the form H=1 (i.e., a decimal number in the range 256-511), but may be used with an H-Length value in the range 1-5 (see example in section 5.3).
H-タイプは256Mandatory Header Extensionsのどちらかか256Optional Header Extensionsの1つである1バイトの分野です。 値がExtension Headersの両方のタイプのために受入れられた現在のセットはIANA Registry(セクション15)によって定義されます。 Optional Extensionsのための登録値は、フォームH=1(すなわち、範囲256-511の10進数)で指定されますが、H-長さの値と共に範囲1-5で使用されるかもしれません(セクション5.3の例を見てください)。
Two examples of Extension Headers are the Test SNDU and the use of Extension-Padding. The Test SNDU Mandatory Extension Header results in the entire PDU's being discarded. The Extension-Padding Optional Extension Header results in the following (if any) option header being ignored (i.e., a total of H-LEN 16-bit words).
Extension Headersに関する2つの例は、Extension-詰め物のTest SNDUと使用です。 Test SNDU Mandatory Extension Headerは全体のPDUのものをもたらして、捨てられます。 Extensionをそっと歩いているOptional Extension Headerは無視される以下の(もしあれば)オプションヘッダー(すなわち、H-LENの16ビットの単語の合計)をもたらします。
The general format for an SNDU with Extension Headers is:
Extension HeadersとSNDUのための一般形式は以下の通りです。
< -------------------------- SNDU ------------------------- > +---+--------------------------------------------------+--------+ |D=0| Length | T1 | NPA Address | H1 | T2 | PDU | CRC-32 | +---+--------------------------------------------------+--------+ < ULE base header > < ext 1 >
<。-------------------------- SNDU------------------------- >+---+--------------------------------------------------+--------+ |D=0| 長さ| T1| NPAアドレス| H1| T2| PDU| CRC-32| +---+--------------------------------------------------+--------+ <ULEはヘッダー><ext1>を基礎づけます。
Figure 8: SNDU Encapsulation with one Extension Header (for D=0)
エイト環: 1Extension HeaderとSNDU Encapsulation(D=0であることの)
Where:
D is the ULE D_bit (in this example D=0; however, NPA addresses may
also be omitted when using Extension Headers).
T1 is the base header Type field. In this case, specifying a
Next-Header value.
H1 is a set of fields defined for header type T1. There may be 0
or more bytes of information for a specific ULE Extension Header.
T2 is the Type field of the next header, or an EtherType > 1535 B
indicating the type of the PDU being carried.
どこ: DはULE D_ビット(この例のD=0で; しかしながら、Extension Headersを使用するとき、また、NPAアドレスは省略されるかもしれない)です。 T1はベースヘッダーType分野です。 この場合Next-ヘッダー値を指定すること。 H1はヘッダータイプT1のために定義された1セットの分野です。 特定のULE Extension Headerのための0バイト以上の情報があるかもしれません。 T2は次のヘッダーのType分野であるかEtherType>1535Bが運ばれるPDUのタイプを示すことです。
Fairhurst & Collini-Nocker Standards Track [Page 17] RFC 4326 ULE for IP over MPEG-2/DVB December 2005
FairhurstとCollini-ノッカーStandardsはMPEG-2/DVBの上の2005年12月にIPのためにRFC4326ULEを追跡します[17ページ]。
< -------------------------- SNDU ------------------------- > +---+---------------------------------------------------+--------+ |D=1| Length | T1 | H1 | T2 | H2 | T3 | PDU | CRC-32 | +---+---------------------------------------------------+--------+ < ULE base header >< ext 1 >< ext 2 >
<。-------------------------- SNDU------------------------- >+---+---------------------------------------------------+--------+ |D=1| 長さ| T1| H1| T2| H2| T3| PDU| CRC-32| +---+---------------------------------------------------+--------+ <ULEベースヘッダー><ext1><ext2>。
Figure 9: SNDU Encapsulation with two Extension Headers (D=1)
図9: 2Extension HeadersとSNDU Encapsulation(D=1)
Using this method, several Extension Headers MAY be chained in series. Figure 12 shows an SNDU including two Extension Headers. In the example, the values of T1 and T2 are both less than 1536 decimal. Each indicates the presence of an Extension Header, rather than a directly following PDU. T3 has a value > 1535 indicating the EtherType of the PDU being carried. Although an SNDU may contain an arbitrary number of consecutive Extension Headers, it is not expected that SNDUs will generally carry a large number of extensions.
このメソッドを使用して、数個のExtension Headersが連続的にチェーニングされるかもしれません。 図12は2Extension Headersを含むSNDUを示しています。 例では、T1とT2の値は1536小数よりそれほど両方です。 それぞれが直接次のPDUよりむしろExtension Headerの存在を示します。 T3は値の>1535に運ばれるPDUのEtherTypeを示させます。 SNDUは連続したExtension Headersの特殊活字の数字を含むかもしれませんが、一般に、SNDUsが多くの拡大を運ばないと予想されます。
5.1. Test SNDU
5.1. テストSNDU
A Test SNDU (Figure 10) is a Mandatory Extension Header of Type 1. This header must be the final (or only) extension header specified in the header chain of an SNDU. The structure of the Data portion of this SNDU is not defined by this document. Receivers MAY record reception in a log file, but MUST then discard any Test SNDUs. The D-bit MAY be set in a TEST SNDU.
Test SNDU(図10)はType1のMandatory Extension Headerです。 このヘッダーはSNDUのヘッダーチェーンで指定された最終的な(単に)拡張ヘッダーであるに違いありません。 このSNDUのData部分の構造はこのドキュメントによって定義されません。 ファイルしますが、そして、ログにおける受信機5月の記録的なレセプションはどんなTest SNDUsも捨てなければなりません。 D-ビットはTEST SNDUに設定されるかもしれません。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|D| Length (15b) | Type = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
= Data (not forwarded by a Receiver) =
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (CRC-32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |D| 長さ(15b)| =0x0000をタイプしてください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | = データ(Receiverによって進められない)=| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (CRC-32) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: SNDU Format for a Test SNDU
図10: テストSNDUのためのSNDU形式
5.2. Bridged Frame SNDU Encapsulation
5.2. フレームSNDUカプセル化であるとブリッジされます。
A bridged SNDU is a Mandatory Extension Header of Type 1. It MUST be the final (or only) extension header specified in the header chain of an SNDU. The payload includes MAC address and EtherType [DIX] or LLC Length [ISO-8802-2] fields together with the contents of a bridged MAC frame. The SNDU has the format shown in Figures 11 and 12.
ブリッジしているSNDUはType1のMandatory Extension Headerです。 それはSNDUのヘッダーチェーンで指定された最終的な(単に)拡張ヘッダーであるに違いありません。 ペイロードはブリッジしているMACフレームのコンテンツと共にMACアドレスとEtherType[DIX]かLLC Length[ISO-8802-2]分野を含んでいます。 SNDUには、図11と12に示された書式があります。
Fairhurst & Collini-Nocker Standards Track [Page 18] RFC 4326 ULE for IP over MPEG-2/DVB December 2005
FairhurstとCollini-ノッカーStandardsはMPEG-2/DVBの上の2005年12月にIPのためにRFC4326ULEを追跡します[18ページ]。
When an NPA address is specified (D=0), Receivers MUST discard all SNDUs that carry an NPA destination address that does NOT match their own NPA address (or a broadcast/multicast address); the payload of the remaining SNDUs are processed by the bridging rules that follow. An SNDU without an NPA address (D=1) results in a Receiver performing bridging processing on the payload of all received SNDUs.
NPAアドレスが指定されるとき(D=0)、Receiversはそれら自身のNPAアドレス(または、放送/マルチキャストアドレス)に合っていないNPA送付先アドレスを運ぶすべてのSNDUsを捨てなければなりません。 残っているSNDUsのペイロードは従うブリッジする規則で処理されます。 NPAアドレス(D=1)のないSNDUはすべての容認されたSNDUsのペイロードの上に処理をブリッジしながら働くReceiverをもたらします。
An Encapsulator MAY also use this encapsulation format to directly communicate network protocol packets that require the LLC encapsulation [IEEE-802.2, ISO-8802-2]. To do this, it constructs an SNDU with a Bridge Extension Header containing the intended destination MAC address, the MAC source address of the Encapsulator, and the LLC-Length. The PDU comprises an LLC header followed by the required payload. The Encapsulator MAY choose to suppress the NPA address (see 4.5).
また、Encapsulatorは、直接LLCカプセル化[IEEE-802.2、ISO-8802-2]を必要とするネットワーク・プロトコルパケットを伝えるのにこのカプセル化形式を使用するかもしれません。 これをするために、それはBridge Extension Headerが意図している送付先MACアドレス、EncapsulatorのMACソースアドレス、およびLLC-長さを含んでいるSNDUを組み立てます。 PDUはLLCヘッダーを包括します、続いて、必要なペイロードを包括します。 Encapsulatorは、NPAアドレスを抑圧するのを選ぶかもしれません(4.5を見てください)。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Length (15b) | Type = 0x0001 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Destination NPA Address (6B) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| MAC Destination Address (6B) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Source Address (6B) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | EtherType/LLC-Length (2B) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
= (Contents of bridged MAC frame) =
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (CRC-32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| 長さ(15b)| =0x0001をタイプしてください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 受信機送付先NPAアドレス(6B)| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | MAC送付先アドレス(6B)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MACソースアドレス(6B)| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | EtherType/LLC-長さ(2B)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | = (ブリッジしているMACフレームのコンテンツ) = | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (CRC-32) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: SNDU Format for a Bridged Payload (D=0)
図11: ブリッジしている有効搭載量のためのSNDU形式(D=0)
Fairhurst & Collini-Nocker Standards Track [Page 19] RFC 4326 ULE for IP over MPEG-2/DVB December 2005
FairhurstとCollini-ノッカーStandardsはMPEG-2/DVBの上の2005年12月にIPのためにRFC4326ULEを追跡します[19ページ]。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Length (15b) | Type = 0x0001 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Destination Address (6B) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| MAC Source Address (6B) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EtherType/LLC-Length (2B) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
= (Contents of bridged MAC frame) =
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (CRC-32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| 長さ(15b)| =0x0001をタイプしてください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC送付先アドレス(6B)| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | MACソースアドレス(6B)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EtherType/LLC-長さ(2B)| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | = (橋を架けられたMACフレームのコンテンツ) = | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (CRC-32) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: SNDU Format for a Bridged Payload (D=1)
図12: 橋を架けられた有効搭載量のためのSNDU形式(D=1)
The EtherType/LLC-Length field of a frame is defined according to IEEE 802.3 [IEEE-802.2] (see section 5).
IEEE802.3[IEEE-802.2]に従って、フレームのEtherType/LLC-長さの分野は定義されます(セクション5を見てください)。
In this special case, the Mandatory Extension Header format may be interpreted as either an EtherType [DIX] or an LLC Length field, specified by IEEE 802 [IEEE-802.3] rather than as a value assigned in the ULE Next-Header Registry maintained by the IANA.
この特別な場合では、Mandatory Extension Header形式はRegistryがIANAで維持したULE Next-ヘッダーで割り当てられた値としてというよりむしろIEEE802[IEEE-802.3]によって指定されたEtherType[DIX]かLLC Length分野のどちらかとして解釈されるかもしれません。
The MAC addresses in the frame being bridged SHOULD be assigned according to the rules specified by the IEEE and denote unknown, unicast, broadcast, and multicast link addresses. These MAC addresses denote the intended recipient in the destination LAN, and therefore have a different function from the NPA addresses carried in the SNDU header.
橋を架けられたSHOULDであるフレームのMACアドレスは、IEEEによって指定された規則に従って割り当てられて、未知、ユニキャスト、放送、およびマルチキャストリンクアドレスを指示します。 これらのMACアドレスは、目的地LANで意図している受取人を指示して、したがって、SNDUヘッダーで運ばれたNPAアドレスと異なった機能を持っています。
A frame Type < 1536 for a bridged frame introduces a LLC Length field. The Receiver MUST check this length and discard any frame with a length greater than permitted by the SNDU payload size.
橋を架けられたフレームへのフレームType<1536はLLC Length野原を挿入します。 Receiverはこの長さをチェックして、長さがSNDUペイロードサイズによって受入れられるより大きい状態でどんなフレームも捨てなければなりません。
In normal operation, it is expected that any padding appended to the Ethernet frame SHOULD be removed prior to forwarding. This requires the sender to be aware of such Ethernet padding (e.g., [DIX, IEEE-802.3]).
通常の操作では、イーサネットフレームSHOULDに追加されたどんな詰め物も推進の前に取り除かれると予想されます。 これは、送付者がそのようなイーサネットが(例えば、[ディックス、IEEE-802.3])を水増しするのを意識しているのを必要とします。
Ethernet frames received at the Encapsulator for onward transmission over ULE carry a Local Area Network Frame Check sequence (LAN FCS)
ULEの上の前方のトランスミッションのためにEncapsulatorに受け取られたイーサネットフレームはローカル・エリア・ネットワークFrame Check系列を運びます。(LAN FCS)
Fairhurst & Collini-Nocker Standards Track [Page 20] RFC 4326 ULE for IP over MPEG-2/DVB December 2005
FairhurstとCollini-ノッカーStandardsはMPEG-2/DVBの上の2005年12月にIPのためにRFC4326ULEを追跡します[20ページ]。
field (e.g., CRC-32 for Ethernet [DIX, IEEE-802.3]). The Encapsulator MUST check the LAN-FCS value of all frames received, prior to further processing. Frames received with an invalid LAN FCS MUST be discarded. After checking, the LAN FCS is then removed (i.e., it is NOT forwarded in the bridged SNDU). As in other ULE frames, the Encapsulator appends a CRC-32 to the transmitted SNDU. At the Receiver, an appropriate LAN-FCS field will be appended to the bridged frame prior to onward transmission on the Ethernet interface.
(例えば、イーサネット[ディックス、IEEE-802.3]のためのCRC-32)をさばいてください。 Encapsulatorはさらなる処理の前に受け取られたすべてのフレームのLAN-FCS値をチェックしなければなりません。 無効のLAN FCS MUSTが捨てられている状態で、フレームは受信されました。 そして、照合の後に、LAN FCSは取り外されます(すなわち、それは橋を架けられたSNDUで進められません)。 他のULEフレームのように、Encapsulatorは伝えられたSNDUにCRC-32を追加します。 Receiverでは、前方のトランスミッションの前にイーサネットインタフェースで適切なLAN-FCS野原を橋を架けられたフレームに追加するでしょう。
This design is readily implemented using existing network interface cards and does not introduce an efficiency cost by calculating/verifying two integrity check fields for bridged frames. However, it also introduces the possibility that a frame corrupted within the processing performed at an Encapsulator and/or Receiver may not be detected by the final recipient(s) (i.e., such corruption would not normally result in an invalid LAN FCS).
このデザインは、既存のネットワーク・インターフェース・カードを使用することで容易に実行されて、2つの保全チェック分野について橋を架けられたフレームに計算するか、または確かめることによって、効率費用を導入しません。 しかしながら、また、それはEncapsulator、そして/または、Receiverで実行された処理の中で崩壊したフレームが最終的な受取人によって検出されないかもしれない(通常、すなわち、そのような不正は無効のLAN FCSをもたらさないでしょう)可能性を導入します。
5.3. Extension-Padding Optional Extension Header
5.3. 拡大をそっと歩く任意の拡張ヘッダー
The Extension-Padding Optional Extension Header is specified by an IANA-assigned H-Type value of 0x100. As in other Optional Extensions, the total length of the extension is indicated by the H-LEN field (specified in 16-bit words). The extension field is formed of a group of one to five 16-bit fields.
Extensionをそっと歩いているOptional Extension Headerは0×100のIANAによって割り当てられたH-タイプ値によって指定されます。 他のOptional Extensionsのように、H-LEN分野(16ビットの単語で、指定される)によって拡大の全長は示されます。 拡大分野は1〜5つの16ビットの分野のグループについて形成されます。
For this specific option, only the last 16-bit word has an assigned value; the sender SHOULD set the remaining values to 0x0000. The last 16-bit field forms the Next-Header Type field. A Receiver MUST interpret the Type field, but MUST ignore any other fields of this Extension Header.
この特定のオプションのために、ベスト16ビット単語だけには、割り当てられた値があります。 送付者SHOULDは0×0000に残余価値を設定します。 ベスト16ビット分野はNext-ヘッダーType分野を形成します。 ReceiverはType分野を解釈しなければなりませんが、このExtension Headerのいかなる他の分野も無視しなければなりません。
Fairhurst & Collini-Nocker Standards Track [Page 21] RFC 4326 ULE for IP over MPEG-2/DVB December 2005
FairhurstとCollini-ノッカーStandardsはMPEG-2/DVBの上の2005年12月にIPのためにRFC4326ULEを追跡します[21ページ]。
6. Processing at the Encapsulator
6. Encapsulatorでの処理
The Encapsulator forms the PDUs queued for transmission into SNDUs by adding a header and trailer to each PDU (section 4). It then segments the SNDU into a series of TS Packet payloads (Figure 13). These are transmitted using a single TS Logical Channel over a TS Multiplex. The TS Multiplex may be processed by a number of MPEG-2 (re)multiplexors before it is finally delivered to a Receiver [RFC4259].
Encapsulatorは、トランスミッションのために列に並ばせられたPDUsで各PDU(セクション4)にヘッダーとトレーラを加えることによって、SNDUsを作ります。 そして、それはSNDUを一連のTS Packetペイロード(図13)に区分します。 これらは、TS Multiplexの上で独身のTS Logical Channelを使用することで伝えられます。 最終的にReceiver[RFC4259]にそれを渡す前に多くのMPEG-2(re)マルチプレクサーはTS Multiplexを処理するかもしれません。
+------+--------------------------------+------+
| ULE | Protocol Data Unit | ULE |
|Header| |CRC-32|
+------+--------------------------------+------+
/ / \ \
/ / \ \
/ / \ \
+--------+---------+ +--------+---------+ +--------+---------+
|MPEG-2TS| MPEG-2 |...|MPEG-2TS| MPEG-2 |...|MPEG-2TS| MPEG-2 |
| Header | Payload | | Header | Payload | | Header | Payload |
+--------+---------+ +--------+---------+ +--------+---------+
+------+--------------------------------+------+ | ウレ| プロトコルデータ単位| ウレ| |ヘッダー| |CRC-32| +------+--------------------------------+------+ / / \ \ / / \ \ / / \ \ +--------+---------+ +--------+---------+ +--------+---------+ |MPEG-2t| MPEG-2|...|MPEG-2t| MPEG-2|...|MPEG-2t| MPEG-2| | ヘッダー| 有効搭載量| | ヘッダー| 有効搭載量| | ヘッダー| 有効搭載量| +--------+---------+ +--------+---------+ +--------+---------+
Figure 13: Encapsulation of an SNDU into a series of TS Packets
図13: 一連のTS PacketsへのSNDUのカプセル化
6.1. SNDU Encapsulation
6.1. SNDUカプセル化
When an Encapsulator has not previously sent a TS Packet for a specific TS Logical Channel, or after an Idle period, it starts to send an SNDU in the first available TS Packet. This first TS Packet generated MUST carry a PUSI value of 1. It MUST also carry a Payload Pointer value of zero, indicating that the SNDU starts immediately after the Payload Pointer in the TS Packet payload.
Encapsulatorが特定のTS Logical Channelか、Idleの期間の後に以前にTS Packetを送らないとき、それは最初の利用可能なTS PacketでSNDUを送り始めます。 発生するこの最初のTS Packetは1のPUSI値を運ばなければなりません。 また、それはゼロの有効搭載量Pointer価値を運ばなければなりません、SNDUがTS Packetペイロードの有効搭載量Pointer直後始まるのを示して。
The Encapsulation MUST ensure that all TS Packets set the MPEG-2 Continuity Counter carried in the TS Packet header, according to [ISO-MPEG2]. This value MUST be incremented by one (modulo 16) for each successive TS Packet containing a fragment/complete SNDU sent using the same TS Logical Channel.
Encapsulationは、すべてのTS PacketsがTS Packetヘッダーで運ばれたMPEG-2Continuity Counterを設定するのを確実にしなければなりません、[ISO-MPEG2]に従って。 この値を同じTS Logical Channelが使用させられる断片/完全なSNDUを含むそれぞれの連続したTS Packetあたり1つ(法16)増加しなければなりません。
An Encapsulator MAY decide not to send another SNDU immediately, even if space is available in a partially filled TS Packet. This procedure is known as Padding (Figure 14). The End Indicator informs the Receiver that there are no more SNDUs in this TS Packet payload. The End Indicator is followed by zero or more unused bytes until the end of the TS Packet payload. All unused bytes MUST be set to the value of 0xFF, following current practice in MPEG-2 [ISO-DSMCC]. The Padding procedure trades decreased efficiency against improved latency.
Encapsulatorは、すぐに別のSNDUを送らないと決めるかもしれません、スペースが部分的にいっぱいにされたTS Packetで利用可能であっても。 この手順はPadding(図14)として知られています。 End Indicatorは、このTS Packetペイロードにはそれ以上のSNDUsが全くないことをReceiverに知らせます。 ゼロか、より未使用のバイトがTS Packetペイロードの端までEnd Indicatorのあとに続いています。 MPEG-2[ISO-DSMCC]における現在の習慣に続いて、すべての未使用のバイトを0xFFの値に設定しなければなりません。 Padding手順業界は改良された潜在に対して能率が下がりました。
Fairhurst & Collini-Nocker Standards Track [Page 22] RFC 4326 ULE for IP over MPEG-2/DVB December 2005
FairhurstとCollini-ノッカーStandardsはMPEG-2/DVBの上の2005年12月にIPのためにRFC4326ULEを追跡します[22ページ]。
+-/------------+
| SubNetwork |
| DU 1 |
+-/------------+
\ \
\ \
\ \
+--------+--------+--------+----------+
|MPEG-2TS| End of | 0xFFFF | Unused |
| Header | SNDU 1 | | Bytes |
+--------+--------+--------+----------+
PUSI=0 ULE
End
Indicator
+-/------------+ | サブネットワーク| | DU1| +-/------------+ \ \ \ \ \ \ +--------+--------+--------+----------+ |MPEG-2t| 終わります。| 0xFFFF| 未使用| | ヘッダー| SNDU1| | バイト| +--------+--------+--------+----------+ PUSI=0 ULEエンドインディケータ
Figure 14: A TS Packet carrying the end of SNDU 1, followed by an
End Indicator
図14: End Indicatorによって続かれたSNDU1の端を運ぶTS Packet
Alternatively, when more packets are waiting at an Encapsulator, and a TS Packet has sufficient space remaining in the payload, the Encapsulator can follow a previously encapsulated SNDU with another SNDU using the next available byte of the TS Packet payload (see 6.2). This is called Packing (Figure 15).
より多くのパケットがEncapsulatorで待っていて、TS Packetにペイロードに残っている十分なスペースがあるとき、あるいはまた、TS Packetペイロードの次の有効なバイトを使用することでEncapsulatorは別のSNDUと共に以前に要約のSNDUに続くことができます(6.2を見てください)。 これはPacking(図15)と呼ばれます。
+-/----------------+ +----------------/-+
| Subnetwork | | Subnetwork |
| DU 2 | | DU 3 |
+-/----------------+ +----------------/-+
\ \ / /\
\ \ / / \
\ \ / / \. . .
+--------+--------+--------+----------+
|MPEG-2TS| Payload| end of | start of |
| Header | Pointer| SNDU 2 | SNDU 3 |
+--------+--------+--------+----------+
PUSI=1 | ^
| |
+--------------+
+-/----------------+ +----------------/-+ | サブネットワーク| | サブネットワーク| | DU2| | DU3| +-/----------------+ +----------------/-+ \ \ / /\ \ \ / / \ \ \ / / \. . . +--------+--------+--------+----------+ |MPEG-2t| 有効搭載量| 終わります。| 始まります。| | ヘッダー| ポインタ| SNDU2| SNDU3| +--------+--------+--------+----------+ PUSI=1| ^ | | +--------------+
Figure 15: A TS Packet with the end of SNDU 2, followed by SNDU 3
図15: SNDU3によって続かれたSNDU2の端があるTS Packet
Fairhurst & Collini-Nocker Standards Track [Page 23] RFC 4326 ULE for IP over MPEG-2/DVB December 2005
FairhurstとCollini-ノッカーStandardsはMPEG-2/DVBの上の2005年12月にIPのためにRFC4326ULEを追跡します[23ページ]。
6.2. Procedure for Padding and Packing
6.2. 詰め物とパッキングのための手順
Five possible actions may occur when an Encapsulator has completed encapsulation of an SNDU:
EncapsulatorがSNDUのカプセル化を完成したとき、5つの可能な動作が起こるかもしれません:
(i) If the TS Packet has no remaining space, the Encapsulator transmits this TS Packet. It starts transmission of the next SNDU in a new TS Packet. (The standard rules [ISO-MPEG2] require that the header of this new TS Packet carry a PUSI value of 1 followed by a Payload Pointer value of 0x00.)
(i) TS Packetに残っているスペースが全くないなら、EncapsulatorはこのTS Packetを伝えます。 それは新しいTS Packetの次のSNDUのトランスミッションを始めます。 (標準の規則[ISO-MPEG2]は、この新しいTS Packetのヘッダーが1のPUSI値を運んで、続いて運ぶのを0×00の有効搭載量Pointer価値を必要とします。)
(ii) If the TS Packet carrying the final part of an SNDU has one byte of unused payload, the Encapsulator MUST place the value 0xFF in this final byte and transmit the TS Packet. This rule provides a simple mechanism to resolve the complex behaviour that may arise when the TS Packet has no PUSI set. To send another SNDU in the current TS Packet would otherwise require the addition of a Payload Pointer that would consume the last remaining byte of TS Packet payload. The behaviour follows similar practice for other MPEG-2 payload types [ISO-DSMCC]. The Encapsulator MUST start transmission of the next SNDU in a new TS Packet. (The standard rules require the header of this new TS Packet to carry a PUSI value of 1 followed by a Payload Pointer value of 0x00.)
(ii) SNDUの最終部分を運ぶTS Packetが1バイトの未使用のペイロードを持っているなら、Encapsulatorはこの最終的なバイトに値の0xFFを置いて、TS Packetを伝えなければなりません。 この規則は、TS PacketがPUSIを全く用意ができさせないとき起こるかもしれない複雑なふるまいを決議するために簡単なメカニズムを提供します。 別のSNDUを送るために、現在のTS Packetは別の方法でTS Packetペイロードの最後の残っているバイトを消費する有効搭載量Pointerの添加を必要とするでしょう。 ふるまいは他のMPEG-2つのペイロードタイプ[ISO-DSMCC]のための同様の習慣に続きます。 Encapsulatorは新しいTS Packetの次のSNDUのトランスミッションを始めなければなりません。 (標準の規則は0×00の有効搭載量Pointer価値があとに続いた1のPUSI値を運ぶためにこの新しいTS Packetをヘッダーに要求します。)
(iii) If the TS Packet carrying the final part of an SNDU has exactly two bytes of unused payload, and the PUSI was NOT already set, the Encapsulator MUST place the value 0xFFFF in these final two bytes, providing an End Indicator (section 4.3), and transmit the TS Packet. This rule prevents fragmentation of the SNDU Length field over two TS Packets. The Encapsulator MUST start transmission of the next SNDU in a new TS Packet. (The standard rules require the header of this new TS Packet to carry a PUSI value of 1 followed by a Payload Pointer value of 0x00.)
(iii) SNDUの最終部分を運ぶTS Packetがちょうど2バイトの未使用のペイロードを持っていて、PUSIが既に用意ができなかったなら、EncapsulatorはEnd Indicator(セクション4.3)を提供して、これらの最終的な2バイトに値の0xFFFFを置いて、TS Packetを伝えなければなりません。 この規則は2以上のSNDU Length分野TS Packetsの断片化を防ぎます。 Encapsulatorは新しいTS Packetの次のSNDUのトランスミッションを始めなければなりません。 (標準の規則は0×00の有効搭載量Pointer価値があとに続いた1のPUSI値を運ぶためにこの新しいTS Packetをヘッダーに要求します。)
(iv) If the TS Packet has more than two bytes of unused payload, the Encapsulator MAY transmit this partially full TS Packet but MUST first place the value 0xFF in all remaining unused bytes (i.e., setting an End Indicator followed by Padding). The Encapsulator MUST then start transmission of the next SNDU in a new TS Packet. (The standard rules [ISO-MPEG2] require that the header of this new TS Packet carry a PUSI value of 1 and a Payload Pointer value of 0x00.)
(iv) TS Packetに2バイト以上の未使用のペイロードがあるなら、Encapsulatorはこの部分的に完全なTS Packetを伝えるかもしれませんが、最初に、すべての残っている未使用のバイトに値の0xFFを置かなければなりません(Paddingですなわち、End Indicatorを設定するということになりました)。 そして、Encapsulatorは新しいTS Packetの次のSNDUのトランスミッションを始めなければなりません。 (標準の規則[ISO-MPEG2]は、この新しいTS Packetのヘッダーが1のPUSI値と0×00の有効搭載量Pointer価値を運ぶのを必要とします。)
(v) If at least two bytes are available for SNDU data in the TS Packet payload (i.e., three bytes if the PUSI was NOT previously set, and two bytes if it was previously set), the Encapsulator MAY encapsulate further queued PDUs, by starting the next SNDU in the next available byte of the current TS Packet payload. When the Encapsulator packs further SNDUs into a TS Packet where the PUSI has
(v) TS PacketペイロードのSNDUデータについて、少なくとも2バイトがあるなら(PUSIがあったなら、すなわち、3バイトは以前にセットしませんでした、そして、それがあったなら、2バイトは以前に、セットしました)、Encapsulatorは一層の列に並ばせられたPDUsを要約するかもしれません、現在のTS Packetペイロードの次の有効なバイトで次のSNDUを始動することによって。 EncapsulatorがPUSIがそうしたTS Packetに一層のSNDUsに詰め込むとき
Fairhurst & Collini-Nocker Standards Track [Page 24] RFC 4326 ULE for IP over MPEG-2/DVB December 2005
FairhurstとCollini-ノッカーStandardsはMPEG-2/DVBの上の2005年12月にIPのためにRFC4326ULEを追跡します[24ページ]。
NOT already been set, the PUSI MUST be updated (set to 1), and an 8-bit Payload Pointer MUST be inserted in the first byte directly following the TS Packet header. (This reduces the size of the TS Packet payload field that is available for data by one byte.) The value of the Payload Pointer MUST be set to the position of the byte following the end of the first SNDU in the TS Packet payload. If no further PDUs are available, an Encapsulator MAY wait for additional PDUs to fill the incomplete TS Packet. The maximum period of time an Encapsulator can wait, known as the Packing Threshold, MUST be bounded and SHOULD be configurable in the Encapsulator. If sufficient additional PDUs are NOT received to complete the TS Packet within the Packing Threshold, the Encapsulator MUST insert an End Indicator (using rule iv).
セット、既にPUSI MUSTでない、アップデートしてください。そうすれば(1に設定します)、直接TS Packetヘッダーに続いて、8ビットの有効搭載量Pointerを最初のバイトに挿入しなければなりません。 (これはデータに1バイト利用可能なTS Packetペイロード分野のサイズを減少させます。) 有効搭載量Pointerの値はTS Packetペイロードにおける最初のSNDUの端に続くバイトの位置へのセットでなければなりません。 一層のどんなPDUsも利用可能でないなら、Encapsulatorは、追加PDUsが不完全なTS Packetをいっぱいにするのを待つかもしれません。 Packing Thresholdとして知られているEncapsulator缶の待ちは境界があるに違いない最大の期間とSHOULD、Encapsulatorで構成可能であってください。 十分な追加PDUsがPacking Thresholdの中でTS Packetを完成するために受け取られないなら、EncapsulatorはEnd Indicatorを挿入しなければなりません(規則ivを使用して)。
Use of the Packing method (v) by an Encapsulator is optional and may be determined on a per-session, per-packet, or per-SNDU basis.
EncapsulatorによるPacking方法(v)の使用は、任意であり、セッション、パケット、またはSNDUあたり1個のベースで決定しているかもしれません。
When an SNDU is less than the size of a TS Packet payload, a TS Packet may be formed that carries a PUSI value of one and also an End Indicator (using rule iv).
SNDUがTS Packetペイロードのサイズ以下であるときに、1のPUSI値とEnd Indicatorも運ぶTS Packetは形成されるかもしれません(規則ivを使用して)。
7. Receiver Processing
7. 受信機処理
A Receiver tunes to a specific TS Multiplex carrying a ULE Stream and sets a receive filter to accept all TS Packets with a specific PID. These TS Packets are associated with a specific TS Logical Channel and are reassembled to form a stream of SNDUs. A single Receiver may be able to receive multiple TS Logical Channels, possibly using a range of TS Multiplexes. In each case, reassembly MUST be performed independently for each TS Logical Channel. To perform this reassembly, the Receiver may use a buffer to hold the partially assembled SNDU, referred to here as the Current SNDU buffer. Other implementations may choose to use other data structures, but MUST provide equivalent operations.
ReceiverはULE Streamを運ぶ特定のTS Multiplexに波長を合わせます、そして、セットaは特定のPIDと共にすべてのTS Packetsを受け入れるためにフィルタを受けます。 これらのTS Packetsは、特定のTS Logical Channelに関連していて、SNDUsの流れを形成するために組み立て直されます。 ことによるとさまざまなTS Multiplexesを使用して、独身のReceiverは複数のTS Logical Channelsを受け取ることができるかもしれません。 その都度、各TS Logical Channelのために独自に再アセンブリを実行しなければなりません。 この再アセンブリを実行するなら、Receiverは、Current SNDUバッファとしてここと呼ばれた部分的に組み立てられたSNDUを持つのにバッファを使用するかもしれません。 他の実現は、他のデータ構造を使用するのを選ぶかもしれませんが、同等な操作を提供しなければなりません。
Receipt of a TS Packet with a PUSI value of 1 indicates that the TS Packet contains the start of a new SNDU. It also indicates the presence of the Payload Pointer (indicating the number of bytes to the start of the first SNDU in the TS-Packet currently being reassembled). It is illegal to receive a Payload Pointer value greater than 181, and this MUST cause the SNDU reassembly to be aborted and the Receiver to enter the Idle State. This event SHOULD be recorded as a payload pointer error.
1のPUSI値があるTS Packetの領収書は、TS Packetが新しいSNDUの始まりを含むのを示します。 また、それは有効搭載量Pointer(現在、バイト数をTS-パケットの最初のSNDUの始まりまで示します組み立て直される)の存在を示します。 有効搭載量Pointer価値より多くの181を受けるのが不法であり、これは、SNDU reassemblyが中止されるのに入って、ReceiverはIdle州に入らなければなりません。 このイベントSHOULD、ペイロードポインタ誤りとして、記録されてください。
A Receiver MUST support the use of both the Packing and Padding method for any received SNDU and MUST support reception of SNDUs with or without a Destination Address Field (i.e., D=0 and D=1).
ReceiverはPackingとPadding方法の両方のどんな容認されたSNDUの使用も支持しなければならなくて、Destination Address Field(すなわち、D=0とD=1)のあるなしにかかわらずSNDUsのレセプションを支持しなければなりません。
Fairhurst & Collini-Nocker Standards Track [Page 25] RFC 4326 ULE for IP over MPEG-2/DVB December 2005
FairhurstとCollini-ノッカーStandardsはMPEG-2/DVBの上の2005年12月にIPのためにRFC4326ULEを追跡します[25ページ]。
7.1. Idle State
7.1. 活動していない状態
After initialisation or errors, or on receipt of an End Indicator, the Receiver enters the Idle State. In this state, the Receiver discards all TS Packets until it discovers the start of a new SNDU, upon which it then enters the Reassembly State. Figure 16 outlines these state transitions:
初期化処理か誤りの、後かEnd Indicatorを受け取り次第、ReceiverはIdle州に入ります。 この状態では、次に、それがReassembly州を入れる新しいSNDUの始まりを発見するまで、ReceiverはすべてのTS Packetsを捨てます。 図16はこれらの状態遷移について概説します:
+-------+
| START |
+---+---+
|
\/
+----------+
\| Idle |/
+-------/| State |\-------+
Insufficient | +----+-----+ |
unused space | | PUSI set | MPEG-2 TS Error
or | \/ | or
End Indicator| +----------+ | SNDU Error
| |Reassembly| |
+--------| State |--------+
+----------+
+-------+ | 始め| +---+---+ | \/ +----------+ \| 怠けてください。|/ +-------/| 状態|\-------+不十分です。| +----+-----+ | 未使用のスペース| | PUSIはセットしました。| またはMPEG-2tの誤り。| \/ | または、インディケータを終わらせてください。| +----------+ | SNDU誤り| |Reassembly| | +--------| 状態|--------+ +----------+
Figure 16: Receiver state transitions
図16: 受信機状態遷移
7.1.1. Idle State Payload Pointer Checking
7.1.1. 無駄な州の有効搭載量ポインタの照合
A Receiver in the Idle State MUST check the PUSI value in the header of all received TS Packets. A PUSI value of 1 indicates the presence of a Payload Pointer. Following a loss of synchronisation, values between 0 and 181 are permitted, in which case the Receiver MUST discard the number of bytes indicated by the Payload Pointer (counted from the first byte of the TS Packet payload field, and excluding the PP field itself), before leaving the Idle State. It then enters the Reassembly State, and starts reassembly of a new SNDU at this point.
Idle州におけるReceiverはすべての容認されたTS PacketsのヘッダーでPUSI値をチェックしなければなりません。 1のPUSI値は有効搭載量Pointerの存在を示します。 連動の損失に続いて、0と181の間の値は可能にされます、その場合、Receiverが有効搭載量Pointer(TS Packetペイロード分野と、PP分野自体を除く最初のバイトから、数える)によって示されたバイト数を捨てなければなりません、Idleを州に残す前に。 それは、次に、Reassembly州に入って、ここに新しいSNDUの再アセンブリを始動します。
7.2. Processing of a Received SNDU
7.2. 容認されたSNDUの処理
When in the Reassembly State, the Receiver reads a 2-byte SNDU Length field from the TS Packet payload. If the value is less than or equal to 4, or equal to 0xFFFF, the Receiver discards the Current SNDU and the remaining TS Packet payload and returns to the Idle State. Receipt of an invalid Length field is an error event and SHOULD be recorded as an SNDU length error.
Reassembly州では、ReceiverがTS Packetペイロードから2バイトのSNDU Length分野を読むとき。 値が4以下、または0xFFFFの同輩であるなら、ReceiverはCurrent SNDUと残っているTS Packetペイロードを捨てて、Idle州に戻ります。 記録されていて、無効のLength分野の領収書は、SNDU長さの誤りとして誤り出来事とSHOULDです。
Fairhurst & Collini-Nocker Standards Track [Page 26] RFC 4326 ULE for IP over MPEG-2/DVB December 2005
FairhurstとCollini-ノッカーStandardsはMPEG-2/DVBの上の2005年12月にIPのためにRFC4326ULEを追跡します[26ページ]。
If the Length of the Current SNDU is greater than 4, the Receiver accepts bytes from the TS Packet payload to the Current SNDU buffer until either Length bytes in total are received, or the end of the TS Packet is reached (see also 7.2.1). When the Current SNDU length equals the value of the Length field, the Receiver MUST calculate and verify the CRC value (see 4.6). SNDUs that contain an invalid CRC value MUST be discarded. Mismatch of the CRC is an error event and SHOULD be recorded as a CRC error. The underlying physical-layer processing (e.g., forward error correction coding) often results in patterns of errors, rather than single bit errors, so the Receiver needs to be robust to arbitrary patterns of corruption to the TS Packet and payload, including potential corruption of the PUSI, PP, and SNDU Length fields. Therefore, a Receiver SHOULD discard the remaining TS Packet payload (if any) following a CRC mismatch and return to the Idle State.
Receiverが、Current SNDUのLengthが4歳以上であるなら、Lengthバイトが合計でそうであることのTS PacketペイロードからCurrent SNDUバッファまでのバイトが受け取られていると受け入れるか、またはTS Packetの端に達している、(参照、7.2、.1、) Current SNDUの長さがLength分野の値と等しいと、ReceiverはCRC値を計算して、確かめなければなりません(4.6を見てください)。 無効のCRC値を含むSNDUsを捨てなければなりません。 記録されていて、CRCのミスマッチは、CRC誤りとして誤り出来事とSHOULDです。 基本的な物理的な層の処理(例えば、前進型誤信号訂正コード化)がしばしばただ一つの噛み付いている誤りよりむしろ誤りのパターンをもたらすので、Receiverは、TS Packetとペイロードへの不正の任意のパターンに強健である必要があります、PUSI、PP、およびSNDU Length分野の潜在的不正を含んでいて。 したがって、Receiver SHOULDはCRCミスマッチに続いて、残っているTS Packetペイロード(もしあれば)を捨てて、Idle州に戻ります。
When the Destination Address is present (D=0), the Receiver accepts SNDUs that match one of a set of addresses specified by the Receiver (this includes the NPA address of the Receiver, the NPA broadcast address, and any required multicast NPA addresses). The Receiver MUST silently discard an SNDU with an unmatched address.
Destination Addressが存在しているとき(D=0)、ReceiverはReceiverによって指定された1セットのアドレスの1つに合っているSNDUsを受け入れます(これはReceiverのNPAアドレス、NPA放送演説、およびどんな必要なマルチキャストNPAアドレスも含んでいます)。 Receiverは優れたアドレスで静かにSNDUを捨てなければなりません。
After receiving a valid SNDU, the Receiver MUST check the Type field (and process any Type 1 Extension Headers). The SNDU payload is then passed to the next protocol layer specified. An SNDU with an unknown Type value < 1536 MUST be discarded. This error event SHOULD be recorded as an SNDU type error.
有効なSNDUを受けた後に、ReceiverはType分野をチェックしなければなりません(あらゆるType1Extension Headersを処理してください)。 そして、SNDUペイロードは指定された次のプロトコル層に渡されます。 未知のType値の<1536とSNDUを捨てなければなりません。 この誤りイベントSHOULD、SNDUタイプ誤りとして、記録されてください。
The Receiver then starts reassembly of the next SNDU. This MAY directly follow the previously reassembled SNDU within the TS Packet payload.
そして、Receiverは次のSNDUの再アセンブリを始動します。 これはTS Packetペイロードの中に直接以前に組み立て直されたSNDUに続くかもしれません。
(i) If the Current SNDU finishes at the end of a TS Packet payload, the Receiver MUST enter the Idle State.
(i) Current SNDUがTS Packetペイロードの端で終わるなら、ReceiverはIdle州に入らなければなりません。
(ii) If only one byte remains unprocessed in the TS Packet payload after completion of the Current SNDU, the Receiver MUST discard this final byte of TS Packet payload. It then enters the Idle State. It MUST NOT record an error when the value of the remaining byte is identical to 0xFF.
(ii) 1バイトだけがCurrent SNDUの完成の後にTS Packetペイロードで未加工のままで残っているなら、ReceiverはTS Packetペイロードのこの最終的なバイトを捨てなければなりません。 そして、それはIdle州に入ります。 残っているバイトの値が0xFFと同じであるときに、それは誤りを記録してはいけません。
(iii) If two or more bytes of TS Packet payload data remain after completion of the Current SNDU, the Receiver accepts the next 2 bytes and examines whether this is an End Indicator. When an End Indicator is received, a Receiver MUST silently discard the remainder of the TS Packet payload and transition to the Idle State. Otherwise, this is the start of the next Packed SNDU, and the Receiver continues by processing this SNDU. (This is provided that the TS Packet has a
(iii) 2バイト以上のTS PacketペイロードデータがCurrent SNDUの完成の後に残っているなら、Receiverは、次の2バイト受け入れて、これがEnd Indicatorであるかどうか調べます。 End Indicatorが受け取られているとき、Receiverは静かにIdle州へのTS Packetペイロードと変遷の残りを捨てなければなりません。 さもなければ、これは次のPacked SNDUの始動です、そして、Receiverは処理でこのSNDUを続けています。 (これはTS Packetでaがあるかどうかということです。
Fairhurst & Collini-Nocker Standards Track [Page 27] RFC 4326 ULE for IP over MPEG-2/DVB December 2005
FairhurstとCollini-ノッカーStandardsはMPEG-2/DVBの上の2005年12月にIPのためにRFC4326ULEを追跡します[27ページ]。
PUSI value of 1, see 7.2.1; otherwise, the Receiver has detected a delimiting error and MUST discard all remaining bytes in the TS Packet payload and transitions to the Idle State.)
PUSIが評価する、1では、7.2に.1を見てください。 さもなければ、Receiverは区切り誤りを検出して、TS Packetペイロードのすべての残っているバイトとIdle州への変遷を捨てなければなりません。)
7.2.1. Reassembly Payload Pointer Checking
7.2.1. Reassembly有効搭載量ポインタの照合
A Receiver that has partially received an SNDU (in the Current SNDU buffer) MUST check the PUSI value in the header of all subsequent TS Packets with the same PID (i.e., same TS Logical Channel). If it receives a TS Packet with a PUSI value of 1, it MUST then verify the Payload Pointer. If the Payload Pointer does NOT equal the number of bytes remaining to complete the Current SNDU (i.e., the difference between the SNDU Length field and the number of reassembled bytes), the Receiver has detected a delimiting error.
SNDU(Current SNDUバッファの)を部分的に受けたReceiverはすべてのその後のTS Packetsのヘッダーで同じPID(すなわち、同じTS Logical Channel)にPUSI値について問い合わせなければなりません。 1のPUSI値でTS Packetを受けるなら、それは有効搭載量Pointerについて確かめなければなりません。 有効搭載量PointerがCurrent SNDU(すなわち、SNDU Length分野と組み立て直されたバイトの数の違い)を完成するために残っているバイト数と等しくないなら、Receiverは区切り誤りを検出しました。
Following a delimiting error, the Receiver MUST discard the partially assembled SNDU (in the Current SNDU buffer) and SHOULD record a reassembly error. It MUST then re-enter the Idle State.
区切り誤りに続いて、Receiverは部分的に組み立てられたSNDU(Current SNDUバッファの)を捨てなければなりません、そして、SHOULDは再アセンブリ誤りを記録します。 そして、それはIdle州に再入しなければなりません。
7.3. Other Error Conditions
7.3. 他のエラー条件
The Receiver SHOULD check the MPEG-2 Transport Error Indicator carried in the TS Packet header [ISO-MPEG2]. This flag indicates a transmission error for a TS Logical Channel. If the flag is set to a value of one, a transmission error event SHOULD be recorded. Any partially received SNDU MUST be discarded. The Receiver then enters the Idle State.
Receiver SHOULDはTS Packetヘッダー[ISO-MPEG2]で運ばれたMPEG-2Transport Error Indicatorをチェックします。 この旗はTS Logical Channelのために伝送エラーを示します。 旗が1、伝送エラーイベントの値にSHOULDを設定することであるなら、記録されてください。 捨てられて、いずれもSNDU MUSTを部分的に受けました。 そして、ReceiverはIdle州に入ります。
The Receiver MUST check the MPEG-2 Continuity Counter carried in the TS Packet header [ISO-MPEG2]. If two (or more) successive TS Packets within the same TS Logical Channel carry the same Continuity Counter value, the duplicate TS Packets MUST be silently discarded. If the received value is NOT identical to that in the previous TS Packet, and it does NOT increment by one for successive TS Packets (modulo 16), the Receiver has detected a continuity error. Any partially received SNDU MUST be discarded. A continuity counter error event SHOULD be recorded. The Receiver then enters the Idle State.
ReceiverはTS Packetヘッダー[ISO-MPEG2]で運ばれたMPEG-2Continuity Counterをチェックしなければなりません。 同じTS Logical Channelの中の2(さらに)連続したTS Packetsが同じContinuity Counter値を運ぶなら、静かに写しTS Packetsを捨てなければなりません。 容認された値が前のTS Packetでそれと同じでなく、またそれが連続したTS Packetsのために(法16)を1つ増加しないなら、Receiverは連続誤りを検出しました。 捨てられて、いずれもSNDU MUSTを部分的に受けました。 記録されていて、連続は誤りイベントSHOULDを打ち返します。 そして、ReceiverはIdle州に入ります。
Note that an MPEG2-2 Transmission network is permitted to carry duplicate TS Packets [ISO-MPEG2], which are normally detected by the MPEG-2 Continuity Counter. A Receiver that does not perform the above Continuity Counter check would accept duplicate copies of TS Packets to the reassembly procedure. In most cases, the SNDU CRC-32 integrity check will result in discard of these SNDUs, leading to unexpected PDU loss; however, in some cases, duplicate PDUs (fitting into one TS Packet) could pass undetected to the next layer protocol.
MPEG2-2 Transmissionネットワークが通常、MPEG-2Continuity Counterによって検出される写しTS Packets[ISO-MPEG2]を運ぶことが許可されていることに注意してください。 上のContinuity Counterチェックを実行しないReceiverはTS Packetsの写本を再アセンブリ手順に受け入れるでしょう。 多くの場合、SNDU CRC-32保全チェックはこれらのSNDUsの破棄をもたらして、予期していなかったPDUの損失を出すでしょう。 しかしながら、いくつかの場合、写しPDUs(1TS Packetに収まる)は次の層のプロトコルに気付かれずに済むかもしれません。
Fairhurst & Collini-Nocker Standards Track [Page 28] RFC 4326 ULE for IP over MPEG-2/DVB December 2005
FairhurstとCollini-ノッカーStandardsはMPEG-2/DVBの上の2005年12月にIPのためにRFC4326ULEを追跡します[28ページ]。
8. Summary
8. 概要
This document defines a Unidirectional Lightweight Encapsulation (ULE) that performs efficient and flexible support for IPv4 and IPv6 network services over networks built upon the MPEG-2 Transport Stream (TS). The encapsulation is also suited to transport of other protocol packets and bridged Ethernet frames.
このドキュメントはIPv4の効率的でフレキシブルなサポートを実行するUnidirectionalライト級Encapsulation(ULE)を定義します、そして、ネットワークの上のIPv6ネットワーク・サービスはMPEG-2Transport Stream(TS)を当てにしました。 また、カプセル化は他のプロトコルパケットと橋を架けられたイーサネットフレームの輸送に合っています。
ULE also provides an Extension Header format and defines an associated IANA registry for efficient and flexible support of both mandatory and optional SNDU headers. This allows for future extension of the protocol, while providing backwards compatibility with existing implementations. In particular, Optional Extension Headers may safely be ignored by Receivers that do not implement them, or choose not to process them.
ULEは義務的なものと同様に任意のSNDUヘッダーの効率的でフレキシブルなサポートのためにまた、Extension Header形式を提供して、関連IANA登録を定義します。 これは既存の実現との互換性を後方に提供している間、プロトコルの今後の拡大を考慮します。 特に、Optional Extension Headersは彼らを実行しないか、または彼らを処理しないのを選ばないReceiversによって安全に無視されるかもしれません。
9. Acknowledgements
9. 承認
This document is based on a previous document authored by: Horst D. Clausen, Bernhard Collini-Nocker, Hilmar Linder, and Gorry Fairhurst. The authors wish to thank the members of the ip-dvb mailing list for their input; in particular, the many comments received from Art Allison, Carstsen Borman, Patrick Cipiere, Wolgang Fritsche, Hilmar Linder, Alain Ritoux, and William Stanislaus. Alain also provided the original examples of usage.
このドキュメントは以下によって書かれた前のドキュメントに基づいています。 地塁D.クローゼン、バーンハード・Collini-ノッカー、Hilmarランデール、およびゴーリーFairhurst。 作者は彼らの入力のためのip-dvbメーリングリストのメンバーに感謝したがっています。 特に、多くのコメントがArtアリソン、Carstsenボーマン、パトリックCipiere、Wolgangフリッチェ、Hilmarランデール、アランRitoux、およびウィリアムStanislausから受信されました。 また、アランは用法のオリジナルの例を提供しました。
10. Security Considerations
10. セキュリティ問題
The security considerations for ULE resemble those that arise when the existing Multi-Protocol Encapsulation (MPE) is used. ULE does not add specific new threats that will impact the security of the general Internet.
ULEのためのセキュリティ問題は既存のMulti-プロトコルEncapsulation(MPE)が使用されているとき起こるものに類似しています。 ULEは一般的なインターネットのセキュリティに影響を与える特定の新しい脅威を加えません。
There is a known security issue with un-initialised stuffing bytes. In ULE, these bytes are set to 0xFF (normal practice in MPEG-2).
不-初期化している詰め物のバイトには知られている安全保障問題があります。 ULEでは、これらのバイトは0xFF(MPEG-2における正常な習慣)に設定されます。
There are known integrity issues with the removal of the LAN FCS in a bridged networking environment. The removal for bridged frames exposes the traffic to potentially undetected corruption while being processed by the Encapsulator and/or Receiver.
橋を架けられたネットワーク環境における、LAN FCSの解任の保全問題は知られています。 Encapsulator、そして/または、Receiverによって処理されている間、橋を架けられたフレームのための取り外しは潜在的に非検出された不正に交通を暴露します。
There is a potential security issue when a Receiver receives a PDU with two Length fields: The Receiver would need to validate the actual length and the Length field and ensure that inconsistent values are not propagated by the network. In direct encapsulation of IPv4/IPv6 in ULE, this is avoided by including only one SNDU Length
Receiverが2つのLength分野があるPDUを受けるとき、潜在的安全保障問題があります: Receiverは実際の長さとLength分野を有効にして、矛盾した値がネットワークによって伝播されないのを保証する必要があるでしょう。 ULEのIPv4/IPv6のダイレクトカプセル化では、これは、1SNDU Lengthだけを含んでいることによって、避けられます。
Fairhurst & Collini-Nocker Standards Track [Page 29] RFC 4326 ULE for IP over MPEG-2/DVB December 2005
FairhurstとCollini-ノッカーStandardsはMPEG-2/DVBの上の2005年12月にIPのためにRFC4326ULEを追跡します[29ページ]。
Field. However, this issue still arises in bridged LLC frames, and frames with a LLC Length greater than the SNDU payload size MUST be discarded, and an SNDU payload length error SHOULD be recorded.
さばきます。 しかしながら、LLC LengthがSNDUペイロードサイズを捨てなければならないよりすばらしく、SNDUペイロード長誤りSHOULDが記録されている状態で、この問題は橋を架けられたLLCフレーム、およびフレームにまだ起こっています。
In the future, a ULE Mandatory Extension Header may be used to define a method to perform link encryption of the SNDU payload. This is as an additional security mechanism to IP-, transport-, or application- layer security, not a replacement [RFC4259]. The approach is generic and decouples the encapsulation from future security extensions. The operation provides functions that resemble those currently used with the MPE encapsulation.
将来、ULE Mandatory Extension Headerは、SNDUペイロードのリンク暗号化を実行する方法を定義するのに使用されるかもしれません。 追加担保メカニズムとして交換[RFC4259]ではなく、IP、輸送、またはアプリケーション層のセキュリティにはこれがあります。 アプローチは、一般的であり、今後のセキュリティ拡大からカプセル化の衝撃を吸収します。 操作は現在使用されているものに類似している機能にMPEカプセル化を提供します。
Additional security control fields may be provided as part of this link encryption Extension Header, e.g., to associate an SNDU with one of a set of Security Association (SA) parameters. As a part of the encryption process, it may also be desirable to authenticate some or all of the SNDU headers. The method of encryption and the way in which keys are exchanged is beyond the scope of this specification, as are the definition of the SA format and that of the related encryption keys.
例えば1セットのSecurity Association(SA)パラメタの1つにSNDUを関連づけるためにこのリンク暗号化Extension Headerの一部として追加担保制御フィールドを提供するかもしれません。 また、暗号化の過程の一部として、いくつかかSNDUヘッダーを皆、認証するのも望ましいかもしれません。 キーが交換される暗号化と方法の方法はこの仕様の範囲を超えています、SA形式の定義と関連する暗号化キーのもののように。
11. IANA Considerations
11. IANA問題
The IANA has created the ULE Next-Header Type field registry as defined in this document.
IANAは本書では定義されるようにULE Next-ヘッダーType分野登録を作成しました。
ULE Next-Header registry
ULE Next-ヘッダー登録
This registry allocates Next-Header values within the range 0-511
(decimal). For each allocated value, it also specifies the set of
allowed H-LEN values (see section 5). In combination, these
define a set of allowed values in the range 0-1535 for the first
part of the ULE Type space (see section 4.4.1).
この登録は範囲0-511(小数)の中のNext-ヘッダー値を割り当てます。 また、それぞれの割り当てられた値として、それは許容H-LEN値のセットを指定します(セクション5を見てください)。 組み合わせでは、これらは範囲0-1535で1セットの許容値をULE Typeスペースの最初の地域と定義します(セクション4.4.1を見てください)。
11.1. IANA Guidelines
11.1. IANAガイドライン
The following contains the IANA guidelines for management of the ULE Next-Header registry. This registry allocates values 0-511 decimal (0x0000-0x01FF, hexadecimal). It MUST NOT allocate values greater than 0x01FF (decimal).
以下はULE Next-ヘッダー登録の管理のためのIANAガイドラインを含んでいます。 この登録は値0-511小数(0×0000 0x01FF、16進)を割り当てます。 それは0x01FF(小数)より大きい値を割り当ててはいけません。
It subdivides the Next-Header registry in the following way:
それは以下の方法でNext-ヘッダー登録を分筆します:
1) 0-255 (decimal) IANA-assigned values, indicating Mandatory
Extension Headers (or link-dependent Type fields) for ULE,
requiring expert review leading to prior issue of an IETF RFC.
This specification MUST define the value and the name associated
with the Extension Header, together with the procedure for
1) 0-255(小数) IETF RFCの先の問題につながる専門のレビューを必要として、ULEのために、Mandatory Extension Headers(または、リンク依存するType分野)を示すIANA-割り当てられた値。 この仕様は手順と共にExtension Headerに関連している値と名前を定義しなければなりません。
Fairhurst & Collini-Nocker Standards Track [Page 30] RFC 4326 ULE for IP over MPEG-2/DVB December 2005
FairhurstとCollini-ノッカーStandardsはMPEG-2/DVBの上の2005年12月にIPのためにRFC4326ULEを追跡します[30ページ]。
processing the Extension Header. It MUST also define the need for
the Mandatory Extension and the intended use. The size of the
Extension Header MUST be specified.
Extension Headerを処理します。 また、それはMandatory Extensionの必要性と意図している使用を定義しなければなりません。 Extension Headerのサイズを指定しなければなりません。
Assignments have been made in this document, and registered by
IANA:
課題は、本書では作られていて、IANAによって登録されました:
Type Name Reference
型名参照
0: Test-SNDU Section 5.1
1: Bridged-SNDU Section 5.2
0: 試SNDU部5.1の1: 橋を架けられたSNDU部5.2
2) 256-511 (decimal) IANA-assigned values, indicating Optional
Extension Headers for ULE, requiring expert review leading to
prior issue of an IETF RFC. This specification MUST define the
value and the name associated with the Extension Header, together
with the procedure for processing the Extension Header. The entry
MUST specify the range of allowable H-LEN values that are
permitted (in the range 1-5). It MUST also define the need for
the Optional Extension and the intended use.
2) 256-511(小数) IETF RFCの先の問題につながる専門のレビューを必要として、ULEのためにOptional Extension Headersを示すIANA-割り当てられた値。 この仕様はExtension Headerに関連している値と名前を定義しなければなりません、Extension Headerを処理するための手順と共に。 エントリーは受入れられる(範囲1-5で)許容できるH-LEN値の範囲を指定しなければなりません。 また、それはOptional Extensionの必要性と意図している使用を定義しなければなりません。
Assignments have been made in this document, and registered by
IANA:
課題は、本書では作られていて、IANAによって登録されました:
Type Name H-LEN Reference
型名H-LEN参照
256: Extension-Padding 1-5 Section 5.3
256: 拡大をそっと歩く1-5セクション5.3
12. References
12. 参照
12.1. Normative References
12.1. 引用規格
[ISO-MPEG2] IS 13818-1, "Information technology -- Generic coding
of moving pictures and associated audio information --
Part 1: Systems", International Standards Organisation
(ISO), 2000.
[ISO-MPEG2]が13818-1である、「情報技術--映画と関連オーディオ情報の一般的なコード化--第1部:、」 「システム」、世界規格機構(ISO)、2000。
[RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, 1997.
[RFC2119] ブラドナー、S.、「使用のための要件レベルを示すRFCsのキーワード」、BCP14、RFC2119、1997。
[RFC1112] Deering, S., "Host extensions for IP multicasting",
STD 5, RFC 1112, August 1989.
[RFC1112] デアリング、S.、「IPマルチキャスティングのためのホスト拡大」、STD5、RFC1112、1989年8月。
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over
Ethernet Networks", RFC 2464, December 1998.
[RFC2464] クロフォード、M.、「イーサネットネットワークの上のIPv6パケットのトランスミッション」、RFC2464、1998年12月。
Fairhurst & Collini-Nocker Standards Track [Page 31] RFC 4326 ULE for IP over MPEG-2/DVB December 2005
FairhurstとCollini-ノッカーStandardsはMPEG-2/DVBの上の2005年12月にIPのためにRFC4326ULEを追跡します[31ページ]。
[ULE1] Registration for format_identifier ULE1, SMPTE
Registration Authority, LLC,
http://www.smpte-ra.org/ule1.html.
形式_識別子ULE1、SMPTE Registration Authority、LLC、 http://www.smpte-ra.org/ule1.html のための[ULE1]登録。
12.2. Informative References
12.2. 有益な参照
[IPDVB-AR] Fairhurst, G. and M-J. Montpetit, "Address Resolution
for IP datagrams over MPEG-2 Networks", Work in
Progress, September 2005.
[IPDVB-AR] Fairhurst、G.、およびM J。 Montpetit、「MPEG-2Networksの上のIPデータグラムのためのアドレスResolution」、Progress、2005年9月のWork。
[ATSC] A/53, "ATSC Digital Television Standard", Advanced
Television Systems Committee (ATSC), Doc. A/53 Rev.C,
2004
[ATSC] Doc、「ATSCのデジタルテレビジョン標準規格」という/53はテレビジョン方式委員会(ATSC)を進めました。 53人の/C師、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。
[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-G] A/54, "Guide to the use of the ATSC Digital Television
Standard", Advanced Television Systems Committee
(ATSC), Doc. A/54, 1995.
[ATSC-G] /54、「ATSC Digital Television Standardの使用へのガイド」、Advanced Television Systems Committee(ATSC)、Doc。 /54、1995。
[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-REG] ATSC "Code Point Registry"
www.atsc.org/standards/Code_Point_Registry.pdf.
_[ATSC-レッジ]ATSC「コード・ポイント登録」www.atsc.org/規格/コードポイント_Registry.pdf。
[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。
[DIX] Digital Equipment Corp, Intel Corp, Xerox Corp,
"Ethernet Local Area Network Specification" Version
2.0, November 1982.
[DIX] デジタル機器Corp、インテルCorp、ゼロックスCorp、「イーサネットローカル・エリア・ネットワーク仕様」バージョン2.0、1982年11月。
[ETSI-DAT] EN 301 192, "Specifications for Data Broadcasting",
European Telecommunications Standards Institute
(ETSI), 2004.
[ETSI-DAT] アン301 192、「データ・ブロードキャスティングのための仕様」、規格が設けるヨーロッパのテレコミュニケーション(ETSI)、2004。
[ETSI-DVBC] EN 300 800, "Digital Video Broadcasting (DVB); DVB
interaction channel for Cable TV distribution systems
(CATV)", European Telecommunications Standards
Institute (ETSI), 1998.
[ETSI-DVBC]アン300 800、「(DVB)を放送するデジタルビデオ」。 「ケーブルTV流通制度のためのDVB相互作用チャンネル(CATV)」、ヨーロッパのTelecommunications Standards Institute(ETSI)、1998。
Fairhurst & Collini-Nocker Standards Track [Page 32] RFC 4326 ULE for IP over MPEG-2/DVB December 2005
FairhurstとCollini-ノッカーStandardsはMPEG-2/DVBの上の2005年12月にIPのためにRFC4326ULEを追跡します[32ページ]。
[ETSI-DVBS] EN 300 421, "Digital Video Broadcasting (DVB);
Modulation and Coding for DBS satellite systems at
11/12 GHz", European Telecommunications Standards
Institute (ETSI), 1997.
[ETSI-DVBS]アン300 421、「(DVB)を放送するデジタルビデオ」。 「11/12ギガヘルツにおけるDBSサテライト・システムのための変調とCoding」、ヨーロッパのTelecommunications Standards Institute(ETSI)、1997
[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), 2004.
[ETSI-DVBT]アン300 744、「(DVB)を放送するデジタルビデオ」。 「地上波デジタル・テレビジョン(DVB-T)のための構造、チャンネル・コーディング、および変調を縁どっています」、ヨーロッパのTelecommunications Standards Institute(ETSI)、2004。
[ETSI-RCS] ETSI 301 790, "Digital Video Broadcasting (DVB);
Interaction Channel for Satellite Distribution
Systems", European Telecommunications Standards
Institute (ETSI), 2005.
[ETSI-RCS]ETSI301 790、「(DVB)を放送するデジタルビデオ」。 「衛星流通制度のための相互作用チャンネル」、規格が設けるヨーロッパのテレコミュニケーション(ETSI)、2005。
[IEEE-802.2] IEEE 802.2, "Local and metropolitan area networks-
Specific requirements Part 2: Logical Link Control",
IEEE Computer Society, (also ISO/IEC 8802-2), 1998.
[IEEE-802.2]IEEE802.2、「地方とメトロポリタンエリアネットワーク決められた一定の要求Part2:」 「論理的なリンク制御」、IEEEコンピュータ社会、(ISO/IEC8802-2も)、1998。
[IEEE-802.3] IEEE 802.3, "Local and metropolitan area networks-
Specific requirements Part 3: Carrier sense multiple
access with collision detection (CSMA/CD) access
method and physical layer specifications", IEEE
Computer Society, (also ISO/IEC 8802-3), 2002.
[IEEE-802.3]IEEE802.3、「地方とメトロポリタンエリアネットワーク決められた一定の要求Part3:」 「衝突検出(CSMA/CD)アクセス法と物理的な層の仕様がある搬送波感知多重アクセス」、IEEEコンピュータSociety、(ISO/IEC8802-3も)、2002。
[ISO-DSMCC] IS 13818-6, "Information technology -- Generic coding
of moving pictures and associated audio information --
Part 6: Extensions for DSM-CC", International
Standards Organisation (ISO), 1998.
[ISO-DSMCC]による13818-6 「情報技術(映画と関連オーディオ情報の一般的なコード化)は6を分ける」ということです。 「DSM-CCのための拡大」、世界規格機構(ISO)、1998。
[ITU-H222] H.222.0, "Information technology - Generic coding of
moving pictures and associated audio information:
Systems", International Telecommunication Union,
(ITU-T), 1995.
[ITU-H222] H.222.0、「情報技術--映画と関連オーディオ情報の一般的なコード化:、」 「システム」、国際電気通信連合、(ITU-T)、1995。
[ITU-3563] I.363.5, "B-ISDN ATM Adaptation Layer specification:
Type 5 AAL", International Telecommunication Union,
(ITU-T), 1996.
[ITU-3563] I.363.5、「B-ISDN ATM Adaptation Layer仕様:」 「タイプ5AAL」、国際電気通信連合、(ITU-T)、1996。
[ISO-8802-2] ISO/IEC 8802.2, "Logical Link Control", International
Standards Organisation (ISO), 1998.
[ISO-8802-2]ISO/IEC8802.2、「論理的なリンク制御」、世界規格機構(ISO)、1998。
[RFC3077] Duros, E., Dabbous, W., Izumiyama, H., Fujii, N., and
Y. Zhang, "A Link-Layer Tunneling Mechanism for
Unidirectional Links", RFC 3077, March 2001.
[RFC3077] Duros、E.、Dabbous、W.、Izumiyama、H.、藤井、N.、およびY.チャン、「単方向の間のリンクレイヤトンネリングメカニズムはリンクします」、RFC3077、2001年3月。
Fairhurst & Collini-Nocker Standards Track [Page 33] RFC 4326 ULE for IP over MPEG-2/DVB December 2005
FairhurstとCollini-ノッカーStandardsはMPEG-2/DVBの上の2005年12月にIPのためにRFC4326ULEを追跡します[33ページ]。
[RFC3309] Stone, J., Stewart, R., and D. Otis, "Stream Control
Transmission Protocol (SCTP) Checksum Change", RFC
3309, September 2002.
[RFC3309] ストーン、J.、スチュワート、R.、およびD.オーティス、「流れの制御伝動プロトコル(SCTP)チェックサム変化」、RFC3309、2002年9月。
[RFC4259] Montpetit, M.-J., Fairhurst, G., Clausen, H.,
Collini-Nocker, B., and H. Linder, "A Framework for
Transmission of IP Datagrams over MPEG-2 Networks",
RFC 4259, November 2005.
[RFC4259]Montpetit、M.J.、Fairhurst、G.、クローゼン、H.、Collini-ノッカー、B.、およびH.ランデール、「MPEG-2つのネットワークの上のIPデータグラムの送信のための枠組み」、RFC4259(2005年11月)。
[SOOR05] M. Sooriyabandara, G. Fairhurst, A. Ang, B. Collini-
Nocker, H. Linder, W. Stering "A Lightweight
Encapsulation Protocol for IP over MPEG-2 Networks:
Design, Implementation and Analysis", Computer
Networks 48 p5-19, 2005.
B.Collini[SOOR05]M.Sooriyabandara、G.Fairhurst、A.アン、ノッカー、H.ランデール、W.Stering、「MPEG-2つのネットワークの上のIPのための軽量のカプセル化プロトコル:」 「デザイン、Implementation、およびAnalysis」、コンピュータNetworks48p5-19、2005
Fairhurst & Collini-Nocker Standards Track [Page 34] RFC 4326 ULE for IP over MPEG-2/DVB December 2005
FairhurstとCollini-ノッカーStandardsはMPEG-2/DVBの上の2005年12月にIPのためにRFC4326ULEを追跡します[34ページ]。
Appendix A: SNDU Packing Examples
付録A: 例を梱包するSNDU
This appendix provides some examples of use. The appendix is informative. It does not provide a description of the protocol. The examples provide the complete TS Packet sequence for some sample encapsulated IP packets.
この付録は使用に関するいくつかの例を提供します。 付録は有益です。 それはプロトコルの記述を提供しません。 例は何らかのサンプルのための完全なTS Packet系列に要約のIPパケットを提供します。
The specification of the TS Packet header operation and field values is provided in [ISO-MPEG2]. The specification of ULE is provided in the body of this document.
TS Packetヘッダー操作と分野値の仕様を[ISO-MPEG2]に提供します。 このドキュメントのボディーにULEの仕様を提供します。
The key below is provided for the following examples.
以下のキーを以下の例に提供します。
HDR 4B TS Packet Header PUSI Payload Unit Start Indicator PP Payload Pointer *** TS Packet Payload Pointer (PP)
HDR 4B t、パケットのヘッダーPUSI有効搭載量ユニットスタートインディケータpp有効搭載量ポインタ***tパケット、有効搭載量ポインタ(pp)
Example A.1: Two 186B PDUs.
例のA.1: 2 186B PDUs。
SNDU A is 200 bytes (including the ULE destination NPA address)
SNDU B is 200 bytes (including the ULE destination NPA address)
SNDU Aによる200バイト(ULE送付先NPAアドレスを含んでいる)のSNDU Bが200バイトであるということです。(ULE送付先NPAアドレスを含んでいます)
The sequence comprises 3 TS Packets:
系列は3TS Packetsを包括します:
SNDU
PP=0 Length
+-----+------+------+------+- -+------+
| HDR | 0x00 | 0x00 | 0xC4 | ... | A182 |
+-----+----*-+-*----+------+- -+------+
PUSI=1 * *
*****
SNDU
PP=17 CRC for A Length
+-----+------+------+- -+--- --+------+------+- -+------+
| HDR | 0x11 | A183 | ... | A199 | 0x00 | 0xC4 | ... | B165 |
+-----+----*-+------+- -+------+-*----+------+- -+------+
PUSI=1 * *
*************************
SNDU ppは0の長さ+と等しいです。-----+------+------+------+- -+------+ | HDR| 0×00| 0×00| 0xC4| ... | A182| +-----+----*-+-*----+------+- -+------長さ+のための17+ PUSI=1*******SNDU pp=CRC-----+------+------+- -+--- --+------+------+- -+------+ | HDR| 0×11| A183| ... | A199| 0×00| 0xC4| ... | B165| +-----+----*-+------+- -+------+-*----+------+- -+------+ PUSI=1***************************
End Stuffing
CRC for A Indicator Bytes
+-----+------+- -+------+----+----+- -+----+
| HDR | B166 | ... | B199 |0xFF|0xFF| ... |0xFF|
+-----+------+- -+------+----+----+- -+----+
PUSI=0
インディケータバイト+終わりの詰め物のCRC-----+------+- -+------+----+----+- -+----+ | HDR| B166| ... | B199|0xFF|0xFF| ... |0xFF| +-----+------+- -+------+----+----+- -+----+ PUSI=0
Fairhurst & Collini-Nocker Standards Track [Page 35] RFC 4326 ULE for IP over MPEG-2/DVB December 2005
FairhurstとCollini-ノッカーStandardsはMPEG-2/DVBの上の2005年12月にIPのためにRFC4326ULEを追跡します[35ページ]。
Example A.2: Usage of last byte in a TS-Packet
例のA.2: TS-パケットの最後のバイトの用法
SNDU A is 183 bytes
SNDU B is 182 bytes
SNDU C is 181 bytes
SNDU D is 185 bytes
SNDU Aによる183バイトのSNDU Bによる182バイトのSNDU Cによる181バイトのSNDU Dが185バイトであるということであるということであるということです。
The sequence comprises 4 TS Packets:
系列は4TS Packetsを包括します:
SNDU
PP=0 Length CRC for A
+-----+------+------+------+- -+------+
| HDR | 0x00 | 0x00 | 0xB3 | ... | A182 |
+-----+----*-+-*----+------+- -+------+
PUSI=1 * *
*****
SNDU Unused
PP=0 Length CRC for B byte
+-----+------+------+------+- -+------+------+
| HDR | 0x00 | 0x00 | 0xB2 | ... | B181 | 0xFF |
+-----+---*--+-*----+------+- -+------+------+
PUSI=1 * *
******
SNDU SNDU
PP=0 Length CRC for C Length
+-----+------+------+------+- -+------+------+------+
| HDR | 0x00 | 0x00 | 0xB1 | ... | C180 | 0x00 | 0x65 |
+-----+---*--+-*----+------+- -+------+------+------+
PUSI=1 * *
****** Unused
byte
+-----+------+- -+------+------+
| HDR | D002 | ... | D184 | 0xFF |
+-----+------+- -+------+------+
PUSI=0
SNDU ppは+のために0長さのCRCと等しいです。-----+------+------+------+- -+------+ | HDR| 0×00| 0×00| 0xB3| ... | A182| +-----+----*-+-*----+------+- -+------Bバイト+0長さの+ PUSI=1*******SNDU未使用のpp=CRC-----+------+------+------+- -+------+------+ | HDR| 0×00| 0×00| 0xB2| ... | B181| 0xFF| +-----+---*--+-*----+------+- -+------+------Cの長さ+のための0長さの+ PUSI=1********SNDU SNDU pp=CRC-----+------+------+------+- -+------+------+------+ | HDR| 0×00| 0×00| 0xB1| ... | C180| 0×00| 0×65| +-----+---*--+-*----+------+- -+------+------+------+ PUSI=1********未使用のバイト+-----+------+- -+------+------+ | HDR| D002| ... | D184| 0xFF| +-----+------+- -+------+------+ PUSI=0
Example A.3: Large SNDUs
例のA.3: 大きいSNDUs
SNDU A is 732 bytes SNDU B is 284 bytes
SNDU Aによる732バイトのSNDU Bが284バイトであるということです。
The sequence comprises 6 TS Packets:
系列は6TS Packetsを包括します:
Fairhurst & Collini-Nocker Standards Track [Page 36] RFC 4326 ULE for IP over MPEG-2/DVB December 2005
FairhurstとCollini-ノッカーStandardsはMPEG-2/DVBの上の2005年12月にIPのためにRFC4326ULEを追跡します[36ページ]。
SNDU
PP=0 Length
+-----+------+------+------+- -+------+
| HDR | 0x00 | 0x02 | 0xD8 | ... | A182 |
+-----+---*--+-*----+------+- -+------+
PUSI=1 * *
******
SNDU ppは0の長さ+と等しいです。-----+------+------+------+- -+------+ | HDR| 0×00| 0×02| 0xD8| ... | A182| +-----+---*--+-*----+------+- -+------+ PUSI=1********
+-----+------+- -+------+
| HDR | A183 | ... | A366 |
+-----+------+- -+------+
PUSI=0
+-----+------+- -+------+ | HDR| A183| ... | A366| +-----+------+- -+------+ PUSI=0
+-----+------+- -+------+
| HDR | A367 | ... | A550 |
+-----+------+- -+------+
PUSI=0
+-----+------+- -+------+ | HDR| A367| ... | A550| +-----+------+- -+------+ PUSI=0
SNDU
PP=181 CRC for A Length
+-----+------+------+- -+------+------+------+
| HDR | 0xB5 | A551 | ... | A731 | 0x01 | 0x18 |
+-----+---*--+------+- -+------+*-----+------+
PUSI=1 * *
*************************
SNDU ppは長さ+のために181CRCと等しいです。-----+------+------+- -+------+------+------+ | HDR| 0xB5| A551| ... | A731| 0×01| 0×18| +-----+---*--+------+- -+------+*-----+------+ PUSI=1***************************
+-----+------+- -+------+
| HDR | B002 | ... | B185 |
+-----+------+- -+------+
PUSI=0
+-----+------+- -+------+ | HDR| B002| ... | B185| +-----+------+- -+------+ PUSI=0
End Stuffing
Indicator Bytes
+-----+------+- -+------+------+------+- -+------+
| HDR | B186 | ... | B283 | 0xFF | 0xFF | ... | 0xFF |
+-----+------+- -+------+------+------+- -+------+
PUSI=0
終わりの詰め物のインディケータバイト+-----+------+- -+------+------+------+- -+------+ | HDR| B186| ... | B283| 0xFF| 0xFF| ... | 0xFF| +-----+------+- -+------+------+------+- -+------+ PUSI=0
Fairhurst & Collini-Nocker Standards Track [Page 37] RFC 4326 ULE for IP over MPEG-2/DVB December 2005
FairhurstとCollini-ノッカーStandardsはMPEG-2/DVBの上の2005年12月にIPのためにRFC4326ULEを追跡します[37ページ]。
Example A.4: Illustration of SNDU Length field
例のA.4: SNDU Length分野のイラスト
SNDU A is 200 bytes
SNDU B is 60 bytes
SNDU C is 60 bytes
SNDU Aによる200バイトのSNDU Bによる60バイトのSNDU Cが60バイトであるということであるということです。
The sequence comprises two TS Packets:
系列は2TS Packetsを包括します:
SNDU
PP=0 Length
+-----+------+------+------+- -+------+
| HDR | 0x00 | 0x00 | 0xC4 | ... | A182 |
+-----+----*-+-*----+------+- -+------+
PUSI=1 * * + +
***** ++++++++
+
+++++++++++++++++
+ SNDU
PP=17 CRC for A + Length
+-----+------+------+- -+------+-+----+------+-
| HDR | 0x11 | A183 | ... | A199 | 0x00 | 0x38 | ...
+-----+----*-+------+- -+------+*-----+------+-
PUSI=1 * * + +
************************ +++++++++
+
+++++++++++++++++++++++++++++++++++++++
+
+ SNDU End Stuffing
+ Length Indicator bytes
+ -+------+------+------+ -+------+------+------+- -+------+
+ ... | B59 | 0x00 | 0x38 |...| C59 | 0xFF | 0xFF |...| 0xFF |
+ -+------+-+----+------+ -+------+-+----+------+- -+------+
+ + + + +
+ + ++++++++ +
+ + + +
++++++++++++++++ ++++++++++++++++++++++
SNDU ppは0の長さ+と等しいです。-----+------+------+------+- -+------+ | HDR| 0×00| 0×00| 0xC4| ... | A182| +-----+----*-+-*----+------+- -+------+長さ+のための17+ PUSI=1**++*****+++++++++++++++++++++++++++SNDU pp=CRC-----+------+------+- -+------+-+----+------+- | HDR| 0×11| A183| ... | A199| 0×00| 0×38| ... +-----+----*-+------+- -+------+*-----+------長さ..バイト------+------+------+ -+------+------+------+- -+------+ + ... | B59| 0×00| 0×38|...| C59| 0xFF| 0xFF|...| 0xFF| + -+------+-+----+------+ -+------+-+----+------+- -+------+ + + + + + + + ++++++++ + + + + + ++++++++++++++++ ++++++++++++++++++++++
*** TS Packet Payload Pointer (PP) +++ ULE Length Indicator
*** t、パケット有効搭載量ポインタ(pp)+++ULE長さのインディケータ
Fairhurst & Collini-Nocker Standards Track [Page 38] RFC 4326 ULE for IP over MPEG-2/DVB December 2005
FairhurstとCollini-ノッカーStandardsはMPEG-2/DVBの上の2005年12月にIPのためにRFC4326ULEを追跡します[38ページ]。
Example A.5: Three 44B PDUs.
例のA.5: 3 44B PDUs。
SNDU A is 52 bytes (no ULE destination NPA address) SNDU B is 52
bytes (no ULE destination NPA address) SNDU C is 52 bytes (no ULE
destination NPA address)
SNDU Aによる(ULE送付先NPAアドレスがありません)SNDU Bが52バイト、52バイト(ULE送付先NPAアドレスがない)のSNDU Cが52バイトであるということであるということです。(ULE送付先NPAアドレスがありません)
The sequence comprises 1 TS Packet:
系列は1TS Packetを包括します:
SNDU
PP=0 Length
+-----+------+------+------+- -+-----+------+------+- -+-----+-
| HDR | 0x00 | 0x80 | 0x30 | ... | A51 | 0x80 | 0x30 | ... | B51 | ..
+-----+----*-+-*----+------+- -+-----+------+------+- -+-----+-
PUSI=1 * *
*****
SNDU ppは0の長さ+と等しいです。-----+------+------+------+- -+-----+------+------+- -+-----+- | HDR| 0×00| 0×80| 0×30| ... | A51| 0×80| 0×30| ... | B51| .. +-----+----*-+-*----+------+- -+-----+------+------+- -+-----+PUSI=1*******
End Stuffing
Indicator bytes
-----+------+- -+-----+---------+- -+------+
... 0x80 | 0x30 | ... | C51 |0xFF|0xFF| | 0xFF |
-----+------+- -+-----+---------+- -+------+
終わりのStuffing Indicatorバイト-----+------+- -+-----+---------+- -+------+ ... 0×80| 0×30| ... | C51|0xFF|0xFF| | 0xFF| -----+------+- -+-----+---------+- -+------+
Fairhurst & Collini-Nocker Standards Track [Page 39] RFC 4326 ULE for IP over MPEG-2/DVB December 2005
FairhurstとCollini-ノッカーStandardsはMPEG-2/DVBの上の2005年12月にIPのためにRFC4326ULEを追跡します[39ページ]。
Appendix B: SNDU Encapsulation
付録B: SNDUカプセル化
An example of ULE encapsulation carrying an ICMPv6 packet generated by ping6.
ICMPv6パケットがping6で発生させたULEカプセル化携帯に関する例。
ULE SNDU Length : 63 decimal D-bit value : 0 (NPA destination address present) ULE Protocol Type : 0x86dd (IPv6) Destination ULE NPA Address : 00:01:02:03:04:05 ULE CRC32 : 0x7c171763
ウレSNDU Length: 63 10進D-ビット値: 0 (NPA目的地アドレスプレゼント)ULEプロトコルType: 0x86dd(IPv6)送付先ULE NPAアドレス: 00:01:02: 03:04:05ウレCRC32: 0x7c171763
Source IPv6 : 2001:DB8:3008:1965::1 Destination IPv6 : 2001:DB8:2509:1962::2
ソースIPv6: 2001 : DB8:3008:1965:、:1 目的地IPv6: 2001 : DB8:2509:1962:、:2
SNDU contents (including CRC-32):
SNDUコンテンツ(CRC-32を含んでいます):
0000: 00 3f 86 dd 00 01 02 03 04 05 60 00 00 00 00 0d 0016: 3a 40 20 01 0d b8 30 08 19 65 00 00 00 00 00 00 0032: 00 01 20 01 0d b8 25 09 19 62 00 00 00 00 00 00 0048: 00 02 80 00 9d 8c 06 38 00 04 00 00 00 00 00 7c 0064: 17 17 63
0000: 00 3f86dd00 01 02 03 04 05 60 00 00 00 00 0d0016: 3a40 20 01 0d b8 30 08 19 65 00 00 00 00 00 00 0032: 00 01 20 01 0d b8 25 09 19 62 00 00 00 00 00 00 0048: 00 02 80 00 9d 8c06 38 00 04 00 00 00 00 00 7c0064: 17 17 63
Fairhurst & Collini-Nocker Standards Track [Page 40] RFC 4326 ULE for IP over MPEG-2/DVB December 2005
FairhurstとCollini-ノッカーStandardsはMPEG-2/DVBの上の2005年12月にIPのためにRFC4326ULEを追跡します[40ページ]。
Authors' Addresses
作者のアドレス
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
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.scicomp.sbg.ac.at/
メール: bnocker@cosy.sbg.ac.at ウェブ: http://www.scicomp.sbg.ac.at/
Fairhurst & Collini-Nocker Standards Track [Page 41] RFC 4326 ULE for IP over MPEG-2/DVB December 2005
FairhurstとCollini-ノッカーStandardsはMPEG-2/DVBの上の2005年12月にIPのためにRFC4326ULEを追跡します[41ページ]。
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機能のための基金は現在、インターネット協会によって提供されます。
Fairhurst & Collini-Nocker Standards Track [Page 42]
FairhurstとCollini-ノッカー標準化過程[42ページ]
一覧
スポンサーリンク
