RFC5163 日本語訳
5163 Extension Formats for Unidirectional Lightweight Encapsulation(ULE) and the Generic Stream Encapsulation (GSE). G. Fairhurst, B.Collini-Nocker. April 2008. (Format: TXT=42935 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group G. Fairhurst
Request for Comments: 5163 University of Aberdeen
Category: Standards Track B. Collini-Nocker
University of Salzburg
April 2008
Fairhurstがコメントのために要求するワーキンググループG.をネットワークでつないでください: 5163年のアバディーン大学カテゴリ: 規格は2008年4月にザルツブルグのB.Collini-ノッカー大学を追跡します。
Extension Formats for Unidirectional Lightweight Encapsulation (ULE)
and the Generic Stream Encapsulation (GSE)
拡大は単方向軽量のカプセル化(ULE)と一般的な流れのカプセル化をフォーマットします。(GSE)
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)の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
This document describes a set of Extension Headers for the Unidirectional Lightweight Encapsulation (ULE), RFC 4326.
このドキュメントはUnidirectionalライト級Encapsulation(ULE)、RFC4326年のExtension Headersの1セットについて説明します。
The Extension Header formats specified in this document define extensions appropriate to both ULE and the Generic Stream Encapsulation (GSE) for the second-generation framing structure defined by the Digital Video Broadcasting (DVB) family of specifications.
本書では指定されたExtension Header形式は仕様のDigital Video Broadcasting(DVB)家によって定義された二世縁どり構造へのULEとGeneric Stream Encapsulationの両方(GSE)に適切な拡大を定義します。
Table of Contents
目次
1. Introduction ....................................................2
2. Conventions Used in This Document ...............................3
3. Description of the Method .......................................4
3.1. MPEG-2 TS-Concat Extension .................................5
3.2. PDU-Concat Extension .......................................8
3.3. TimeStamp Extension .......................................12
4. IANA Considerations ............................................13
5. Acknowledgments ................................................13
6. Security Considerations ........................................14
7. References .....................................................14
7.1. Normative References ......................................14
7.2. Informative References ....................................14
Appendix A. The Second-Generation DVB Transmission
Specifications .................................................16
1. 序論…2 2. このドキュメントで中古のコンベンション…3 3. 方法の記述…4 3.1. MPEG-2t-Concat拡張子…5 3.2. PDU-Concat拡張子…8 3.3. タイムスタンプ拡張子…12 4. IANA問題…13 5. 承認…13 6. セキュリティ問題…14 7. 参照…14 7.1. 標準の参照…14 7.2. 有益な参照…14付録、A. 二世DVBトランスミッション仕様…16
Fairhurst & Collini-Nocker Standards Track [Page 1] RFC 5163 Extension Formats for the ULE Encapsulation April 2008
FairhurstとCollini-ノッカー標準化過程[1ページ]RFC5163拡張子は2008年4月にULEのためにカプセル化をフォーマットします。
1. Introduction
1. 序論
This document describes three Extension Headers that may be used with both the Unidirectional Lightweight Encapsulation (ULE) [RFC4326] and the Generic Stream Encapsulation (GSE) [GSE]. ULE is defined for links that employ the MPEG-2 Transport Stream, and supports a wide variety of physical-layer bearers [RFC4259].
このドキュメントはUnidirectionalライト級Encapsulation(ULE)[RFC4326]とGeneric Stream Encapsulation(GSE)[GSE]の両方と共に使用されるかもしれない3Extension Headersについて説明します。 ULEはリンクその雇用MPEG-2Transport Streamのために定義されて、さまざまな運搬人[RFC4259]物理的な層を支えます。
GSE has been designed for the Generic Mode (also known as the Generic Stream (GS)), offered by second-generation DVB physical layers, and in the first instance for DVB-S2 [ETSI-S2]. The requirements for the Generic Stream are described in [S2-REQ]. The important characteristics of this encapsulation are described in the appendix of this document. GSE maintains a design philosophy that presents a network interface that is common to that presented by ULE and uses a similar construction for SubNetwork Data Units (SNDUs).
GSEは二世のDVBの物理的な層で提供されたGeneric Mode(また、Generic Stream(GS)として、知られている)とまずDVB-S2[ETSI-S2]のために設計されています。 Generic Streamのための要件は[S2-REQ]で説明されます。 このカプセル化の重要な特性はこのドキュメントの付録で説明されます。 GSEはULEによって提示されたそれに共通のネットワーク・インターフェースを提示して、SubNetwork Data Units(SNDUs)に同様の構造を使用する設計理念を維持します。
The first Extension Header defines a method that allows one or more TS Packets [ISO-MPEG2] to be sent within a ULE SNDU. This method may be used to provide control plane information including the transmission of MPEG-2 Program Specific Information (PSI) for the Multiplex. In GSE, there is no native support for Transport Stream packets and this method is therefore suitable for providing an MPEG-2 control plane.
最初のExtension Headerは1TS Packets[ISO-MPEG2]がULE SNDUの中で送られるのを許容する方法を定義します。 この方法は、MPEG-2Program Specific情報の伝達(PSI)を含むコントロール飛行機情報をMultiplexに供給するのに使用されるかもしれません。 GSEには、Transport Streamパケットをどんなネイティブのサポートもありません、そして、したがって、この方法はMPEG-2制御飛行機を提供するのに適当です。
A second Extension Header allows one or more PDUs to be sent within the same ULE SNDU. This method is designed for cases where a large number of small PDUs are directed to the same Network Point of Attachment (NPA) address. The method may improve transmission efficiency (by removing duplicated MAC layer overhead). It can also reduce processing overhead for a receiver that is not configured to receive the NPA address associated with an SNDU, allowing this receiver to then skip several PDUs in one operation. The method is defined as a generic Extension Header and may be used for IPv4 or IPv6 packets. If, and when, a compression format is defined for ULE or Ethernet, the method may also be used in combination with this method.
第2のExtension Headerは、1PDUsが同じULE SNDUの中で送られるのを許容します。 この方法は多くの小さいPDUsがAttachment(NPA)アドレスの同じNetwork Pointに向けられるケースのために設計されています。 方法は伝達効率(コピーされたMAC層のオーバーヘッドを取り除くのによる)を改良するかもしれません。 また、それはSNDUに関連しているNPAアドレスを受け取るために構成されない受信機のために処理のオーバーヘッドを減らすことができます、数個のPDUsがその時一挙にスキップするようにこの受信機を許容して。 方法は、一般的なExtension Headerと定義されて、IPv4かIPv6パケットに使用されるかもしれません。 圧縮書式はULEかイーサネットのために定義されます、そして、方法はまたこの方法と組み合わせて使用されるかもしれません。
A third Extension Header provides an optional TimeStamp value for an SNDU. Examples of the use of this TimeStamp option include monitoring and benchmarking of ULE and GSE links. Receivers that do not wish to decode (or do not support) the TimeStamp extension may discard the extension and process the remaining PDU or Extension Headers.
第3のExtension Headerは任意のTimeStamp値をSNDUに供給します。 このTimeStampオプションの使用に関する例は、モニターするのを含んでいます、そして、ULEとGSEのベンチマーキングはリンクされます。 TimeStamp拡張子を解読したがっていない(どんなサポートもしないでください)受信機は過程の拡大と残っているPDUかExtension Headersを捨てるかもしれません。
The appendix includes a summary of key design issues and considerations relating to the GSE Specification defined by the DVB Technical Module [GSE].
付録はDVB Technical Module[GSE]によって定義されたGSE Specificationに関連する主要なデザイン問題と問題の概要を含んでいます。
Fairhurst & Collini-Nocker Standards Track [Page 2] RFC 5163 Extension Formats for the ULE Encapsulation April 2008
FairhurstとCollini-ノッカー標準化過程[2ページ]RFC5163拡張子は2008年4月にULEのためにカプセル化をフォーマットします。
2. Conventions Used in This Document
2. 本書では使用されるコンベンション
The 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 RFC 2119 [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[RFC2119]で説明されるように本書では解釈されることであるべきですか?
b: bit. For example, one byte consists of 8b.
b: ビット。 例えば、1バイトは8bから成ります。
B: byte. Groups of bytes are represented in Internet byte order.
B: バイト。 バイトのグループはインターネットバイトオーダーで代表されます。
BBFrame payload: The data field part of a Baseband frame [ETSI-S2] that may be used for the communication of data. Typical BBFrames range in size from 3072 to 58192 bits according to the choice of modulation format and Forward Error Correction (FEC) in use.
BBFrameペイロード: データはデータに関するコミュニケーションに使用されるかもしれないBasebandフレーム[ETSI-S2]の一部をさばきます。 使用中の変調形式とForward Error Correction(FEC)の選択に従って、典型的なBBFramesは3072〜58192ビットのサイズのねらいを定めます。
DVB: Digital Video Broadcasting. A framework and set of associated standards published by the European Telecommunications Standards Institute (ETSI) for the transmission of video, audio, and data.
DVB: デジタルビデオ放送。 ヨーロッパのTelecommunications Standards Institute(ETSI)によって関連規格の枠組みとセットはビデオ、オーディオ、およびデータの伝達のために発行されました。
E: A one-bit flag field defined in GSE [GSE].
E: 1ビットの旗の分野はGSEで[GSE]を定義しました。
Encapsulator: A network device [RFC4259] that receives PDUs and formats these into Payload Units (known here as SNDUs) for output in DVB-S or the Generic Mode of DVB-S2.
Encapsulator: 出力のためにDVB-S2のDVB-SかGeneric Modeで有効搭載量Units(ここで、SNDUsとして知られている)にPDUsを受けて、これらをフォーマットするネットワーク装置[RFC4259]。
GS: Generic Stream. A stream of BBFrames identified by a common Input Stream Identifier, and which does not use the MPEG-2 TS format [ETSI-S2]. It represents layer 2 of the ISO/OSI reference model.
GS: 一般的な流れ。 MPEG-2TS形式[ETSI-S2]を使用しない一般的なInput Stream Identifierによって特定されたBBFramesの流れ。 それはISO/OSI参照モデルの層2を表します。
GSE: Generic Stream Encapsulation [GSE]. A method for encapsulating PDUs to form a Generic Stream, which is sent using a sequence of BBFrames. This encapsulation format shares the same extension format and basic processing rules of ULE and uses a common IANA Registry.
GSE: 一般的な流れのカプセル化[GSE]。 BBFramesの系列が使用させられるGeneric Streamを形成するためにPDUsを要約するための方法。 このカプセル化形式は、ULEの同じ拡大形式と基本的な処理規則を共有して、一般的なIANA Registryを使用します。
LT: A two-bit flag field defined in GSE [GSE].
LT: 安っぽい旗の分野はGSEで[GSE]を定義しました。
MAC: Medium Access Control [IEEE-802.3]. A link-layer protocol defined by the IEEE 802.3 standard.
Mac: 媒体アクセス制御[IEEE-802.3]。 IEEE802.3規格によって定義されたリンク層プロトコル。
MPEG-2: A set of standards specified by the Motion Picture Experts Group (MPEG), and standardized by the International Organization for Standardization (ISO/IEC 113818-1) [ISO-MPEG2], and ITU-T (in H.220).
MPEG-2: エムペグ(MPEG)によって指定されて、国際標準化機構(ISO/IEC113818-1)[ISO-MPEG2]、およびITU-Tによって標準化された1セットの規格(H.220の)。
Next-Header: A Type value indicating an Extension Header [RFC4326].
次のヘッダー: Extension Header[RFC4326]を示すType値。
Fairhurst & Collini-Nocker Standards Track [Page 3] RFC 5163 Extension Formats for the ULE Encapsulation April 2008
FairhurstとCollini-ノッカー標準化過程[3ページ]RFC5163拡張子は2008年4月にULEのためにカプセル化をフォーマットします。
NPA: Network Point of Attachment [RFC4326]. In this document, refers to a destination address (resembling an IEEE MAC address) within the DVB-S/S2 transmission network that is used to identify individual Receivers or groups of Receivers.
NPA: 接着点[RFC4326]をネットワークでつないでください。 本書では、送付先アドレス(IEEE MACアドレスに類似している)はReceiversの個々のReceiversかグループを特定するのに使用されるDVB-S/S2送電網の中で言及します。
PID: Packet Identifier [ISO-MPEG2]. A 13-bit field carried in the header of each TS Packet. This identifies the TS Logical Channel to which a TS Packet belongs [ISO-MPEG2]. The TS Packets that form the parts of a Table Section or other Payload Unit must all carry the same PID value. The all-ones PID value indicates a Null TS Packet introduced to maintain a constant bit rate of a TS Multiplex. There is no required relationship between the PID values used for TS Logical Channels transmitted using different TS Multiplexes.
PID: パケット識別子[ISO-MPEG2]。 13ビットの野原はそれぞれのTS Packetのヘッダーで運ばれました。 これはTS Packetが属するTS Logical Channel[ISO-MPEG2]を特定します。 Tableセクションか他の有効搭載量Unitの部分を形成するTS Packetsはすべて、同じPID値を運ばなければなりません。 オールものPID値がTS Multiplexの固定ビットレートを維持するために導入されたNull TS Packetを示します。 異なったTS Multiplexesを使用することで伝えられたTS Logical Channelsに使用されるPID値の間のどんな必要な関係もありません。
PDU: Protocol Data Unit [RFC4259]. Examples of a PDU include Ethernet frames, IPv4 or IPv6 datagrams, and other network packets.
PDU: データ単位[RFC4259]について議定書の中で述べてください。 PDUに関する例はイーサネットフレームかIPv4かIPv6データグラムと、他のネットワークパケットを含んでいます。
PSI: Program Specific Information [ISO-MPEG2].
psi: 特殊情報[ISO-MPEG2]をプログラムしてください。
S: A one-bit flag field defined in [GSE].
S: [GSE]で定義された1ビットの旗の分野。
SI Table: Service Information Table [ISO-MPEG2]. In this document, this term describes a table that is been defined by another standards body to convey information about the services carried on a DVB Multiplex.
SIテーブル: 情報テーブル[ISO-MPEG2]を調整してください。 本書では、今期はテーブルについて説明します。別の標準化団体によって定義されて、DVB Multiplexで提供されたサービスに関して情報を伝達します。
SNDU: SubNetwork Data Unit [RFC4259]. In this document, this is an encapsulated PDU sent using ULE or GSE.
SNDU: サブネットワークデータ単位[RFC4259]。 本書では、これはULEかGSEが使用させられた要約のPDUです。
Stream: A logical flow from an Encapsulator to a set of Receivers.
以下を流してください。 論理的なEncapsulatorからReceiversの1セットまでの流れ。
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.
t: MPEG-2レベルにおけるトランスミッションの方法がTS Packetsを使用して、Stream[ISO-MPEG2]を輸送してください。 それはISO/OSI参照モデルの層2を表します。
ULE: Unidirectional Lightweight Encapsulation (ULE) [RFC4326]. A method that encapsulates PDUs into SNDUs that are sent in a series of TS Packets using a single TS Logical Channel. The encapsulation defines an extension format and an associated IANA Registry.
ウレ: 単方向のライト級カプセル化(ULE)[RFC4326。] 一連のTS Packetsで独身のTS Logical Channelを使用することで送られるSNDUsにPDUsを要約する方法。 カプセル化は拡大形式と関連IANA Registryを定義します。
3. Description of the Method
3. 方法の記述
In ULE, a Type field value that is less than 1536 in decimal indicates an Extension Header. This section describes a set of three extension formats for the ULE encapsulation. [GSE] uses a Type field that adopts the same semantics as specified by RFC 4326. The
ULEでは、小数で1536未満であるType分野価値はExtension Headerを示します。 このセクションはULEカプセル化のために3つの拡大形式のセットについて説明します。 [GSE]はRFC4326による指定されるのと同じ意味論を採用するType分野を使用します。 The
Fairhurst & Collini-Nocker Standards Track [Page 4] RFC 5163 Extension Formats for the ULE Encapsulation April 2008
FairhurstとCollini-ノッカー標準化過程[4ページ]RFC5163拡張子は2008年4月にULEのためにカプセル化をフォーマットします。
encapsulation format differs in that GSE does not include a Cyclic Redundancy Check (CRC) for each SNDU, has different header flags, and utilizes a different SNDU length calculation [GSE].
カプセル化形式はGSEが各SNDUのためのCyclic Redundancy Check(CRC)を含まないで、異なったヘッダー旗を持って、異なったSNDU長さの計算[GSE]を利用するという点において異なります。
There is a natural ordering of Extension Headers, which is determined by the fields upon which the Extension Header operates. A suitable ordering for many applications is presented in the list below (from first to last header within an SNDU). This does not imply that all types of Extensions should be present in a single SNDU. The presented ordering may serve as a guideline for optimization of Receiver processing.
Extension Headersの自然な注文があります。(Extension HeadersはExtension Headerが作動させる分野で断固としています)。 以下のリストに多くのアプリケーションのための適当な注文を示す、(最初から最後まで、SNDUの中のヘッダー) これは、Extensionsのすべてのタイプに独身のSNDUに出席しているべきであるのを含意しません。 提示された注文はReceiver処理の最適化のためのガイドラインとして機能するかもしれません。
+----------------------------------+-------------------------------+ |Fields related to Extension Header| Example Extension Headers | +----------------------------------+-------------------------------+ | Link framing and transmission | TimeStamp Extension | +----------------------------------+-------------------------------+ | Entire remaining SNDU Payload | Encryption Extension | +----------------------------------+-------------------------------+ | Group of encapsulated PDUs | PDU-Concat or TS-Concat | +----------------------------------+-------------------------------+ | Specific encapsulated PDU | IEEE-defined type | | | Test or MAC bridging Extension| +----------------------------------+-------------------------------+
+----------------------------------+-------------------------------+ |Extension Headerに関連する分野| 例の拡張ヘッダー| +----------------------------------+-------------------------------+ | リンク縁どりとトランスミッション| タイムスタンプ拡張子| +----------------------------------+-------------------------------+ | 全体の残っているSNDU有効搭載量| 暗号化拡大| +----------------------------------+-------------------------------+ | 要約のPDUsのグループ| PDU-Concatかt-Concat| +----------------------------------+-------------------------------+ | 特定の要約のPDU| IEEEによって定義されたタイプ| | | Extensionに橋を架けるテストかMAC| +----------------------------------+-------------------------------+
Table 1: Recommended ordering of Extension Headers
テーブル1: Extension Headersのお勧めの注文
3.1. MPEG-2 TS-Concat Extension
3.1. MPEG-2t-Concat拡張子
The MPEG-2 TS-Concat Extension Header is specified by an IANA- assigned H-Type value of 0x0002 in hexadecimal. This is a Mandatory Extension Header.
MPEG-2TS-Concat Extension Headerは16進の0×0002のH-タイプ値が割り当てられたIANAによって指定されます。 これはMandatory Extension Headerです。
The extension is used to transport one or more MPEG-2 TS Packets within a ULE SNDU. The number of TS Packets carried in a specific SNDU is determined from the size of the remainder of the payload following the MPEG-2 TS Extension Header. The number of TS Packets contained in the SNDU is therefore (Length-N-10+D*6) / 188, where N is the number of bytes associated with Extension Headers that precede the MPEG-2 TS-Concat Extension (zero if there are none) and D is the value of the D-bit.
拡張子はULE SNDUの中のより多くの輸送1MPEG-2TS Packetsまで使用されます。 MPEG-2TS Extension Headerに続いて、特定のSNDUで運ばれたTS Packetsの数はペイロードの残りのサイズから決定しています。 したがって(長さ-N-10+D*6)、SNDUに含まれたTS Packetsの数は/188です、そして、DはD-ビットの価値です。そこでは、NがMPEG-2TS-Concat Extensionに先行するExtension Headersに関連しているバイト数(そこであるなら、ゼロはなにもである)です。
A Receiver MUST check the validity of the Length value prior to processing the payload. A valid Length corresponds to an integral number of TS Packets. An invalid Length (a remainder from the division by 188) MUST result in the discard of all encapsulated TS Packets and SHOULD be recorded as TS-Concat size mismatch error.
ペイロードを処理する前に、ReceiverはLength価値の正当性をチェックしなければなりません。 有効なLengthはTS Packetsの整数に対応しています。 TS-Concatサイズが誤りにミスマッチするので記録されていて、無効のLength(188の除法からの残り)はすべての要約のTS PacketsとSHOULDの破棄をもたらさなければなりません。
Fairhurst & Collini-Nocker Standards Track [Page 5] RFC 5163 Extension Formats for the ULE Encapsulation April 2008
FairhurstとCollini-ノッカー標準化過程[5ページ]RFC5163拡張子は2008年4月にULEのためにカプセル化をフォーマットします。
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 = 0x0002 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Destination NPA Address (6B) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| TS-Packet 1 |
= =
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TS-Packet 2 (if Length > 2*188) |
= =
| etc. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (CRC-32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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)| =0x0002をタイプしてください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 受信機送付先NPAアドレス(6B)| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | tパケット1| = = | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | tパケット2(長さ>2*188であるなら)| = = | など | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (CRC-32) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: ULE/SNDU Format for a TS-Packet Payload (D=0)
図1: tパケット有効搭載量のためのウレ/SNDU形式(D=0)
Figure 1 illustrates the format of this Extension Header for ULE with a value D=0, which indicates the presence of an NPA address [RFC4326]. In this case, the valid payload Length for a ULE SNDU with no other extensions is (Length-10) / 188.
図1はULEのために値のD=0と共にこのExtension Headerの形式を例証します。(D=0はNPAアドレス[RFC4326]の存在を示します)。 この場合、他の拡大のないULE SNDUのための有効なペイロードLengthは(長さ-10)/188です。
The method used to define the Length in GSE differs to that of ULE. The equivalent case for GSE would result in a payload Length value of (Length-6) / 188 (Figure 2).
GSEでLengthを定義するのに使用される方法はULEのものに異なります。 GSEに、同等なケースは(長さ-6)/188(図2)のペイロードLength価値をもたらすでしょう。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S|E|0 0| Length (12b) | Type = 0x0002 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Destination NPA Address (6B) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| TS-Packet 1 |
= =
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TS-Packet 2 (if Length > 2*188) |
= =
| etc. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |S|E|0 0| 長さ(12b)| =0x0002をタイプしてください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 受信機送付先NPAアドレス(6B)| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | tパケット1| = = | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | tパケット2(長さ>2*188であるなら)| = = | など | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: GSE/SNDU Format for a TS-Packet Payload (LT=00)
図2: tパケット有効搭載量のためのGSE/SNDU形式(LT=00)
Fairhurst & Collini-Nocker Standards Track [Page 6] RFC 5163 Extension Formats for the ULE Encapsulation April 2008
FairhurstとCollini-ノッカー標準化過程[6ページ]RFC5163拡張子は2008年4月にULEのためにカプセル化をフォーマットします。
Fragmented GSE SNDUs are protected by a CRC-32 carried in the final fragment. After reassembly, this CRC-32 is removed and the resulting SNDU carries a Total Length field. The fields labeled S and E are defined by [GSE] and contain control flags used by the GSE link layer. The Label Type (LT) field specifies the presence and format of the GSE label. The LT field is only specified for the first fragment (or a non-fragmented) GSE SNDU (i.e., when S=1).
断片化しているGSE SNDUsは最終的な断片で運ばれたCRC-32によって保護されます。 再アセンブリの後に、このCRC-32は取り外されます、そして、結果として起こるSNDUはTotal Length野原を運びます。 SとEとラベルされた分野は、[GSE]によって定義されて、GSEリンクレイヤによって使用される指揮旗を含んでいます。 Label Type(LT)分野はGSEラベルの存在と形式を指定します。 LT分野が最初の断片に指定されるだけである、(a、非断片化される、)、GSE SNDU(すなわち、S=1であるときに)。
In ULE, a value of D=1 is also permitted and indicates the absence of an NPA address (Figure 3). A similar format is supported in GSE.
ULEでは、D=1の値は、また、受入れられて、NPAアドレス(図3)の欠如を示します。 同様の形式はGSEで支持されます。
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 = 0x0002 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TS-Packet 1 |
= =
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TS-Packet 2 (if Length > 2*188) |
= =
| etc. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (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)| =0x0002をタイプしてください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | tパケット1| = = | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | tパケット2(長さ>2*188であるなら)| = = | など | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (CRC-32) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: ULE/SNDU Format for a TS-Packet Payload (D=1)
図3: tパケット有効搭載量のためのウレ/SNDU形式(D=1)
The TS-Concat extension may be used to transport one or more MPEG-2 TS Packets of arbitrary content, interpreted according to [ISO- MPEG2]. One expected use is for the transmission of MPEG-2 SI/PSI signalling [RFC4259].
TS-Concat拡張子は[ISO MPEG2]に従って解釈された任意の内容のより多くの輸送1MPEG-2TS Packetsまで使用されるかもしれません。 あるものは、使用が[RFC4259]に合図するMPEG-2SI/PSIのトランスミッションのためのものであると予想しました。
NULL TS Packets [ISO-MPEG2] SHOULD NOT be sent using this encapsulation. To reduce transmission overhead and processing, an Encapsulator SHOULD specify a maximum period of time that it can wait before sending all queued TS Packets. This is known as the TS Packing Threshold. This value MUST be bounded and SHOULD be configurable in the Encapsulator. A larger value can improve efficiency, but incurs higher jitter and could increase the probability of corruption. If additional TS Packets are NOT received within the TS Packing Threshold, the Encapsulator MUST immediately send any queued TS Packets.
NULL TS Packets[ISO-MPEG2]SHOULD NOT、このカプセル化を使用させてください。 減少するために、トランスミッションオーバーヘッドと処理、Encapsulator SHOULDはすべてを送るとTS Packetsが列に並ばせる前に待つことができる最大の期間を指定します。 これはTS Packing Thresholdとして知られています。 この値は境界があるに違いない、SHOULD、Encapsulatorで構成可能であってください。 より大きい値は、能率を増進できますが、より高いジターを被って、不正の確率を増加させるかもしれません。 追加TS PacketsがTS Packing Thresholdの中に受け取られないなら、Encapsulatorはすぐに、どんな列に並ばせられたTS Packetsも送らなければなりません。
The use of this format to transfer MPEG-2 clock references (e.g., a Network Clock Reference, NCR) over ULE/GSE framing raises timing considerations at the encapsulation gateway, including the need to
必要性を含むカプセル化ゲートウェイで問題を調節するULE/GSE縁どりの上の参照(例えば、Network Clock Reference、NCR)が上げるMPEG-2時計を移すこの形式の使用
Fairhurst & Collini-Nocker Standards Track [Page 7] RFC 5163 Extension Formats for the ULE Encapsulation April 2008
FairhurstとCollini-ノッカー標準化過程[7ページ]RFC5163拡張子は2008年4月にULEのためにカプセル化をフォーマットします。
update/modify the timing information prior to transmission by the physical layer. These issues are not considered here, but this operation may be simplified in GSE by ensuring that all SNDUs that carry this Extension Header are placed before other data within the BBFrame DataField [GSE].
トランスミッションの前にタイミング情報をアップデートするか、または物理的な層のそばで変更してください。 これらの問題はここで考えられませんが、このExtension Headerを運ぶすべてのSNDUsが他のデータの前にBBFrame DataField[GSE]の中に置かれるのを確実にすることによって、この操作はGSEで簡素化されるかもしれません。
This document does not specify how TS Packets are to be handled at the Receiver. However, it notes:
このドキュメントはTS PacketsがReceiverで扱われることになっている方法を指定しません。しかしながら、それは以下に注意します。
* A Receiver needs to consistently associate all TS Packets in a
Stream with one TS Logical Channel (Stream). If an Encapsulator
transmits more than one Stream of TS Packets each encapsulated at a
different level or with a different NPA address, a Receiver needs
to ensure that each is independently demultiplexed as a separate
Stream (Section 3.2 [RFC4259]).
* Receiverは、Streamで一貫して1TS Logical Channel(流れ)にすべてのTS Packetsを関連づける必要があります。 Encapsulatorが異なったレベルでそれぞれ要約されたTS Packetsか異なったNPAアドレスで1Streamを伝えるなら、Receiverは、それぞれが別々のStream(セクション3.2[RFC4259])として独自に反多重送信されるのを保証する必要があります。
* If an Encapsulator transmits service information encapsulated at
different levels or with different NPA addresses, the Receivers
need to ensure each Stream is related to the corresponding SI table
information (if any). A RECOMMENDED way to reduce signaling
interactions is to ensure each PID value uniquely identifies a
Stream within a TS Multiplex carrying ULE and also any TS Packets
encapsulated by a ULE/GSE Stream.
* Encapsulatorが異なったレベルにおいて、または、異なったNPAアドレスで要約されたサービス情報を伝えるなら、Receiversは、各Streamが対応するSIテーブル情報(もしあれば)に関連するのを保証する必要があります。 シグナリング相互作用を減少させるRECOMMENDED方法はそれぞれのPID値がULEを運ぶTS MultiplexとULE/GSE Streamによって要約されたどんなTS Packetsの中でも唯一Streamを特定するのを保証することです。
The need for consistency in the use of PIDs and the related service information is described in section 4.2 of [RFC4947].
PIDsの使用と関連するサービス情報の一貫性欲求は[RFC4947]のセクション4.2で説明されます。
3.2. PDU-Concat Extension
3.2. PDU-Concat拡張子
The PDU-Concat Extension Header is specified by an IANA-assigned H-Type value of 0x0003 in hexadecimal. This is a Mandatory Next- Header Extension. It enables a sequence of (usually short) PDUs to be sent within a single SNDU Payload.
PDU-Concat Extension Headerは16進の0×0003のIANAによって割り当てられたH-タイプ値によって指定されます。 これはMandatory NextヘッダーExtensionです。 それは、(通常短い)のPDUsの系列がただ一つのSNDU有効搭載量の中で送られるのを可能にします。
The base header contains the Length of the entire SNDU. This carries the value of the combined length of all PDUs to be encapsulated, including each set of encapsulation headers. The base header MAY be followed by one or more additional Extension Headers that precede the PDU-Concat Extension Header. These Extension Headers (e.g., a TimeStamp Extension) apply to the composite concatenated PDU.
ベースヘッダーは全体のSNDUのLengthを含んでいます。 これはそれぞれのセットのカプセル化ヘッダーを含むすべての要約されるべきPDUsの結合した長さの値を運びます。 ベースヘッダーはPDU-Concat Extension Headerに先行する1追加Extension Headersによって続かれるかもしれません。 これらのExtension Headers(例えば、TimeStamp Extension)は合成連結されたPDUに適用します。
The Extension Header also contains a 16-bit ULE Type field describing the encapsulated PDU, PDU-Concat-Type. Although any Type value specified in the ULE Next-Header Registry (including Extension Header Types) may be assigned to the encapsulated PDU (except the recursive use of a PDU-Concat type), all concatenated PDUs MUST have a common ULE Type (i.e., all concatenated PDUs passed by the network layer
また、Extension Headerは要約のPDUについて説明する16ビットのULE Type分野、PDU-Concat-タイプを含んでいます。 ULE Next-ヘッダーRegistry(Extension Header Typesを含んでいる)で指定されたどんなType値も要約のPDU(PDU-Concatタイプの再帰的な使用を除いた)に割り当てられるかもしれませんが、すべての連結されたPDUsには一般的なULE Typeがなければならない、(すなわち、すべてがネットワーク層によって渡されたPDUsを連結しました。
Fairhurst & Collini-Nocker Standards Track [Page 8] RFC 5163 Extension Formats for the ULE Encapsulation April 2008
FairhurstとCollini-ノッカー標準化過程[8ページ]RFC5163拡張子は2008年4月にULEのためにカプセル化をフォーマットします。
must be associated with the same Type value). This simplifies the receiver design, and reduces the transmission overhead for common use cases.
同じType値に関連していなければならない、) これは、受信機デザインを簡素化して、一般の使用のためのオーバーヘッドがケースに入れるトランスミッションを抑えます。
Each PDU is prefixed by its length in bytes (shown in the following diagrams as PDU-x-Length for the xth PDU). Encapsulated PDUs are of arbitrary length (in bytes) and are not necessarily aligned to 16-bit or 32-bit boundaries within the SNDU (as shown in the figures 4, 5, and 6). The most significant bit of the first byte is reserved, R, and this specification requires that this MUST be set to zero. Receivers MUST ignore the value of the R bit. The length of each PDU MUST be less than 32758 bytes, but will generally be much smaller.
各PDUはバイト(以下のダイヤグラムで、xth PDUのためのPDU-x-長さとして目立つ)で表現される長さによって前に置かれています。 要約のPDUsは任意の長さ(バイトによる)があって、必ずSNDUの中で16ビットか32ビットの境界に並べられるというわけではありません(4、5、および6の数字に示されるように)。 最初のバイトの最も重要なビットは予約されています、R、この仕様は、ゼロにこれを設定しなければならないのを必要とします。 受信機はRビットの価値を無視しなければなりません。 それぞれのPDU MUSTの長さは、32758バイト未満ですが、一般に、はるかにわずかになるでしょう。
When the SNDU header indicates the presence of an SNDU Destination Address field (i.e., D=0 in ULE), 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 transmission network that should process a received SNDU. When present, the Receiver MUST associate the same specified MAC/NPA address with all PDUs within the SNDU Payload. This MAC/NPA address MUST also be forwarded with each PDU, if required by the forwarding interface.
SNDUヘッダーがいつ(すなわち、ULEのD=0)(Attachment、NPAのNetwork Point)が直接さばくSNDU Destination Address分野の存在を示すかがSNDUヘッダーの4番目のバイトに続きます。 NPA送付先アドレスは通常、16進で表された容認されたSNDUを処理するべきである送電網でReceiver(s)を特定するのにおいて中古の6バイトの数です。 存在しているとき、ReceiverはSNDU有効搭載量の中で同じ指定されたMAC/NPAアドレスをすべてのPDUsに関連づけなければなりません。 また、必要なら推進インタフェースは各PDUと共にこのMAC/NPAアドレスを転送しなければなりません。
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 = 0x0003 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Destination NPA Address (6B) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | PDU-Concat-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| PDU-1-Length (15b) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
= PDU-1 =
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| PDU-2-Length (15b) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
= PDU-2 =
| |
More PDUs as required
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)| =0x0003をタイプしてください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 受信機送付先NPAアドレス(6B)| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | PDU-Concat-タイプ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R| PDU1の長さ(15b)| | ++++++++++++++++++=PDU-1=| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R| PDU2の長さ(15b)| | ++++++++++++++++++=PDU-2=| | より多くのPDUs、必要に応じて。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (CRC-32) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (CRC-32) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: ULE/SNDU Format for a PDU-Concat Payload (D=0)
図4: PDU-Concat有効搭載量のためのウレ/SNDU形式(D=0)
Fairhurst & Collini-Nocker Standards Track [Page 9] RFC 5163 Extension Formats for the ULE Encapsulation April 2008
FairhurstとCollini-ノッカー標準化過程[9ページ]RFC5163拡張子は2008年4月にULEのためにカプセル化をフォーマットします。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S|E|0 0| Length (12b) | Type = 0x0003 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Destination NPA Address (6B) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | PDU-Concat-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| PDU-1-Length (15b) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
= PDU-1 =
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| PDU-2-Length (15b) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
= PDU-2 =
| |
More PDUs as required
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |S|E|0 0| 長さ(12b)| =0x0003をタイプしてください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 受信機送付先NPAアドレス(6B)| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | PDU-Concat-タイプ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R| PDU1の長さ(15b)| | ++++++++++++++++++=PDU-1=| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R| PDU2の長さ(15b)| | ++++++++++++++++++=PDU-2=| | より多くのPDUs、必要に応じて。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: GSE/SNDU Format for a PDU-Concat Payload (LT=00)
図5: PDU-Concat有効搭載量のためのGSE/SNDU形式(LT=00)
When the SNDU header indicates the absence of an SNDU Destination Address field (i.e., D=1 in ULE), all encapsulated PDUs MUST be processed as if they had been received without an NPA address.
SNDUヘッダーがSNDU Destination Address分野(すなわち、ULEのD=1)の欠如を示すとき、まるでNPAアドレスなしで彼らを受け取ったかのようにすべての要約のPDUsを処理しなければなりません。
The value of D in the ULE header indicates whether an NPA/MAC address is in use [RFC4326]. A similar format is supported in GSE (using the LT field).
ULEヘッダーのDの値は、NPA/MACアドレスが使用中であるかどうかを[RFC4326]示します。 同様の形式はGSEで支持されます(LT分野を使用して)。
Fairhurst & Collini-Nocker Standards Track [Page 10] RFC 5163 Extension Formats for the ULE Encapsulation April 2008
FairhurstとCollini-ノッカー標準化過程[10ページ]RFC5163拡張子は2008年4月にULEのためにカプセル化をフォーマットします。
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 = 0x0003 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PDU-Concat-Type |R| PDU-1-Length (15b) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
= PDU-1 =
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| PDU-2-Length (15b) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
= PDU-2 =
| |
More PDUs as required
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)| =0x0003をタイプしてください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PDU-Concat-タイプ|R| PDU1の長さ(15b)| +++++++++++++++++++++++++++++++++はPDU-1=と等しいです。| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R| PDU2の長さ(15b)| | ++++++++++++++++++=PDU-2=| | より多くのPDUs、必要に応じて。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (CRC-32) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (CRC-32) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: ULE/SNDU Format for a PDU-Concat Payload (D=1)
図6: PDU-Concat有効搭載量のためのウレ/SNDU形式(D=1)
To reduce transmission overhead and processing, an Encapsulator SHOULD specify a maximum period of time it will wait before sending a Concatenated PDU. This is known as the PDU Packing Threshold. This value MUST be bounded and SHOULD be configurable in the Encapsulator. A larger value can improve efficiency, but incurs higher jitter and could increase the probability of corruption. If additional PDUs are NOT received within the PDU Packing Threshold, the Encapsulator MUST immediately send all queued PDUs.
減少するために、トランスミッションオーバーヘッドと処理、Encapsulator SHOULDはConcatenated PDUを送る前にそれが待っている最大の期間に指定します。 これはPDU Packing Thresholdとして知られています。 この値は境界があるに違いない、SHOULD、Encapsulatorで構成可能であってください。 より大きい値は、能率を増進できますが、より高いジターを被って、不正の確率を増加させるかもしれません。 追加PDUsがPDU Packing Thresholdの中に受け取られないなら、Encapsulatorはすぐに、すべての列に並ばせられたPDUsを送らなければなりません。
The Receiver processes this Extension Header by verifying that it supports the specified PDU-Concat Type (unsupported Types MUST be discarded, but the receiver SHOULD record a PDU-Type error [RFC4326]). It then extracts each encapsulated PDU in turn. The Receiver MUST verify the Length of each PDU. It MUST also ensure that the sum of the Lengths of all processed PDUs equals the Length specified in the SNDU base header. A Receiver SHOULD discard the whole SNDU if the total and PDU sizes are not consistent and this
指定されたPDU-Concat Typeを支持することを確かめることによって、ReceiverはこのExtension Headerを処理します(サポートされないTypesを捨てなければなりませんが、受信機SHOULDはPDU-タイプ誤り[RFC4326]を記録します)。 そして、それは順番にそれぞれの要約のPDUを抽出します。 ReceiverはそれぞれのPDUのLengthについて確かめなければなりません。 また、それは、すべての処理PDUsのLengthsの合計がSNDUベースヘッダーで指定されたLengthと等しいのを確実にしなければなりません。 合計とPDUサイズが一貫していないならA Receiver SHOULDが全体のSNDUを捨てる、これ
Fairhurst & Collini-Nocker Standards Track [Page 11] RFC 5163 Extension Formats for the ULE Encapsulation April 2008
FairhurstとCollini-ノッカー標準化過程[11ページ]RFC5163拡張子は2008年4月にULEのためにカプセル化をフォーマットします。
event SHOULD be recorded as a PDU-Concat size mismatch error. A receiver MUST NOT forward a partial PDU with an indicated PDU-Length greater than the number of unprocessed bytes remaining in the SNDU payload field.
イベントSHOULD、PDU-Concatサイズミスマッチ誤りとして、記録されてください。 示されたPDU-長さがSNDUペイロード分野に残っている未加工のバイトの数より大きい状態で受信機は部分的なPDUを進めてはいけません。
3.3. TimeStamp Extension
3.3. タイムスタンプ拡張子
The TimeStamp Extension Header is an Optional Extension Header that permits an Encapsulator to add a TimeStamp field to an SNDU. The TimeStamp Extension Header is specified by the IANA-assigned H-Type value of 257 decimal. This extension is an Optional Extension Header ([RFC4326], Section 5).
TimeStamp Extension HeaderはEncapsulatorがTimeStamp分野をSNDUに加えるのを可能にするOptional Extension Headerです。 TimeStamp Extension Headerは257小数のIANAによって割り当てられたH-タイプ値によって指定されます。 この拡張子はOptional Extension Header([RFC4326]、セクション5)です。
This extension is designed to support monitoring and measurement of the performance of a link to indicate the quality of an operational ULE link. This may be useful for GSE links (e.g., where significant complexity exists in the scheduling provided by the lower layers). Possible uses of this extension include:
この拡大は、リンクが操作上のULEリンクの品質を示す性能のモニターと測定を支持するように設計されています。 これはGSEリンクの役に立つかもしれません(例えば、どこに、重要な複雑さは下層によって提供されたスケジューリングで存在していますか)。 この拡大の可能な用途は:
* Validation of in-sequence ordering per Logical Channel * Measurement of one-way delay (when synchronized with the sender) * Measurement of PDU Jitter introduced by the link * Measurement of PDU loss (with additional information from sender)
* PDUの損失のリンク*測定で導入されたPDU Jitterの片道遅れ(送付者に連動すると)*測定のLogical Channel*測定単位で連続して注文する合法化(送付者からの追加情報がある)
Figure 7 shows the format of this extension with a HLEN value of 3 indicating a TimeStamp of length 4B with a Type field (there is no implied byte-alignment).
図7は3のHLEN値がType分野がある長さの4BのTimeStampを示しているこの拡大の書式を示しています(どんな暗示しているバイト整列もありません)。
0 7 15 23 31 +---------------+---------------+---------------+---------------+ | 0x03 | 0x01 | TimeStamp HI | +---------------+---------------+---------------+---------------+ | TimeStamp LO | Type | +---------------+---------------+---------------+---------------+
0 7 15 23 31 +---------------+---------------+---------------+---------------+ | 0×03| 0×01| TimeStamp HI| +---------------+---------------+---------------+---------------+ | タイムスタンプ最低気温| タイプ| +---------------+---------------+---------------+---------------+
Figure 7: Format of the 32-bit TimeStamp Extension Header
図7: 32ビットのタイムスタンプ拡張ヘッダーの形式
The extension carries a 32-bit value (TimeStamp HI plus TimeStamp LO). The specified resolution is 1 microsecond. The value therefore indicates the number of 1-microsecond ticks past the hour in Universal Time when the PDU was encapsulated. This value may be earlier than the time of transmission, due for example to Packing, queuing, and other Encapsulator processing. The value is right- justified to the 32-bit field. Systems unable to insert TimeStamps at the specified resolution MUST pad the unused least-significant bits with a value of zero.
拡大は32ビットの値(TimeStamp HIとTimeStamp LO)を運びます。 指定された解決は1マイクロセカンドです。 したがって、値はPDUが要約された世界標準時に時間の先間、1マイクロセカンドのカチカチする音の数を示します。 トランスミッションの当然の時間より早く、例えば、Packing、列を作り、および他のEncapsulator処理にはこの値があるかもしれません。 値は32ビットの分野にまさしく正当です。 指定された解決のときにTimeStampsを挿入できないシステムはゼロの値で未使用の最下位ビットを水増ししなければなりません。
Fairhurst & Collini-Nocker Standards Track [Page 12] RFC 5163 Extension Formats for the ULE Encapsulation April 2008
FairhurstとCollini-ノッカー標準化過程[12ページ]RFC5163拡張子は2008年4月にULEのためにカプセル化をフォーマットします。
The last two bytes carry a 16-bit Type field that indicates the type of payload carried in the SNDU or the presence of a further Next- Header ([RFC4326], Section 4.4).
最後の2バイトはSNDUで運ばれたペイロードのタイプか一層のNextヘッダーの存在([RFC4326]、セクション4.4)を示す16ビットのType野原を運びます。
Receivers MAY process the TimeStamp when the PDU encapsulation is removed. Receivers that do not implement, or do not wish to process, the TimeStamp Extension MAY skip this Extension Header. Receivers MUST continue to process the remainder of the SNDU, forwarding the encapsulated PDU.
PDUカプセル化を取り除くとき、受信機はTimeStampを処理するかもしれません。 TimeStamp Extension5月のスキップがこのExtension Headerであることを実行しないで、また処理するために願っていない受信機。 要約のPDUを進めて、受信機は、SNDUの残りを処理し続けなければなりません。
4. IANA Considerations
4. IANA問題
IANA has assigned three new Next-Header Type values from the IANA ULE Next-Header Registry. These options are defined for specific use cases envisaged by GSE, but are compatible with ULE.
IANAはType値をIANA ULE Next-ヘッダーRegistryから3の新しいNext-ヘッダーに割り当てました。 これらのオプションは、ケースがGSEで考えた特定的用法のために定義されますが、ULEと互換性があります。
The following assignments have been made in this document and registered by IANA:
以下の課題は、本書では作られていて、IANAによって登録されました:
Type Name Reference
型名参照
2: TS-Concat Section 3.1
3: PDU-Concat Section 3.2
2: t-Concat部3.1の3: PDU-Concat部3.2
Type Name H-LEN Reference
型名H-LEN参照
257: TimeStamp 3 Section 3.3
257: タイムスタンプ3部3.3
The TS-Concat Extension is a Mandatory next-type Extension Header, specified in Section 3.1 of this document. The value of this next- header is defined by an IANA assigned H-Type value of 0x0002.
TS-Concat Extensionはこのドキュメントのセクション3.1で指定されたMandatory次のタイプExtension Headerです。 この次のヘッダーの値は0×0002のH-タイプ値が割り当てられたIANAによって定義されます。
The PDU-Concat Extension is a Mandatory next-type Extension Header specified in Section 3.2 of this document. The value of this next- header is defined by an IANA assigned H-Type value of 0x0003.
PDU-Concat Extensionはこのドキュメントのセクション3.2で指定されたMandatory次のタイプExtension Headerです。 この次のヘッダーの値は0×0003のH-タイプ値が割り当てられたIANAによって定義されます。
The TimeStamp Extension is an Optional next-type Extension Header specified in Section 3.3 of this document. The value of this next- header is defined by an IANA assigned H-Type value of 257 decimal. This documents defines the format for an HLEN value of 0x3.
TimeStamp Extensionはこのドキュメントのセクション3.3で指定されたOptional次のタイプExtension Headerです。 この次のヘッダーの値は257小数のH-タイプ値が割り当てられたIANAによって定義されます。 0×3のHLEN値のために、フォーマットを定義しますこれが、ドキュメントである。
5. Acknowledgments
5. 承認
The authors gratefully acknowledge the inputs, comments, and assistance offered by the members of the DVB-GBS ad hoc group on DVB-S2 encapsulation, in particular contributions on DVB-S2 transmission aspects from Rita Rinaldo, Axel Jahn, and Ulrik De Bie.
作者は感謝してDVB-S2カプセル化に関するDVB-GBS専門家班のメンバーによって提供された入力、コメント、および支援を承諾します、リタ・リナルドからのDVB-S2トランスミッション局面における特定の貢献、Axelジャーン、およびウーリック・Deビエで。
Fairhurst & Collini-Nocker Standards Track [Page 13] RFC 5163 Extension Formats for the ULE Encapsulation April 2008
FairhurstとCollini-ノッカー標準化過程[13ページ]RFC5163拡張子は2008年4月にULEのためにカプセル化をフォーマットします。
Juan Cantillo provided a significant contribution to the informative appendix. The authors thank Christian Praehauser for his insight and contribution on Extension Header processing issues.
ホアンCantilloは有益な付録への重要な貢献を提供しました。 作者は彼の洞察と貢献についてExtension Header処理問題でクリスチャンのPraehauserに感謝します。
6. Security Considerations
6. セキュリティ問題
Security considerations for ULE are described in [RFC4326], and further information on security aspects of using ULE are described in the security considerations of [RFC4259] and [Sec-Req].
ULEのためのセキュリティ問題は[RFC4326]で説明されます、そして、ULEを使用するセキュリティ局面に関する詳細は[RFC4259]と[秒-Req]のセキュリティ問題で説明されます。
An attacker that is able to inject arbitrary TS Packets in a ULE or GSE Stream may modify layer 2 signalling information transmitted by the MPEG-2 TS-Concat extension. Since this attack requires access to the link and/or layer 2 equipment, such an attack could also directly attack signalling information sent as native TS Packets (not encapsulated by ULE/GSE). Security issues relating to the transmission and interpretation of layer 2 signalling information (including Address Resolution) within a TS Multiplex are described in [RFC4947]. The use of security mechanisms to protect the MPEG-2 signalling information is discussed by [Sec-Req].
ULEかGSE Streamで任意のTS Packetsを注入できる攻撃者はMPEG-2TS-Concat拡張子で伝えられた層2の合図情報を変更するかもしれません。 この攻撃がリンク、そして/または、層へのアクセスを必要とするので、2設備、そのような攻撃は発信できて、また、直接、攻撃合図情報はネイティブのTS Packetsとして発信しました(ULE/GSEによって要約されません)。 TS Multiplexの中で層2の合図情報(Address Resolutionを含んでいる)のトランスミッションと解釈に関連する安全保障問題が[RFC4947]で説明されます。 MPEG-2合図情報を保護するセキュリティー対策の使用は[秒-Req]によって議論されています。
7. References
7. 参照
7.1. Normative References
7.1. 引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC4326] Fairhurst, G. and B. Collini-Nocker, "Unidirectional
Lightweight Encapsulation (ULE) for Transmission of IP
Datagrams over an MPEG-2 Transport Stream (TS)", RFC
4326, December 2005.
[RFC4326] Fairhurst、G.、およびB.Collini-ノッカー、「MPEG-2の上のIPデータグラム輸送の送信のための単方向のライト級カプセル化(ULE)は(ts)を流します」、RFC4326、2005年12月。
[GSE] TS 102 606 "Digital Video Broadcasting (DVB); Generic
Stream Encapsulation (GSE) Protocol, "European
Telecommunication Standards, Institute (ETSI), 2007.
[GSE]t102 606「デジタルビデオ放送(DVB)」。 一般的な流れのカプセル化(GSE)プロトコル、「ヨーロッパの電気通信規格、研究所(ETSI)、2007。」
7.2. Informative References
7.2. 有益な参照
[ETSI-S2] EN 302 307, "Digital Video Broadcasting (DVB); Second
generation framing structure, channel coding and
modulation systems for Broadcasting, Interactive
Services, News Gathering and other broadband satellite
applications", European Telecommunication Standards
Institute (ETSI).
[ETSI-S2]アン302 307、「(DVB)を放送するデジタルビデオ」。 「Broadcasting、Interactive Services、News Gathering、および他の広帯域の衛星アプリケーションの構造、チャンネル・コーディング、および変調システムを縁どる二世」、ヨーロッパ電気通信規格研究所(ETSI)。
Fairhurst & Collini-Nocker Standards Track [Page 14] RFC 5163 Extension Formats for the ULE Encapsulation April 2008
FairhurstとCollini-ノッカー標準化過程[14ページ]RFC5163拡張子は2008年4月にULEのためにカプセル化をフォーマットします。
[S2-REQ] Cantillo, J. and J. Lacan, "A Design Rationale for
Providing IP Services over DVB-S2 Links", Work in
Progress, December 2006.
[S2-REQ] 「DVB-S2リンクの上にIPサービスを供給するためのデザイン原理」というCantillo、J.、およびJ.ラカンは進行中(2006年12月)で働いています。
[Sec-Req] Cruickshank, H., Iyengar, S., and P. Pillai, "Security
requirements for the Unidirectional Lightweight
Encapsulation (ULE) protocol", Work in Progress,
November 2007.
[秒-Req] クリュックシァンク、H.、アイアンガー、S.、およびP.ピッライ、「Unidirectionalライト級Encapsulation(ULE)のためのセキュリティ要件は議定書を作ります」、ProgressのWork、2007年11月。
[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 802.3, IEEE Computer
Society, (also ISO/IEC 8802-3), 2002.
[IEEE-802.3]、「地方とメトロポリタンエリアネットワーク--決められた一定の要求Part3:、」 「衝突検出(CSMA/CD)アクセス法と物理的な層の仕様がある搬送波感知多重アクセス」、IEEE802.3、IEEEコンピュータSociety、(ISO/IEC8802-3も)、2002。
[ISO-MPEG2] ISO/IEC DIS 13818-1:2000, "Information Technology;
Generic Coding of Moving Pictures and Associated Audio
Information Systems", International Organization for
Standardization (ISO), 2000.
[ISO-MPEG2]ISO/IECは13818-1をけなします: 2000、「情報技術」 「映画と関連オーディオ情報システムの一般的なコード化」、国際標準化機構(ISO)、2000。
[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月)。
[RFC4947] Fairhurst, G. and M. Montpetit, "Address Resolution
Mechanisms for IP Datagrams over MPEG-2 Networks", RFC
4947, July 2007.
[RFC4947]FairhurstとG.とM.Montpetit、「MPEG-2つのネットワークの上のIPデータグラムのためのアドレス解決メカニズム」、RFC4947、2007年7月。
Fairhurst & Collini-Nocker Standards Track [Page 15] RFC 5163 Extension Formats for the ULE Encapsulation April 2008
FairhurstとCollini-ノッカー標準化過程[15ページ]RFC5163拡張子は2008年4月にULEのためにカプセル化をフォーマットします。
Appendix A. The Second-Generation DVB Transmission Specifications
付録A.は二世DVBトランスミッション仕様です。
This section provides informative background to the network-layer requirements of the second-generation DVB Transmission Specifications. The second-generation waveforms specified by the Digital Video Broadcasting project offer two main enhancements. First, more efficient physical-layer methods that employ higher-order modulation with stronger FEC and permit adaptive coding and modulation response to changes in traffic and propagation conditions. Second, at the link layer, they offer greater flexibility in framing. Support is provided for a range of stream formats including the classical Transport Stream (TS) [RFC4259]. In addition, a new method called Generic Stream (GS) (or the Generic Mode) is supported. A GS can be packetized or continuous and is intended to provide native transport of other network-layer services. One such method is that provided by the Generic Stream Encapsulation (GSE) [GSE].
このセクションは二世DVB Transmission Specificationsのネットワーク層要件に有益なバックグラウンドを提供します。 Digital Video Broadcastingプロジェクトによって指定された二世波形は2つの主な増進を提供します。 最初に、より強いFECと共に高次な変調を使って、交通で適応型のコード化と変化への変調応答を可能にするより効率的な物理的な層の方法と伝播状態。 2番目に、リンクレイヤでは、彼らは縁どりにおける、より大きい柔軟性を提供します。 古典的なTransport Stream(TS)を含むさまざまな流れの形式にサポートを提供します[RFC4259]。 さらに、Generic Stream(GS)(または、Generic Mode)と呼ばれる新しい方法は支持されます。 GSは、packetizedされているか、または連続している場合があって、他のネットワーク層サービスのネイティブの輸送を提供することを意図します。 そのような方法の1つはGeneric Stream Encapsulation(GSE)[GSE]によって提供されたそれです。
For example, the DVB-S2 [ETSI-S2] transmission link sequentially multiplexes a series of baseband frames (BBFrames). Each BBFrame comprises a fixed-size 10B header and a payload. The payload carries a DataField and uses padding to fill any unused space. A stream comprises a sequence of BBFrames associated with an Input Stream Identifier (ISI) that is carried in the header of each BBFrame. The simplest scheme uses a single stream (with just one ISI value), but multiple streams are permitted. The BBFrames forming a stream may be of variable size (selected from a set of allowed sizes), and must use the same stream format (i.e., TS or GSE). Each stream represents an independent link with independent address resolution [RFC4947].
例えば、DVB-S2[ETSI-S2]トランスミッションリンクは一連のベースバンドフレーム(BBFrames)を連続して、多重送信します。 各BBFrameは固定サイズ10Bヘッダーとペイロードを包括します。 ペイロードはどんな未使用のスペースもいっぱいにするためにそっと歩くDataFieldと用途を運びます。 流れはそれぞれのBBFrameのヘッダーで運ばれるInput Stream Identifier(ISI)に関連しているBBFramesの系列を含みます。 最も簡単な計画はただ一つの流れ(ちょうど1つのISI値がある)を使用しますが、複数の流れが受入れられます。 流れを形成するBBFramesは可変サイズ(1セットの許容サイズから選び抜く)があるかもしれなくて、同じ流れの形式(すなわち、TSかGSE)を使用しなければなりません。 各流れは独立しているアドレス解決[RFC4947]との独立しているリンクを表します。
GSE provides functions that are equivalent to those of the Unidirectional Lightweight Encapsulation (ULE) [RFC4326]. It supports the transmission of IP packets and other network-layer protocols. The network-layer interface resembles that of ULE, where it adopts common mechanisms for a Length field, a 16-bit Type field, and support for Extension Headers. As in ULE, GSE permits multiple address formats, indicated by the LT field (functionally equivalent to the D field in ULE). The default addressing mode uses a 6-byte NPA and a suppressed NPA address (functionally equivalent to D=1 in ULE).
GSEはUnidirectionalライト級Encapsulation(ULE)[RFC4326]のものに同等な機能を提供します。 それはIPパケットと他のネットワーク層プロトコルの送信を支持します。 ネットワーク層インタフェースはULEのものに類似しています。(そこでは、それがLength分野、16ビットのType分野、およびExtension Headersのサポートのために一般的なメカニズムを採用します)。 ULEのように、GSEはLT分野(ULEのD分野に機能上同等な)によって示された複数のアドレス形式を可能にします。 デフォルトアドレッシング・モードは6バイトのNPAと抑圧されたNPAアドレス(D=1にULEで機能上同等な)を使用します。
GSE also provides more flexible fragmentation at the interface to the physical layer (using the S and E flags). This adapts the SNDUs to a variable-sized link-layer frame, and reflects the more complex requirements in terms of fragmentation and assembly that arise when using point-to-multipoint adaptive physical layers. The integrity of a reassembled SNDU is validated using a CRC-32 in the last fragment for the corresponding PDU.
また、GSEはインタフェースで物理的な層(Sを使用して、E旗)によりフレキシブルな断片化を供給します。 これは、変数サイズのリンクレイヤフレームにSNDUsを適合させて、ポイントツーマルチポイントの適応型の物理的な層を使用するとき起こる断片化とアセンブリで、より複雑な要件を反映します。 組み立て直されたSNDUの保全は、対応するPDUに最後の断片でCRC-32を使用することで有効にされます。
Fairhurst & Collini-Nocker Standards Track [Page 16] RFC 5163 Extension Formats for the ULE Encapsulation April 2008
FairhurstとCollini-ノッカー標準化過程[16ページ]RFC5163拡張子は2008年4月にULEのためにカプセル化をフォーマットします。
Authors' Addresses
作者のアドレス
Godred Fairhurst School of Engineering, University of Aberdeen, Aberdeen, AB24 3UE UK
Godred Fairhurst工学部、アバディーン、アバディーンAB24 3UEイギリスの大学
EMail: gorry@erg.abdn.ac.uk URI: 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 Computer Sciences, University of Salzburg, Jakob Haringer Str. 2, 5020 Salzburg, Austria
コンピューターサイエンシズのバーンハードCollini-ノッカー部、ザルツブルグ大学、ジェイコブハーリンガーStr。 2、5020ザルツブルグ(オーストリア)
EMail: bnocker@cosy.sbg.ac.at URI: http://www.cosy.sbg.ac.at
メール: bnocker@cosy.sbg.ac.at ユリ: http://www.cosy.sbg.ac.at
Fairhurst & Collini-Nocker Standards Track [Page 17] RFC 5163 Extension Formats for the ULE Encapsulation April 2008
FairhurstとCollini-ノッカー標準化過程[17ページ]RFC5163拡張子は2008年4月にULEのためにカプセル化をフォーマットします。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(2008)。
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, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
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に情報を記述してください。
Fairhurst & Collini-Nocker Standards Track [Page 18]
FairhurstとCollini-ノッカー標準化過程[18ページ]
一覧
スポンサーリンク
