RFC4164 日本語訳
4164 RObust Header Compression (ROHC): Context Replication for ROHCProfiles. G. Pelletier. August 2005. (Format: TXT=47088 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group G. Pelletier Request for Comments: 4164 Ericsson Category: Standards Track August 2005
コメントを求めるワーキンググループG.ペレティア要求をネットワークでつないでください: 4164年のエリクソンカテゴリ: 標準化過程2005年8月
RObust Header Compression (ROHC):
Context Replication for ROHC Profiles
体力を要しているヘッダー圧縮(ROHC): ROHCプロフィールのための文脈模写
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
要約
This document defines context replication, a complement to the context initialization procedure found in Robust Header Compression (ROHC), as specified in RFC 3095. Profiles defining support for context replication may use the mechanism described herein to establish a new context based on another already existing context. Context replication is introduced to reduce the overhead of the context establishment procedure. It may be especially useful for the compression of multiple short-lived flows that may be occurring simultaneously or near-simultaneously, such as short-lived TCP flows.
このドキュメントは文脈模写を定義します、と文脈初期化手順への補数によって、Robust Header Compression(ROHC)でわかりました、RFC3095で指定されるように。 文脈模写のサポートを定義するプロフィールは別の既に既存の文脈に基づく新しい関係を証明するためにここに説明されたメカニズムを使用するかもしれません。 文脈設立手順のオーバーヘッドを下げるために文脈模写を導入します。 それは特に短命なTCP流れなどの短命な-同時に、起こっているか同時であるかもしれない複数の流れの圧縮の役に立つかもしれません。
Pelletier Standards Track [Page 1] RFC 4164 Context Replication for ROHC Profiles August 2005
ROHCのためのペレティア標準化過程[1ページ]RFC4164文脈模写は2005年8月の輪郭を描きます。
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Context Replication for ROHC Profiles ...........................5
3.1. Robustness Considerations ..................................5
3.2. Replication of Control Fields ..............................5
3.3. Compressor States and Logic ................................6
3.3.1. Context Replication (CR) State ......................6
3.3.2. State Machine with Context Replication ..............7
3.3.3. State Transition Logic ..............................7
3.3.3.1. Selection of Base Context, Upward
Transition .................................8
3.3.3.2. Optimistic Approach, Upward Transition .....9
3.3.3.3. Optional Acknowledgements (ACKs),
Upward Transition ..........................9
3.3.3.4. Negative ACKs (NACKs), Downward
Transition .................................9
3.4. Decompressor Logic ........................................10
3.4.1. Replication and Context Initialization .............10
3.4.2. Reconstruction and Verification ....................10
3.4.3. Actions upon Failure ...............................11
3.4.4. Feedback Logic .....................................11
3.5. Packet Formats ............................................11
3.5.1. CRCs in the IR-CR Packet ...........................12
3.5.1.1. 7-bit CRC .................................13
3.5.1.2. 8-bit CRC .................................13
3.5.2. General Format of the IR-CR Packet .................13
3.5.3. Properties of the Base Context Identifier (BCID) ...15
4. Security Considerations ........................................15
5. Acknowledgements ...............................................15
6. References .....................................................16
6.1. Normative References ......................................16
6.2. Informative References ....................................16
Appendix A: General Format of the IR-CR Packet (Informative).......17
A.1. General Structure (Informative) ..........................17
A.2. Profile-Specific Replication Information (Informative) ...17
Appendix B: Inter-Profile Context Replication (Informative)........18
B.1. Defining Support for Inter-Profile Context Replication ...18
B.2. Compatibility between Different Profiles (Informative) ...19
1. 序論…3 2. 用語…4 3. ROHCプロフィールのための文脈模写…5 3.1. 丈夫さ問題…5 3.2. 制御フィールドの模写…5 3.3. コンプレッサー州と論理…6 3.3.1. 文脈模写(CR)状態…6 3.3.2. 文脈模写でマシンを述べてください…7 3.3.3. 変遷論理を述べてください…7 3.3.3.1. 基地の文脈の選択、上向きの変遷…8 3.3.3.2. 楽観的なアプローチ、上向きの変遷…9 3.3.3.3. 任意の承認(ACKs)、上向きの変遷…9 3.3.3.4. 否定的ACKs(NACKs)、下向きの変遷…9 3.4. 減圧装置論理…10 3.4.1. 模写と文脈初期設定…10 3.4.2. 再建と検証…10 3.4.3. 失敗への動作…11 3.4.4. フィードバック論理…11 3.5. パケット形式…11 3.5.1. IR-CRパケットのCRCs…12 3.5.1.1. 7ビットのCRC…13 3.5.1.2. 8ビットのCRC…13 3.5.2. IR-CRパケットの一般形式…13 3.5.3. 基地の文脈識別子(BCID)の特性…15 4. セキュリティ問題…15 5. 承認…15 6. 参照…16 6.1. 標準の参照…16 6.2. 有益な参照…16 付録A: IR-CRパケット(有益な)の一般形式…17 A.1。 一般構造(有益な)…17 A.2。 プロフィール特有の模写情報(有益な)…17 付録B: 相互文脈模写(有益な)の輪郭を描いてください…18 B.1。 相互プロフィール文脈模写のサポートを定義します…18 B.2。 異なったプロフィール(有益な)の間の互換性…19
Pelletier Standards Track [Page 2] RFC 4164 Context Replication for ROHC Profiles August 2005
ROHCのためのペレティア標準化過程[2ページ]RFC4164文脈模写は2005年8月の輪郭を描きます。
1. Introduction
1. 序論
There is often some redundancy between header fields of different flows that pass through the same compressor-decompressor pair. This means that some of the information needed to initialize the context for decompressing the headers of a new flow may already be present at the decompressor. It may be desirable to reuse this information and remove some of the overhead normally required for the initialization of a new header compression context at both the compressor and decompressor.
同じコンプレッサー減圧装置組を通り抜ける異なった流れのヘッダーフィールドの間には、何らかの冗長がしばしばあります。 これは、新しい流れのヘッダーを減圧するための文脈を初期化するのに必要である情報のいくつかが減圧装置で既に存在しているかもしれないことを意味します。 この情報を再利用して、通常、オーバーヘッドのいくつかを取り除くのが両方の新しいヘッダー圧縮関係の初期化のためにコンプレッサーと減圧装置を必要としたのは、望ましいかもしれません。
Reducing the overhead of the context establishment procedure is particularly useful when multiple short-lived connections (or flows) occur simultaneously, or near-simultaneously, between the same compressor-decompressor pair. Because each new packet stream requires most of the header information to be sent during the initialization phase before smaller compressed headers can be used, a multitude of short-lived connections may significantly reduce the overall gain from header compression.
複数の短命な接続(または、流れる)が同時、または-同時頃に起こるとき、文脈設立手順のオーバーヘッドを下げるのは特に役に立ちます、同じコンプレッサー減圧装置組の間で。 より小さい圧縮されたヘッダーを使用できる前にそれぞれの新しいパケットの流れが、ヘッダー情報の大部分が初期設定段階の間、送られるのを必要とするので、短命な接続の多数がヘッダー圧縮から総合的な利得をかなり下げるかもしれません。
Context replication allows some header fields, such as the IP source and/or destination addresses (16 octets each for IPv6), to be omitted within the special Initiation and Refresh (IR) packet type specifically defined for replication. It also allows other fields, such as source and/or destination ports, to be either omitted or sent in a compressed form from the very first packet of the header compressed flow.
文脈模写はIPソースなどのいくつかのヘッダーフィールドを許容します、そして、目的地は(IR)パケットタイプが模写のために明確に定義した特別なInitiationとRefreshの中で省略されるために(IPv6のためのそれぞれ16の八重奏)を記述します。 また、それは他の分野を許容します、ソース、そして/または、仕向港のように圧縮形で省略するか、または送るために、そもそもの初めからヘッダーのパケットは流れを圧縮しました。
Context replication is herein defined as a general ROHC mechanism. The benefits of context replication are not limited to any particular protocol and its support may be defined for any ROHC profile.
文脈模写はここに一般的なROHCメカニズムと定義されます。 文脈模写の恩恵はどんな特定のプロトコルにも制限されません、そして、サポートはどんなROHCプロフィールのためにも定義されるかもしれません。
In particular, context replication is applicable to TCP compression because many TCP transfers are short-lived; a behavior analysis of TCP/IP header fields among multiple short-lived connections may be found in [5]. In addition, [4] introduces considerations and requirements for the ROHC-TCP profile [3] to efficiently compress such short-lived TCP transfers.
多くのTCP転送が短命であるので、文脈模写はTCP圧縮に特に、適切です。 複数の短命な接続の中のTCP/IPヘッダーフィールドの振舞い分析は[5]で見つけられるかもしれません。 さらに、[4]は問題とROHC-TCPプロフィール[3]が効率的にそのような短命なTCP転送を圧縮するという要件を紹介します。
For profiles supporting this mechanism, the compressor performs context replication by reusing or creating a copy of an existing context, i.e., a base context, to create the replicated context. The replicated context is then updated to match the header fields of the new flow. The compressor then sends to the decompressor a packet that contains a reference to the selected base context, along with some data for the fields that need to be updated when creating the
このメカニズムをサポートするプロフィールに関しては、コンプレッサーは、模写された文脈を作成するためにすなわち、既存の文脈、ベース文脈のコピーを再利用するか、または作成することによって、文脈模写を実行します。 そして、新しい流れのヘッダーフィールドを合わせるために模写された文脈をアップデートします。 そして、コンプレッサーは作成するとき、アップデートする必要がある分野のためのいくつかのデータに伴う選択されたベース文脈の参照を含むパケットを減圧装置に送ります。
Pelletier Standards Track [Page 3] RFC 4164 Context Replication for ROHC Profiles August 2005
ROHCのためのペレティア標準化過程[3ページ]RFC4164文脈模写は2005年8月の輪郭を描きます。
replicated context. Finally, the decompressor creates the replicated context based on the reference to the base context along with the uncompressed and compressed data from the received packet.
文脈を模写しました。 最終的に、減圧装置は容認されたパケットから解凍されて圧縮されたデータに伴うベース文脈の参照に基づく模写された文脈を作成します。
This document specifies the context replication procedure for ROHC profiles. It defines the general compressor and decompressor logic used during context replication, as well as the general format of the special IR packet required for this procedure. Profiles defining support for context replication must further specify the specific format(s) of this packet.
このドキュメントは文脈模写手順をROHCプロフィールに指定します。 それは文脈模写の間に使用される一般的なコンプレッサーと減圧装置論理を定義します、この手順に必要である特別なIRパケットの一般形式と同様に。 文脈模写のサポートを定義するプロフィールはさらにこのパケットの特定の形式を指定しなければなりません。
The fundamentals of the ROHC framework may be found in [2]. It is assumed throughout this document that these are understood.
ROHC枠組みの原理は[2]で見つけられるかもしれません。 このドキュメント中でこれらが理解されていると思われます。
2. Terminology
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 [1].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[1]で説明されるように本書では解釈されることであるべきですか?
This document reuses some of the terminology found in [2]. In addition, this document defines the following terms:
このドキュメントは[2]で見つけられた用語のいくつかを再利用します。 さらに、このドキュメントは次の用語を定義します:
Base context
基地の文脈
A base context is a context that has been validated by both the
compressor and the decompressor. The compressor can use a base
context as the reference when building a new context using
replication.
ベース文脈はコンプレッサーと減圧装置の両方によって有効にされた文脈です。 模写を使用することで新しい関係を築き上げるとき、コンプレッサーは参照としてベース文脈を使用できます。
Base CID (BCID)
基地のCid(BCID)
The Base Context Identifier is the CID used to identify the base
context, from which information needed for context replication can
be extracted.
基地のContext Identifierは文脈模写に必要である情報を抜粋できるベース文脈を特定するのに使用されるCIDです。
Context replication
文脈模写
Context replication is the mechanism that initializes a new
context based on another already existing context (a base
context).
文脈模写は別の既に既存の文脈(ベース文脈)に基づく新しい関係を初期化するメカニズムです。
Pelletier Standards Track [Page 4] RFC 4164 Context Replication for ROHC Profiles August 2005
ROHCのためのペレティア標準化過程[4ページ]RFC4164文脈模写は2005年8月の輪郭を描きます。
3. Context Replication for ROHC Profiles
3. ROHCプロフィールのための文脈模写
For profiles defining its support, context replication may be used as an alternative to the context initialization procedure found in [2]. Note that for such profiles, only the decompressor is mandated to support context replication; the use of the IR-CR packet is optional for the compressor.
サポートを定義するプロフィールのために、文脈模写は[2]で見つけられた文脈初期化手順に代わる手段として使用されるかもしれません。 そのようなプロフィールに関して、減圧装置だけが文脈模写を支持するために強制されることに注意してください。 コンプレッサーに、IR-CRパケットの使用は任意です。
This section describes the compressor and decompressor logic as well as the general format of the IR packet used with context replication.
このセクションはIRパケットの一般形式と同様に論理が文脈模写と共に使用したコンプレッサーと減圧装置について説明します。
3.1. Robustness Considerations
3.1. 丈夫さ問題
Context replication deviates from the initialization procedure defined in [2] in that it is able to achieve a certain level of compression from the first packet used to initialize the context for a new flow. Therefore, it is of particular importance that the context replication procedure be robust. This requires that a base context suitable for replication be used, that the integrity of the initialization packet be guaranteed, and finally that the outcome of the replication process be verified.
文脈模写は新しい流れのための文脈を初期化するのに使用される最初のパケットからあるレベルの圧縮を達成できるので[2]で定義された初期化手順から逸れます。 したがって、文脈模写手順が強健であることは、特別の重要性のそうです。 これは、模写に適したベース文脈が使用されて、初期化パケットの保全が保証されて、最終的に、模写の過程の結果が確かめられるのを必要とします。
The primary mechanisms used to achieve robustness of the context replication procedure are the selection of the base context (based on prior feedback from the decompressor) and the use of checksums. Specifically, the compressor must obtain enough confidence that the base context selected for replication is valid and available at the decompressor before initiating the replication procedure. Thus, the most reliable way to select the base context is to choose a context for which at least the static part to be replicated has previously been acknowledged by the decompressor.
文脈模写手順の丈夫さを達成するのに使用される一次機構は、ベース文脈(減圧装置からの先のフィードバックに基づいている)の選択とチェックサムの使用です。明確に、コンプレッサーは、模写手順に着手する前に模写のために選択されたベース文脈が減圧装置で有効であって、利用可能であるという十分な信用を得なければなりません。 したがって、ベース文脈を選択する最も信頼できる方法は少なくとも模写されるべき静的な部分が以前に減圧装置によって承認された文脈を選ぶことです。
In addition, the presence of a CRC covering the information that initializes the context ensures the integrity of the IR header used for replication. Finally, an additional CRC calculated over the original uncompressed header allows the decompressor to validate the reconstructed header and the outcome of the replication process.
さらに、文脈を初期化する情報をカバーするCRCの存在は模写に使用されるIRヘッダーの保全を確実にします。 最終的に、オリジナルの解凍されたヘッダーの上に計算された追加CRCは減圧装置に再建されたヘッダーと模写の過程の結果を有効にさせます。
3.2. Replication of Control Fields
3.2. 制御フィールドの模写
Control fields are fields that are either transmitted from a ROHC compressor to a ROHC decompressor or inferred based on the behavior of other fields, but are not part of the uncompressed header itself.
制御フィールドは、ROHCコンプレッサーからROHC減圧装置まで伝えられるか、または他の分野の振舞いに基づいて推論される野原ですが、解凍されたヘッダー自体の一部ではありません。
They can be used to control compression and decompression behavior, in particular, the set of packet formats to be used. Control fields are profile-specific. Examples of such fields include the NBO and RND flags [2], which indicate whether the IP-ID field is in Network
使用されるのにコントロール圧縮と減圧の振舞い、特にパケット・フォーマットのセットにそれらを使用できます。 制御フィールドはプロフィール特有です。 そのような分野に関する例はNBOとRND旗[2]を含んでいます。(旗はIP-ID分野がNetworkにあるかを示します)。
Pelletier Standards Track [Page 5] RFC 4164 Context Replication for ROHC Profiles August 2005
ROHCのためのペレティア標準化過程[5ページ]RFC4164文脈模写は2005年8月の輪郭を描きます。
Byte Order and the type of behavior of the field, respectively. Another example is the parameter indicating the mode of operation [2].
それぞれ分野の振舞いのバイトOrderとタイプ 別の例は運転モード[2]を示すパラメタです。
The IR-CR differs from the IR packet [2] in that its purpose is to entirely specify what part of the base context is replicated, and to convey the complementary information needed to create a new context. Because of this, a profile supporting the use of the IR-CR packet SHOULD define for each control field if the value of the field is replicated from the base context to the new context, or if its value is reinitialized.
IR-CRは[2] 目的がベース文脈のどんな部分が模写されるかを完全に指定して、新しい関係を作成するのに必要である補足的な情報を伝えることであるという点においてIRパケットと異なっています。 これのために、分野の値がベース文脈から新しい関係まで模写されるか、または値があるならSHOULDが各制御フィールドと定義するIR-CRパケットの使用を支持するプロフィールは再初期化されました。
In addition, a compressor MUST NOT initiate context replication while a control field that is not reinitialized by replication is being updated, e.g., during the handshake for a mode transition [2].
さらに、コンプレッサーは模写で再初期化されない制御フィールドをアップデートしている間、文脈模写を開始してはいけません、例えば、モード変遷[2]のための握手の間。
3.3. Compressor States and Logic
3.3. コンプレッサー州と論理
Compression with ROHC normally starts in the IR state, where IR packets must be sent to initialize a new context at the decompressor. IR packets include all static and non-static fields of the original header in uncompressed form plus some additional information. The compressor stays in the IR state until it obtains confidence that the decompressor has received the information.
通常、ROHCとの圧縮はIR状態で始まります。そこでは、減圧装置で新しい関係を初期化するためにIRパケットを送らなければなりません。 IRパケットは解凍されたフォームと何らかの追加情報にオリジナルのヘッダーのすべての静的で非静的な分野を含んでいます。 減圧装置が知らせを聞いたという信用を得るまで、コンプレッサーはIR状態にいます。
Context replication provides an optional mechanism to complement the ROHC initialization procedure. It defines a packet type, the IR packet for Context Replication (IR-CR), which can be used to initialize a new context. Consequently, the Context Replication (CR) state is introduced to the compressor state machine to encompass the additional logic required for the use of the IR-CR packet.
文脈模写は、ROHC初期化手順の補足となるように任意のメカニズムを提供します。 それはContext Replication(IR-CR)のためにパケットタイプ、IRパケットを定義します。(新しい関係を初期化するのにContext Replicationを使用できます)。 その結果、IR-CRパケットの使用に必要である追加論理を包含するようにContext Replication(CR)状態をコンプレッサー州のマシンに導入します。
For profiles defining support for context replication, the compressor may thus transit directly from the IR state to the CR state if an already existing context can be selected as a base context for replication. This effectively replaces any IR/IR-DYN packets sent during the context establishment procedure with an IR-CR packet.
文脈模写、コンプレッサーのサポートを定義するプロフィールのために、その結果、直接IR状態からCRまでのトランジットが、模写のためのベース文脈として既に既存の文脈を選定されることができるかどうかと述べますように。 事実上、これは文脈設立手順の間にIR-CRパケットと共に送られたどんなIR IR/DYNパケットも取り替えます。
3.3.1. Context Replication (CR) State
3.3.1. 文脈模写(CR)状態
The purpose of the CR state is to initialize a new context by reusing an already existing context. In this state, the compressor sends a combination of uncompressed and compressed information, along with a reference to a base context plus some additional information. Therefore, header information pertaining to fields that are being replicated is not sent.
CR状態の目的は既に既存の文脈を再利用することによって新しい関係を初期化することです。 この状態では、コンプレッサーは解凍されて圧縮された情報の組み合わせを送ります、ベース文脈の参照と何らかの追加情報と共に。 したがって、模写されている分野に関係するヘッダー情報が送られません。
Pelletier Standards Track [Page 6] RFC 4164 Context Replication for ROHC Profiles August 2005
ROHCのためのペレティア標準化過程[6ページ]RFC4164文脈模写は2005年8月の輪郭を描きます。
The compressor stays in the CR state until it is confident that the decompressor has received the replication information correctly.
減圧装置が正しく模写情報を受け取ったのは、自信があるまで、コンプレッサーがCR状態にいます。
3.3.2. State Machine with Context Replication
3.3.2. 文脈模写がある州のマシン
The compressor always starts in the lower compression state (IR), and transits to the context replication state (CR) under the constraint that the compressor can select a base context that is suitable for the flow being compressed (see also Section 3.3.3.1).
また、セクション3.3を見てください。コンプレッサーが下側の圧縮状態(IR)でいつも始まって、コンプレッサーが圧縮されていて、流れに適したベース文脈を選択できるという規制の下の文脈模写状態(CR)に通過する、(.3 .1)。
The transition from the CR state to a higher compression state (e.g., the CO state for [3]) is based on the optimistic approach principle or feedback received from the decompressor.
変遷は状態をCRより、より高い圧縮に述べます。([3])のための例えばCO州は減圧装置から受け取られた楽観的なアプローチ原則かフィードバックに基づいています。
The figure below shows the additional state for the compressor. The details of the state transitions and compression logic are given in sub-sections following the figure.
以下の図はコンプレッサーのために追加状態を示しています。 図に従って、状態遷移と圧縮論理の詳細は小区分で明らかにされます。
BCID selection Optimistic approach / ACK
+----->----->------+ +----->----->----->-----+
| | | |
| v | v
+---------+ +---------+ +-------------+
| IR | | CR | | Higher |
| state | | state | | order state |
+---------+ +---------+ +-------------+
^ |
| NACK / STATIC-NACK |
+---<-----<-----<----+
BCID選択Optimisticアプローチ/ACK+----->、-、-、-、--、>、-、-、-、-、--+ +----->、-、-、-、--、>、-、-、-、--、>、-、-、-、--+ | | | | | v| +に対して---------+ +---------+ +-------------+ | IR| | CR| | より高い| | 状態| | 状態| | オーダー状態| +---------+ +---------+ +-------------+ ^ | | 静的なナック/ナック| +---<、-、-、-、--、<、-、-、-、--、<、-、-、--+
Note that context replication is a complement to the normal initialization procedure for ROHC profiles that support it. Therefore, the compressor transition to the CR state is an optional addition to the state machine, and does not affect already existing transitions between the IR state and higher order state(s).
文脈模写がそれを支持するROHCプロフィールのための正常な初期化手順への補数であることに注意してください。 したがって、CR状態へのコンプレッサー変遷は、州のマシンへの任意の添加であり、IR州と、より高いオーダー状態の間で既に既存の変遷に影響しません。
3.3.3. State Transition Logic
3.3.3. 状態遷移論理
Decisions about transition to and from the CR state are taken by the compressor on the basis of:
コンプレッサーは以下に基づいて状態とCR状態からの変遷に関する決定を取ります。
- availability of a base context - positive feedback from the decompressor (Acknowledgements -- ACKs) - negative feedback from the decompressor (Negative ACKs -- NACKs) - confidence level regarding error-free decompression of a packet
- ベース文脈の有用性--減圧装置(承認--ACKs)からの積極的なフィードバック--減圧装置(否定的ACKs--NACKs)からの負のフィードバック--パケットのエラーのない減圧に関する信頼水準
Pelletier Standards Track [Page 7] RFC 4164 Context Replication for ROHC Profiles August 2005
ROHCのためのペレティア標準化過程[7ページ]RFC4164文脈模写は2005年8月の輪郭を描きます。
Context replication is designed to operate over links where a feedback channel is available. This is necessary to ensure that the information used to create a new context is synchronized between the compressor and the decompressor. In addition, context replication may also make use of feedback from decompressor to compressor for transition back to the IR state and for OPTIONAL improved forward transition towards a state with a higher compression ratio.
文脈模写は、フィードバックチャンネルが利用可能であるリンクの上に作動するように設計されています。 これが、新しい関係を作成するのに使用される情報がコンプレッサーと減圧装置の間で同期するのを保証するのに必要です。 また、さらに、文脈模写は、より高い圧縮比でフィードバックのIR状態への変遷とOPTIONALの減圧装置からコンプレッサーまでの使用を状態に向かった改良された前進の変遷にするかもしれません。
The format that must be used by all profiles for the feedback field within the general ROHC format is specified in Section 5.2.2 of [2]; the feedback information is structured using two possible formats: FEEDBACK-1 and FEEDBACK-2. In particular, FEEDBACK-2 can carry one of three possible types of feedback information: ACK, NACK, or STATIC-NACK.
一般的なROHCの中のフィードバック分野にすべてのプロフィールによって使用されて、形式がセクション5.2.2で指定されるということであるに違いない[2]の形式。 フィードバック情報は2つの可能な形式を使用することで構造化されます: フィードバック-1とフィードバック-2。 特に、FEEDBACK-2はフィードバック情報の3つの可能なタイプのひとりを運ぶことができます: ACK、ナック、または静的なナック。
3.3.3.1. Selection of Base Context, Upward Transition
3.3.3.1. 基地の文脈の選択、上向きの変遷
The compressor may initiate a transition from the IR state to the CR state when a suitable base context can be identified. To perform this transition, the compressor selects a context that has previously been acknowledged by the decompressor as the base context. The selected context MUST have been acknowledged by the decompressor using the CRC option (see also [2], Section 5.7.6.3) in the feedback message. The static part of the base context to be replicated MUST have been acknowledged by the decompressor and the base context MUST be valid at replication time.
適当なベース文脈を特定できるとき、コンプレッサーはIR状態からCR状態までの変遷を開始するかもしれません。 この変化をするために、コンプレッサーは以前にベース文脈として減圧装置によって承認された文脈を選択します。 また、[2]を見てください、セクション5.7。CRCオプションを使用して、選択された文脈が減圧装置によって承認されたに違いない、(.6 フィードバックメッセージの.3)。 模写されるべきベース文脈の静的な部分は減圧装置によって承認されたに違いありません、そして、ベース文脈は模写時に有効であるに違いありません。
This also implies that a compressor is not allowed to use the context replication mechanism if a feedback channel is not present. However, note that the presence of the feedback channel cannot provide the guarantee that a base context selected for replication has not been corrupted after it has been acknowledged, or that it is still part of the state managed by the decompressor when the IR-CR will be received.
また、フィードバックチャンネルが出席していないなら、コンプレッサーはこれが文脈模写メカニズムを使用できないつもりです。 しかしながら、フィードバックチャンネルの存在がそれが承認された後に模写のために選択されたベース文脈が腐敗していないか、それでも、それがIR-CRを受け取るとき減圧装置で経営する状態の一部であるという保証を提供できないことに注意してください。
More specifically, RFC 3095 [2] defines the context identifier (CID) as a reference to the state information (i.e., the context) used for compression and decompression. Multiple packet streams, each having its own context, may thus share a channel; and the CID space along with its representation within packet formats may be negotiated as part of the channel state. However, because RFC 3095 [2] does not explicitly define context state management between compressor and decompressor, in particular for connection-oriented flows (e.g., TCP), no more than a high degree of confidence can be achieved when selecting a base context.
より明確に、RFC3095[2]は圧縮と減圧に使用される州の情報(すなわち、文脈)の参照と文脈識別子(CID)を定義します。 その結果、それぞれそれ自身の文脈を持っていて、複数のパケットの流れがチャンネルを共有するかもしれません。 そして、パケット・フォーマットの中の表現に伴うCIDスペースはチャンネル状態の一部として交渉されるかもしれません。 しかしながら、RFC3095[2]が明らかにコンプレッサーと減圧装置の間の文脈国家管理を定義しないので、特に接続指向の流れ(例えば、TCP)において、ベース文脈を選択するとき、信用の高度しか達成できません。
Pelletier Standards Track [Page 8] RFC 4164 Context Replication for ROHC Profiles August 2005
ROHCのためのペレティア標準化過程[8ページ]RFC4164文脈模写は2005年8月の輪郭を描きます。
In the case where feedback is not used by the decompressor, the compressor may have to periodically transit back to the IR state. In such a case, the same logic applies for the transition back to the higher order state via the CR state: a base context, previously acknowledged and suitable for replication, must be re-selected.
フィードバックが減圧装置によって使用されない場合では、コンプレッサーはIR状態にトランジットを定期的に持っているかもしれません。 このような場合には、同じ論理はCR状態を通して、より高いオーダー状態への変遷に申し込みます: 以前に、承認されて、模写に適したベース文脈を、再選択しなければなりません。
The criteria for whether an existing context is a suitable base context for replication for a new flow are left to implementations.
既存の文脈が新しい流れのための模写のための適当なベース文脈であるかどうか評価基準は実現に残されます。
Whenever the sequencing information from the last acknowledgement received is available, the compressor MAY use it to determine what fields can be replicated to avoid replicating any fields that have changed significantly from the state corresponding to the acknowledged packet.
受けられた最後の承認からの配列情報が利用可能であるときはいつも、コンプレッサーは、何か承認されたパケットに対応する状態からかなり変化した分野を模写するのを避けるためにどんな分野を模写できるかを決定するのにそれを使用するかもしれません。
3.3.3.2. Optimistic Approach, Upward Transition
3.3.3.2. 楽観的なアプローチ、上向きの変遷
Transition to a higher order state can be carried out according to the optimistic approach principle. This means that the compressor may perform an upward state transition when it is fairly confident that the decompressor has received enough information to correctly decompress packets sent according to the higher compression state.
楽観的なアプローチ原則によると、より高いオーダー状態への変遷を行うことができます。 これは、減圧装置が正しくより高い圧縮状態に応じて送られたパケットを減圧できるくらいの情報を受け取ったのが、かなり自信があるとき、コンプレッサーが上向きの状態遷移を実行するかもしれないことを意味します。
In general, there are many approaches where the compressor can obtain such information. The compressor may obtain its confidence by sending several IR-CR packets with the same information.
一般に、多くのアプローチがコンプレッサーがそのような情報を得ることができるところにあります。 コンプレッサーは、同じ情報でいくつかのIR-CRパケットを送ることによって、信用を得るかもしれません。
3.3.3.3. Optional Acknowledgements (ACKs), Upward Transition
3.3.3.3. 任意の承認(ACKs)、上向きの変遷
An ACK may be sent by the decompressor to indicate that a context has been successfully initialized during context replication.
減圧装置でACKを送って、文脈が文脈模写の間首尾よく初期化されているのを示すかもしれません。
Upon reception of an ACK, the compressor may assume that the context replication procedure was successful and transit from its initial state (e.g., IR state) to a higher compression state.
ACKのレセプションでは、コンプレッサーは、文脈模写手順がうまくいったと仮定して、初期状態(例えば、IR状態)から、より高い圧縮状態まで通過するかもしれません。
3.3.3.4. Negative ACKs (NACKs), Downward Transition
3.3.3.4. 否定的ACKs(NACKs)、下向きの変遷
A STATIC-NACK sent by the decompressor may indicate that the decompressor could not initialize a valid context during context replication, and that the corresponding context has been invalidated.
送られたSTATIC-ナックは、減圧装置で減圧装置が文脈模写の間有効な文脈を初期化できないで、対応する文脈が無効にされたのを示すかもしれません。
Upon reception of a STATIC-NACK, the compressor MUST transit back to its initial no context state. The compressor SHOULD also refrain from sending IR-CR packets using the same base context, at least until an acknowledgement subsequent to the reception of the
STATIC-ナックのレセプションでは、コンプレッサーは文脈状態を全くイニシャルに通過して戻してはいけません。 また、コンプレッサーSHOULDは少なくともレセプションへのその後の承認まで同じベース文脈を使用することでIR-CRパケットを送るのを控えます。
Pelletier Standards Track [Page 9] RFC 4164 Context Replication for ROHC Profiles August 2005
ROHCのためのペレティア標準化過程[9ページ]RFC4164文脈模写は2005年8月の輪郭を描きます。
STATIC-NACK makes this context suitable for replication (Section 3.3.3.1). The compressor SHOULD re-initialize the decompressor context using an IR packet.
STATIC-ナックがこの文脈を模写に適するようにする、(セクション3.3 .3 .1)。 コンプレッサーSHOULDは、IRパケットを使用することで減圧装置文脈を再初期化します。
A NACK sent by the decompressor may indicate that a valid context has been successfully initialized but that the decompression of one or more subsequent packets has failed.
送られたナックは、減圧装置で有効な文脈が首尾よく初期化されましたが、1つ以上のその後のパケットの減圧が失敗したのを示すかもしれません。
Upon reception of a NACK, the compressor MAY assume that the static part of the decompressor context is valid, but that the dynamic part is invalid; the compressor may take actions accordingly.
ナックのレセプションでは、コンプレッサーは、減圧装置文脈の静的な部分が有効ですが、ダイナミックな部分が無効であると仮定するかもしれません。 コンプレッサーはそれに従って、行動を取るかもしれません。
3.4. Decompressor Logic
3.4. 減圧装置論理
3.4.1. Replication and Context Initialization
3.4.1. 模写と文脈初期設定
Upon reception of an IR-CR packet, the decompressor first determines its content ([2], Section 5.2.6). The profile indicated in the IR-CR packet determines how it is to be processed. If the CRC (8-bit CRC) fails to verify the packet, the packet MUST be discarded.
IR-CRパケットのレセプションでは、減圧装置は最初に、内容([2]、セクション5.2.6を)決定します。 IR-CRパケットで示されたプロフィールはそれが処理されることになっている方法を決定します。 CRC(8ビットのCRC)がパケットについて確かめないなら、パケットを捨てなければなりません。
If the profile as indicated in the IR-CR packet defines the use of the Base CID, and if its corresponding field is present within the packet format, this field is used to identify the base context; otherwise, the CID is used.
IR-CRパケットにみられるようにプロフィールが基地のCIDの使用を定義して、対応する分野がパケット・フォーマットの中に存在しているなら、この分野はベース文脈を特定するのに使用されます。 さもなければ、CIDは使用されています。
3.4.2. Reconstruction and Verification
3.4.2. 再建と検証
The decompressor creates a new context using the information present in the IR-CR packet together with the identified base context, and decompresses the original header.
減圧装置は、特定されたベース文脈に伴うIR-CRパケットの現在の情報を使用することで新しい関係を作成して、オリジナルのヘッダーを減圧します。
The CRC calculated over the original uncompressed header and carried within the profile-specific part of the IR-CR headers (7-bit CRC) MUST be used to verify decompression.
減圧について確かめるのにオリジナルの解凍されたヘッダーの上に計算されて、IR-CRヘッダー(7ビットのCRC)のプロフィール特有の一部の中で運ばれたCRCを使用しなければなりません。
When the decompression is verified and successful, the decompressor initializes or updates the context with the information received in the current header. The decompressor SHOULD send an ACK when it successfully validates the context as a result of the decompression of one or more IR-CR packets.
減圧が確かめられてうまくいっているとき、減圧装置は、文脈を初期化するか、または現在のヘッダーに情報を受け取っていてアップデートします。 それが1つ以上のIR-CRパケットの減圧の結果、首尾よく文脈を有効にすると、減圧装置SHOULDはACKを送ります。
Otherwise, if the reconstructed header fails the CRC check, changes (either initialization or update) to the context MUST NOT be performed. When the decompressor fails to validate the header, actions as specified in Section 3.4.3 are taken.
さもなければ、再建されたヘッダーがCRCチェックに失敗するなら、文脈への変化(初期化かアップデートのどちらか)を実行してはいけません。 減圧装置がヘッダーを有効にしないと、セクション3.4.3における指定されるとしての行動を取ります。
Pelletier Standards Track [Page 10] RFC 4164 Context Replication for ROHC Profiles August 2005
ROHCのためのペレティア標準化過程[10ページ]RFC4164文脈模写は2005年8月の輪郭を描きます。
3.4.3. Actions upon Failure
3.4.3. 失敗への動作
For profiles supporting context replication, the feedback logic of a decompressor is similar to the logic used for context initialization, as described in [2].
文脈模写を支持するプロフィールに関しては、減圧装置のフィードバック論理は文脈初期化に使用される論理と同様です、[2]で説明されるように。
Specifically, when the decompressor fails to validate the context following the decompression of one or more initial IR-CR packets, it MUST invalidate the context and remain in its initial state. In addition, the decompressor SHOULD send a STATIC-NACK. In particular, a decompressor implementation performing strict memory management, such as deleting context state information when a connection-oriented flow (e.g., TCP) is known to have terminated, SHOULD send STATIC-NACK in this case. Otherwise, there is a risk that the compressor will maintain a specific CID as a potential candidate for a later replication attempt, while actually there is insufficient state left in the decompressor for this CID to act as a Base CID.
明確に、1つ以上の初期のIR-CRパケットの減圧に続いて、減圧装置が文脈を有効にしないとき、それは、文脈を無効にして、初期状態に残らなければなりません。 さらに、減圧装置SHOULDはSTATIC-ナックを送ります。 特に、いつ接続指向の流れ(例えば、TCP)が終わったのが知られているかという文脈州の情報を削除などなどの厳しいメモリ管理を実行する減圧装置実現、SHOULDはこの場合STATIC-ナックを送ります。 さもなければ、不十分な状態が実際にある間の後の模写試みの潜在的候補がこのCIDが基地のCIDとして機能させる減圧装置でいなくなったのでコンプレッサーが特定のCIDを維持するというリスクがあります。
If the context has been successfully validated from the decompression of one or more initial IR-CR packets, the decompressor SHOULD send a NACK when it fails to verify the context following the decompression of one or more subsequent IR-CR packets.
文脈が1つ以上の初期のIR-CRパケットの減圧から首尾よく有効にされて、1つ以上のその後のIR-CRパケットの減圧に続いて、それが文脈について確かめないと、減圧装置SHOULDはナックを送ります。
3.4.4. Feedback Logic
3.4.4. フィードバック論理
The decompressor SHOULD use the CRC option (see [2], Section 5.7.6.3) when sending feedback corresponding to an IR or an IR-CR packet.
[2]を見てください、セクション5.7。減圧装置SHOULDがCRCオプションを使用する、(.6 .3) IRかIR-CRパケットに対応するフィードバックを送るとき。
3.5. Packet Formats
3.5. パケット・フォーマット
The format of the IR-CR packet has been designed under the following constraints:
IR-CRパケットの形式は以下の規制で設計されています:
a) it must be possible to either overwrite a CID during context
replication, or to use a different CID than the Base CID for the
replicated context;
b) it must be possible to selectively include or exclude from the
packet format some fields that may be replicable;
c) it must be possible for some fields that may be replicable to be
represented within the packet format using either a compressed or
an uncompressed form;
d) it must be possible for the decompressor to verify the success of
the replication procedure;
e) it is anticipated that profiles, other than ROHC-TCP [3], will
also define support for context replication. Therefore it is
desirable that the packet format be profile independent.
a) 文脈模写の間、CIDを上書きするか、または異なったCIDを使用するのが模写された文脈のための基地のCIDより可能であるに違いありません。 b) パケット・フォーマットからいくつかのreplicableであるかもしれない分野を選択的に含んでいるか、または除くのが可能であるに違いありません。 c) いくつかに、パケットの中に表されるためにreplicableであるかもしれない分野がどちらかを使用するか、aが圧縮した解凍されたフォームをフォーマットするのは、可能であるに違いありません。 d) 減圧装置が模写手順の成功について確かめるのは、可能であるに違いありません。 e) また、ROHC-TCP[3]を除いて、プロフィールが文脈模写のサポートを定義すると予期されます。 したがって、パケット・フォーマットがプロフィール独立者であることは望ましいです。
Pelletier Standards Track [Page 11] RFC 4164 Context Replication for ROHC Profiles August 2005
ROHCのためのペレティア標準化過程[11ページ]RFC4164文脈模写は2005年8月の輪郭を描きます。
3.5.1. CRCs in the IR-CR Packet
3.5.1. IR-CRパケットのCRCs
The IR packet, as defined in [2], is used to communicate static and/or dynamic parts of a context, and typically initialize the context. For example, the static and dynamic chains of IR packets may contain an uncompressed representation of the original header.
[2]で定義されるIRパケットは、文脈の静的な、そして/または、ダイナミックな部分を伝えて、文脈を通常初期化するのに使用されます。 例えば、IRパケットの静的でダイナミックなチェーンはオリジナルのヘッダーの解凍された表現を含むかもしれません。
The IR packet format includes an 8-bit CRC, calculated over the initial part of the IR packet. This CRC is meant to protect any information that initializes the context. In particular, its coverage always includes any CID information as well as the profile used to interpret the remainder of the IR packet.
IRパケット・フォーマットはIRパケットの初期の一部の上計算された8ビットのCRCを含んでいます。 このCRCは文脈を初期化するどんな情報も保護することになっています。 特に、適用範囲はIRパケットの残りを解釈するのに使用されるプロフィールと同様にどんなCID情報もいつも含んでいます。
The purpose of the 8-bit CRC is to ensure the integrity of the IR header itself. Profiles may extend the coverage of this CRC to include the entire IR header, thus allowing the verification of the integrity of the entire uncompressed header. However, because the format of the IR packet is common to all ROHC profiles and verified as part of the initial processing of a ROHC decompressor (see [2], Section 5.2.6.), profiles may not redefine this CRC beyond the extent of its coverage.
CRCがIRヘッダー自体の保全を確実にすることになっている8ビットの目的。 プロフィールは全体のIRヘッダーを含むようにこのCRCの適用範囲を広げるかもしれません、その結果、全体の解凍されたヘッダーの保全の検証を許します。 しかしながら、IRパケットの形式がすべてのROHCプロフィールに共通でROHC減圧装置の初期の処理の一部が確かめられるので(.6に[2]、セクション5.2を見てください)、プロフィールは適用範囲の範囲を超えてこのCRCを再定義しないかもしれません。
RFC 3095 [2] also defines a 3-bit CRC and a 7-bit CRC for compressed headers, used to verify proper decompression and validate the context. This type of CRC is calculated over the original uncompressed header, as it is not sufficient to protect only the compressed data being exchanged between compressor and decompressor for the purpose of ensuring a robust reconstruction of the original header.
また、RFC3095[2]は圧縮されたヘッダーのために3ビットのCRCと7ビットのCRCを定義します、適切な減圧について確かめて、文脈を有効にするのにおいて、使用されています。 CRCのこのタイプはオリジナルの解凍されたヘッダーの上に計算されます、コンプレッサーと減圧装置の間でオリジナルのヘッダーの体力を要している再建を確実にする目的と交換される圧縮されたデータだけを保護するのが十分でないときに。
Thus, there is a clear distinction in purpose between the 8-bit CRC found in the IR packet and the 3-bit or 7-bit CRC found in compressed headers. With context replication, where the IR-CR packet may contain both compressed as well as uncompressed information and omit entirely replicable fields, this distinction in no longer present.
したがって、圧縮されたヘッダーで見つけられたCRCがIRパケットで見つけた8ビットと3ビットか7ビットのCRCの間には、目的に明らかな区別があります。 文脈模写で、IR-CRパケットがそうするかもしれないところに圧縮されて解凍の両方にされた情報を含んでください、そして、完全にreplicableな分野(もう現在のこの区別)を省略してください。
Profiles supporting context replication MUST define a CRC over the original uncompressed header as part of the profile-specific information in the IR-CR packet. This is necessary to allow a decompressor to verify that the replication process has succeeded.
文脈模写を支持するプロフィールはオリジナルの解凍されたヘッダーの上にIR-CRパケットでプロフィール特有の情報の一部とCRCを定義しなければなりません。 これが、減圧装置が、模写の過程が成功したことを確かめるのを許容するのに必要です。
Pelletier Standards Track [Page 12] RFC 4164 Context Replication for ROHC Profiles August 2005
ROHCのためのペレティア標準化過程[12ページ]RFC4164文脈模写は2005年8月の輪郭を描きます。
3.5.1.1. 7-bit CRC
3.5.1.1. 7ビットのCRC
The 7-bit CRC in the IR-CR packet is calculated over all octets of the entire original header, before replication, in the same manner as described in Section 5.9.2 of [2].
IR-CRパケットの7ビットのCRCは全体のオリジナルのヘッダーのすべての八重奏に関して計算されます、模写の前に、[2]についてセクション5.9.2で説明されるのと同じ方法で。
The initial content of the CRC register is to be preset to all 1's. The CRC polynomial used for the 7-bit CRC in the IR-CR is:
CRCレジスタの初期の内容はすべての1にあらかじめセットされることです。 IR-CRの7ビットのCRCに使用されるCRC多項式は以下の通りです。
C(x) = 1 + x + x^2 + x^3 + x^6 + x^7
C(x)は1+x+x^2+x^3+x^6+x^7と等しいです。
3.5.1.2. 8-bit CRC
3.5.1.2. 8ビットのCRC
The coverage of the 8-bit CRC in the IR-CR packet is not profile dependent, as opposed to the ROHC IR(-DYN) packet (see [2], Sections 5.2.3 and 5.2.4). It MUST cover the entire packet, excluding the payload. In particular, this includes the CID or any add-CID octet as well as the Base CID field, if present. For profiles that define the usage of the Base CID within the packet format of the IR-CR as optional, this CRC MUST also cover the information used to indicate the presence of this field within the packet.
[2]、セクション5.2.3と5.2を見てください。IR-CRパケットの8ビットのCRCの適用範囲はプロフィール扶養家族ではありません、ROHC IR(-DYN)パケットと対照的に(.4)。 ペイロードを除いて、それは全体のパケットを覆わなければなりません。 存在しているなら、特に、これはCIDか基地のCID分野と同様にどんなCIDを加えている八重奏も含んでいます。 また、IR-CRのパケット・フォーマットの中で基地のCIDの使用法を任意であると定義するプロフィールに関しては、このCRC MUSTはパケットの中にこの分野の存在を示すのに使用される情報をカバーしています。
The initial content of the CRC register is to be preset to all 1's. The CRC polynomial used for the 8-bit CRC in the IR-CR is:
CRCレジスタの初期の内容はすべての1にあらかじめセットされることです。 IR-CRの8ビットのCRCに使用されるCRC多項式は以下の通りです。
C(x) = 1 + x + x^2 + x^8
C(x)は1+x+x^2+x^8と等しいです。
3.5.2. General Format of the IR-CR Packet
3.5.2. IR-CRパケットの一般形式
The context replication mechanism requires a dedicated IR packet format that uniquely identifies the IR-CR packet. This packet communicates the static and the dynamic parts of the replicated context. It may also communicate a reference to a base context.
文脈模写メカニズムは唯一IR-CRパケットを特定するひたむきなIRパケット・フォーマットを必要とします。 このパケットは静的な部分と模写された文脈のダイナミックな部分を伝えます。 また、それはベース文脈の参照を伝えるかもしれません。
With consideration to the extensibility of the IR packet type defined in [2], support for replication can be added using the profile- specific part of the IR packet. Note that there is one bit, (x), left in the IR header for "Profile specific information". The definition of this bit is profile specific. Thus, profiles supporting context replication MAY use this bit as a flag indicating whether the packet is an IR packet or an IR-CR packet. Note also that profiles may define an alternative method to identify the IR-CR packet within the profile-specific information, instead of using this bit.
[2]で定義されたIRパケットタイプの伸展性への考慮で、IRパケットのプロフィールの特定の一部を使用することで模写のサポートを加えることができます。 1ビットがあるというメモ((x))はIRヘッダーで「プロフィール特殊情報」にいなくなりました。 このビットの定義はプロフィール特有です。 したがって、文脈模写を支持するプロフィールはパケットがIRパケットであるかどうかを示す旗かIR-CRパケットとしてこのビットを使用するかもしれません。 また、このビットを使用することの代わりにプロフィールがプロフィール特有の情報の中でIR-CRパケットを特定する別法を定義するかもしれないことに注意してください。
The IR-CR header associates a CID with a profile, and initializes the context using the context replication mechanism. It is not recommended to use this packet to repair a damaged context.
IR-CRヘッダーは、CIDをプロフィールに関連づけて、文脈模写メカニズムを使用することで文脈を初期化します。 それが破損している文脈を修理するのにこのパケットを使用することが勧められません。
Pelletier Standards Track [Page 13] RFC 4164 Context Replication for ROHC Profiles August 2005
ROHCのためのペレティア標準化過程[13ページ]RFC4164文脈模写は2005年8月の輪郭を描きます。
The IR-CR has the following general format:
IR-CRには、以下の一般形式があります:
0 1 2 3 4 5 6 7
--- --- --- --- --- --- --- ---
: Add-CID octet : if for small CIDs and (CID != 0)
+---+---+---+---+---+---+---+---+
| 1 1 1 1 1 1 0 x | IR type octet
+---+---+---+---+---+---+---+---+
: :
/ 0-2 octets of CID / 1-2 octets if for large CIDs
: :
+---+---+---+---+---+---+---+---+
| Profile | 1 octet
+---+---+---+---+---+---+---+---+
| CRC | 1 octet
+---+---+---+---+---+---+---+---+
| |
/ Profile-specific information / variable length
| |
- - - - - - - - - - - - - - - -
| |
/ Payload / variable length
| |
- - - - - - - - - - - - - - - -
0 1 2 3 4 5 6 7 --- --- --- --- --- --- --- --- : CIDを加えている八重奏: 小さいCIDsと(CID!=0)+のために---+---+---+---+---+---+---+---+ | 1 1 1 1 1 1 0、x| IRタイプ八重奏+---+---+---+---+---+---+---+---+ : : CID / 1-2八重奏の/0-2八重奏、大きいCIDsのために: : +---+---+---+---+---+---+---+---+ | プロフィール| 1 八重奏+---+---+---+---+---+---+---+---+ | CRC| 1 八重奏+---+---+---+---+---+---+---+---+ | | /プロフィール特有の情報/可変長| | - - - - - - - - - - - - - - - - | | /有効搭載量/可変長| | - - - - - - - - - - - - - - - -
x: Profile-specific information. Interpreted according to
the profile indicated in the Profile field.
x: プロフィール特有の情報。 Profile分野で示されたプロフィールによると、解釈されます。
Profile: The profile to be associated with the CID. In the IR-CR
packet, the profile identifier is abbreviated to the 8
least significant bits (LSBs). It selects the highest-
number profile in the channel state parameter PROFILES
that matches the 8 LSBs given (see also [2]).
以下の輪郭を描いてください。 CIDに関連しているプロフィール。 IR-CRパケットでは、プロフィール識別子は8つの最下位ビット(LSBs)に簡略化されています。 それは与えられている8LSBsに合っているチャンネル州のパラメタPROFILESで最も高い数のプロフィールを選択します。(また、[2])を見てください。
CRC: 8-bit CRC computed using the polynomial of Section
3.5.1.2.
CRC: .2にセクション3.5.1の多項式を使用することで計算された8ビットのCRC
Profile-specific information: The contents of this part of the
IR-CR packet are defined by the individual profiles.
This information is interpreted according to the profile
indicated in the Profile field. It MUST include a 7-bit
CRC over the original uncompressed header using the
polynomial of Section 3.5.1.1. It also includes the
static and dynamic subheader information used for
replication; thus, which header fields are replicated
and their respective encoding methods are outside the
scope of this document.
プロフィール特有の情報: IR-CRパケットのこの部分の内容は個々のプロフィールによって定義されます。 Profile分野で示されたプロフィールによると、この情報は解釈されます。 .1にセクション3.5.1の多項式を使用して、それはオリジナルの解凍されたヘッダーの上に7ビットのCRCを含まなければなりません。 また、それは模写に使用される静的でダイナミックな「副-ヘッダー」情報を含んでいます。 したがって、このドキュメントの範囲の外にどのヘッダーフィールドが模写されるか、そして、それらのそれぞれのコード化方法があります。
Pelletier Standards Track [Page 14] RFC 4164 Context Replication for ROHC Profiles August 2005
ROHCのためのペレティア標準化過程[14ページ]RFC4164文脈模写は2005年8月の輪郭を描きます。
Payload: The payload of the corresponding original packet, if
any.
有効搭載量: もしあれば対応するオリジナルのパケットのペイロード
3.5.3. Properties of the Base Context Identifier (BCID)
3.5.3. 基地の文脈識別子の特性(BCID)
The Base CID within the packet format of the IR-CR may be assigned a different value than the context identifier associated with the new flow (i.e., BCID != CID); otherwise, the base context is overwritten with the new context by the replication process.
異価は新しい流れに関連している文脈識別子よりIR-CRのパケット・フォーマットの中の基地のCIDに割り当てられるかもしれません(すなわち、BCID!はCIDと等しいです)。 さもなければ、ベース文脈は新しい関係で模写工程で上書きされます。
When the channel uses small CIDs, a four-bit field within the packet format of the IR-CR minimally represents the BCID with a value from 0 to 15. In particular, the four bits of Add-CID used with small CIDs [2] are not needed for the BCID, as this information is already provided by the CID of the IR-CR packet itself. When large CIDs are used, the BCID is represented in the IR-CR with one or two octets, and it is coded in the same way as a large CID [2].
チャンネルが小さいCIDsを使用すると、IR-CRのパケット・フォーマットの中の4ビットの分野は値でBCIDを最少量で0〜15まで表します。 小さいCIDs[2]と共に使用されるAdd-CIDの4ビットはBCIDに特に、必要ではありません、この情報がIR-CRパケット自体のCIDによって既に提供されるとき。 大きいCIDsが使用されているとき、BCIDはIR-CRに1か2つの八重奏で表されます、そして、大きいCID[2]と同様に、それはコード化されます。
4. Security Considerations
4. セキュリティ問題
This document adds an alternative mechanism for ROHC profiles to increase the compression efficiency when initializing a new context, by reusing information already existing at the decompressor. This is achieved by introducing new state transition logic, new feedback logic, and a new packet type -- all based on logic and packet formats already defined in RFC 3095 [2].
新しい関係を初期化するとき、ROHCプロフィールが圧縮効率を増加させるように、このドキュメントは代替のメカニズムを加えます、減圧装置で既に存在する情報を再利用することによって。 これは新しい状態遷移論理、新しいフィードバック論理、および新しいパケットタイプを導入することによって、達成されます--論理に基づくすべてとRFC3095[2]で既に定義されたパケット・フォーマット。
In this respect, this document is not believed to bring any additional weakness to potential attacks to those already listed in [2]. However, it does increase the potential impacts of these attacks by creating dependencies between multiple contexts. Specifically, corruption of one context can fail compressor attempts to initialize another context at the decompressor, or to propagate to another context, if the compressor uses a corrupted context as a base for replication.
この点で、このドキュメントが[2]に既に記載されたものに起こり得るかもしれない攻撃へのどんな別の弱みももたらすと信じられていません。 しかしながら、それは、複数の文脈の間の依存を引き起こすことによって、これらの攻撃の可能性のある衝撃を増加させます。 明確に、1つの文脈の不正は減圧装置で別の文脈を初期化するか、または別の文脈に伝播するコンプレッサー試みに失敗できます、コンプレッサーが模写にベースとして崩壊した文脈を使用するなら。
5. Acknowledgements
5. 承認
The author would like to thank Richard Price, Kristofer Sandlund, Fredrik Lindstroem, Zhigang Liu, and HongBin Liao for valuable input, as well as Mark West and Lars-Erik Jonsson who also served as committed working group document reviewers.
作者は貴重な入力、マーク西洋、およびラース-エリック・イェンソンのためのまた、遂行されたワーキンググループのドキュメント評論家として勤めたリチャードPrice、クリストファSandlund、フレドリックLindstroem、Zhigangリュウ、およびHongBinリャオに感謝したがっています。
Pelletier Standards Track [Page 15] RFC 4164 Context Replication for ROHC Profiles August 2005
ROHCのためのペレティア標準化過程[15ページ]RFC4164文脈模写は2005年8月の輪郭を描きます。
6. References
6. 参照
6.1. Normative References
6.1. 引用規格
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[1] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[2] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H.,
Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Liu,
Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T.,
Yoshimura, T., and H. Zheng, "RObust Header Compression (ROHC):
Framework and four profiles: RTP, UDP, ESP, and uncompressed",
RFC 3095, July 2001.
[2] ボルマン、C.、バーマイスター、C.、デーゲルマルク、M.、福島、H.、ハンヌ、H.、イェンソン、L-E.、Hakenberg、R.、コーレン、T.、Le、K.、リュウ、Z.、Martensson、A.、宮崎、A.、Svanbro、K.、Wiebke、T.、Yoshimura、T.、およびH.ツェン、「体力を要しているヘッダー圧縮(ROHC):」 枠組みと4個のプロフィール: 「RTP、超能力であって、解凍されたUDP」、RFC3095、7月2001日
6.2. Informative References
6.2. 有益な参照
[3] Pelletier, G., Jonsson, L-E., Sandlund, K., and M. West, "RObust
Header Compression (ROHC): A Profile for TCP/IP (ROHC-TCP)",
Work in Progress, July 2005.
[3] ペレティア、G.、イェンソン、L-E.、Sandlund、K.、およびM.西洋、「体力を要しているヘッダー圧縮(ROHC):」 「TCP/IP(ROHC-TCP)のためのプロフィール」、処理中の作業、2005年7月。
[4] Jonsson, L-E., "RObust Header Compression (ROHC): Requirements
on TCP/IP Header Compression", RFC 4163, August 2005.
[4] イェンソン、L-E.、「体力を要しているヘッダー圧縮(ROHC):」 「TCP/IPヘッダー圧縮に関する要件」、RFC4163、2005年8月。
[5] West, M. and S. McCann, "TCP/IP Field Behavior", Work in
Progress, October 2004.
[5] 「TCP/IP分野の振舞い」という西洋、M.、およびS.マッキャンは進歩、2004年10月に働いています。
[6] Finking, R. and G. Pelletier, "Formal Notation for Robust Header
Compression (ROHC-FN)", Work in Progress, June 2005.
[6] 「体力を要しているヘッダー圧縮(ROHC-FN)のための正式な記法」というFinking、R.、およびG.ペレティアは進歩、2005年6月に働いています。
Pelletier Standards Track [Page 16] RFC 4164 Context Replication for ROHC Profiles August 2005
ROHCのためのペレティア標準化過程[16ページ]RFC4164文脈模写は2005年8月の輪郭を描きます。
Appendix A: General Format of the IR-CR Packet (Informative)
付録A: IR-CRパケットの一般形式(有益)です。
A.1. General Structure (Informative)
A.1。 一般構造体(有益)です。
This section provides an example of the format of the profile- specific information within the general format of the IR-CR.
このセクションはIR-CRの一般形式の中でプロフィール特殊情報の形式に関する例を提供します。
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| |
/ replication base information / variable length
| |
+---+---+---+---+---+---+---+---+
| |
/ replication information / variable length
| |
- - - - - - - - - - - - - - - -
0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | | /模写ベース情報/可変な長さ| | +---+---+---+---+---+---+---+---+ | | /模写情報/可変長| | - - - - - - - - - - - - - - - -
Replication base information: The contents of this part of the IR-CR
packet are defined by the individual profiles. This information
is interpreted according to the profile indicated in the Profile
field. It MUST include a 7-bit CRC over the original uncompressed
header using the polynomial of Section 3.4.1.1. See Appendix A.2.
模写ベース情報: IR-CRパケットのこの部分の内容は個々のプロフィールによって定義されます。 Profile分野で示されたプロフィールによると、この情報は解釈されます。 .1にセクション3.4.1の多項式を使用して、それはオリジナルの解凍されたヘッダーの上に7ビットのCRCを含まなければなりません。 付録A.2を見てください。
Replication information: The contents of this part of the IR-CR
packet are also defined by the individual profiles. This part
contains the static and dynamic subheader information used for
replication. How this information is structured is profile
specific; profiles may define the contents of this field using a
chain structure (static and dynamic replication chains) or by
defining header formats for replication (e.g., ROHC-TCP [3]).
模写情報: また、IR-CRパケットのこの部分の内容は個々のプロフィールによって定義されます。 この部分は模写に使用される静的でダイナミックな「副-ヘッダー」情報を含んでいます。 この情報がどう構造化されるかは、プロフィール特有です。 プロフィールは、(静的でダイナミックな模写チェーン)か模写のためにヘッダー形式を定義することによって鎖状構造を使用することでこの分野のコンテンツを定義するかもしれません。(例えば、ROHC-TCP[3])。
A.2. Profile-Specific Replication Information (Informative)
A.2。 プロフィール特有の模写情報(有益)です。
This section provides a more detailed example of the possible format of the replication information field described in Appendix A.1:
このセクションはAppendix A.1で説明された模写情報フィールドの可能な形式の、より詳細な例を提供します:
+---+---+---+---+---+---+---+---+ | B | CRC7 | 1 octet +---+---+---+---+---+---+---+---+ | | present if B = 1, / Base CID / 1 octet if for small CIDs, or | | 1-2 octets if for large CIDs +---+---+---+---+---+---+---+---+
+---+---+---+---+---+---+---+---+ | B| CRC7| 1 八重奏+---+---+---+---+---+---+---+---+ | | またはプレゼントがBであるなら1と等しく、小さいCIDsのために/がCID/1八重奏を基づかせる。| | 1-2 八重奏、多大CIDs+のために---+---+---+---+---+---+---+---+
Pelletier Standards Track [Page 17] RFC 4164 Context Replication for ROHC Profiles August 2005
ROHCのためのペレティア標準化過程[17ページ]RFC4164文脈模写は2005年8月の輪郭を描きます。
B: B = 1 indicates that the Base CID field is present.
B: B=1は、基地のCID分野が存在しているのを示します。
CRC7: The CRC over the original, uncompressed, header. This 7-bit
CRC is computed according to Section 3.4.1.1.
CRC7: オリジナルの、そして、解凍されたヘッダーの上のCRC。 セクション3.4.1に従って、この7ビットのCRCは.1に計算されます。
Base CID: The CID identifying the base context used for replication.
Cidを基礎づけてください: 模写に使用されるベース文脈を特定するCID。
Appendix B: Inter-Profile Context Replication (Informative)
付録B: 相互プロフィール文脈模写(有益)です。
Context replication as defined in this document does not explicitly support the concept of context replication between profiles. However, it might be of interest when developing new compression profiles.
本書では定義される文脈模写は明らかにプロフィールの間の文脈模写の概念を支持しません。 しかしながら、新しい圧縮プロフィールを開発するとき、それは興味があるかもしれません。
Inter-profile context replication would require that the decompressor have access to data structures from the base context, which belongs to a profile different than the profile using replication. This information would have to be made available in a format consistent with the data structures and encoding method(s) in use for all header fields that are being replicated.
相互プロフィール文脈模写は、減圧装置がベース文脈からデータ構造に近づく手段を持っているのを必要とするでしょう。(文脈は模写を使用するプロフィールと異なったプロフィールに属します)。 この情報は、データ構造と一致した形式で利用可能に作られていて、模写されているすべてのヘッダーフィールドのために使用中の方法をコード化しなければならないでしょう。
B.1. Defining Support for Inter-Profile Context Replication
B.1。 相互プロフィール文脈模写のサポートを定義します。
A ROHC profile describes how to compress a specific protocol stack, and includes one or more sets of packet formats. The packet formats will typically compress the protocol headers relative to a context of field values from previous headers in a flow. This context may also contain some control data. Thus, the packet formats specify a mapping between the uncompressed and compressed version of a protocol field.
ROHCプロフィールは、特定のプロトコル・スタックを圧縮する方法を説明して、1セット以上のパケット・フォーマットを含んでいます。 分野値の文脈に比例してパケット・フォーマットは流れで前のヘッダーでプロトコルヘッダーを通常圧縮するでしょう。 また、この文脈はいくらかの制御データを含むかもしれません。 したがって、パケット・フォーマットはプロトコル分野の解凍されて圧縮されたバージョンの間のマッピングを指定します。
This mapping is achieved through the use of one or more encoding methods, which are simply functions applied to compress or decompress a field. An encoding method is in turn defined using a name, a set of function parameters, and a formal expression (i.e., using the ROHC-FN [6]) or a textual description (i.e., a la RFC 3095 [2]) of its behaviour.
このマッピングが1つの使用で実現されたか、または方法をさらにコード化して、どれが単に機能であるかは、分野を圧縮するか、または減圧するのに申し込みました。 コード化方法は名前を使用することで順番に定義されます、関数パラメータ、および正式な表現の1セット、(すなわち、ROHC-FN[6])か原文の記述を使用する、(すなわち、ふるまいのRFC3095[2])のように。
To compress one or more fields of a specific protocol stack, different profiles may define their packet formats using different encoding methods, or using a variant of a similar technique. A typical example of the latter is list compression, such as used for IP extension headers. This implies that context entries for a field belonging to a specific protocol stack may differ in their content, representation, and structure from one profile to another.
特定のプロトコル・スタックの1つ以上の分野を圧縮するために、異なったプロフィールは異なったコード化方法を使用するか、または同様のテクニックの異形を使用することでそれらのパケット・フォーマットを定義するかもしれません。 後者の典型的な例はIP拡張ヘッダーに使用されるようにリスト圧縮です。 これは、特定のプロトコル・スタックに属す分野のための文脈エントリーがそれらの内容、表現、および別の1個のプロフィールからプロフィールまでの構造で異なるかもしれないのを含意します。
Pelletier Standards Track [Page 18] RFC 4164 Context Replication for ROHC Profiles August 2005
ROHCのためのペレティア標準化過程[18ページ]RFC4164文脈模写は2005年8月の輪郭を描きます。
As a consequence of the above, a profile that supports context replication can only use a base context from another profile explicitly supporting the concept of a base context. That is, existing profiles not supporting this concept must be updated first to ensure that they can export the necessary context data entries that use a meaningful representation during replication.
上記の結果として、文脈模写を支持するプロフィールは明らかにベース文脈の概念を支持する別のプロフィールからのベース文脈を使用できるだけです。 最初に、模写の間に重要な表現を使用する必要な文脈データエントリーは輸出できるのを保証するためにすなわち、この概念を支持しない既存のプロフィールをアップデートしなければなりません。
Specifically, inter-profile context replication would require that decompressor implementations (including existing ones) of other profiles be updated when adding support for a profile that uses context replication. Therefore, inter-profile context replication cannot be seen as an implementation-specific issue.
明確に、相互プロフィール文脈模写は、文脈模写を使用するプロフィールのサポートを加えるとき、他のプロフィールの減圧装置実現(既存のものを含んでいる)をアップデートするのを必要とするでしょう。 したがって、相互プロフィール文脈模写を実現特有の問題と考えることができません。
The compressor must know if the decompressor supports inter-profile context replication before initiating the procedure. The compressor must also know which contexts (belonging to which profile) may be used as a base context. Therefore, a compressor cannot initiate context replication using a base context belonging to a different profile, unless that profile explicitly provides the proper mapping for its context entries or that profile is defined formally using ROHC-FN [6] in a manner that makes both profiles compatible. The set of profiles negotiated for the channel (see also RFC 3095 [2]) can then be used to determine if a context for a specific profile can be used as a base context.
コンプレッサーは、手順に着手する前に減圧装置が相互プロフィール文脈模写を支持するかどうかを知らなければなりません。 また、コンプレッサーは、どの文脈(どのプロフィールに属す)がベース文脈として使用されるかもしれないかを知らなければなりません。 したがって、コンプレッサーは異なったプロフィールに属すベース文脈を使用することで文脈模写を開始できません、そのプロフィールが明らかに文脈エントリーのための適切なマッピングを提供するか、またはそのプロフィールが両方をプロフィール互換性があるようにする方法で正式にROHC-FN[6]を使用することで定義されない場合。 プロフィールのセットはチャンネルを交渉しました。(また、次に、ベース文脈として特定のプロフィールのための文脈を使用できるかどうか決定するのにRFC3095[2])を使用できるのを確実にしてください。
B.2. Compatibility between Different Profiles (Informative)
B.2。 異なったプロフィールの間の互換性(有益)です。
Compatibility between profiles, when replicating a field for a particular protocol stack, can be expressed as follow: a field that is compressed by different profiles is compatible for inter-profile replication if it is defined in the set of packet formats using the same mapping function between its uncompressed and compressed version.
特定のプロトコル・スタックのために分野を模写するとき、続くとき、プロフィールの間の互換性を言い表すことができます: それがパケット・フォーマットのセットで解凍されて圧縮されたバージョンの間の同じマッピング機能を使用することで定義されるなら、相互プロフィール模写において、異なったプロフィールによって圧縮される分野は互換性があります。
For example, the IP Destination Address field which, based on the packet formats and compression strategies defined in RFC 3095 [2], is implicitly compressed using an encoding method equivalent to the static() method defined in ROHC-FN [6].
例えばRFC3095[2]で定義されたパケット・フォーマットと圧縮戦略に基づいてROHC-FN[6]で定義された静的な()方法に同等なコード化方法を使用することでそれとなく圧縮されるIP Destination Address分野。
In particular, for profiles that define their packet formats using a formal notation such as ROHC-FN [6], two different encoding methods may not have the same name. Thus, a field from a protocol stack is said to be compatible for replication between two different profiles if it has an equivalent definition within respective packet formats.
2つの異なったコード化方法には、ROHC-FN[6]などの正式な記法を使用することでそれらのパケット・フォーマットを定義するプロフィールに関して特に、同じ名前がないかもしれません。 したがって、それぞれのパケット・フォーマットの中に同等な定義を持っているなら、プロトコル・スタックからの分野は2個の異なったプロフィールの間の模写において互換性があると言われます。
Pelletier Standards Track [Page 19] RFC 4164 Context Replication for ROHC Profiles August 2005
ROHCのためのペレティア標準化過程[19ページ]RFC4164文脈模写は2005年8月の輪郭を描きます。
Author's Address
作者のアドレス
Ghyslain Pelletier Box 920 Ericsson AB SE-971 28 Lulea, Sweden
GhyslainペレティアBox920エリクソンAB SE-971 28ルーレオ(スウェーデン)
Phone: +46 8 404 29 43 Fax: +46 920 996 21 EMail: ghyslain.pelletier@ericsson.com
以下に電話をしてください。 +46 8 404、29 43、Fax: +46 920 996 21メール: ghyslain.pelletier@ericsson.com
Pelletier Standards Track [Page 20] RFC 4164 Context Replication for ROHC Profiles August 2005
ROHCのためのペレティア標準化過程[20ページ]RFC4164文脈模写は2005年8月の輪郭を描きます。
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機能のための基金は現在、インターネット協会によって提供されます。
Pelletier Standards Track [Page 21]
ペレティア標準化過程[21ページ]
一覧
スポンサーリンク
