[要約] RFC 4901は、MPLS上でのヘッダ圧縮のためのプロトコル拡張に関するものであり、MPLSネットワークでのパフォーマンス向上を目指しています。
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
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）The IETF Trust（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）を使用して、MPLSラベルスイッチ付きパス上にヘッダー圧縮（HC）パケットをルーティングする方法を定義します。HCは、パケットヘッダーのオーバーヘッドを大幅に削減でき、MPLと組み合わせて、各ルーターでHCを使用する同時圧縮フローの最大数の観点から、帯域幅の効率と処理スケーラビリティを増加させることもできます。ここでは、MPLS PSEUDOWIREがHCコンテキストを輸送し、イングレスと出口のMPLSラベルスイッチングルーターの間でメッセージを輸送する方法を定義します。これは、たとえば、音声オーバー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.
Voice over IP（VoIP）は通常、カプセル化音声/RTP/UDP/IPを使用します。MPLSラベル[RFC3031]が追加されると、これはVoice/RTP/UDP/IP/MPLS-Labelsになります。MPLS VPN（例：[RFC4364]）はラベルスタッキングを使用し、IPv4の最も単純なケースでは、合計パケットヘッダーは少なくとも48バイトですが、音声ペイロードはたとえば30バイト以下です。IPv6を使用すると、ペイロードと比較したヘッダーの相対サイズがさらに大きくなります。ヘッダー圧縮（HC）への関心は、強化された圧縮RTP（ECRTP）[RFC3545]や堅牢なヘッダー圧縮（RHC）[RFC3095、RFC3095BIS、RFC4815]など、さまざまな圧縮メカニズムを介してオーバーヘッドを大幅に削減する可能性を活用することです。また、HCのスケーラビリティを向上させるため。MPLSは、各ルーターで圧縮/減圧サイクルなしでMPLSラベルスイッチ付きパス（LSP）にHCパケットをルーティングするために使用されます。このようなHCオーバーMPLS機能は、各ルーターでHCを使用する同時圧縮フローの最大数の処理スケーラビリティと同様に、帯域幅の効率を高める可能性があります。MPLを超えるHCの目標と要件については、[RFC4247]で説明しています。このドキュメントに記載されているMPLS Pseudowire（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ヘッダー圧縮の対象となるフローに関連する状態。コンテキストの正確な性質は特定のHCプロトコル（CRTP、ECRTP、ROHCなど）に固有ですが、この状態には通常以下が含まれます。
- 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などの一部のフィールドの値の変更。フローの過去2つの連続した送信パケット（コンプレッサー）または受信パケット（減圧器）の間のヘッダー。ヘッダー内のフィールドの一部は、ほとんどの場合、フロー内の後続のパケット間で一定の量だけ変化します。これらのフィールドの変化をパケットからパケットまで保存することで、一定の変化率が起こっていることを確認し、通常の変更からの逸脱に遭遇した場合に適切なアクションを実行できます。
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].
強化された圧縮リアルタイムプロトコル（ECRTP）：[RFC3545]で説明されている特定のHCプロトコル。
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とそれに関連するプロトコルを実行する特定の方法。堅牢なヘッダー圧縮（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 PWは双方向であるため、PWの単方向脚が各方向に設置されています。双方向PWの片方の脚は、ヘッダー圧縮トラフィックではなく、圧縮フィードバックのみを搭載するように設定できます。HCチャネルは、単一のコンテキストIDを使用して圧縮される可能性のある個々のトラフィックフローと混同しないでください。各HCチャネルは、一意のCIDのセットを管理します。
IP Header Compression (IPHC): a particular HC protocol described in [RFC2507] Label: a short fixed length physically contiguous identifier that is used to identify a FEC, usually of local significance
IPヘッダー圧縮（IPHC）：[RFC2507]ラベルに記載されている特定のHCプロトコルラベル：通常、局所的に重要な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
ラベルスイッチングルーター（LSR）：ネイティブL3パケットを転送できるMPLSノード
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ルーティングと転送を操作し、1つのルーティングまたは管理ドメインにあるノードの連続的なセットセット
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ノードは、MPLS制御プロトコルを認識し、1つ以上のL3ルーティングプロトコルを操作し、ラベルに基づいてパケットを転送できます。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）：Pseudowire 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
Pseudowire（PW）：1つのプロバイダーエッジルーターからPSN上の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
PSEUDOWIREエミュレーションエッジツーエッジ（PWE3）：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 PSN Tunnel: a tunnel across a PSN, inside which one or more PWs can be carried
PSEUDOWIRE PDU（PW-PDU）：PDUがPWに送信されたPDUは、目的のサービス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 Demultiplexer：プロバイダーエッジルーターで終了する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）：フレームワーク[RFC3095BIS]とさまざまなプロトコルの多くのプロファイル、たとえば、RTP、UDP、ESP [RFC3095]、およびIP [RFC3843]で構成される特定の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.
MPLSにHCを実装するには、IngressルーターがHCアルゴリズムをIPパケットに適用した後、圧縮パケットがMPLSラベルを使用してMPLS LSPに転送され、Engressルーターが非圧縮ヘッダーを復元します。多くのHCアルゴリズム/プロトコルを使用できます。これらのアルゴリズムは、通常、単一のポイントツーポイントリンク層ホップで動作するために設計されています。MPLS PWS [RFC3985]は、多くのポイントツーポイントリンクレイヤーサービス（フレームリレー永久仮想回路（PVC）やATM PVCなど）のエミュレーションを提供するために使用されます。-PoineリンクレイヤーホップHCトラフィックが輸送される可能性があります。
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.
図1は、R1/HC - > R2-> R3-> R4/HDからいくつかのLSRを通過するLSPに確立されたHC上のMPLSチャネルを示しています。ここで、R1/HCはHCを実行するイングレスルーター、R4/HDは、ヘッダー減圧（HD）を実行する出力ルーターです。この例では、圧縮されているパケットフローにRTP/UDP/IPヘッダーがあり、ROHC、CRTP、ECRTPなどのHCスキームを使用していることを前提としています。RTP/UDP/IPヘッダーの圧縮はR1/HCで実行され、圧縮パケットは、R1/HCからR2、最後にR4/HDへのMPLSラベルを使用してルーティングされます。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
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はデータ/RTP/UDP/IP/MPLSラベルの代わりにデータ/圧縮ヘッダー/MPLSラベルを輸送し、多くの場合、90％以上を節約します。RTP/UDP/IPオーバーヘッド。通常、2つの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は、ほとんどのパケットでIP/UDP/RTPヘッダーを2〜4バイトに減らします。ヘッダーサイズの減少の半分は、IP/UDP/RTPヘッダーのバイトの半分が流れの寿命にわたって一定のままであるという観察から来ています。非圧縮ヘッダーテンプレートを1回送信した後、これらのフィールドは、次の圧縮ヘッダーから削除される場合があります。残りの圧縮は、すべてのパケットでいくつかのフィールドが変化しますが、パケットからパケットまでの差はしばしば一定または少なくとも限られているため、2次の差はゼロであるという観察結果から来ています。
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スキーム間で異なる場合があります。コンプレッサーのコンテキストには、通常、フローで送信された最後のパケットの非圧縮ヘッダー、および最後のパケット送信されたパケットとその直前に送信されるパケットの間の選択されたヘッダーフィールド値の違いの何らかの尺度が含まれます。Decompressorのコンテキストには、受信パケットに関する同様の情報が含まれます。この情報を使用すると、ワイヤー全体で伝達する必要があるのは、パケットがどのフロー（CID）に関連付けられているかを示し、パケット間の2次の違い（つまり、差異を予測するのが難しい）のコンパクトなエンコードがあることを示しています。
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 PWS [RFC3985]を使用して、HCパケットを入力と出口MPLS LSRの間で輸送します。各PWは、コンプレッサーと減圧器の間の論理的なポイントツーポイントリンクのように機能します。各PWは、HCスキーム操作の観点から見ると、単一のPPPリンクまたは単一のフレームリレーPVCに似ている単一のHCチャネルをサポートします。この一般的なモデルの1つの例外は、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 PWSを使用すると、コンプレッサーはスタックの下部にラベルを追加し、decompressorはこのラベルを削除します。コンプレッサーと減圧器の間にLSRは、このラベルを検査または変更しません。スタック内のより高いラベルは、パケットスイッチネットワーク（PSN）ラベルと呼ばれ、[RFC3031]で説明されているように、MPLSネットワークを介してパケットを転送するために使用されます。減圧器は、適切な減圧コンテキストを見つけるために、着信MPLS PWラベル（スタックの下部にあるラベル）とCIDを使用します。標準のHCメソッド（ECRTP、ROHCなど）を使用して、コンテキストを決定します。CIDは通常どおりHCによって割り当てられ、異なる圧縮チャネルをサポートする異なるPWSに対してHDで重複したCIDを受信しても問題ありません。たとえば、2つの異なるコンプレッサー、HCAとHCBが両方とも同じCIDを減圧器HDCに導く2つの個別のフローのそれぞれに割り当てた場合、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ラベルに加えて、HCオーバーMPLSパケットもHCコントロールパラメーターを搭載しています。HCコントロールパラメーターには、パケットタイプフィールドとパケット長の両方のフィールドの両方が含まれています。この仕様でサポートされている各HCスキームは、たとえば「フルヘッダー」パケットを定義しているため、パケットタイプのフィールドが必要です。たとえば、コンプレッサーと減圧装置のコンテキストを初期化および/または再同期させるために使用される「フルヘッダー」パケット、対通常のHCパケット。また、ほとんどのHCスキームでは、基礎となるリンクレイヤープロトコルがパケットタイプ間の差別化を提供する必要があります。同様に、ほとんどのHCスキームの一部である仮定の1つは、IPデータグラムの長さを暗黙的に決定できるため、RTP/UDP/IPなどのパケット長フィールドをネットワーク全体に明示的に送信する必要はないということです。下層から。この仕様では、1つの例外を除き、HC IPデータグラムの長さは、MPLSネットワークを介して送信されるパケットのリンクレイヤーから決定できることを前提としています。例外は、イーサネットリンクを通過するパケットの場合です。イーサネットでは、ペイロードサイズの長さが46バイト未満のパケットのパディングが必要です。したがって、HC制御パラメーターには6ビットの長さフィールドが含まれており、長さ64バイト未満のHCパケットの長さをエンコードします。
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 PWは、PWシグナル伝達プロトコル[RFC4447]によって設定されます。[RFC4447]は、MPLSラベル分布プロトコル（LDP）[RFC3036]の拡張セットを実際に定義します。[RFC4447]で定義されているように、PWSをセットアップ、解体、および管理するためのLDPシグナル伝達は、PWエンドポイント、この場合はコンプレッサーと減圧器の間で直接実行されます。PWシグナル伝達は、スタックの下部にPWラベルをセットアップするためにのみ使用され、PSNラベルのセットアップに使用できる他のシグナルとは独立して使用されます。したがって、たとえば、図1では、LDP PWシグナル伝達がR1/HCとR4/HDの間で直接実行されます。Router 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]は、PPPでROHCが使用される方法を指定し、[RFC3544]は、PPPで他のいくつかのHCスキーム（CRTP、ECRTP、IPHC）がどのように使用されるかを指定します。これらのRFCはどちらも、PPPを介してHCを交渉するための構成オプションを提供します。これらの構成オプションの形式は、PWSでHCをセットアップするためにここで再利用されます。PPP環境で使用する場合、これらの構成オプションは、[RFC1661]で説明されているPPPのIPコントロールプロトコル[RFC1332]および詳細なPPPオプションネゴシエーションプロセスの拡張として使用されます。これは、PPPリンクが複数のプロトコルをサポートしているため、それぞれが独自のアドレス指定スキームとオプションをサポートする可能性があるためです。相互運用性を達成するには、リンクの各端のノードが両方ともサポートする一連のプロトコルとオプションに同意できるように、交渉プロセスが必要です。ただし、単一のHC PWは、単一のHCスキームを使用してHCトラフィックのみをサポートします。したがって、[RFC3241]と[RFC3544]の構成オプションの形式はここで再利用されますが、詳細なPPP交渉プロセスはそうではありません。代わりに、これらのオプションは、HC PWの基本パラメーターの記述子（LDPおよび[RFC4447]の特定の用語のTLV）と同様にここで再利用されます。これらのパラメーターについては、セクション4でさらに説明します。HC構成パラメーターは、最初は減圧装置によって生成され、decompressorが受信するものを説明します。
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]の基本的なシグナル伝達プロセスは、単方向PWSを設定し、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.
図1は、R1/HC-> R2-> R3-> R4/HDから設定されたデータフローの例を示しています。ここで、R1/HCはヘッダー圧縮が実行されるイングレスルーター、R4/HDは出力ルーターですヘッダー減圧が行われる場所。各ルーターはLSRとして機能し、LSP/PWSのシグナル伝達をサポートします。図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フローごとに圧縮性のないパケットが発生します。この種の問題が発生するもう1つの方法は、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：Pseudowire Protocol Stack Reference Model
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ラベルを割り当てるのではなく、多くのHCフロー（100または1000になる可能性があります）に使用する必要があります。後者のアプローチには、PWラベルの割り当ての複雑なメカニズムが含まれ、フローが終了した後のラベルの解放など、潜在的に1000の同時HCフローのために。一方、CID割り当てのメカニズム、解放などが整っており、個々のHCフローのPW割り当て/deassignmentでそれを複製する必要はありません。
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.
さまざまな圧縮ストリームに異なるサービス品質（QOS）要件が必要な場合に備えて、複数のPWを確立する必要があります。フローで受信したQoSは、PWラベルのEXPビットマーキングによって決定されます。通常、すべてのRTPパケットは、Diffservで迅速な転送（EF）治療[RFC3246]に相当する同じ経験[RFC3270]を取得します。ただし、このドキュメントで指定されたプロトコルは、RTPストリームだけでなく、いくつかの異なるタイプのストリームに適用され、EF以外のQOS処理が必要になる場合があります。
Figure 3 shows the HC over MPLS protocol stack (with uncompressed header): 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)
図3は、MPLS（圧縮されていないヘッダー付き）を超えるHCを示しています：メディアストリーム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スキームのパケットタイプを識別する必要があります。MPLSラベルは、PW識別子とMPLSトンネル識別子の2つのレイヤーを技術的に定義します。PWラベルは、HDによってDemultiplexerフィールドとして使用する必要があります。ここでは、MPLSラベルスタックの下部ラベルにPWラベルが表示されます。減圧を実行するLSRは、チャネルのためにそれが配布するラベル（例えば、LDP経由）が一意であることを保証する必要があります。たとえば、MPLS VPNを識別するために、他のMPLSラベルもあります。図3に示すように、IP/UDP/RTPヘッダーは送信前に圧縮され、スタックの残りの部分を単独で放置します。
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.
HC-HDエンドポイントによって交換された[RFC4447]制御メッセージを使用して、メディアストリームの輸送のためにPWSを事前にセットアップする必要があります。さらに、PWタイプを使用して、PWで使用されているHCスキームを示す必要があります。[RFC4447]は、PWSを設定および維持するためのMPLSラベル分布プロトコル（LDP）[RFC3036]拡張を指定し、PWSの属性を識別および信号する新しい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ラベルを割り当てて配布するには、[RFC3036]で説明されている拡張発見メカニズムを使用して、PWエンドポイント間にLDPセッションを設定する必要があります。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 PWSを識別するために、FECオブジェクト内で運ばれる新しいPWタイプの値を定義します。PWタイプは、[RFC4446]レジストリで指定されているように、IANAによって割り当てられた15ビットパラメーターであり、PWで使用されているHCスキームを示すために使用する必要があります。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スキームパラメーターが信号を送信した場合、HCトラフィックを運ぶPWの一方向の脚でインターフェイスパラメーターサブTLVを使用する必要があります。圧縮フィードバックのみを搭載する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アプローチは、PW/MPLSレイヤーに依存して、HCチャネル構成情報を伝達します。インターフェイスパラメーターSub-TLV [IANA、RFC4447]を使用して、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:
PseudowireインターフェイスパラメーターSub-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インターフェイスパラメーターSub-TLVにカプセル化され、それぞれのプロトコルのヘッダー圧縮セッションのセットアップとパラメーターネゴシエーションをネゴシエートするために使用する必要があります。この方法でサポートされているTLVには、次のものを含める必要があります。o[RFC3544]で指定されているように、o構成オプション形式、RTP圧縮サブオプション、RTP圧縮サブオプション、TCP/非TCP圧縮サブオプション、
o Configuration Option Format, PROFILES Suboption, as specified in [RFC3241]
o [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-Compression-Protocol 0061（六角）
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でなければならず、最大255である必要があります（値0は1つのコンテキストを持つことを意味します）。このフィールドは、CRTP（PWタイプ0x001b）およびECRTP（PWタイプ0x001b）PWSには使用されません。これらの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でなければならず、最大65535では（値0は1つのコンテキストを持つことを意味します）。
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）PWSには使用されません。これらの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）PWSには使用されません。これらの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.
RTP-Compressionサブオプションは、IP/UDP/RTP圧縮を有効にする場合、IPHCのNCP IP-Compression-Protocolオプションに含まれています。このサブオプションは、CRTP PWS（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-Compression Suboptionを含めることで、[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]で指定されているように、Protocol Identifiersの使用を有効にします。
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が追加されます。Suboption 2は、Suboption 1に加えてではなく、代わりにネゴシエートされます。このサブオプションはECRTP PWS（0x001B）に含める必要があり、他の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].
Suboption 1は、セクション4.2.2で指定されているRTP圧縮サブオプションを指し、Suboption 2はセクション4.2.3で指定されている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]で指定されているように、Protocol Identifiersの使用を有効にします。さらに、[RFC3545]のコンプライアンス圧縮を使用して、追加のフラグを備えたプロトコル識別子Compressed_udpの使用を含み、full_headerプロトコル識別子を使用してCフラグを使用して、Compressed_rtpおよびCompressed_udpパケットでHDRCKSUMを使用することを示すことができます。
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
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 HCまたは非TCP HCのみを交渉することはできませんでした。これは、TCP_SPACEまたはNON_TCP_SPACEフィールドの0の値が実際に1コンテキストがネゴシエートされることを意味するためです。
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 PWS（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-Compression-Protocol 0003（六角）
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でなければならず、最大16383（値0は1つのコンテキストを持つことを意味します）。
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のほとんどの初期実装は、プロファイル0x0000〜0x0003を実装しています。このオプションは提供する必要があります。
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:
HC制御パラメーターは、図4に示すように、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 11-15: Not yet assigned. (See Section 8, "IANA Considerations", for discussion of the registration rules.)
「パケットタイプ」エンコーディング：0：ROHC Small-CID 1：ROHC Large-Cids 2：Full_header 3：Compressed_tcp 4：Compressed_nodelta 5：Compressed_non_tcp 6：Compresded_rtp_8 7：Compresded_rtp_16 8まだ割り当てられています。（登録規則の議論については、セクション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]で説明したように、このMPLSペイロードタイプはIPではないため、最初のニブルは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]は、コンプレッサーと減圧装置の間のパケット損失と誤った順序の両方に対する堅牢性を高めると見なされる場合があります。これは、選択されたコンテキストパラメーターのデルタ値に加えて、更新を繰り返し、絶対的な（非圧縮）値を送信することによって達成されます。IPHCはTCP_NODELTAを使用する必要があります。ECRTPは絶対値を送信する必要があります。ROHCは[RFC4224]で説明するように適応する必要があります。ECRTPおよびROHCの並べ替えの評価とシミュレーションは、[再注文平均]に与えられています。
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.
この例では、双方向ECRTP [RFC3545]トラフィックをサポートするMPLS PWのセットアップを追跡します。この例は、図1に示すトポロジーを想定しています。PWは、LSRS R1/HCとR4/HDの間に設定されます。LSRS 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はLDPシグナル伝達に使用されるR4/HDのIPアドレスをすでに取得していると想定されており、逆も同様です。R1/HCとR4/HDの両方が同じ32ビットPW IDで構成されていると想定されています。、[RFC447]のセクション5.2で説明されているように、R1/HCはLDP発見プロセスを開始するように構成されています。さらに、R1/HCはR4/HDから最大200の同時ECRTPフローを受信するように構成されており、R4/HDがR1/HCから最大255 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 LSRS上のHC間で使用されます。R1/HCは拡張ディスカバリーを開始するように構成されているため、R1/HCが送信したターゲットを絞ったHelloメッセージをUDPポート646でR4/HDのIPアドレスにLDPターゲットメッセージを送信します。こんにちはパラメーターTLV、R4/HDにターゲットを絞ったハローメッセージをR1/HCに送信するよう要求します。R4/HDはR1/HDでHC PWを設定するように構成されているため、R4/HDは要求どおりに行い、R1/HCのIPアドレスのUDPポート646にUnicast UDPパケットとしてLDPターゲットを絞った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からターゲットを絞ったハローメッセージを受信すると、R4/HDへのLDPセッションの確立を開始する場合があります。これは、ポート646からR4/HDのシグナリングIPアドレスにTCP接続を開始することにより開始します。TCP接続の確立に成功した後、R1/HCは次の特性を使用してLDP初期化メッセージをR4/HDに送信します。
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からターゲットを絞ったハローメッセージを受信すると、R4/HDへのLDPセッションの確立を開始する場合があります。[RFC3036]のセクション2.5.2で説明した手順は、どのLSRがアクティブLSRであり、どのパッシブLSRであるかを決定するために使用されます。R1/HCには数値的に高いIPアドレスがあるため、アクティブな役割を果たすと仮定します。R1/HCは、ポート646のTCP接続をR4/HDの信号IPアドレスから開始することから開始します。TCP接続の確立が成功した後、R1/HCは次の特性を使用してR4/HDにLDP初期化メッセージを送信します。o共通セッションパラメーターTLV：-Aビット= 0（下流の未承諾モード）-Dビット= 0（ループ検出無効） - pvlim = 0（d bit = 0の場合は必須） - LDP識別子を受信（R4/HDのハローメッセージから取得）> 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がR1/HCのHelloメッセージで受け取ったLDP識別子を受信LDP識別子として使用することです。一般的なセッションパラメーターTLVの他のすべてのフィールドが両側に受け入れられると仮定すると、R1/HCはR4/HDにLDPキープライブメッセージを送信し、R4/HDはLDPキープライブメッセージを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のいずれかがLDPラベルマッピングメッセージを送信してPWを構成する場合があります。特定のルーターによって送信されたラベルマッピングメッセージは、そのルーターに送信され、特定のPWに関連付けられたすべてのパケットのMPLSラベルスタックの下部に使用する必要があるラベルを宣伝します。R1/HCからR4/HDに送信されたラベルマッピングメッセージには、次の特性があります。
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 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:
o FEC TLV -FEC要素タイプ0x80（[RFC4447]で定義されているPWID FEC要素] - コントロールパラメータービット= 1（コントロールパラメーターの表示）-PWタイプ= 0x001B（ECRTP [RFC3545]）-R1/HCによって選択されたグループID-PW ID =このPWの構成値は、R4/HDによってラベルマッピングメッセージに送信されたものと同じでなければなりません - インターフェイスパラメーターSub-TLV>インターフェイスMTU Sub-TLV（タイプ0x01）> CRTP/ECRTP/IPHC HCMPLS構成上のSub-TLV（タイプ0x0F）タイプ= 2（RFC 3544から）長さ= 16 TCP_SPACE =気にしないでください（推奨値に残します= 15）NON_TCP_SPACE = 200（R1で設定）F_MAX_PERIOD = DOT CARE推奨値に残しますR1、LR1 oオプションのパラメータなしR4/HDからR1/HCに送信されるラベルマッピングメッセージは、次の例外を除いて、反対方向に送信されたものとほぼ同じです。
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で構成されているように、CRTP/ECRTP/IPHC HC over MPLS構成のCRTP/ECRTP/IPHC HCのnon_tcp_spaceの値をCRTP/ECRTP/IPHC HC over MPLS構成のnon_tcp_spaceの値を選択できます。ラベル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のいずれかが、同じPWタイプとPW IDを持つラベルマッピングメッセージの両方を送信および受信するとすぐに、HCエンドポイントがPWを確立したと見なします。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は、この特定のフローでの圧縮は、コンテキストの再同期を必要とせずに2つの連続したパケットの損失から回復できるはずであると判断します（つまり、[RFC3545]の「n」値は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
ここで、xxはどちらかを意味します。MPLSルーティングレイヤーによって決定される値b。気にしないでください
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]で定義されているFull_headerパケットが来ます。これは基本的にIP/UDP/RTPヘッダーで構成され、IPおよびUDPの長さフィールドはCID、シーケンス番号、および「世代」をコードする値に置き換えられます。、[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
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タイムスタンプフィールドの絶対値とDELTA値を確立するために、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
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
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.
著者は、ロア・アンダーソン、スコット・ブリム、スチュワート・ブライアント、スペンサー・ドーキンス、エイドリアン・ファレル、ビクトリア・ファインバーグ、エリック・グレイ、アリソン・マンキン、ルカ・マルティーニ、コリン・パーキンス、クリストファー・サンドルンド、ヤアコフ・シュタイン、ジョージ・ザロウ、マーク・タウンズリーからの貴重なインプットと提案に感謝しています。Curtis Villamizar、Magnus Westerlund。
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]
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で説明したように、Pseudowireインターフェイスパラメーターサブ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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、RFC 2119、1997年3月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031] Rosen、E.、Viswanathan、A。、およびR. Callon、「Multiprotocolラベルスイッチングアーキテクチャ」、RFC 3031、2001年1月。
[RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and B. Thomas, "LDP Specification", RFC 3036, January 2001.
[RFC3036] Andersson、L.、Doolan、P.、Feldman、N.、Fredette、A。、およびB. Thomas、「LDP仕様」、RFC 3036、2001年1月。
[RFC3241] Bormann, C., "Robust Header Compression (ROHC) over PPP", RFC 3241, April 2002.
[RFC3241] Bormann、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.、Bormann、C。、およびT. Koren、「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] Martini、L.、Ed。、Rosen、E.、El-Aawar、N.、Smith、T。、およびG. Heron、「ラベル分布プロトコル（LDP）を使用した擬似ワイヤーのセットアップとメンテナンス」、RFC 4447、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] Swallow、G.、Bryant、S。、およびL. Andersson、「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] McGregor、G。、「PPPインターネットプロトコル制御プロトコル（IPCP）」、RFC 1332、1992年5月。
[RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[RFC1661] Simpson、W.、ed。、「ポイントツーポイントプロトコル（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. Allen、「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. Pink、「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] Bormann、C.、et al。、「堅牢なヘッダー圧縮（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。Pelletier、G。、およびK. Sandlund、「The Robust Header Compression（ROHC）フレームワーク」、2006年11月、Progressの作業。
[RFC3209] Awduche, D., et al., "RSVP-TE: Extensions to RSVP for LSP Tunnels," RFC 3209, December 2001.
[RFC3209] Awduche、D.、et al。、「RSVP-TE：LSPトンネルのRSVPへの拡張」、RFC 3209、2001年12月。
[RFC3544] Koren, T., et al., "IP Header Compression over PPP," RFC 3544, July 2003.
[RFC3544] Koren、T.、et al。、「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] Koren、T.、et al。、「高い遅延、パケット損失、並べ替えを伴うリンクにIP/UDP/RTPヘッダーを圧縮する」、RFC 3545、2003年7月。
[RFC3246] Davie, B., et al., "An Expedited Forwarding PHB (Per-Hop Behavior)," RFC 3246, March 2002.
[RFC3246] Davie、B.、et al。、「迅速な転送PHB（ホップごとの行動）」、RFC 3246、2002年3月。
[RFC3270] Le Faucheur, F., et al., "Multi-Protocol Label Switching (MPLS) Support of Differentiated Services," RFC 3270, May 2002.
[RFC3270] Le Faucheur、F.、et al。、「Multi-Protocol Label Switching（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.、et al。、「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] Jonsson、L-E。およびG. Pelletier、「堅牢なヘッダー圧縮（ROHC）：IPの圧縮プロファイル」、RFC 3843、2004年6月。
[RFC3985] Bryant, S., Pate, P., "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture," RFC 3985, March 2005.
[RFC3985] Bryant、S.、Pate、P。、「Pseudo Wire Emulation Edge-to-Edge（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] Pelletier、G.、et al。、「Robust Header圧縮（ROHC）：Packetsを並べ替えることができるチャネル上のROHC」、RFC 4224、2006年1月。
[RFC4247] Ash, G., Goode, B., Hand, J., "Requirements for Header Compression over MPLS", RFC 4247, November 2005.
[RFC4247] Ash、G.、Goode、B.、Hand、J。、「MPLS上のヘッダー圧縮の要件」、RFC 4247、2005年11月。
[RFC4364] Rosen, E., Rekhter, Y., "BGP/MPLS IP Virtual Private Networks (VPN)s", RFC 4364, February 2006.
[RFC4364] Rosen、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] Bryant、S.、et al。、「Pseudowire Emulation Edge-to-Edge（PWE3）MPLS PSNでの使用を制御する」、RFC 4385、2006年2月。
[RFC4446] Martini, L., et al., "IANA Allocations for Pseudo Wire Edge To Edge Emulation (PWE3)," RFC 4446, April 2006.
[RFC4446] Martini、L.、et al。、「擬似ワイヤエッジからエッジエミュレーション（PWE3）へのIANAの割り当て」、RFC 4446、2006年4月。
[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] Jonsson、L-E。、Sandlund、K.、Pelletier、G。、およびP. Kremer、「堅牢なヘッダー圧縮（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
Bur Goode 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
Lars-erik Jonsson Optand 737 SE-831 92 SWEDEN電話：46 70 365 20 58電子メール：lars-erik@lejonsson.com
Raymond Zhang Infonet Services Corporation 2160 E. Grand Ave. El Segundo, CA 90025 USA EMail: zhangr@bt.infonet.com
Raymond Zhang Infonet Services Corporation 2160 E. Grand Ave. El Segundo、CA 90025 USAメール：zhangr@bt.infonet.com
Editors' Addresses
編集者のアドレス
Jerry Ash AT&T Email: gash5107@yahoo.com
Jerry Ash AT＆Tメール：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
Jim Hand AT＆T Room MT A2-1A03 200 Laurel Avenue Middletown、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
Andrew G. Malis Verizon Communications 40 Sylvan Road Waltham、MA 02451 USAメール：andrew.G.Malis@verizon.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。