Network Working Group J. Ash, Ed.
Request for Comments: 4901 J. Hand, Ed.
Category: Standards Track AT&T
A. Malis, Ed.
Verizon Communications
June 2007
Protocol Extensions for Header Compression over MPLS
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.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
Abstract
抽象
This specification defines how to use Multi-Protocol Label Switching (MPLS) to route Header-Compressed (HC) packets over an MPLS label switched path. HC can significantly reduce packet-header overhead and, in combination with MPLS, can also increases bandwidth efficiency and processing scalability in terms of the maximum number of simultaneous compressed flows that use HC at each router). Here we define how MPLS pseudowires are used to transport the HC context and control messages between the ingress and egress MPLS label switching routers. This is defined for a specific set of existing HC mechanisms that might be used, for example, to support voice over IP. This specification also describes extension mechanisms to allow support for future, as yet to be defined, HC protocols. In this specification, each HC protocol operates independently over a single pseudowire instance, very much as it would over a single point-to-point link.
この仕様は、パスを切り替えMPLSラベルの上にルートヘッダ圧縮（HC）パケットにマルチプロトコルラベルスイッチング（MPLS）を使用する方法を定義します。 HCが大幅にパケットヘッダのオーバーヘッドを減らすことができると、MPLSと組み合わせて、また各ルータでHCを使用する同時圧縮フロー）の最大数で帯域幅効率と処理のスケーラビリティを増加させることができます。ここでは、MPLS疑似回線はスイッチングルータ入力および出力MPLSラベル間のHCコンテキストおよび制御メッセージを転送するために使用されている方法を定義します。これは、IP上で音声をサポートするために、例えば、使用されるかもしれない既存のHCメカニズムの特定のセットのために定義されています。また、この仕様は、まだ定義されるように、将来のためのサポートを可能にするHCプロトコルの拡張メカニズムを記述する。本明細書では、各HCプロトコルは、それが単一のポイントツーポイントリンク上になるように非常に多くの、独立して、単疑似回線のインスタンスで動作します。
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................3
3. Header Compression over MPLS Protocol Overview ..................6
4. Protocol Specifications ........................................11
4.1. MPLS Pseudowire Setup and Signaling .......................13
4.2. Header Compression Scheme Setup, Negotiation, and
Signaling .................................................14
4.2.1. Configuration Option Format [RFC3544] ..............15
4.2.2. RTP-Compression Suboption [RFC3544] ................17
4.2.3. Enhanced RTP-Compression Suboption [RFC3544] .......18
4.2.4. Negotiating Header Compression for Only TCP
or Only Non-TCP Packets [RFC3544] ..................19
4.2.5. Configuration Option Format [RFC3241] ..............20
4.2.6. PROFILES Suboption [RFC3241] .......................21
4.3. Encapsulation of Header Compressed Packets ................22
4.4. Packet Reordering .........................................23
5. HC Pseudowire Setup Example ....................................24
6. Security Considerations ........................................29
7. Acknowledgements ...............................................29
8. IANA Considerations ............................................29
9. Normative References ...........................................30
10. Informative References ........................................31
11. Contributors ..................................................33
Voice over IP (VoIP) typically uses the encapsulation voice/RTP/UDP/IP. When MPLS labels [RFC3031] are added, this becomes voice/RTP/UDP/IP/MPLS-labels. MPLS VPNs (e.g., [RFC4364]) use label stacking, and in the simplest case of IPv4 the total packet header is at least 48 bytes, while the voice payload is often no more than 30 bytes, for example. When IPv6 is used, the relative size of the header in comparison to the payload is even greater. The interest in header compression (HC) is to exploit the possibility of significantly reducing the overhead through various compression mechanisms, such as with enhanced compressed RTP (ECRTP) [RFC3545] and robust header compression (ROHC) [RFC3095, RFC3095bis, RFC4815], and also to increase scalability of HC. MPLS is used to route HC packets over an MPLS label switched path (LSP) without compression/decompression cycles at each router. Such an HC over MPLS capability can increase bandwidth efficiency as well as the processing scalability of the maximum number of simultaneous compressed flows that use HC at each router. Goals and requirements for HC over MPLS are discussed in [RFC4247]. The solution using MPLS pseudowire (PW) technology put forth in this document has been designed to address these goals and requirements.
ボイスオーバーIP（VoIP）は、通常のカプセル化音声/ RTP / UDP / IPを使用しています。 MPLSラベル[RFC3031]が追加されると、これは、音声/ RTP / UDP / IP / MPLS-ラベルになります。 MPLS VPNは（例えば、[RFC4364]）ラベルスタックを使用し、音声ペイロードは、例えば、多くの場合、これ以上30バイト以内である間はIPv4の最も簡単な場合には、総パケットヘッダは、少なくとも48バイトです。 IPv6が使用される場合、ペイロードと比較して、ヘッダの相対的な大きさがさらに大きくなります。ヘッダ圧縮（HC）への関心が大きく、圧縮増強RTP（ECRTP）[RFC3545]とロバストヘッダ圧縮（ROHC）[RFC3095、RFC3095bis、RFC4815]と同様に、様々な圧縮機構を介してオーバーヘッドを低減する可能性を利用することで、また、HCのスケーラビリティを向上させます。 MPLSは、MPLSラベル上に経路HCパケットに使用される各ルータでの圧縮/解凍サイクルなしパス（LSP）を切り替えます。 MPLS能力を超えるようなHCは、帯域幅効率ならびに各ルータでHCを使用する同時圧縮フローの最大数の処理のスケーラビリティを高めることができます。 MPLS上目標とHCのための要件は、[RFC4247]に記載されています。この文書で出すMPLS疑似回線（PW）技術を使用したソリューションは、これらの目標や要件に対応するように設計されています。
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", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。
Context: the state associated with a flow subject to IP header compression. While the exact nature of the context is specific to a particular HC protocol (CRTP, ECRTP, ROHC, etc.), this state typically includes:
コンテキスト：IPヘッダ圧縮への流れ対象に関連付けられている状態。コンテキストの正確な性質は、（CRTP、ECRTP、ROHC等）特定のHCプロトコルに特異的であるが、この状態は、典型的には含みます。
- the values of all of the fields in all of the headers (IP, UDP, TCP, RTP, Encapsulating Security Payload (ESP), etc.) that the particular header compression protocol operates on for the last packet of the flow sent (by the compressor) or received (by the decompressor).
- 特定のヘッダ圧縮プロトコル（によって送信されたフローの最後のパケットのために動作することのヘッダ（IP、UDP、TCP、RTP、カプセル化セキュリティペイロード（ESP）、等）のすべてのフィールドのすべての値圧縮）またはデコンプレッサによって（受信）。
- the change in the value of some of the fields in the IP, UDP, TCP, etc. headers between the last two consecutive sent packets (compressor) or received packets (decompressor) of the flow. Some of the fields in the header change by a constant amount between subsequent packets in the flow most of the time. Saving the changes in these fields from packet to packet allows verification that a constant rate of change is taking place, and to take appropriate action when a deviation from the normal changes are encountered.
- IP、UDP、TCPのフィールドなどのいくつかの値の変化の最後の二つの連続送信パケット（圧縮機）またはフローの受信パケット（減圧装置）との間のヘッダ。ほとんどの時間フローの後続パケット間の一定量だけヘッダ変更のフィールドの一部。パケットからパケットにこれらのフィールドの変更を保存すると、一定の変化率が行われていることを確認することができ、通常の変化からの偏差が発生した際に適切な処置を取ること。
For most HC protocols, a copy of the context of each compressed flow is maintained at both the compressor and the decompressor.
最もHCプロトコルのために、各圧縮フローのコンテキストのコピーは圧縮と減圧の両方で維持されます。
compressed Real-time Transport Protocol (CRTP): a particular HC protocol described in [RFC2508].
圧縮されたリアルタイムトランスポートプロトコル（CRTP）：[RFC2508]に記載された特定のHCプロトコル。
Context ID (CID): a small number, typically 8 or 16 bits, used to identify a particular flow, and the context associated with the flow. Most HC protocols in essence work by sending the CID across the link in place of the full header, along with any unexpected changes in the values in the various fields of the headers.
コンテキストID（CID）：少数の、特定のフローを識別するために使用される典型的には8ビットまたは16ビット、およびフローに関連するコンテキスト。エッセンス仕事のほとんどのHCプロトコルヘッダの様々なフィールドの値のいずれかの予期しない変更に伴い、完全なヘッダの代わりにリンクを介してCIDを送信することもできます。
Enhanced Compressed Real-time Protocol (ECRTP): a particular HC protocol described in [RFC3545].
[RFC3545]に記載された特定のHCプロトコル：圧縮されたリアルタイムプロトコル（ECRTP）を増強しました。
Forwarding Equivalence Class (FEC): a group of packets that are forwarded in the same manner (e.g., over the same LSP, with the same forwarding treatment)
転送等価クラス（FEC）：（同一の転送処理と、同じLSP上に、例えば）同じ方法で転送されたパケットのグループ
Header Compression scheme (HC scheme): a particular method of performing HC and its associated protocol. Multiple methods of HC have been defined, including Robust Header Compression (ROHC [RFC3095, RFC3095bis]), compressed RTP (CRTP, [RFC2508]), enhanced CRTP (ECRTP, [RFC3545]), and IP Header Compression (IPHC, [RFC2507]). This document explicitly supports all of the HC schemes listed above, and is intended to be extensible to others that may be developed.
ヘッダ圧縮方式（HC方式）：HCおよびその関連プロトコルを実行する特定の方法。 HCの複数の方法は、ロバストヘッダ圧縮（ROHC [RFC3095、RFC3095bis]）、圧縮RTP（CRTP、[RFC2508]）、強化CRTP（ECRTP、[RFC3545]）、およびIPヘッダー圧縮（IPHC、[RFC2507を含む、定義されています]）。この文書は、明示的に上記のHCスキームのすべてをサポートし、開発することができる他の人に拡張可能であることを意図しています。
Header Compression channel (HC channel): a session established between a header compressor and a header decompressor using a single HC scheme, over which multiple individual flows may be compressed. From this perspective, every PPP link over which HC is operating defines a single HC channel, and based on this specification, every HC PW defines a single HC channel. HC PWs are bi-directional, which means that a unidirectional leg of the PW is set up in each direction. One leg of the bi-directional PW may be set up to carry only compression feedback, not header compressed traffic. An HC channel should not be confused with the individual traffic flows that may be compressed using a single Context ID. Each HC channel manages a set of unique CIDs.
ヘッダ圧縮チャネル（HCチャンネル）：ヘッダ圧縮機と複数の個々の流れを圧縮することができる上、単一のHCスキームを使用して解凍器ヘッダとの間に確立されたセッション。この観点から、HCが動作する上すべてのPPPリンクは、単一のHCチャンネルを定義し、この仕様に基づいて、すべてのHC PWは、単一のHCのチャネルを画定します。 HCのPWSが双方向、PWの一方向脚を各方向に設定されていることを意味しています。双方向PWの一方の脚部のみ、圧縮フィードバックを運ぶない圧縮トラフィックのヘッダに設定することができます。 HCチャネルは、単一のコンテキストIDを使用して圧縮することができる個々のトラフィックフローと混同してはなりません。各HCチャネルは、ユニークなCIDのセットを管理します。
IP Header Compression (IPHC): a particular HC protocol described in [RFC2507]
IPヘッダー圧縮（IPHC）：[RFC2507]に記載された特定のHCプロトコル
Label: a short fixed length physically contiguous identifier that is used to identify a FEC, usually of local significance
ラベル：FECを識別するために使用される短い固定長の物理的に連続した識別子、通常ローカル有意の
Label Stack: an ordered set of labels
ラベルスタック：ラベルの順序集合
Label Switched Path (LSP): the path through one or more LSRs at one level of the hierarchy followed by a packet in a particular forwarding equivalence class (FEC)
ラベルスイッチパス（LSP）：特定の転送等価クラス内のパケットに続く階層の1つのレベルに1つまたは複数のLSRを通る経路（FEC）
Label Switching Router (LSR): an MPLS node that is capable of forwarding native L3 packets
転送ネイティブL3パケットの可能なMPLSノード：ラベルスイッチングルータ（LSR）
MPLS domain: a contiguous set of nodes that operate MPLS routing and forwarding and which are also in one Routing or Administrative Domain
MPLSドメイン：つのルーティングまたは管理ドメイン内でもあるMPLSルーティングおよび転送とを動作させるノードの連続する組
MPLS label: a label that is carried in a packet header, and that represents the packet's FEC
MPLSラベル：パケット・ヘッダで運ばれるラベル、及びそのパケットのFECを表します。
MPLS node: a node that is running MPLS. An MPLS node will be aware of MPLS control protocols, will operate one or more L3 routing protocols, and will be capable of forwarding packets based on labels. An MPLS node may also optionally be capable of forwarding native L3 packets.
MPLSノード：MPLSを実行しているノード。 MPLSノードは、一つ以上のL3ルーティングプロトコルを動作する、MPLS制御プロトコルを知っているであろう、そしてラベルに基づいてパケットを転送することができるであろう。 MPLSノードはまた、必要に応じてネイティブL3パケットを転送することが可能です。
Multiprotocol Label Switching (MPLS): an IETF working group and the effort associated with the working group, including the technology (signaling, encapsulation, etc.) itself
マルチプロトコルラベルスイッチング（MPLS）：IETFワーキンググループと技術を含むワーキング・グループに関連付けられている努力、（シグナリング、カプセル化、など）自体
Packet Switched Network (PSN): Within the context of Pseudowire PWE3, this is a network using IP or MPLS as the mechanism for packet forwarding.
パケットネットワーク（PSN）を交換：疑似PWE3の文脈において、このことは、パケット転送のためのメカニズムとして、IPまたはMPLSを用いたネットワークです。
Protocol Data Unit (PDU): the unit of data output to, or received from, the network by a protocol layer.
プロトコルデータユニット（PDU）へのデータ出力の単位、またはから受信した、プロトコルレイヤによってネットワーク。
Pseudowire (PW): a mechanism that carries the essential elements of an emulated service from one provider edge router to one or more other provider edge routers over a PSN
疑似回線（PW）：PSN上の1つのまたは複数の他のプロバイダエッジルータに1つのプロバイダエッジルータからエミュレートされたサービスの本質的な要素を搬送機構
Pseudowire Emulation Edge to Edge (PWE3): a mechanism that emulates the essential attributes of service (such as a T1 leased line or Frame Relay) over a PSN
（PWE3）をEdgeにスードワイヤ・エミュレーション・エッジ：PSN以上（例えばT1専用線やフレームリレーなど）サービスの基本的な属性をエミュレートするメカニズム
Pseudowire PDU (PW-PDU): a PDU sent on the PW that contains all of the data and control information necessary to emulate the desired service
疑似回線PDU（PW-PDU）：すべてのデータが含まれており、所望のサービスをエミュレートするために必要な制御情報をPWに送られるPDU
PSN Tunnel: a tunnel across a PSN, inside which one or more PWs can be carried
PSNトンネル：PSNを横切るトンネル、一の以上のPWを実施することができる内部
PSN Tunnel Signaling: a protocol used to set up, maintain, and tear down the underlying PSN tunnel
PSNトンネルシグナリング：、設定、維持、及び下層のPSNトンネルを切断するために使用されるプロトコル
PW Demultiplexer: data-plane method of identifying a PW terminating at a provider edge router
PWデマルチプレクサ：プロバイダエッジルータでPW終端を特定のデータプレーン方法
Real Time Transport Protocol (RTP): a protocol for end-to-end network transport for applications transmitting real-time data, such as audio or video [RFC3550].
リアルタイムトランスポートプロトコル（RTP）、オーディオやビデオなどのリアルタイムデータを送信するアプリケーションのためのエンドツーエンドのネットワーク・トランスポートのためのプロトコル[RFC3550]。
Robust Header Compression (ROHC): a particular HC protocol consisting of a framework [RFC3095bis] and a number of profiles for different protocols, e.g., for RTP, UDP, ESP [RFC3095], and IP [RFC3843]
ロバストヘッダ圧縮（ROHC）：RTP、UDP、ESP [RFC3095]、およびIP [RFC3843]のためのフレームワーク[RFC3095bis]と異なるプロトコルのプロファイルの数、例えば、からなる特定のHCプロトコル
Tunnel: a method of transparently carrying information over a network
トンネル：透過的にネットワークを介して情報を伝送する方法
To implement HC over MPLS, after the ingress router applies the HC algorithm to the IP packet, the compressed packet is forwarded on an MPLS LSP using MPLS labels, and then the egress router restores the uncompressed header. Any of a number of HC algorithms/protocols can be used. These algorithms have generally been designed for operation over a single point-to-point link-layer hop. MPLS PWs [RFC3985], which are used to provide emulation of many point-to-point link layer services (such as frame relay permanent virtual circuits (PVCs) and ATM PVCs) are used here to provide emulation of a single, point-to-point link layer hop over which HC traffic may be transported.
入口ルータは、IPパケットにHCアルゴリズムを適用した後に、MPLS上にHCを実現するために、圧縮されたパケットは、MPLSラベルを使用して、MPLS LSPに転送され、その後、出口ルータは、非圧縮ヘッダを復元します。 HCアルゴリズム/プロトコルのうちのいずれかを使用することができます。これらのアルゴリズムは一般的に、単一のポイントツーポイントリンク層ホップ上で動作するように設計されています。多くの（例えば、フレームリレー相手先固定接続（PVC）等のATM PVCの）ポイント・ツー・ポイント・リンク層サービスのエミュレーションを提供するために使用されるMPLSのPW [RFC3985]は、単一の点へのエミュレーションを提供するためにここで使用されていますHCトラフィックが輸送することができる、その上-pointリンク層ホップ。
Figure 1 illustrates an HC over MPLS channel established on an LSP that traverses several LSRs, from R1/HC --> R2 --> R3 --> R4/HD, where R1/HC is the ingress router performing HC, and R4/HD is the egress router performing header decompression (HD). This example assumes that the packet flow being compressed has RTP/UDP/IP headers and is using a HC scheme such as ROHC, CRTP, or ECRTP. Compression of the RTP/UDP/IP header is performed at R1/HC, and the compressed packets are routed using MPLS labels from R1/HC to R2, to R3, and finally to R4/HD, without further decompression/recompression cycles. The RTP/UDP/IP header is decompressed at R4/HD and can be forwarded to other routers, as needed. This example assumes that the application is VoIP and that the HC algorithm operates on the RTP, UDP, and IP headers of the VoIP flows. This is an extremely common application of HC, but need not be the only one. The HC algorithms supported by the protocol extensions specified in this document may operate on TCP or IPsec ESP headers as well.
> R2 - - > R3 - 図1は、R1 / HCから、いくつかのLSRを横断するLSP上に確立されたMPLSチャネル上でHCを示し> R4 / HD、R1 / HCがHCを行う入口ルータであり、及びR4 / HDは、出口ルータ行うヘッダ復元（HD）です。この例では、圧縮されたパケット・フローは、RTP / UDP / IPヘッダを有しており、ROHC、CRTP、又はECRTPとしてHC方式を使用していることを前提としています。さらに減圧/再圧縮サイクルなしで、RTP / UDP / IPヘッダの圧縮は、R1 / HCで行われ、そして圧縮されたパケットはR3に、R2とR1 / HCからMPLSラベルを使用してルーティングされ、最後にR4 / HDへ。 RTP / UDP / IPヘッダは、R4 / HDで減圧され、必要に応じて、他のルータに転送することができます。この例では、アプリケーションがVoIPであることを前提とし、HCアルゴリズムは、VoIPのRTP、UDP、およびIPヘッダ上で動作することを流れます。これは、HCの非常に一般的なアプリケーションですが、一つだけである必要はありません。この文書で指定されたプロトコルの拡張機能でサポートされているHCアルゴリズムは、同様にTCPやIPsec ESPヘッダ上で動作することができます。
|
| data (e.g., voice)/RTP/UDP/IP/link layer
V
_____
| |
|R1/HC| Header Compression (HC) Performed
|_____|
|
| data (e.g., voice)/compressed-header/MPLS-labels
V
_____
| |
| R2 | Label Switching
|_____| (no compression/decompression)
|
| data (e.g., voice)/compressed-header/MPLS-labels
V
_____
| |
| R3 | Label Switching
|_____| (no compression/decompression)
|
| data (e.g., voice)/compressed-header/MPLS-labels
V
_____
| |
|R4/HD| Header Decompression (HD) Performed
|_____|
|
| data (e.g., voice)/RTP/UDP/IP/link layer
V
Figure 1: Example of HC over MPLS over Routers R1 --> R4
図1：ルータR1上MPLS上HCの例 - > R4
In the example scenario, HC therefore takes place between R1 and R4, and the MPLS LSP transports data/compressed-header/MPLS-labels instead of data/RTP/UDP/IP/MPLS-labels, often saving more than 90% of the RTP/UDP/IP overhead. Typically there are two MPLS labels (8 octets) and a link-layer HC control parameter (2 octets). The MPLS label stack and link-layer headers are not compressed. Therefore, HC over MPLS can significantly reduce the header overhead through compression mechanisms.
例示的なシナリオでは、HCしたがってR1とR4との間で行われ、MPLS LSPは、多くの場合、90％以上を保存する代わりに、データ/ RTP / UDP / IP / MPLS-ラベルデータ/圧縮されたヘッダ/ MPLS-ラベルを輸送しますRTP / UDP / IPのオーバーヘッド。典型的には二つMPLSラベル（8つのオクテット）とリンク層HC制御パラメータ（2オクテット）があります。 MPLSラベルスタックとリンク層のヘッダは圧縮されません。したがって、MPLS上HCを大幅に圧縮機構を介してヘッダのオーバーヘッドを低減することができます。
HC reduces the IP/UDP/RTP headers to 2-4 bytes for most packets. Half of the reduction in header size comes from the observation that half of the bytes in the IP/UDP/RTP headers remain constant over the life of the flow. After sending the uncompressed header template once, these fields may be removed from the compressed headers that follow. The remaining compression comes from the observation that although several fields change in every packet, the difference from packet to packet is often constant or at least limited, and therefore the second-order difference is zero.
HCは、ほとんどのパケット2-4バイトにIP / UDP / RTPヘッダを低減します。ヘッダサイズの減少の半分は、IP / UDP / RTPヘッダ内のバイトの半分が流れの人生にわたって一定のまま観察から来ています。一度圧縮されていないヘッダテンプレートを送信した後、これらのフィールドは、以下の圧縮されたヘッダから除去されてもよいです。残りの圧縮は、いくつかのフィールドがすべてのパケットに変化するが、パケットにパケットの差がしばしば一定又は少なくとも制限され、したがって第二階差分がゼロであるという観察から来ています。
The compressor and decompressor both maintain a context for each compressed flow. The context is the session state shared between the compressor and decompressor. The details of what is included in the context may vary between HC schemes. The context at the compressor would typically include the uncompressed headers of the last packet sent on the flow, and some measure of the differences in selected header field values between the last packet transmitted and the packet(s) transmitted just before it. The context at the decompressor would include similar information about received packets. With this information, all that must be communicated across the wire is an indication of which flow a packet is associated with (the CID), and some compact encoding of the second order differences (i.e., the harder to predict differences) between packets.
コンプレッサーと減圧の両方各圧縮フローのためのコンテキストを維持します。コンテキストは、圧縮器と解凍器との間で共有セッションの状態です。コンテキストに含まれているものの詳細はHCスキームの間で変化してもよいです。コンプレッサーでコンテキストは、典型的には、フロー上で送信された最後のパケットの非圧縮ヘッダー、送信された最後のパケットと直前に送信されたパケット（S）との間の選択されたヘッダフィールド値の差のいくつかの尺度を含むことになります。解凍器におけるコンテクストは、受信されたパケットに関する同様の情報を含むであろう。この情報を用いて、ワイヤを介して通信しなければならないすべてのパケットが（CID）に関連付けられて流れるの指示、およびパケット間の二次差分（すなわち、硬い差を予測するために）いくつかのコンパクトな符号化です。
MPLS PWs [RFC3985] are used to transport the HC packets between the ingress and egress MPLS LSRs. Each PW acts like a logical point-to-point link between the compressor and the decompressor. Each PW supports a single HC channel, which, from the perspective of the HC scheme operation, is similar to a single PPP link or a single frame relay PVC. One exception to this general model is that PWs carry only packets with compressed headers, and do not share the PW with uncompressed packets.
MPLSのPW [RFC3985]は、入口と出口MPLS LSRの間のHCパケットを転送するために使用されます。各PWは、コンプレッサとデコンプレッサとの間の論理的なポイントツーポイントリンクのように作用します。各PWはHC方式操作の観点から、単一のPPPリンク又は単一のフレームリレーPVCと類似して、単一のHCチャネルをサポートします。この一般的なモデルの一つの例外は、PWSは、圧縮ヘッダを持つパケットのみを運び、非圧縮パケットとPWを共有していないということです。
The PW architecture specifies the use of a label stack with at least 2 levels. The label at the bottom of the stack is called the PW label. The PW label acts as an identifier for a particular PW. With HC PWs, the compressor adds the label at the bottom of the stack and the decompressor removes this label. No LSRs between the compressor and decompressor inspect or modify this label. Labels higher in the stack are called the packet switch network (PSN) labels, and are used to forward the packet through the MPLS network as described in [RFC3031]. The decompressor uses the incoming MPLS PW label (the label at the bottom of the stack), along with the CID to locate the proper decompression context. Standard HC methods (e.g., ECRTP, ROHC, etc.) are used to determine the contexts. The CIDs are assigned by the HC as normal, and there would be no problem if duplicate CIDs are received at the HD for different PWs, which support different compressed channels. For example, if two different compressors, HCa and HCb, both assign the same CID to each of 2 separate flows destined to decompressor HDc, HDc can still differentiate the flows and locate the proper decompression context for each, because the tuples <PWlabel-HCa, CID> and <PWlabel-HCb, CID> are still unique.
PWアーキテクチャは、少なくとも2つのレベルのラベルスタックの使用を指定します。スタックの底のラベルは、PWラベルと呼ばれています。 PWラベルは、特定のPWの識別子として働きます。 HCのPWを使用すると、コンプレッサーは、スタックの最下部にラベルを追加し、解凍器は、このラベルを削除します。コンプレッサーと減圧器との間にはのLSRは、このラベルを検査していないか、変更します。スタックの上位ラベルは、パケット交換ネットワーク（PSN）ラベルと呼ばれ、[RFC3031]に記載されているようにMPLSネットワークを介してパケットを転送するために使用されます。減圧装置は、適切な伸張コンテキストを検索するためにCIDとともに、着信MPLS PWラベル（スタックの下部にラベル）を使用します。標準HCの方法（例えば、ECRTP、ROHC等）コンテキストを決定するために使用されます。 CIDは、通常のようにHCによって割り当てられ、重複のCIDは、異なる圧縮チャネルをサポートする別のPW用HDで受信された場合には問題はないだろう。なぜならタプル<PWlabel-HCA例えば、2つの異なる圧縮機、HCA及びHCB場合、両方のHDCをデコンプレッサ運命2分離流のそれぞれに同じCIDを割り当て、HDCは依然として、フローを区別し、それぞれの適切な伸張コンテキストを見つけることができ、CID>と<PWlabel-HCB、CID>はまだユニークです。
In addition to the PW label and PSN label(s), HC over MPLS packets also carry a HC control parameter. The HC control parameter contains both a packet type field and a packet length field. The packet type field is needed because each HC scheme supported by this specification defines multiple packet types, for example, "full header" packets, which are used to initialize and/or re-synchronize the context between compressor and decompressor, vs. normal HC packets. And most of the HC schemes require that the underlying link layer protocols provide the differentiation between packet types. Similarly, one of the assumptions that is part of most of the HC schemes is that the packet length fields in the RTP/UDP/IP, etc. headers need not be explicitly sent across the network, because the IP datagram length can be implicitly determined from the lower layers. This specification assumes that, with one exception, the length of an HC IP datagram can be determined from the link layers of the packets transmitted across the MPLS network. The exception is for packets that traverse an Ethernet link. Ethernet requires padding for packets whose payload size is less than 46 bytes in length. So the HC control parameter contains a length field of 6 bits to encode the lengths of any HC packets less than 64 bytes in length.
PWラベルとPSNラベル（複数可）に加えて、MPLSパケット上HCはまた、HC制御パラメータを運びます。 HC制御パラメータは、パケットタイプフィールド、パケット長フィールドの両方が含まれています。パケットタイプフィールドは、本明細書によってサポートされる各HC方式は、例えば、複数のパケットタイプを定義するために必要とされる、初期化および/またはコンプレッサとデコンプレッサとの間のコンテキストを再同期するために使用される「全ヘッダ」パケット、対正常HCパケット。そして、HCスキームのほとんどは、基礎となるリンク層プロトコルは、パケットタイプとの差別化を提供する必要があります。同様に、HCスキームのほとんどの部分である仮定の一つは、IPデータグラム長が暗黙的に判断することができるので、RTP / UDP / IPのパケット長フィールドは、などのヘッダーを明示的に、ネットワークを介して送信する必要がないということです下位レイヤから。この仕様は、1つの例外を除いて、HC IPデータグラムの長さは、MPLSネットワーク上で送信されたパケットのリンク層から決定することができる、と仮定しています。例外は、イーサネットリンクを通過するパケットのためです。イーサネットペイロードサイズ未満の長さ46バイトであり、パケットのパディングが必要です。そうHC制御パラメータは、長さが64バイト未満の任意のHCパケットの長さを符号化するために、6ビットの長さフィールドを含みます。
HC PWs are set up by the PW signaling protocol [RFC4447]. [RFC4447] actually defines a set of extensions to the MPLS label distribution protocol (LDP) [RFC3036]. As defined in [RFC4447], LDP signaling to set up, tear down, and manage PWs is performed directly between the PW endpoints, in this case, the compressor and the decompressor. PW signaling is used only to set up the PW label at the bottom of the stack, and is used independently of any other signaling that may be used to set up PSN labels. So, for example, in Figure 1, LDP PW signaling would be performed directly between R1/HC and R4/HD. Router R2 and R3 would not participate in PW signaling.
HCのPWsのは、PWシグナリングプロトコル[RFC4447]によって設定されます。 [RFC4447]は、実際にMPLSラベル配布プロトコル（LDP）[RFC3036]の拡張機能のセットを定義します。 [RFC4447]で定義されるように、設定破棄、およびPWは、この場合、コンプレッサとデコンプレッサにおいて、PWエンドポイント間で直接実行される管理するシグナリングLDP。 PWシグナリングはスタックの底にPWラベルを設定するためにのみ使用され、PSNラベルを設定するために使用することができる任意の他のシグナル伝達の独立して使用されます。したがって、例えば、図1に、LDP PWシグナリングがR1 / HC及びR4 / HD間で直接実行されます。ルータR2とR3は、PWシグナリングに参加しないでしょう。
[RFC4447] provides extensions to LDP for PWs, and this document provides further extensions specific to HC. Since PWs provide a logical point-to-point connection over which HC can be run, the extensions specified in this document reuse elements of the protocols used to negotiate HC over the Point-to-Point Protocol [RFC1661]. [RFC3241] specifies how ROHC is used over PPP and [RFC3544] specifies how several other HC schemes (CRTP, ECRTP, IPHC) are used over PPP. Both of these RFCs provide configuration options for negotiating HC over PPP. The formats of these configuration options are reused here for setting up HC over PWs. When used in the PPP environment, these configuration options are used as extensions to PPP's IP Control Protocol [RFC1332] and the detailed PPP options negotiations process described in [RFC1661]. This is necessary because a PPP link may support multiple protocols, each with its own addressing scheme and options. Achieving interoperability requires a negotiation process so that the nodes at each end of the link can agree on a set of protocols and options that both support. However, a single HC PW supports only HC traffic using a single HC scheme. So while the formats of configuration options from [RFC3241] and [RFC3544] are reused here, the detailed PPP negotiation process is not. Instead, these options are reused here just as descriptors (TLVs in the specific terminology of LDP and [RFC4447]) of basic parameters of an HC PW. These parameters are further described in Section 4. The HC configuration parameters are initially generated by the decompressor and describe what the decompressor is prepared to receive.
[RFC4447]はPWsのためのLDPの拡張を提供し、この文書は、HCの特定さらに拡張機能を提供します。 PWSがHCを実行することができる上に論理ポイントツーポイント接続、ポイントツーポイントプロトコル[RFC1661]の上にHCを交渉するために使用されるプロトコルのこの文書の再利用要素で指定された拡張を提供するからです。 [RFC3241]はROHCはPPP上で使用され、[RFC3544]はいくつかの他のHCスキーム（CRTP、ECRTP、IPHC）はPPP上で使用される方法を指定する方法を指定します。これらのRFCの両方がPPP上でHCを交渉するための設定オプションを提供します。これらの設定オプションのフォーマットは、PWを介してHCを設定するために、ここで再利用されます。 PPPの環境で使用される場合、これらの設定オプションは、PPPのIP制御プロトコル[RFC1332]と[RFC1661]で説明した詳細なPPPオプションの交渉プロセスへの拡張として使用されています。 PPPリンクは、複数のプロトコル、独自のアドレス体系およびオプションで各をサポートする可能性があるため、これが必要です。リンクの両端のノードは、プロトコルとの両方のサポートオプションのセットに同意することができるように相互運用性を達成することは交渉プロセスを必要とします。しかし、単一HC PWは、単一のHCスキームを使用してのみHCトラフィックをサポートしています。 [RFC3241]と[RFC3544]から設定オプションのフォーマットは、ここで再利用されている間ので、詳細なPPPネゴシエーションプロセスではありません。代わりに、これらのオプションは、ちょうどHC PWの基本パラメータの記述子（特定のLDPの用語と[RFC4447]でのTLV）として、ここで再利用されます。これらのパラメータは、さらにHC設定パラメータが最初に解凍装置により生成され、減圧装置が受信する準備が何であるかを説明しているセクション4に記載されています。
Most HC schemes use a feedback mechanism which requires bi-directional flow of HC packets, even if the flow of compressed IP packets is in one direction only. The basic signaling process of [RFC4447] sets up unidirectional PWs, and must be repeated in each direction in order to set up the bi-directional flow needed for HC.
ほとんどのHC方式は、圧縮されたIPパケットの流れが一方向のみであっても、HCパケットの双方向の流れを必要とするフィードバック機構を使用しています。 [RFC4447]の基本的なシグナリングプロセスは、単方向のPWを設定し、HCに必要な双方向の流れを設定するために、各方向に繰り返されなければなりません。
Figure 1 illustrates an example data flow set up from R1/HC --> R2 --> R3 --> R4/HD, where R1/HC is the ingress router where header compression is performed, and R4/HD is the egress router where header decompression is done. Each router functions as an LSR and supports signaling of LSP/PWs. See Section 5 for a detailed example of how the flow depicted in Figure 1 is established.
> R2 - - > R3 - R1 / HCは、ヘッダ圧縮が行われる入口ルータであり、及びR4 / HDは、出口ルータである> R4 / HD、図1は、R1 / HCから設定データフロー例を示す図でありますヘッダ復元が行われる場合。各ルータLSRとして機能し、LSP / PWをのシグナリングをサポートしています。図1に示すフローが確立された方法の詳細な例については、セクション5を参照してください。
All the HC schemes used here are built so that if an uncompressible packet is seen, it should just be sent uncompressed. For some types of compression (e.g., IPHC-TCP), a non-compressed path is required. For IPHC-TCP compression, uncompressible packets occur for every TCP flow. Another way that this kind of issue can occur is if MAX_HEADER is configured lower than the longest header, in which case, compression might not be possible in some cases.
非圧縮パケットが見られた場合、それだけで非圧縮送られるべきであるように、ここで使用されるすべてのHCのスキームが構築されています。圧縮のいくつかのタイプ（例えば、IPHC-TCP）のために、非圧縮パスが必要です。 IPHC-TCP圧縮のために、非圧縮パケットは、すべてのTCPフローのために発生します。 MAX_HEADERは、圧縮は、いくつかのケースでは可能ではないかもしれない、その場合、最長のヘッダ、より低く設定されている場合、問題のこの種が発生することができる別の方法です。
The uncompressed packets associated with HC flows (e.g., uncompressed IPHC-TCP packets) can be sent through the same MPLS tunnel along with all other non-HC (non-PW) IP packets. MPLS tunnels can transport many types of packets simultaneously, including non-PW IP packets, layer 3 VPN packets, and PW (e.g., HC flow) packets. In the specification, we assume that there is a path for uncompressed traffic, and it is a compressor decision as to what would or would not go in the HC-PW.
HC・フロー（例えば、非圧縮IPHC-TCPパケット）に関連付けられた非圧縮パケットは、他のすべての非HC（非PW）のIPパケットと一緒に同じMPLSトンネルを介して送信することができます。 MPLSトンネルは、非PW IPパケットを、レイヤ3 VPNパケット、及びPW（例えば、HCフロー）パケットを含む、同時にパケットの多くの種類を輸送することができます。仕様では、圧縮されていないトラフィックのパスがあることを前提とし、それがまたはHC-PWには行かないだろうだろうかについてのコンプレッサーの決定です。
Figure 2 illustrates the PW stack reference model to support PW emulated services.
図2は、PWエミュレートされたサービスをサポートするためにPWスタック参照モデルを示す図です。
+-------------+ +-------------+
| Layer2 | | Layer2 |
| Emulated | | Emulated |
| Services | Emulated Service | Services |
| |<==============================>| |
+-------------+ +-------------+
| HC | Pseudowire | HD |
|Demultiplexer|<==============================>|Demultiplexer|
+-------------+ +-------------+
| PSN | PSN Tunnel | PSN |
| MPLS |<==============================>| MPLS |
+-------------+ +-------------+
| Physical | | Physical |
+-----+-------+ +-----+-------+
Figure 2: Pseudowire Protocol Stack Reference Model
図2：擬似回線プロトコルスタック参照モデル
Each HC-HD compressed channel is mapped to a single PW and associated with 2 PW labels, one in each direction. A single PW label MUST be used for many HC flows (could be 100's or 1000's) rather than assigning a different PW label to each flow. The latter approach would involve a complex mechanism for PW label assignment, freeing up of labels after a flow terminates, etc., for potentially 1000's of simultaneous HC flows. On the other hand, the mechanism for CID assignment, freeing up, etc., is in place and there is no need to duplicate it with PW assignment/deassignment for individual HC flows.
各HC-HD圧縮チャンネルは、単一のPWにマッピングされ、2つのPWラベル、各方向に1つに関連付けられます。単一のPWラベルがなく、各フローに異なるPWラベルを割り当てるよりも、（100のまたは1000のをすることができる）、多くのHCが流れるために使用されなければなりません。後者のアプローチは、流れが終了した後、同時HC・フローの潜在的に1000のために、など、ラベルの解放、PWラベルの割り当てのための複雑な機構を伴うだろう。一方、CIDの割り当てのためのメカニズムなど、解放、所定の位置にあり、個々のHCフローのPWの割り当て/割り当て解除でそれを複製する必要はありません。
Multiple PWs SHOULD be established in case different quality of service (QoS) requirements are needed for different compressed streams. The QoS received by the flow would be determined by the EXP bit marking in the PW label. Normally, all RTP packets would get the same EXP marking [RFC3270], equivalent to expedited forwarding (EF) treatment [RFC3246] in Diffserv. However, the protocol specified in this document applies to several different types of streams, not just RTP streams, and QoS treatment other than EF may be required for those streams.
複数のPWSはサービスの場合異なる品質に確立すべきである（QoS）の要件が異なる圧縮されたストリームのために必要とされます。フローによって受信されたQoSは、PWラベルにマーキングEXPビットによって決定されるであろう。通常、すべてのRTPパケットは、Diffservの中優先転送（EF）処理[RFC3246]に相当同じEXPマーキング[RFC3270]を得るであろう。しかし、この文書で指定されたプロトコルは、いくつかの異なるストリームのタイプだけでなく、RTPストリームに適用され、そしてEF以外のQoS処理は、これらのストリームのために必要とされてもよいです。
Figure 3 shows the HC over MPLS protocol stack (with uncompressed header):
図3は、（非圧縮ヘッダを持つ）MPLSプロトコルスタック上HCを示しています。
Media stream RTP UDP IP HC control parameter MPLS label stack (at least 2 labels for this application) Link layer under MPLS (PPP, PoS, Ethernet) Physical layer (SONET/SDH, fiber, copper)
メディアストリームRTP、UDP、IP HC制御パラメータMPLSラベルスタック（このアプリケーションの少なくとも2つのラベル）MPLS下のリンクレイヤ（PPP、POS、イーサネット（登録商標））物理層（SONET / SDH、繊維、銅）
+--------------+
| Media stream |
+--------------+
\_______ ______/
2-4 octets V
+------+--------------+
Compressed /RTP/UDP/IP/ |header| |
+------+--------------+
\__________ __________/
2 octets V
+------+---------------------+
HC Control Parameter |header| |
+------+---------------------+
\______________ _____________/
8 octets V
+------+----------------------------+
MPLS Labels |header| |
+------+----------------------------+
\_________________ _________________/
V
+------------------------------------------+
Link Layer under MPLS | |
+------------------------------------------+
\____________________ _____________________/
V
+-------------------------------------------------+
Physical Layer | |
+-------------------------------------------------+
Figure 3: Header Compression over MPLS Media Stream Transport
図3：MPLSメディアストリーム交通におけるヘッダ圧縮
The HC control parameter MUST be used to identify the packet types for the HC scheme in use. The MPLS labels technically define two layers: the PW identifier and the MPLS tunnel identifier. The PW label MUST be used as the demultiplexer field by the HD, where the PW label appears at the bottom label of an MPLS label stack. The LSR that will be performing decompression MUST ensure that the label it distributes (e.g., via LDP) for a channel is unique. There can also be other MPLS labels, for example, to identify an MPLS VPN. The IP/UDP/RTP headers are compressed before transmission, leaving the rest of the stack alone, as shown in Figure 3.
HC制御パラメータは、使用中のHCスキームのためのパケットタイプを識別するために使用されなければなりません。 PW識別子とMPLSトンネル識別子：MPLSラベルは、技術的に二つの層を定義します。 PWラベルは、PWラベルは、MPLSラベルスタックの最下部のラベルに表示されますHD、デマルチプレクサフィールドとして使用しなければなりません。チャネル用減圧ラベルは、それが（LDPを介して、例えば）を配信することを保証しなければならない実行するLSRは一意です。また、MPLS VPNを識別するために、例えば、他のMPLSラベルが存在する場合があります。 IP / UDP / RTPヘッダは、図3に示すように、単独で、スタックの残りの部分を残して、送信前に圧縮されます。
PWs MUST be set up in advance for the transport of media streams using [RFC4447] control messages exchanged by the HC-HD endpoints. Furthermore, a PW type MUST be used to indicate the HC scheme being used on the PW. [RFC4447] specifies the MPLS label distribution protocol (LDP) [RFC3036] extensions to set up and maintain the PWs, and defines new LDP objects to identify and signal attributes of PWs. Any acceptable method of MPLS label distribution MAY be used for distributing the MPLS tunnel label [RFC3031]. These methods include LDP [RFC3036], RSVP-TE [RFC3209], or configuration.
PWSがHC-HDエンドポイントで交換[RFC4447]制御メッセージを使用してメディアストリームのトランスポートのために予め設定されなければなりません。また、PWタイプがPWで使用されているHC方式を示すために使用されなければなりません。 [RFC4447]は設定およびPWを維持するために、MPLSラベル配布プロトコル（LDP）[RFC3036]の拡張機能を指定する、およびPWの属性を識別し、信号新しいLDPオブジェクトを定義します。 MPLSラベル配布の任意の許容可能な方法は、MPLSトンネルラベル[RFC3031]を配信するために使用されるかもしれません。これらの方法は、LDP [RFC3036]、RSVP-TE [RFC3209]、または構成を含みます。
To assign and distribute the PW labels, an LDP session MUST be set up between the PW endpoints using the extended discovery mechanism described in [RFC3036]. The PW label bindings are distributed using the LDP downstream unsolicited mode described in [RFC3036]. An LDP label mapping message contains a FEC object, a label object, and possible other optional objects. The FEC object indicates the meaning of the label, identifies the PW type, and identifies the PW that the PW label is bound to. See [RFC4447] for further explanation of PW signaling.
PWラベルを割り当て、分配するために、LDPセッションは、[RFC3036]に記載の拡張ディスカバリメカニズムを使用して、PWエンドポイントとの間に設定されなければなりません。 PWラベルバインディングは[RFC3036]で説明LDP下流迷惑モードを使用して分配されます。 LDPラベルマッピングメッセージは、FECオブジェクト、ラベルオブジェクト、および可能な他の任意のオブジェクトが含まれています。 FECオブジェクトは、ラベルの意味を示しPWタイプを識別し、PWラベルがバインドされているPWを識別します。 PWシグナリングのさらなる説明のために[RFC4447]を参照してください。
This specification defines new PW type values to be carried within the FEC object to identify HC PWs for each HC scheme. The PW type is a 15-bit parameter assigned by IANA, as specified in the [RFC4446] registry, and MUST be used to indicate the HC scheme being used on the PW. IANA has set aside the following PW type values for assignment according to the registry specified in RFC 4446, Section 3.2:
この仕様は、各HCスキームにHCのPWを識別するためにFECオブジェクト内に担持される新しいPWタイプの値を定義します。 [RFC4446]レジストリに指定され、PWで使用されているHC方式を示すために使用されなければならないようにPWタイプは、IANAによって割り当てられた15ビットのパラメータです。 IANAは、RFC 4446で指定されたレジストリ、セクション3.2に従って割り当てのための次のPWタイプ値を取っておきました。
PW type Description Reference
=============================================================
0x001A ROHC Transport Header-compressed Packets [RFC3095bis]
0x001B ECRTP Transport Header-compressed Packets [RFC3545]
0x001C IPHC Transport Header-compressed Packets [RFC2507]
0x001D CRTP Transport Header-compressed Packets [RFC2508]
The HC control parameter enables distinguishing between various packets types (e.g., uncompressed, UDP compressed, RTP compressed, context-state, etc.). However, the HC control parameter indications are not unique across HC schemes, and therefore the PW type value allows the HC scheme to be identified.
HC制御パラメータは、様々なパケットのタイプ（例えば、非圧縮、UDP圧縮し、圧縮されたRTP、コンテキスト状態、等）を区別可能にします。しかしながら、HC制御パラメータ表示はHC方式で一意ではないので、PWタイプ値は、HC方式を識別することを可能にします。
As described in the previous section, the HC PW MUST be used for compressed packets only, which is configured at PW setup. If a flow is not compressed, it MUST NOT be placed on the HC PW. HC PWs MUST be bi-directional, which means that a unidirectional leg of the PW MUST be set up in each direction. One leg of the bi-directional PW MAY be set up to carry only compression feedback, not header compressed traffic. The same PW type MUST be used for PW signaling in both directions.
前のセクションで説明したように、HC PWはPWセットアップで構成されているだけ圧縮されたパケットのために使用しなければなりません。流れが圧縮されていない場合、それはHC PWの上に置かれてはなりません。 HC PWSがPWの一方向脚を各方向に設定しなければならないことを意味する双方向でなければなりません。双方向のPWの片足だけ圧縮フィードバックを運び、いない圧縮されたトラフィックをヘッダに設定することができます。同じPWタイプは、両方向にPWシグナリングのために使用されなければなりません。
HC scheme parameters MAY be manually configured, but if so, manual configuration MUST be done in both directions. If HC scheme parameters are signaled, the Interface Parameters Sub-TLV MUST be used on any unidirectional legs of a PW that will carry HC traffic. For a unidirectional leg of a PW that will carry only compression feedback, the components of the Interface Parameters Sub-TLV described below are not relevant and MUST NOT be used.
HC方式パラメータが手動で設定することができるが、その場合、手動設定が両方向で行われなければなりません。 HCスキームパラメータが通知された場合は、インターフェイスパラメータサブTLVは、HCのトラフィックを伝送しますPWの任意の一方向の足の上に使用しなければなりません。のみ圧縮フィードバックを運ぶPWの一方向脚ため、インターフェイスパラメータサブTLVの構成要素は、以下に説明する関連ではなく、使用してはいけません。
The PW HC approach relies on the PW/MPLS layer to convey HC channel configuration information. The Interface Parameters Sub-TLV [IANA, RFC4447] must be used to signal HC channel setup and specify HC parameters. That is, the configuration options specified in [RFC3241, RFC3544] are reused in this specification to specify PW-specific parameters, and to configure the HC and HD ports at the edges of the PW so that they have the necessary capabilities to interoperate with each other.
PW HCアプローチは、HCチャネル構成情報を伝達するためにPW / MPLS層に依存しています。インターフェイスパラメータサブTLV [IANA、RFC4447]はHCチャネルセットアップ信号及びHCのパラメータを指定するために使用されなければなりません。すなわち、[RFC3241、RFC3544]で指定された構成オプションは、PW固有のパラメータを指定するために、それらはそれぞれと相互運用するために必要な能力を有するようにPWのエッジでHC及びHDポートを設定するには、この明細書では再利用されますその他。
Pseudowire Interface Parameter Sub-TLV type values are specified in [RFC4446]. IANA has set aside the following Pseudowire Interface Parameter Sub-TLV type values according to the registry specified in RFC 4446, Section 3.3:
疑似回線インタフェースパラメータサブTLVのタイプ値は、[RFC4446]で指定されています。 IANAはRFC 4446、セクション3.3で指定されたレジストリに応じて、以下の疑似回線インタフェースパラメータサブTLVのタイプの値を取っておきました。
Parameter ID Length Description Reference
--------- --------------- ---------------------------- ---------
0x0D up to 256 bytes ROHC over MPLS configuration RFC 4901
RFC 3241
0x0F up to 256 bytes CRTP/ECRTP/IPHC HC over MPLS RFC 4901
configuration RFC 3544
TLVs identified in [RFC3241] and [RFC3544] MUST be encapsulated in the PW Interface Parameters Sub-TLV and used to negotiate header compression session setup and parameter negotiation for their respective protocols. The TLVs supported in this manner MUST include the following: o Configuration Option Format, RTP-Compression Suboption, Enhanced RTP-Compression Suboption, TCP/non-TCP Compression Suboptions, as specified in [RFC3544]
[RFC3241]及び[RFC3544]において同定のTLVは、PWインターフェイスパラメータサブTLVにカプセル化され、それらのそれぞれのプロトコルのヘッダ圧縮セッションのセットアップ、パラメータのネゴシエーションを交渉するために使用されなければなりません。 [RFC3544]で指定されるように、設定オプションのフォーマット、RTP圧縮サブオプション、拡張RTP圧縮サブオプション、TCP /非TCP圧縮サブオプション○：TLVが以下を含まなければならない、このようにサポート
o Configuration Option Format, PROFILES Suboption, as specified in [RFC3241]
O構成オプションフォーマット、PROFILESサブオプション、[RFC3241]で指定されています
These TLVs are now specified in the following sections.
これらのTLVは、現在、次のセクションで指定されています。
Both the network control protocol for IPv4, IPCP [RFC1332] and the IPv6 Network Control Protocol (NCP), IPV6CP [RFC2472] may be used to negotiate IP HC parameters for their respective controlled protocols. The format of the configuration option is the same for both IPCP and IPV6CP. This configuration option MUST be included for ECRTP, CRTP and IPHC PW types and MUST NOT be included for ROHC PW types. A decompressor MUST reject this option (if misconfigured) for ROHC PW types and send an explicit error message to the compressor [RFC3544].
IPv4の、IPCP [RFC1332]とIPv6ネットワーク制御プロトコル（NCP）のネットワーク制御プロトコルの両方は、IPV6CP [RFC2472]は、それぞれの制御プロトコルのIP HCパラメータをネゴシエートするために使用することができます。設定オプションのフォーマットは、IPCPとIPV6CPの両方で同じです。この設定オプションは、ECRTP、CRTPとIPHC PWタイプのために含まれなければならないとROHC PWタイプのために含んではいけません。デコンプレッサは、ROHC PWタイプの（不適切に設定する場合）、このオプションを拒否し、圧縮[RFC3544]に明示的なエラーメッセージを送らなければなりません。
Description
説明
This NCP configuration option is used to negotiate parameters for IP HC. Successful negotiation of parameters enables the use of Protocol Identifiers FULL_HEADER, COMPRESSED_TCP, COMPRESSED_TCP_NODELTA, COMPRESSED_NON_TCP, and CONTEXT_STATE as specified in [RFC2507]. The option format is summarized below. The fields are transmitted from left to right.
このNCPの設定オプションは、IP HCのパラメータを交渉するために使用されます。パラメータの成功した交渉は、[RFC2507]で指定されたプロトコル識別子FULL_HEADER、COMPRESSED_TCP、COMPRESSED_TCP_NODELTA、COMPRESSED_NON_TCP、およびCONTEXT_STATEの使用を可能にします。オプションの形式は以下のように要約されます。フィールドは左から右に送信されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | IP-Compression-Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TCP_SPACE | NON_TCP_SPACE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| F_MAX_PERIOD | F_MAX_TIME |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX_HEADER | suboptions... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 2
タイプ2
Length >= 14
長さ> = 14
The length may be increased if the presence of additional parameters is indicated by additional suboptions.
追加のパラメータの存在は、追加のサブオプションによって示されている場合は、長さを増加させることができます。
IP-Compression-Protocol 0061 (hex)
IP-圧縮・プロトコル0061（16進）
TCP_SPACE The TCP_SPACE field is two octets and indicates the maximum value of a context identifier in the space of context identifiers allocated for TCP.
TCP_SPACEはTCP_SPACEフィールドは、2つのオクテットであり、TCPのために割り当てられたコンテクスト識別子の空間のコンテキスト識別子の最大値を示しています。
Suggested value: 15
推奨値：15
TCP_SPACE must be at least 0 and at most 255 (the value 0 implies having one context). This field is not used for CRTP (PW type 0x001B) and ECRTP (PW type 0x001B) PWs. For these PW types, it should be set to its suggested value by the sender and ignored by the receiver.
TCP_SPACEは（値0があるコンテキストを有することを意味する）、少なくとも0かつ多くとも255でなければなりません。このフィールドは、CRTP（PWタイプ0x001B）とECRTP（PWタイプ0x001B）のPWには使用されません。これらのPWタイプの場合、それは、送信者がその提案の値に設定する必要があり、受信機で無視します。
NON_TCP_SPACE The NON_TCP_SPACE field is two octets and indicates the maximum value of a context identifier in the space of context identifiers allocated for non-TCP. These context identifiers are carried in COMPRESSED_NON_TCP, COMPRESSED_UDP and COMPRESSED_RTP packet headers.
NON_TCP_SPACEはNON_TCP_SPACEフィールドは、2つのオクテットであり、非TCPのために割り当てられたコンテクスト識別子の空間のコンテキスト識別子の最大値を示しています。これらのコンテキスト識別子はCOMPRESSED_NON_TCP、COMPRESSED_UDPとCOMPRESSED_RTPパケットヘッダで運ばれます。
Suggested value: 15
推奨値：15
NON_TCP_SPACE must be at least 0 and at most 65535 (the value 0 implies having one context).
NON_TCP_SPACEは（値0があるコンテキストを有することを意味する）、少なくとも0かつ多くとも65535でなければなりません。
F_MAX_PERIOD Maximum interval between full headers. No more than F_MAX_PERIOD COMPRESSED_NON_TCP headers may be sent between FULL_HEADER headers.
フルヘッダ間F_MAX_PERIOD最大間隔。 F_MAX_PERIOD COMPRESSED_NON_TCPヘッダよりもないんFULL_HEADERヘッダとの間で送信することができます。
Suggested value: 256
推奨値：256
A value of zero implies infinity, i.e., there is no limit to the number of consecutive COMPRESSED_NON_TCP headers. This field is not used for CRTP (PW type 0x001B) and ECRTP (PW type 0x001B) PWs. For these PW types, it should be set to its suggested value by the sender and ignored by the receiver.
ゼロの値は無限大、すなわち、連続COMPRESSED_NON_TCPヘッダの数に制限はありません意味しています。このフィールドは、CRTP（PWタイプ0x001B）とECRTP（PWタイプ0x001B）のPWには使用されません。これらのPWタイプの場合、それは、送信者がその提案の値に設定する必要があり、受信機で無視します。
F_MAX_TIME Maximum time interval between full headers. COMPRESSED_NON_TCP headers may not be sent more than F_MAX_TIME seconds after sending the last FULL_HEADER header.
フルヘッダ間F_MAX_TIME最大時間間隔。 COMPRESSED_NON_TCPヘッダは最後FULL_HEADERヘッダーを送信した後以上F_MAX_TIME秒を送信しなくてもよいです。
Suggested value: 5 seconds
推奨値：5秒
A value of zero implies infinity. This field is not used for CRTP (PW type 0x001B) and ECRTP (PW type 0x001B) PWs. For these PW types, it should be set to its suggested value by the sender and ignored by the receiver.
ゼロの値は無限大を意味しています。このフィールドは、CRTP（PWタイプ0x001B）とECRTP（PWタイプ0x001B）のPWには使用されません。これらのPWタイプの場合、それは、送信者がその提案の値に設定する必要があり、受信機で無視します。
MAX_HEADER The largest header size in octets that may be compressed.
圧縮されてもよいオクテットで最大ヘッダサイズをMAX_HEADER。
Suggested value: 168 octets
推奨値：168個のオクテット
The value of MAX_HEADER should be large enough so that at least the outer network layer header can be compressed. To increase compression efficiency MAX_HEADER should be set to a value large enough to cover common combinations of network and transport layer headers.
少なくとも外側のネットワーク層ヘッダを圧縮することができるようにMAX_HEADERの値は十分に大きくなければなりません。圧縮効率MAX_HEADERを増加させるためには、ネットワークおよびトランスポート層ヘッダの一般的な組み合わせをカバーするのに十分に大きな値に設定されるべきです。
suboptions The suboptions field consists of zero or more suboptions. Each suboption consists of a type field, a length field and zero or more parameter octets, as defined by the suboption type. The value of the length field indicates the length of the suboption in its entirety, including the lengths of the type and length fields.
サブオプションのサブオプションフィールドは、ゼロ個以上のサブオプションで構成されています。サブオプションのタイプによって定義されるように各サブオプションは、タイプフィールド、長さフィールドおよびゼロ以上のパラメータのオクテットで構成されています。長さフィールドの値は、タイプと長さフィールドの長さを含め、その全体がサブオプションの長さを示します。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Parameters...|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The RTP-Compression suboption is included in the NCP IP-Compression-Protocol option for IPHC if IP/UDP/RTP compression is to be enabled. This suboption MUST be included for CRTP PWs (0x001C) and MUST NOT be included for other PW types.
IP / UDP / RTP圧縮を有効にする場合はRTP圧縮サブオプションは、IPHCのためのNCP IP圧縮プロトコルオプションに含まれています。このサブオプションは、CRTPのPW（0x001C）のために含まれなければならないと、他のPWタイプのために含んではいけません。
Inclusion of the RTP-Compression suboption enables use of additional Protocol Identifiers COMPRESSED_RTP and COMPRESSED_UDP along with additional forms of CONTEXT_STATE as specified in [RFC2508].
RTP圧縮サブオプションを含めることは、[RFC2508]で指定されるようCONTEXT_STATEの追加の形態と共に追加のプロトコル識別子COMPRESSED_RTPとCOMPRESSED_UDPの使用を可能にします。
Description
説明
Enables the use of Protocol Identifiers COMPRESSED_RTP, COMPRESSED_UDP, and CONTEXT_STATE as specified in [RFC2508].
[RFC2508]で指定されるようにプロトコル識別子COMPRESSED_RTP、COMPRESSED_UDP、及びCONTEXT_STATEの使用を可能にします。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 1
タイプ1
Length 2
長さ2
To use the enhanced RTP HC defined in [RFC3545], a new suboption 2 is added. Suboption 2 is negotiated instead of, not in addition to, suboption 1. This suboption MUST be included for ECRTP PWs (0x001B) and MUST NOT be included for other PW types.
[RFC3545]で定義された拡張RTP HCを使用する、新しいサブオプション2が添加されます。サブオプション2はいないサブオプションこのサブオプションは、ECRTPのPW（0x001B）のために含まれなければならない1、に加えて、代わりにネゴシエートされ、他のPWタイプに含まれてはいけません。
Note that suboption 1 refers to the RTP-Compression Suboption, as specified in Section 4.2.2, and suboption 2 refers to the Enhanced RTP-Compression Suboption, as specified in Section 4.2.3. These suboptions MUST NOT occur together. If they do (e.g., if misconfigured), a decompressor MUST reject this option and send an explicit error message to the compressor [RFC3544].
セクション4.2.2で指定され、かつセクション4.2.3で指定されるようにサブオプション2は、拡張RTP圧縮サブオプションを指すように、そのサブオプション1は、RTP圧縮サブオプションを指します。これらのサブオプションが同時に発生してはなりません。それらは（例えば、誤って設定場合）を行う場合、デコンプレッサは、このオプションを拒否し、圧縮[RFC3544]に明示的なエラーメッセージを送らなければなりません。
Description
説明
Enables the use of Protocol Identifiers COMPRESSED_RTP and CONTEXT_STATE as specified in [RFC2508]. In addition, it enables the use of [RFC3545] compliant compression including the use of Protocol Identifier COMPRESSED_UDP with additional flags and use of the C flag with the FULL_HEADER Protocol Identifier to indicate use of HDRCKSUM with COMPRESSED_RTP and COMPRESSED_UDP packets.
[RFC2508]で指定されたプロトコル識別子COMPRESSED_RTPとCONTEXT_STATEの使用を可能にします。また、COMPRESSED_RTPとCOMPRESSED_UDPパケットでHDRCKSUMの使用を示すために、追加のフラグとFULL_HEADERプロトコル識別子とCフラグを用いて、プロトコル識別子COMPRESSED_UDPの使用を含む[RFC3545]に準拠した圧縮の使用を可能にします。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 2
タイプ2
Length 2
長さ2
4.2.4. Negotiating Header Compression for Only TCP or Only Non-TCP Packets []
4.2.4. ] [のみTCPまたは唯一の非TCPパケットのためのヘッダ圧縮を交渉
In [RFC3544] it was not possible to negotiate only TCP HC or only non-TCP HC because a value of 0 in the TCP_SPACE or the NON_TCP_SPACE fields actually means that 1 context is negotiated.
[RFC3544]にはTCP_SPACE又はNON_TCP_SPACEフィールドにおける0の値は、実際に1つのコンテキストがネゴシエートされていることを意味するためにのみTCPのHCまたは唯一の非TCP HCを交渉することはできませんでした。
A new suboption 3 is added to allow specifying that the number of contexts for TCP_SPACE or NON_TCP_SPACE is zero, disabling use of the corresponding compression. This suboption MUST be included for IPHC PWs (0x001C) and MUST NOT be included for other PW types.
新しいサブオプション3は、対応する圧縮の使用を無効にする、TCP_SPACE又はNON_TCP_SPACEためのコンテキストの数がゼロであることを指定できるようにするために添加されます。このサブオプションはIPHCのPW（0x001C）のために含まれなければならないと、他のPWタイプのために含んではいけません。
Description
説明
Enable HC for only TCP or only non-TCP packets.
唯一のTCPまたは唯一の非TCPパケットのHCを有効にします。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Parameter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 3
タイプ3
Length 3
長さ3
Parameter
パラメーター
The parameter is 1 byte with one of the following values:
パラメータは、次のいずれかの値を持つ1バイトであります：
1 = the number of contexts for TCP_SPACE is 0 2 = the number of contexts for NON_TCP_SPACE is 0
1 = TCP_SPACEためのコンテキストの数は0〜2である= NON_TCP_SPACEためのコンテキストの数が0であります
This suboption overrides the values that were previously assigned to TCP_SPACE and NON_TCP_SPACE in the IP HC option.
このサブオプションは、以前IP HCオプションでTCP_SPACEとNON_TCP_SPACEに割り当てられた値を上書きします。
If suboption 3 is included multiple times with parameter 1 and 2, compression is disabled for all packets.
サブオプション3は、パラメータ1と2で複数回含まれている場合、圧縮はすべてのパケットのために無効になっています。
Both the network control protocol for IPv4, IPCP [RFC1332] and the IPv6 NCP, IPV6CP [RFC2472] may be used to negotiate IP HC parameters for their respective controlled protocols. The format of the configuration option is the same for both IPCP and IPV6CP. This configuration option MUST be included for ROHC PW types and MUST NOT be included for ECRTP, CRTP, and IPHC PW types. A decompressor MUST reject this option (if misconfigured) for ECRTP, CRTP, and IPHC PW types, and send an explicit error message to the compressor [RFC3544].
IPv4の、IPCP [RFC1332]とIPv6 NCPのネットワーク制御プロトコルの両方、IPV6CP [RFC2472]は、それぞれの制御プロトコルのIP HCパラメータをネゴシエートするために使用することができます。設定オプションのフォーマットは、IPCPとIPV6CPの両方で同じです。この設定オプションは、ROHC PWタイプのために含まれなければならないとECRTP、CRTP、およびIPHC PWタイプのために含んではいけません。減圧装置はECRTP、CRTP、およびIPHC PWタイプの（不適切に設定する場合）、このオプションを拒否し、そして圧縮[RFC3544]に明示的なエラーメッセージを送らなければなりません。
Description
説明
This NCP configuration option is used to negotiate parameters for ROHC. The option format is summarized below. The fields are transmitted from left to right.
このNCPの設定オプションは、ROHCのためのパラメータを交渉するために使用されます。オプションの形式は以下のように要約されます。フィールドは左から右に送信されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | IP-Compression-Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX_CID | MRRU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX_HEADER | suboptions... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 2
タイプ2
Length >= 10
長さ> = 10
The length may be increased if the presence of additional parameters is indicated by additional suboptions.
追加のパラメータの存在は、追加のサブオプションによって示されている場合は、長さを増加させることができます。
IP-Compression-Protocol 0003 (hex)
IP-圧縮・プロトコル0003（16進）
MAX_CID The MAX_CID field is two octets and indicates the maximum value of a context identifier.
MAX_CIDザMAX_CIDフィールドは、2つのオクテットであり、コンテキスト識別子の最大値を示しています。
Suggested value: 15
推奨値：15
MAX_CID must be at least 0 and at most 16383 (The value 0 implies having one context).
MAX_CIDは（値0があるコンテキストを有することを意味する）、少なくとも0かつ多くとも16383でなければなりません。
MRRU The MRRU field is two octets and indicates the maximum reconstructed reception unit (see [RFC3095bis], Section 5.1.2).
MRRUザMRRUフィールドは、2つのオクテットであり、最大再構成された受信ユニット（[RFC3095bis]セクション5.1.2を参照）を示しています。
Suggested value: 0
推奨値：0
MAX_HEADER The largest header size in octets that may be compressed.
圧縮されてもよいオクテットで最大ヘッダサイズをMAX_HEADER。
Suggested value: 168 octets
推奨値：168個のオクテット
The value of MAX_HEADER should be large enough so that at least the outer network layer header can be compressed. To increase compression efficiency MAX_HEADER should be set to a value large enough to cover common combinations of network and transport layer headers.
少なくとも外側のネットワーク層ヘッダを圧縮することができるようにMAX_HEADERの値は十分に大きくなければなりません。圧縮効率MAX_HEADERを増加させるためには、ネットワークおよびトランスポート層ヘッダの一般的な組み合わせをカバーするのに十分に大きな値に設定されるべきです。
NOTE: The four ROHC profiles defined in RFC 3095 do not provide for a MAX_HEADER parameter. The parameter MAX_HEADER defined by this document is therefore without consequence in these profiles because the maximum compressible header size is unspecified. Other profiles (e.g., ones based on RFC 2507) can make use of the parameter by explicitly referencing it.
注：RFC 3095で定義された4つのROHCプロファイルはMAX_HEADERパラメータのために提供されていません。最大圧縮ヘッダのサイズが指定されていないため、この文書によって定義されたパラメータMAX_HEADERは、これらのプロファイルの結果なしことです。他のプロファイル（例えば、RFC 2507に基づくもの）は、明示的にそれを参照することで、パラメータを利用することができます。
suboptions The suboptions field consists of zero or more suboptions. Each suboption consists of a type field, a length field, and zero or more parameter octets, as defined by the suboption type. The value of the length field indicates the length of the suboption in its entirety, including the lengths of the type and length fields.
サブオプションのサブオプションフィールドは、ゼロ個以上のサブオプションで構成されています。サブオプションのタイプによって定義されるように各サブオプションは、タイプフィールド、長さフィールド、およびゼロ以上のパラメータのオクテットで構成されています。長さフィールドの値は、タイプと長さフィールドの長さを含め、その全体がサブオプションの長さを示します。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Parameters...|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The set of profiles to be enabled is subject to negotiation. Most initial implementations of ROHC implement profiles 0x0000 to 0x0003. This option MUST be supplied.
有効にするプロファイルのセットは交渉の対象となります。 ROHCのほとんどの初期の実装は、プロファイル0x0003に0000を実装します。このオプションを指定する必要があります。
Description
説明
Define the set of profiles supported by the decompressor.
デコンプレッサでサポートされているプロファイルのセットを定義します。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Profiles... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 1
タイプ1
Length 2n+2
長さ2N + 2
Value n octet-pairs in ascending order, each octet-pair specifying a ROHC profile supported.
昇順に値Nオクテット対は、ROHCプロファイルを指定する各オクテット対がサポート。
HC flow identification is being done now in many ways. Since there are multiple possible approaches to the problem, no specific method is specified in this document.
HCのフロー識別は、多くの点で、今行われています。問題に対する複数の可能なアプローチがあるので、具体的な方法は、この文書で指定されていません。
The HC control parameter is used to identify the packet types for IPHC [RFC2507], CRTP [RFC2508], and ECRTP [RFC3545], as shown in Figure 4:
図4に示すように、HC制御パラメータは、IPHC [RFC2507]、CRTP [RFC2508]、およびECRTP [RFC3545]のためのパケットタイプを識別するために使用されます。
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0|Pkt Typ| Length |Res|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: HC Control Parameter
図4：HC制御パラメータ
where:
どこ：
"Packet Type" encoding: 0: ROHC Small-CIDs 1: ROHC Large-CIDs 2: FULL_HEADER 3: COMPRESSED_TCP 4: COMPRESSED_TCP_NODELTA 5: COMPRESSED_NON_TCP 6: COMPRESSED_RTP_8 7: COMPRESSED_RTP_16 8: COMPRESSED_UDP_8 9: COMPRESSED_UDP_16 10: CONTEXT_STATE
"パケットタイプ" エンコーディング：0：ROHC小-CIDS 1：ROHC大のCID 2：FULL_HEADER 3：COMPRESSED_TCP 4：COMPRESSED_TCP_NODELTA 5：COMPRESSED_NON_TCP 6：COMPRESSED_RTP_8 7：COMPRESSED_RTP_16 8：COMPRESSED_UDP_8 9：COMPRESSED_UDP_16 10：CONTEXT_STATE
11-15: Not yet assigned. (See Section 8, "IANA Considerations", for discussion of the registration rules.)
11-15：まだ割り当てられていません。 （登録ルールの説明については、第8章、「IANAの考慮事項」を参照してください。）
As discussed in [ECMP-AVOID], since this MPLS payload type is not IP, the first nibble is set to 0000 to avoid being mistaken for IP. This is also consistent with the encoding of the PW MPLS control word (PWMCW) described in [RFC4385]; however, the HC control parameter is not intended to be a PWMCW.
[ECMP-AVOID]で議論するように、これはペイロードタイプはIPないMPLSので、最初のニブルは、IPと間違えである避けるために0000に設定されています。また、これは[RFC4385]で説明PW MPLS制御ワード（PWMCW）の符号化と一致しています。しかし、HC制御パラメータはPWMCWことを意図するものではありません。
Note that ROHC [RFC3095, RFC3095bis] provides its own packet type within the protocol; however, the HC control parameter MUST still be used to avoid the problems identified above. Since the "Packet Type" will be there anyway, it is used to indicate ROHC CID size, in the same way as with PPP.
ROHC [RFC3095、RFC3095bis]は、プロトコル内独自のパケットタイプを提供することに留意されたいです。しかし、HC制御パラメータは、まだ上記の特定された問題を回避するために使用しなければなりません。 「パケットタイプは」とにかくがあるでしょうので、PPPと同じように、ROHC CIDのサイズを示すために使用されます。
The HC control parameter length field is ONLY used for short packets because padding may be appended by the Ethernet Data Link Layer. If the length is greater than or equal to 64 octets, the length field MUST be set to zero. If the MPLS payload is less than 64 bytes, then the length field MUST be set to the length of the PW payload plus the length of the HC control parameter. Note that the last 2 bits in the HC control parameter are reserved.
パディングは、イーサネットデータリンク層によって追加することができるので、HC制御パラメータの長さのフィールドは、ショートパケットのために使用されています。長さがより大きいかまたは64個のオクテットに等しい場合、長さフィールドはゼロに設定しなければなりません。 MPLSペイロードが64バイト未満である場合、長さフィールドは、PWペイロードの長さプラスHC制御パラメータの長さに設定しなければなりません。 HC制御パラメータの最後の2ビットは予約されていることに留意されたいです。
Packet reordering for ROHC is discussed in [RFC4224], which is a useful source of information. In case of lossy links and other reasons for reordering, implementation adaptations are needed to allow all the schemes to be used in this case. Although CRTP is viewed as having risks for a number of PW environments due to reordering and loss, it is still the protocol of choice in many cases. CRTP was designed for reliable point to point links with short delays. It does not perform well over links with a high rate of packet loss, packet reordering, and long delays. In such cases, ECRTP [RFC3545] may be considered to increase robustness to both packet loss and misordering between the compressor and the decompressor. This is achieved by repeating updates and sending of absolute (uncompressed) values in addition to delta values for selected context parameters. IPHC should use TCP_NODELTA, ECRTP should send absolute values, ROHC should be adapted as discussed in [RFC4224]. An evaluation and simulation of ECRTP and ROHC reordering is given in [REORDER-EVAL].
ROHCのパケット並べ替えは、情報の有用なソースである[RFC4224]に記載されています。非可逆リンクや並べ替えのための他の理由の場合は、実装の適合は、すべてのスキームが、この場合に使用できるようにするために必要とされています。 CRTPは、並べ替えや損失によるPW環境の数のリスクを持つと見られているが、それでも多くの場合、選択したプロトコルです。 CRTPは、短い遅延を持つリンクを指すように信頼性の高いポイントのために設計されました。これは、高いパケット損失率、パケットの並べ替え、および長い遅延とのリンクの上にうまく実行されません。このような場合、ECRTP [RFC3545]は、コンプレッサとデコンプレッサとの間のパケットロスと誤った順序の両方にロバスト性を増加することが考えられます。これは、更新を繰り返し、選択されたコンテキストパラメータのデルタ値に加えて、絶対的な（非圧縮）の値を送信することによって達成されます。 [RFC4224]で議論するようにIPHCがECRTP絶対値を送信する必要があり、TCP_NODELTAを使用する必要があり、ROHCは、適合しなければなりません。 ECRTP及びROHCリオーダリングの評価とシミュレーション[REORDER-EVAL]で与えられます。
This example will trace the setup of an MPLS PW supporting bi-directional ECRTP [RFC3545] traffic. The example assumes the topology shown in Figure 1. The PW will be set up between LSRs R1/HC and R4/HD. LSRs R2 and R3 have no direct involvement in the signaling for this PW, other than to transport the signaling traffic.
この例では、MPLS PWサポートする双方向ECRTP [RFC3545]トラフィックの設定をトレースします。例は、PWは、LSRのR1 / HC及びR4 / HDとの間に設定され、図1に示すトポロジを想定しています。 LSR R2とR3は、シグナリングトラフィックを転送する以外に、このPWのためのシグナリングには直接関与し、持っていません。
For this example, it is assumed that R1/HC has already obtained the IP address of R4/HD used for LDP signaling, and vice versa, that both R1/HC and R4/HD have been configured with the same 32-bit PW ID, as described in Section 5.2 of [RFC4447], and that R1/HC has been configured to initiate the LDP discovery process. Furthermore, we assume that R1/HC has been configured to receive a maximum of 200 simultaneous ECRTP flows from R4/HD, and R4/HD has been configured to receive a maximum of 255 ECRTP flows from R1/HC.
この例では、両方のR1 / HC及びR4 / HDは、同じ32ビットPW IDで構成されていることを、R1 / HCが既にLDPシグナリングに使用R4 / HD、およびその逆のIPアドレスを取得しているものとします、[RFC4447]のセクション5.2に記載し、そしてR1 / HCは、LDPディスカバリプロセスを開始するように構成されているような。さらに、我々はR1 / HCはR4 / HDから流れ、及びR4 / HDは255 ECRTPの最大値はR1 / HCから流れて受信するように設定された200の同時ECRTPの最大値を受信するように設定されていることを前提としています。
Assuming that there is no existing LDP session between R1/HC and R4/HD, the PW signaling must start by setting up an LDP session between them. As described earlier in this document, LDP extended discovery is used between HC over MPLS LSRs. Since R1/HC has been configured to initiate extended discovery, it will send LDP Targeted Hello messages to R4/HD's IP address at UDP port 646. The Targeted Hello messages sent by R1/HC will have the "R" bit set in the Common Hello Parameters TLV, requesting R4/HD to send Targeted Hello messages back to R1/HC. Since R4/HD has been configured to set up an HC PW with R1/HD, R4/HD will do as requested and send LDP Targeted Hello messages as unicast UDP packets to UDP port 646 of R1/HC's IP address.
R1 / HCおよびR4 / HDとの間には、既存のLDPセッションが存在しないと仮定すると、PWシグナリングは、それらの間のLDPセッションを設定することから始めなければなりません。本書で前述したように、LDP拡張発見は、MPLS LSRの上HCの間で使用されています。 R1 / HCは、拡張検出を開始するように構成されているので、それは自民党が「R」が共通に設定されたビットを持つことになりますUDPポート646でR4 / HDのIPアドレスにR1 / HCにより送信されたターゲットhelloメッセージをHelloメッセージをターゲットに送信しますバックR1 / HCへのHelloターゲットメッセージを送信するためにR4 / HDを要求し、パラメータTLVこんにちは。 R4 / HDは、R1 / HDとHC PWを設定するように設定されているため、R4 / HDは、要求に応じて行うと、LDPはR1 / HCのIPアドレスのUDPポート646へのユニキャストUDPパケットとしてHelloメッセージをターゲットに送信します。
When R1/HC receives a Targeted Hello message from R4/HD, it may begin establishing an LDP session to R4/HD. It starts this by initiating a TCP connection on port 646 to R4/HD's signaling IP address. After successful TCP connection establishment, R1/HC sends an LDP Initialization message to R4/HD with the following characteristics:
R1 / HCはR4 / HDからターゲットHelloメッセージを受信すると、R4 / HDにLDPセッションを確立し始めることができます。これは、R4 / HDのシグナリングIPアドレスにポート646上のTCP接続を開始することによって、これを起動します。成功したTCPコネクションの確立後、R1 / HCは、次の特性を持つR4 / HDへのLDP初期化メッセージを送信します。
When R1/HC receives a Targeted Hello message from R4/HD, it may begin establishing an LDP session to R4/HD. The procedure described in Section 2.5.2 of [RFC3036] is used to determine which LSR is the active LSR and which is the passive LSR. Assume that R1/HC has the numerically higher IP address and therefore takes the active role. R1/HC starts by initiating a TCP connection on port 646 to R4/HD's signaling IP address. After successful TCP connection establishment, R1/HC sends an LDP Initialization message to R4/HD with the following characteristics: o Common Session Parameters TLV: - A bit = 0 (Downstream Unsolicited Mode) - D bit = 0 (Loop Detection Disabled) - PVLim = 0 (required when D bit = 0) - Receive LDP identifier (taken from R4/HD's Hello message) > 4 octets LSR identifier (typically an IP address with IPv4) > 2 octet Label space identifier (typically 0) o No Optional Parameters TLV
R1 / HCはR4 / HDからターゲットHelloメッセージを受信すると、R4 / HDにLDPセッションを確立し始めることができます。 [RFC3036]のセクション2.5.2に記載された手順をLSRがアクティブLSRであり、受動LSRであるかを決定するために使用されます。 R1 / HCは、数値的に高いIPアドレスを持っているため、積極的な役割を果たしていることを前提としています。 R1 / HCはR4 / HDのシグナリングIPアドレスにポート646上のTCP接続を開始することによって開始します。成功したTCPコネクション確立後、R1 / HCは、以下の特性とR4 / HDにLDP初期化メッセージを送信する：共通セッションパラメータTLV（O） - ビット= 0（下流迷惑モード） - Dビット= 0（ループ検出無効） - PVLim = 0（必要なときにDビット= 0） - LDP識別子を受信（R4 / HDのHelloメッセージから取られた）> 4つのオクテットLSR識別子（IPv4では通常IPアドレス）> 2オクテットラベル空間識別子（通常は0）いいえオプションOパラメータTLV
Following the LDP session initialization state machine of Section 2.5.4 of [RFC3036], R4/HD would send a similar Initialization message to R1/HD. The primary difference would be that R4/HD would use the LDP identifier it received in R1/HC's Hello message(s) as the Receive LDP identifier. Assuming that all other fields in the Common Session Parameters TLV were acceptable to both sides, R1/HC would send an LDP Keepalive message to R4/HD, R4/HD would send a LDP Keepalive message to R1/HC, and the LDP session would become operational.
[RFC3036]のセクション2.5.4のLDPセッションの初期化状態マシンに続き、R4 / HDは、R1 / HDと同様の初期化メッセージを送信します。主な違いは、R4 / HDは、それが受信LDP識別子としてR1 / HCのHelloメッセージ（複数可）で受信されたLDP識別子を使用することになります。一般的なセッションパラメータTLV内の他のすべてのフィールドは、両側に許容できるものであったと仮定すると、R1 / HCはR4 / HDにLDPキープアライブメッセージを送信し、R4 / HDは、R1 / HCにLDPキープアライブメッセージを送信して、LDPセッションが希望操作可能になります。
At this point, either R1/HC or R4/HD may send LDP Label Mapping messages to configure the PW. The Label Mapping message sent by a particular router advertises the label that should be used at the bottom of the MPLS label stack for all packets sent to that router and associated with the particular PW. The Label Mapping message sent from R1/HC to R4/HD would have the following characteristics:
この時点では、R1 / HCまたはR4 / HDのどちらかはPWを設定するには、LDPラベルマッピングメッセージを送信することができます。特定のルータによって送信されたLabel Mappingメッセージは、ルータに送信し、特定のPWに関連付けられたすべてのパケットのMPLSラベルスタックの底部に使用されるべきラベルをアドバタイズ。 R4 / HDにR1 / HCから送られたLabel Mappingメッセージには、次のような特徴を持っているでしょう。
o FEC TLV - FEC Element type 0x80 (PWid FEC Element, as defined in [RFC4447] - Control Parameter bit = 1 (Control Parameter present) - PW type = 0x001B (ECRTP [RFC3545]) - Group ID as chosen by R1/HC - PW ID = the configured value for this PW, which must be the same as that sent in the Label Mapping message by R4/HD - Interface Parameter Sub-TLVs > Interface MTU sub-TLV (Type 0x01) > CRTP/ECRTP/IPHC HC over MPLS configuration sub-TLV (Type 0x0F) + Type = 2 (From RFC 3544) + Length = 16 + TCP_SPACE = Don't Care (leave at suggested value = 15) + NON_TCP_SPACE = 200 (configured on R1) + F_MAX_PERIOD = Don't Care (leave at suggested value = 256) + F_MAX_TIME = Don't Care (leave at suggested value = 5 seconds) + MAX_HEADER = 168 (Suggested Value) + Enhanced RTP-Compression Suboption & Type = 2 & Length = 2 o Label TLV - contains label selected by R1, Lr1 o No Optional Parameters
FECエレメント・タイプは0x80（PWID FEC要素、[RFC4447]で定義されるように - - R1 / HCによって選択され、グループID - 現在の制御パラメータビット= 1（制御パラメータ） - PWタイプ= 0x001B（ECRTP [RFC3545]）FEC TLV O - PWのID = R4 / HDによってLabel Mappingメッセージで送信されたものと同じである必要があり、このPWのために構成された値、 - インタフェースパラメータサブTLVの>インターフェイスMTUのサブTLV（タイプ0×01）> CRTP / ECRTP / IPHC MPLS設定サブTLV（タイプ0x0Fの）+タイプ= 2（RFC 3544から）+長さ= 16 + TCP_SPACEは=ドントケア（15 =推奨値で残す）+ NON_TCP_SPACE = 200（R1上で設定）+ F_MAX_PERIOD上HC = =ドント・ケア（256 =推奨値のままにしておきます）+ F_MAX_TIMEは=ドント・ケア（= 5秒推奨値のままにしておきます）+ MAX_HEADER = 168（推奨値）+強化されたRTP圧縮サブオプション＆タイプ= 2＆長2 OラベルTLV - オプションパラメータoをR1、Lr1とによって選択されたラベルが含まれています
The Label Mapping message sent from R4/HD to R1/HC would be almost identical to the one sent in the opposite direction, with the following exceptions:
R1 / HCにR4 / HDから送られたLabel Mappingメッセージは、次の例外を除いて、反対方向に送信されたものとほぼ同じになります：
o R4/HD could select a different Group ID o The Value of NON_TCP_SPACE in the CRTP/ECRTP/IPHC HC over MPLS configuration sub-TLV would be 255 instead of 200, as configured on R4/HD o R4/HD would choose its own value for the Label TLV, Lr4
O R4 / HDは、R4 / HD oをR4 / HDに設定されたとして、255の代わりに200になりMPLS設定サブTLV上CRTP / ECRTP / IPHC HCでNON_TCP_SPACEの価値oを異なるグループIDを選択することができ、独自のを選ぶだろうラベルTLV、LR4の値
As soon as either R1/HC or R4/HD has both transmitted and received Label Mapping Messages with the same PW Type and PW ID, that HC endpoint considers the PW established. R1/HC could send ECRTP packets using the label it received in the Label Mapping Message from R4/HD, Lr4, and could identify received ECRTP packets by the label it had sent to R4/HD, Lr1. And vice versa.
すぐにR1 / HCまたはR4のいずれか/ HDの両方HCエンドポイントは、PWを確立することを考えて、送信と同じPWタイプとPW IDとラベルマッピングメッセージを受信しました。 R1 / HCは、それがR4 / HD、LR4からラベルマッピングメッセージで受信したラベルを使用してECRTPパケットを送信することができ、そしてそれはR4 / HD、Lr1とに送られたラベルが受信したECRTPパケットを特定することができました。およびその逆。
In this case, assume that R1/HC has an IPv4 RTP flow to send to R4/HD that it wishes to compress using the ECRTP PW just set up. The RTP flow is G.729 media with 20 bytes of payload in each RTP packet. In this particular case, the IPv4 identifier changes by a small constant value between consecutive packets in the stream. In the RTP layer of the flow, the Contributing Source Identifiers count is 0. R1/HC decides to use 8-bit Context Identifiers for the compressed flow. Also, R1/HC determines that compression in this particular flow should be able to recover from the loss of 2 consecutive packets without requiring re-synchronization of the context (i.e., the "N" value from [RFC3545] is 2).
この場合、R1 / HCは、それだけで設定ECRTP PWを使用して圧縮したいR4 / HDに送信するIPv4のRTPの流れを持っていることを前提としています。 RTPフローは、各RTPパケット内のペイロードの20バイトのG.729媒体です。この特定のケースでは、IPv4の識別子は、ストリーム内の連続したパケット間の小さい一定値で変化します。流れのRTP層で、貢献ソース識別子のカウントが0 R1 / HCは、圧縮フローに対して8ビットコンテキスト識別子を使用することを決定します。また、R1 / HC（すなわち、[RFC3545]から「N」の値は2である）、この特定のフローの圧縮コンテキストの再同期を必要とせずに、2人の連続するパケットの損失から回復することができなければならないことを決定します。
The first 3 (N + 1) packets of this flow would be sent as FULL_HEADER packets. The MPLS and PW headers at the beginning of these packets would be formatted as follows:
このフローの第3（N + 1）パケットがFULL_HEADERパケットとして送信されます。次のようにこれらのパケットの先頭にMPLSおよびPWヘッダがフォーマットされます：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | Exp |S| TTL |
| XX | XX |0| XX |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | Exp |S| TTL |
| Lr4 | XX |1| >0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |Pkt Typ| Length |Res|
|0 0 0 0| 2 | 62 |0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
^
|
-- 2 == FULL_HEADER
where XX signifies either
a. value determined by the MPLS routing layer
b. don't care
Immediately following the above header would come the FULL_HEADER packet as defined in [RFC3545], which basically consists of the IP/UDP/RTP header, with the IP and UDP length field replaced by values encoding the CID, sequence number, and "generation", as defined in [RFC3545]. The length field value of 62 comprises:
[RFC3545]で定義されるように、直ちに上記ヘッダーを次するCIDをコード値に置き換えIPとUDP長フィールド、シーケンス番号、および「世代」で、基本的にIP / UDP / RTPヘッダで構成され、FULL_HEADERパケットが来ます[RFC3545]で定義されます。 62の長さフィールド値は：
o 2 bytes of HC control parameter (included in the above diagram) o 20 bytes of the IP header portion of the RFC 3545 FULL_HEADER o 8 bytes of the UDP header portion of the RFC 3545 FULL_HEADER o 12 bytes of the RTP header portion of the RFC 3545 FULL_HEADER o 20 bytes of G.729 payload
RFC 3545 FULL_HEADER oのIPヘッダ部の20バイトO（上記の図に含まれる）HC制御パラメータの2バイトOのRTPヘッダ部の12バイトO RFC 3545 FULL_HEADERのUDPヘッダ部の8つのバイトG.729ペイロードの20バイトO RFC 3545 FULL_HEADER
The next 3 RTP packets from this flow would be sent as COMPRESSED_UDP_8, to establish the absolute and delta values of the IPv4 identifier and RTP timestamp fields. These packets would use the same ECRTP CID as the previous 3 FULL_HEADER packets. The MPLS and PW headers at the beginning of these packets would be formatted as follows:
この流れから次の3つのRTPパケットは、IPv4の識別子及びRTPタイムスタンプフィールドの絶対値とデルタ値を確立するために、COMPRESSED_UDP_8として送信されることになります。これらのパケットは、前の3つのFULL_HEADERパケットと同じECRTPのCIDを使用します。次のようにこれらのパケットの先頭にMPLSおよびPWヘッダがフォーマットされます：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | Exp |S| TTL |
| XX | XX |0| XX |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | Exp |S| TTL |
| Lr4 | XX |1| >0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |Pkt Typ| Length |Res|
|0 0 0 0| 8 | 36 |0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
^
|
-- 8 == COMPRESSED_UDP_8
There is no change in the MPLS label stack between the FULL_HEADER packets and the COMPRESSED_UDP packets. The HC control parameter changes to reflect another ECRTP packet type following the control parameter, and a change of packet length. The length changes because the new packet type more compactly encodes the headers. The length field value of 36 comprises: o 2 bytes of HC control parameter (included in the above diagram) o 1 byte of CID o 2 bytes of COMPRESSED_UDP fields that are not octet-aligned: - 4 bits of COMPRESSED_UDP flags - 4 bits of sequence number - 5 bits of COMPRESSED UDP extension flags - 3 bits MUST_BE_ZERO o 2 bytes of UDP checksum or HDRCKSUM o 1 byte of delta IPv4 ID o 2 bytes of delta RTP timestamp (changes by 160 in this case, differential encoding will encode as 2 bytes) o 2 bytes of absolute IPv4 ID o 4 bytes of absolute RTP timestamp o 20 bytes of G.729 payload
FULL_HEADERパケットとCOMPRESSED_UDPパケット間のMPLSラベルスタックに変更はありません。 HC制御パラメータの変更は、制御パラメータ次の別のECRTPパケットタイプ、およびパケット長の変化を反映します。新しいパケットタイプは、よりコンパクトヘッダを符号化するため、長さが変化します。 36の長さフィールド値は、前記オクテット整列されていないCOMPRESSED_UDPフィールドの2バイトO CIDの1バイトO（上記の図に含まれる）HC制御パラメータの2バイト（O） - COMPRESSED_UDPフラグの4ビット - の4ビットシーケンス番号 - COMPRESSED UDP拡張フラグの5ビット - 3ビットMUST_BE_ZERO UDPチェックサムまたはHDRCKSUMデルタRTPタイムスタンプの2バイトOデルタIPv4のIDの1バイトOの2バイトO（この場合160による変化は、差分符号化は、2としてエンコードしますG.729ペイロードの20バイトO絶対RTPタイムスタンプの4バイトO絶対IPv4のIDの2バイトOバイト）
After the context for the IPv4 ID and RTP timestamp is initialized. Subsequent packets on this flow, at least until the end of the talk spurt or until there is some other unexpected change in the IP/UDP/RTP headers, may be sent as COMPRESSED_RTP_8 packets. Again, the same MPLS stack would be used for these packets, and the same value of the CID would be used in this case as for the packets described above. The MPLS and PW headers at the beginning of these packets would be formatted as follows:
IPv4のIDとRTPタイムスタンプのためのコンテキストが初期化された後。このフローの後続のパケットは、少なくともトークスパートの終わりまで、またはIP / UDP / RTPヘッダ内の他の予期しない変更があるまで、COMPRESSED_RTP_8パケットとして送信することができます。再度、同一のMPLSスタックがこれらのパケットのために使用される、およびCIDの同じ値は、上記パケットのように、この場合に使用されるであろう。次のようにこれらのパケットの先頭にMPLSおよびPWヘッダがフォーマットされます：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | Exp |S| TTL |
| XX | XX |0| XX |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | Exp |S| TTL |
| Lr4 | XX |1| >0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |Pkt Typ| Length |Res|
|0 0 0 0| 6 | 26 |0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
^
|
-- 6 == COMPRESSED_RTP_8
The HC control parameter again changes to reflect another ECRTP packet type following the control parameter, and shorter length associated with an even more compact encoding of headers. The length field value of 26 comprises: o 2 bytes of HC control parameter (included in the above diagram) o 1 byte of CID o 1 byte COMPRESSED_UDP fields that are not octet-aligned: - 4 bits of COMPRESSED_RTP flags - 4 bits of sequence number o 2 bytes of UDP checksum or HDRCKSUM o 20 bytes of G.729 payload
HC制御パラメータは、再度ヘッダーの一層コンパクトな符号化に関連する別のECRTPパケット制御パラメータ以下のタイプ、およびより短い長さを反映するように変更します。 26の長さフィールド値は、前記整列オクテットされていないCID 0 1バイトCOMPRESSED_UDPフィールドの1バイトO（上記の図に含まれる）HC制御パラメータの2バイト（O） - COMPRESSED_RTPフラグの4ビット - シーケンスの4ビットG.729ペイロードの20バイトO UDPチェックサムまたはHDRCKSUMの2バイトO数
Additional flows in the same direction may be compressed using the same basic encapsulation, including the same PW label. The CID that is part of the HC protocol is used to differentiate flows. For traffic in the opposite direction, the primary change would be the PW label, Lr4, used in the example above would be replaced by the label Lr1 that R1/HC provides to R4/HD.
同じ方向に追加のフローが同じPWラベルを含む、同じ基本的なカプセル化を用いて圧縮することができます。 HCプロトコルの一部であるCIDはフローを区別するために使用されます。逆方向のトラフィックのために、主な変更は、上記の例で使用されるPWラベル、LR4は、R1 / HCは、R4 / HDに提供Lr1とそのラベルによって置き換えられるであろう。
MPLS PW security considerations in general are discussed in [RFC3985] and [RFC4447], and those considerations also apply to this document. This document specifies an encapsulation and not the protocols that may be used to carry the encapsulated packets across the PSN, or the protocols being encapsulated. Each such protocol may have its own set of security issues, but those issues are not affected by the encapsulations specified herein.
一般的にはMPLS PWのセキュリティの考慮事項は、[RFC3985]と[RFC4447]で議論されており、これらの考慮事項はまた、この文書に適用されます。この文書では、カプセル化を指定し、PSN横切っカプセル化されたパケット、またはプロトコルを運ぶために使用され得るプロトコルは、カプセル化されていません。各そのようなプロトコルは、セキュリティ上の問題の独自のセットを持っている可能性がありますが、これらの問題は、ここで指定されたカプセル化の影響を受けません。
The security considerations of the supported HC protocols [RFC2507, RFC2508, RFC3095, RFC3095bis, RFC3545] all apply to this document as well.
サポートHCプロトコル[RFC2507、RFC2508、RFC3095、RFC3095bis、RFC3545]すべてのセキュリティ上の考慮事項は、同様に、この文書に適用されます。
The authors appreciate valuable inputs and suggestions from Loa Andersson, Scott Brim, Stewart Bryant, Spencer Dawkins, Adrian Farrel, Victoria Fineberg, Eric Gray, Allison Mankin, Luca Martini, Colin Perkins, Kristofer Sandlund, Yaakov Stein, George Swallow, Mark Townsley, Curtis Villamizar, and Magnus Westerlund.
著者は、ロア・アンダーソン、スコット・ブリム、スチュワートブライアント、スペンサードーキンス、エードリアンファレル、ビクトリアFineberg、エリックグレー、アリソンマンキン、ルカ・マルティーニ、コリンパーキンス、クリストファーSandlund、Yaakovのスタイン、ジョージくん、マークTownsleyからの貴重な入力と提案に感謝しますカーティスVillamizar、およびマグヌスウェスター。
As discussed in Section 4.1, PW type values have been assigned by IANA, as follows:
セクション4.1で議論するように、以下のように、PWタイプ値は、IANAによって割り当てられています：
0x001A ROHC Transport Header-compressed Packets [RFC3095bis] 0x001B ECRTP Transport Header-compressed Packets [RFC3545] 0x001C IPHC Transport Header-compressed Packets [RFC2507] 0x001D CRTP Transport Header-compressed Packets [RFC2508]
0x001A ROHCトランスポートヘッダ圧縮パケット[RFC3095bis] 0x001B ECRTPトランスポートヘッダ圧縮パケット[RFC3545] 0x001C IPHCトランスポートヘッダ圧縮パケット[RFC2507] 0x001D CRTPトランスポートヘッダ圧縮パケット[RFC2508]
Procedures for registering new PW type values are given in [RFC4446].
新しいPW型の値を登録するための手順は、[RFC4446]に記載されています。
As discussed in Section 4.2, Pseudowire Interface Parameter Sub-TLV type values have been specified by IANA, as follows:
セクション4.2で議論するように、以下のように、擬似回線インタフェースパラメータサブTLVのタイプ値は、IANAによって指定されています。
Parameter ID Length Description Reference
--------- --------------- ---------------------------- ---------
0x0D up to 256 bytes ROHC over MPLS configuration RFC 4901
RFC 3241
0x0F up to 256 bytes CRTP/ECRTP/IPHC HC over MPLS RFC 4901
configuration RFC 3544
As discussed in Section 4.3, IANA has defined a new registry, "Header Compression Over MPLS HC Control Parameter Packet Type". This is a four-bit value. Packet Types 0 through 10 are defined in Section 4.3 of this document. Packet Types 11 to 15 are to be assigned by IANA using the "Expert Review" policy defined in [RFC2434].
4.3節で述べたように、IANAは、新しいレジストリ、「ヘッダ圧縮オーバーMPLS HC制御パラメータパケットタイプ」を定義しています。これは、4ビットの値です。パケットタイプは、0〜10は、このドキュメントのセクション4.3で定義されています。パケットタイプ11から15は、[RFC2434]で定義された「エキスパートレビュー」ポリシーを使用してIANAによって割り当てられるべきです。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、RFC 2119、1997年3月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031]ローゼン、E.、Viswanathanの、A.、およびR. Callon、 "マルチプロトコルラベルスイッチングアーキテクチャ"、RFC 3031、2001年1月。
[RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and B. Thomas, "LDP Specification", RFC 3036, January 2001.
[RFC3036]アンデション、L.、Doolan、P.、フェルドマン、N.、Fredette、A.、およびB.トーマス、 "LDP仕様"、RFC 3036、2001年1月。
[RFC3241] Bormann, C., "Robust Header Compression (ROHC) over PPP", RFC 3241, April 2002.
[RFC3241]ボルマン、C.、 "PPPオーバーロバストヘッダ圧縮（ROHC）"、RFC 3241、2002年4月。
[RFC3544] Engan, M., Casner, S., Bormann, C., and T. Koren, "IP Header Compression over PPP", RFC 3544, July 2003.
[RFC3544] Engan、M.、Casner、S.、ボルマン、C.、およびT.コレン、 "PPP上のIPヘッダー圧縮"、RFC 3544、2003年7月。
[RFC4447] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC 4447, April 2006.
[RFC4447]、RFC 4447マティーニ、L.、エド。、ローゼン、E.、エルAawar、N.、スミス、T.、およびG.サギ、 "ラベル配布プロトコル（LDP）を使用して疑似回線の設定とメンテナンス" 、2006年4月。
[ECMP-AVOID] Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal Cost Multipath Treatment in MPLS Networks", Work in Progress, February 2007.
[ECMP-AVOID]ツバメ、G.、ブライアント、S.、およびL.アンダーソン、 "MPLSネットワークにおけるイコールコストマルチパス治療の回避"、進歩、2007年2月での作業。
[REORDER-EVAL] Knutsson, C., "Evaluation and Implementation of Header Compression Algorithm ECRTP", http://epubl.luth.se/ 1402-1617/2004/286/LTU-EX-04286-SE.pdf.
[REORDER-EVAL] Knutsson、C.、 "評価とヘッダ圧縮アルゴリズムECRTPの実装"、http://epubl.luth.se/ 1402-1617 / 2004/286 / LTU-EX-04286-SE.pdf。
[RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol (IPCP)", RFC 1332, May 1992.
[RFC1332]マクレガー、G.、 "PPPインターネットプロトコル制御プロトコル（IPCP）"、RFC 1332、1992年5月。
[RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[RFC1661]シンプソン、W.、編、 "ポイントツーポイントプロトコル（PPP）"、STD 51、RFC 1661、1994年7月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 2434、1998年10月。
[RFC2472] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC 2472, December 1998.
[RFC2472] Haskin、D.およびE.アレン、 "PPPオーバーIPバージョン6"、RFC 2472、1998年12月。
[RFC2507] Degermark, M., Nordgren, B., and S. Pink, "IP Header Compression", RFC 2507, February 1999.
[RFC2507] Degermark、M.、Nordgren、B.、およびS.ピンク、 "IPヘッダー圧縮"、RFC 2507、1999年2月。
[RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", RFC 2508, February 1999.
[RFC2508] Casner、S.とV. Jacobson氏、 "低速シリアルリンクのIP / UDP / RTPヘッダの圧縮"、RFC 2508、1999年2月。
[RFC3095] Bormann, C., et al., "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001.
[RFC3095]ボルマン、C.ら、 "ロバストヘッダ圧縮（ROHC）：フレームワークおよび4つのプロファイル：RTP、UDP、ESP、および非圧縮"、RFC 3095、2001年7月。
[RFC3095bis] Jonsson, L-E. Pelletier, G., and K. Sandlund, "The RObust Header Compression (ROHC) Framework", Work in Progress, November 2006.
【RFC3095bis]ジョンソン、L-E。ペルティエ、G.、およびK. Sandlund、 "ロバストヘッダ圧縮（ROHC）フレームワーク"、進歩、2006年11月に作業。
[RFC3209] Awduche, D., et al., "RSVP-TE: Extensions to RSVP for LSP Tunnels," RFC 3209, December 2001.
[RFC3209] Awduche、D.、ら、 "RSVP-TE：ExtensionsはLSPトンネルのためのRSVPする"。RFC 3209、2001年12月。
[RFC3544] Koren, T., et al., "IP Header Compression over PPP," RFC 3544, July 2003.
[RFC3544]コレン、T.、ら、 "PPP上のIPヘッダー圧縮、" RFC 3544、2003年7月。
[RFC3545] Koren, T., et al., "Compressing IP/UDP/RTP Headers on Links with High Delay, Packet Loss, and Reordering," RFC 3545, July 2003.
[RFC3545]コレン、T.、ら、RFC 3545、2003年7月 "高遅延、パケット損失、および並べ替え、とのリンクの上にIP / UDP / RTPヘッダの圧縮"。
[RFC3246] Davie, B., et al., "An Expedited Forwarding PHB (Per-Hop Behavior)," RFC 3246, March 2002.
[RFC3246]デイビー、B.、ら、 "緊急転送PHB（ホップ単位動作）、" RFC 3246、2002年月。
[RFC3270] Le Faucheur, F., et al., "Multi-Protocol Label Switching (MPLS) Support of Differentiated Services," RFC 3270, May 2002.
[RFC3270]ルFaucheur、F.、ら、 "マルチプロトコルラベルスイッチング差別化サービスの（MPLS）のサポート、" RFC 3270、2002年5月。
[RFC3550] Schulzrinne, H., et al., "RTP: A Transport Protocol for Real-Time Applications," RFC 3550, July 2003.
[RFC3550] Schulzrinneと、H.、ら、 "RTP：リアルタイムアプリケーションのためのトランスポートプロトコル、"。RFC 3550、2003年7月。
[RFC3843] Jonsson, L-E. and G. Pelletier, "RObust Header Compression (ROHC): A Compression Profile for IP", RFC 3843, June 2004.
[RFC3843]ジョンソン、L-E。そして、G.ペルティエ、 "ロバストヘッダ圧縮（ROHC）：IPの圧縮プロファイル"、RFC 3843、2004年6月。
[RFC3985] Bryant, S., Pate, P., "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture," RFC 3985, March 2005.
[RFC3985]ブライアント、S.、パテ、P.、 "疑似ワイヤーエミュレーションエッジツーエッジ（PWE3）アーキテクチャ、" RFC 3985、2005年3月。
[RFC4224] Pelletier, G., et al., "RObust Header Compression (ROHC): ROHC over Channels that can Reorder Packets," RFC 4224, January 2006.
[RFC4224]らペルティエ、G.、 "ロバストヘッダ圧縮（ROHC）：パケットの順序を変更することができますチャンネル以上のROHC、"。RFC 4224、2006年1月。
[RFC4247] Ash, G., Goode, B., Hand, J., "Requirements for Header Compression over MPLS", RFC 4247, November 2005.
[RFC4247]アッシュ、G.、グッド、B.、手、J.、 "MPLSオーバーヘッダー圧縮のための要件"、RFC 4247、2005年11月。
[RFC4364] Rosen, E., Rekhter, Y., "BGP/MPLS IP Virtual Private Networks (VPN)s", RFC 4364, February 2006.
[RFC4364]ローゼン、E.、Rekhter、Y.、 "BGP / MPLS IP仮想プライベートネットワーク（VPN）S"、RFC 4364、2006年2月。
[RFC4385] Bryant, S., et al., "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN," RFC 4385, February 2006.
[RFC4385]ブライアント、S.、ら、 "MPLS PSN上擬似回線エミュレーションエッジ・ツー・エッジ（PWE3）使用するための制御ワード、" RFC 4385、2006年2月。
[RFC4446] Martini, L., et al., "IANA Allocations for Pseudo Wire Edge To Edge Emulation (PWE3)," RFC 4446, April 2006.
[RFC4446]マティーニ、L.は、ら、RFC 4446、2006年4月 "疑似ワイヤーエッジのためのIANA配分は、エミュレーション（PWE3）をEdgeに"。
[RFC4815] Jonsson, L-E., Sandlund, K., Pelletier, G., and P. Kremer, "RObust Header Compression (ROHC): Corrections and Clarifications to RFC 3095", RFC 4815, February 2007.
[RFC4815]ヨンソン、L-E、Sandlund、K.、ペルティエ、G.、およびP.クレーメル、 "ロバストヘッダ圧縮（ROHC）：RFC 3095の訂正と明確化"、RFC 4815、2007年2月。
Besides the editors listed below, the following people contributed to the document:
下記に記載されている編集者のほかに、次の人が文書に貢献しました。
Bur Goode AT&T Phone: +1 203-341-8705 EMail: bgoode@att.com
バール・グッドAT＆T電話：+1 203-341-8705電子メール：bgoode@att.com
Lars-Erik Jonsson Optand 737 SE-831 92 Ostersund, Sweden Phone: +46 70 365 20 58 EMail: lars-erik@lejonsson.com
選択ラース・エリックジョンソンSE-831 92 737エステルスンド、スウェーデン電話：+46 70 365 8時58分、午後電子メール：lars-erik@lejonsson.com
Raymond Zhang Infonet Services Corporation 2160 E. Grand Ave. El Segundo, CA 90025 USA EMail: zhangr@bt.infonet.com
レイモンド・チャンインフォネット・サービス株式会社2160 E.グランドアベニューエル・セグンド、CA 90025 USA電子メール：zhangr@bt.infonet.com
Editors' Addresses
エディタのアドレス
Jerry Ash AT&T Email: gash5107@yahoo.com
ジェリー・アッシュAT＆T Eメール：gash5107@yahoo.com
Jim Hand AT&T Room MT A2-1A03 200 Laurel Avenue Middletown, NJ 07748, USA Phone: +1 732-420-3017 EMail: jameshand@att.com
ジム・ハンドAT＆TルームMT A2-1A03 200ローレルアベニューミドルタウン、NJ 07748、USA電話：+1 732-420-3017電子メール：jameshand@att.com
Andrew G. Malis Verizon Communications 40 Sylvan Road Waltham, MA 02451 USA EMail: andrew.g.malis@verizon.com
アンドリューG. Malisベライゾン・コミュニケーションズ40シルバンロードウォルサム、MA 02451 USA電子メール：andrew.g.malis@verizon.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
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.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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は、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
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リポジトリから。
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機能のための基金は現在、インターネット協会によって提供されます。