[要約] RFC 4247は、MPLS上でのヘッダ圧縮の要件を定義しており、効率的なネットワークリソースの使用とパフォーマンスの向上を目的としています。
Network Working Group J. Ash
Request for Comments: 4247 B. Goode
Category: Informational J. Hand
AT&T
R. Zhang
BT Infonet
November 2005
Requirements for Header Compression over MPLS
MPLS上のヘッダー圧縮の要件
Status of This Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（2005）。
Abstract
概要
Voice over IP (VoIP) typically uses the encapsulation voice/RTP/UDP/IP. When MPLS labels are added, this becomes voice/RTP/UDP/IP/MPLS-labels. For an MPLS VPN, the packet header is typically 48 bytes, while the voice payload is often no more than 30 bytes, for example. Header compression can significantly reduce the overhead through various compression mechanisms, such as enhanced compressed RTP (ECRTP) and robust header compression (ROHC). We consider using MPLS to route compressed packets over an MPLS Label Switched Path (LSP) without compression/decompression cycles at each router. This approach can increase the bandwidth efficiency as well as processing scalability of the maximum number of simultaneous flows that use header compression at each router. In this document, we give a problem statement, goals and requirements, and an example scenario.
Voice over IP（VoIP）は通常、カプセル化音声/RTP/UDP/IPを使用します。MPLSラベルが追加されると、これはVoice/RTP/UDP/IP/MPLS-Labelsになります。MPLS VPNの場合、パケットヘッダーは通常48バイトですが、音声ペイロードはたとえば30バイト以下です。ヘッダー圧縮は、強化された圧縮RTP（ECRTP）や堅牢なヘッダー圧縮（ROHC）など、さまざまな圧縮メカニズムを介してオーバーヘッドを大幅に減らすことができます。MPLSを使用して、各ルーターで圧縮/減圧サイクルなしでMPLSラベルスイッチ付きパス（LSP）に圧縮パケットをルーティングすることを検討します。このアプローチは、各ルーターでヘッダー圧縮を使用する同時フローの最大数のスケーラビリティを処理するだけでなく、帯域幅の効率を高めることができます。このドキュメントでは、問題のステートメント、目標と要件、および例のシナリオを示します。
Table of Contents
目次
1. Introduction ....................................................2
2. Problem Statement ...............................................3
2.1. Specification of Requirements ..............................4
3. Goals and Requirements ..........................................5
4. Candidate Solution Methods and Needs ............................6
5. Example Scenario ................................................7
6. Security Considerations .........................................8
7. Normative References ............................................8
8. Informative References ..........................................9
9. Acknowledgements ...............................................10
Voice over IP (VoIP) typically uses the encapsulation voice/RTP/UDP/IP. When MPLS labels [MPLS-ARCH] are added, this becomes voice/RTP/UDP/IP/MPLS-labels. For an MPLS Virtual Private Network (VPN) (e.g., [MPLS-VPN]), the packet header is at least 48 bytes, while the voice payload is often no more than 30 bytes, for example. 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] or robust header compression [ROHC], and also to increase scalability of HC. We consider using MPLS to route compressed 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 flows that use HC at each router.
Voice over IP（VoIP）は通常、カプセル化音声/RTP/UDP/IPを使用します。MPLSラベル[MPLS-ARCH]が追加されると、これはVoice/RTP/UDP/IP/MPLS-Labelsになります。MPLS仮想プライベートネットワーク（VPN）（例：[MPLS-VPN]）の場合、パケットヘッダーは少なくとも48バイトですが、音声ペイロードはたとえば30バイト以下です。ヘッダー圧縮（HC）への関心は、強化された圧縮RTP [ECRTP]や堅牢なヘッダー圧縮[ROHC]など、さまざまな圧縮メカニズムを介してオーバーヘッドを大幅に削減する可能性を活用することです。MPLSを使用して、各ルーターで圧縮/減圧サイクルなしでMPLSラベルスイッチ付きパス（LSP）に圧縮パケットをルーティングすることを検討します。このようなHCオーバーMPLS機能は、各ルーターでHCを使用する同時フローの最大数の処理スケーラビリティと同様に、帯域幅の効率を高める可能性があります。
To implement HC over MPLS, the ingress router/gateway would have to apply the HC algorithm to the IP packet, the compressed packet routed on an MPLS LSP using MPLS labels, and the compressed header would be decompressed at the egress router/gateway where the HC session terminates. Figure 1 illustrates an HC over MPLS session established on an LSP that crosses several routers, from R1/HC --> R2 --> R3 --> R4/HD, where R1/HC is the ingress router where HC is performed, and R4/HD is the egress router where header decompression (HD) is done. HC 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.
MPLSにHCを実装するには、Ingressルーター/ゲートウェイはHCアルゴリズムをIPパケットに適用する必要があります。MPLSラベルを使用してMPLS LSPにルーティングされた圧縮パケットを適用する必要があり、HCセッションが終了するEgress Router/Gatewayで圧縮ヘッダーが減圧されます。図1は、R1/HC - > R2-> R3-> R4/HDからいくつかのルーターを通過するLSPで確立されたHC上のMPLSセッションを示しています。ここで、R1/HCはHCが実行される侵入ルーターであり、R4/HDはヘッダー脱圧縮（HD）が行われる出力ルーターです。RTP/UDP/IPヘッダーのHCはR1/HCで実行され、圧縮パケットは、R1/HCからR2、最終的にR4/HDにMPLSラベルを使用してルーティングされ、さらに減圧/再結合サイクルがありません。RTP/UDP/IPヘッダーはR4/HDで減圧され、必要に応じて他のルーターに転送できます。
_____
| |
|R1/HC| Header Compression (HC) Performed
|_____|
|
| voice/compressed-header/MPLS-labels
V
_____
| |
| R2 |
|_____|
|
| voice/compressed-header/MPLS-labels
V
_____
| |
| R3 |
|_____|
|
| voice/compressed-header/MPLS-labels
V
_____
| |
|R4/HD| Header Decompression (HD) Performed
|_____|
Figure 1. Example of Header Compression over MPLS over Routers R1-->R4
図1.ルーター上のMPLS上のヘッダー圧縮の例R1-> R4
In the example scenario, HC therefore takes place between R1 and R4, and the MPLS path transports voice/compressed-header/MPLS-labels instead of voice/RTP/UDP/IP/MPLS-labels, typically saving 30 octets or more per packet. The MPLS label stack and link-layer headers are not compressed. A signaling method is needed to set up a correspondence between the ingress and egress routers of the HC over MPLS session.
したがって、例のシナリオでは、HCはR1とR4の間で行われ、MPLSパスは音声/RTP/UDP/IP/MPLSラベルの代わりに音声/圧縮者/MPLSラベルを輸送し、通常はパケットごとに30オクテット以上を節約します。MPLSラベルスタックとリンク層ヘッダーは圧縮されていません。MPLSセッション上のHCのイングレスルーターと出口ルーターの間に対応を設定するには、シグナル伝達方法が必要です。
In Section 2 we give a problem statement, in Section 3 we give goals and requirements, and in Section 5 we give an example scenario.
セクション2では、セクション3では目標と要件を示し、セクション5ではシナリオの例を示します。
As described in the introduction, HC over MPLS can significantly reduce the header overhead through HC mechanisms. The need for HC may be important on low-speed links where bandwidth is more scarce, but it could also be important on backbone facilities, especially where costs are high (e.g., some global cross-sections). VoIP typically will use voice compression mechanisms (e.g., G.729) on low-speed and international routes, in order to conserve bandwidth. With HC, significantly more bandwidth could be saved. For example, carrying uncompressed headers for the entire voice load of a large domestic network with 300 million or more calls per day could consume on the order of about 20-40 gigabits per second on the backbone network for headers alone. This overhead could translate into considerable bandwidth capacity.
はじめに説明されているように、MPLS上のHCは、HCメカニズムを介してヘッダーオーバーヘッドを大幅に減らすことができます。HCの必要性は、帯域幅がより少ない低速リンクでは重要かもしれませんが、特にコストが高い場合（たとえば、グローバルな断面など）、バックボーン施設でも重要である可能性があります。VoIPは通常、帯域幅を保護するために、低速および国際的なルートで音声圧縮メカニズム（G.729など）を使用します。HCを使用すると、帯域幅を大幅に保存できます。たとえば、1日あたり3億個以上のコールを備えた大規模な国内ネットワークの音声負荷全体に非圧縮ヘッダーを運ぶことで、バックボーンネットワークでヘッダーだけで約20〜40ギガビットのオーダーで消費できます。このオーバーヘッドは、かなりの帯域幅容量に変換される可能性があります。
The claim is often made that once fiber is in place, increasing the bandwidth capacity is inexpensive, nearly 'free'. This may be true in some cases; however, on some international cross-sections, especially, facility/transport costs are very high and saving bandwidth on such backbone links is very worthwhile. Decreasing the backbone bandwidth is needed in some areas of the world where bandwidth is very expensive. It is also important in almost all locations to decrease the bandwidth consumption on low-speed links. So although bandwidth is getting cheaper, the value of compression does not go away. It should be further noted that IPv6 will increase the size of headers, and therefore increase the importance of HC for RTP flows.
多くの場合、繊維が設置されると、帯域幅の容量を増やすことは安価で、ほぼ「無料」であるという主張が行われます。これは場合によっては当てはまるかもしれません。ただし、一部の国際的な断面、特に施設/輸送コストは非常に高く、そのようなバックボーンリンクの帯域幅の節約は非常に価値があります。帯域幅が非常に高価な世界の一部の地域では、バックボーン帯域幅を減らす必要があります。また、ほぼすべての場所で、低速リンクの帯域幅の消費を減らすことも重要です。したがって、帯域幅は安くなっていますが、圧縮の値はなくなりません。さらに、IPv6がヘッダーのサイズを増加させ、したがってRTPフローのHCの重要性を高めることに注意する必要があります。
Although hop-by-hop HC could be applied to decrease bandwidth requirements, that implies a processing requirement for compression-decompression cycles at every router hop, which does not scale well for large voice traffic loads. The maximum number of compressed RTP (cRTP) flows is about 30-50 for a typical customer premise router, depending upon its uplink speed and processing power, while the need may exceed 300-500 for a high-end case. Therefore, HC over MPLS seems to be a viable alternative to get the compression benefits without introducing costly processing demands on the intermediate nodes. By using HC over MPLS, routers merely forward compressed packets without doing a decompression/recompression cycle, thereby increasing the maximum number of simultaneous compressed flows that routers can handle.
ホップバイホップHCを適用して帯域幅要件を減らすことができますが、それはすべてのルーターホップでの圧縮抑制サイクルの処理要件を意味します。圧縮されたRTP（CRTP）フローの最大数は、典型的な顧客の前提ルーターでは、アップリンク速度と処理能力に応じて約30〜50ですが、ハイエンドの場合は300〜500を超える可能性があります。したがって、HCオーバーMPLSは、中間ノードに費用のかかる処理需要を導入することなく、圧縮利点を取得するための実行可能な代替手段であると思われます。HCをMPLSで使用することにより、ルーターは単に減圧/再圧縮サイクルを行わずに圧縮パケットを転送するだけで、ルーターが処理できる同時圧縮フローの最大数が増加します。
Therefore, the proposal is to use existing HC techniques, together with MPLS labels, to make the transport of the RTP/UDP/IP headers more efficient over an MPLS network. However, at this time, there are no standards for HC over MPLS, and vendors have not implemented such techniques.
したがって、提案は、MPLSラベルとともに既存のHCテクニックを使用して、MPLSネットワークよりもRTP/UDP/IPヘッダーの輸送をより効率的にすることです。ただし、現時点では、MPLを介したHCの基準はなく、ベンダーはそのような手法を実装していません。
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 [KEY].
「必須」、「必要」、「必須」、「「しなければならない」、「そうしない」、「そうではない」、「そうはならない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[key]に記載されていると解釈されます。
The goals of HC over MPLS are as follows:
MPLS上のHCの目標は次のとおりです。
a. provide more efficient voice transport over MPLS networks, b. increase the scalability of HC to a large number of flows, c. not significantly increase packet delay, delay variation, or loss probability, and d. leverage existing work through use of standard protocols as much as possible.
a. MPLSネットワークよりも効率的な音声輸送を提供するb。HCのスケーラビリティを多数のフローに増やす、c。パケット遅延、遅延変動、または損失確率を大幅に増加させない、d。標準プロトコルを可能な限り使用して既存の作業を活用します。
Therefore the requirements for HC over MPLS are as follows:
したがって、MPLを超えるHCの要件は次のとおりです。
a. MUST use existing protocols (e.g., [ECRTP], [ROHC]) to compress RTP/UDP/IP headers, in order to provide for efficient transport, tolerance to packet loss, and resistance to loss of session context. b. MUST allow HC over an MPLS LSP, and thereby avoid hop-by-hop compression/decompression cycles (e.g., [HC-MPLS-PROTO]). c. MUST minimize incremental performance degradation due to increased delay, packet loss, and jitter. d. MUST use standard protocols to signal context identification and control information (e.g., [RSVP], [RSVP-TE], [LDP]). e. Packet reordering MUST NOT cause incorrectly decompressed packets to be forwarded from the decompressor.
a. 効率的な輸送、パケット損失に対する耐性、およびセッションコンテキストの損失に対する抵抗を提供するために、既存のプロトコル（例：[ECRTP]、[ROHC]）を使用する必要があります。b。MPLS LSPを介したHCを許可する必要があり、それにより、ホップバイホップの圧縮/減圧サイクル（[HC-MPLS-Proto]）を避ける必要があります。c。遅延、パケットの損失、およびジッターの増加により、増分性能劣化を最小限に抑える必要があります。d。標準プロトコルを使用して、コンテキストの識別と制御情報を通知する必要があります（例：[RSVP]、[RSVP-TE]、[LDP]）。e。パケットの並べ替えにより、誤って減圧されたパケットが減圧器から転送されてはなりません。
It is necessary that the HC method be able to handle out-of-sequence packets. MPLS [MPLS-ARCH] enables 4-byte labels to be appended to IP packets to allow switching from the ingress Label Switching Router (LSR) to the egress LSP on an LSP through an MPLS network. However, MPLS does not guarantee that packets will arrive in order at the egress LSR, since a number of things could cause packets to be delivered out of sequence. For example, a link failure could cause the LSP routing to change, due perhaps to an MPLS fast reroute taking place, or to the Interior Gateway Protocol (IGP) and Label Distribution Protocol (LDP) converging to another route, among other possible reasons. Other causes could include IGP reroutes due to 'loose hops' in the LSP, or BGP route changes reflecting back into IGP reroutes. HC algorithms may be able to handle reordering magnitudes on the order of about 10 packets, which may make the time required for IGP reconvergence (typically on the order of seconds) untenable for the HC algorithm. On the other hand, MPLS fast reroute may be fast enough (on the order of 50 ms or less) for the HC algorithm to handle packet reordering. The issue of reordering needs to be further considered in the development of the HC over MPLS solution.
HCメソッドは、アウトオブシーケンスパケットを処理できる必要があります。MPLS [MPLS-ARCH]を使用すると、4バイトのラベルをIPパケットに追加して、MPLSネットワークを介してLSPでLSPの出力LSPに切り替えるように切り替えることができます。ただし、MPLSは、パケットがシーケンスから配信される可能性があるため、PacketsがEgress LSRで順番に到着することを保証するものではありません。たとえば、リンク障害により、おそらくMPLS Fast Rerouteが発生しているため、または他の可能性のある理由の中でも、別のルートに収束するインテリアゲートウェイプロトコル（IGP）およびラベル分布プロトコル（LDP）のために、LSPルーティングが変更される可能性があります。その他の原因には、LSPの「ルーズホップ」によるIGPルーアウト、またはIGPルートに戻るBGPルートの変更が含まれる場合があります。HCアルゴリズムは、HCアルゴリズムには受け入れられない、IGPの再構成に必要な時間（通常は秒程度）に必要な時間を作る可能性があります。一方、MPLS Fast Rerouteは、HCアルゴリズムがパケットの再注文を処理するのに十分な速さ（50ミリ秒以下）である可能性があります。並べ替えの問題は、MPLSソリューションを超えるHCの開発でさらに考慮する必要があります。
Resynchronization and performance also needs to be considered, since HC over MPLS can sometimes have multiple routers in the LSP. Tunneling an HC session over an MPLS LSP with multiple routers in the path will increase the round-trip delay and the chance of packet loss, and HC contexts may be invalidated due to packet loss. The HC error recovery mechanism can compound the problem when long round-trip delays are involved.
MPLS上のHCがLSPに複数のルーターを持つ場合があるため、再同期とパフォーマンスも考慮する必要があります。パスに複数のルーターを備えたMPLS LSPでHCセッションをトンネリングすると、往復遅延が増加し、パケット損失の可能性が高くなり、パケットの損失によりHCコンテキストが無効になる場合があります。HCエラー回復メカニズムは、長い往復遅延が関係する場合に問題を悪化させる可能性があります。
[cRTP] performs best with very low packet error rates on all hops of the path. When the cRTP decompressor context state gets out of synch with the compressor, it will drop packets associated with the context until the two states are resynchronized. To resynchronize context state at the two ends, the decompressor transmits the CONTEXT_STATE packet to the compressor, and the compressor transmits a FULL_HEADER packet to the decompressor.
[CRTP]は、パスのすべてのホップで非常に低いパケットエラー率で最適に機能します。CRTP減圧装置のコンテキスト状態がコンプレッサーと同期しなくなると、2つの状態が再同期されるまで、コンテキストに関連付けられたパケットをドロップします。コンテキスト状態を再同期するために、両端でコンテキストの状態を再同期するために、減圧器はContext_Stateパケットをコンプレッサーに送信し、コンプレッサーはfull_headerパケットをDecompressorに送信します。
[ECRTP] uses mechanisms that make cRTP more tolerant to packet loss, and ECRTP thereby helps to minimize the use of feedback-based error recovery (CONTEXT_STATE packets). ECRTP is therefore a candidate method to make HC over MPLS more tolerant of packet loss and to guard against frequent resynchronizations. ECRTP may need some implementation adaptations to address the reordering requirement in Section 3 (requirement e), since a default implementation will probably not meet the requirement. ECRTP protocol extensions may be required to identify FULL_HEADER, CONTEXT_STATE, and compressed packet types. [cRTP-ENCAP] specifies a separate link-layer packet type defined for HC. Using a separate link-layer packet type avoids the need to add extra bits to the compression header to identify the packet type. However, this approach does not extend well to MPLS encapsulation conventions [MPLS-ENCAP], in which a separate link-layer packet type translates into a separate LSP for each packet type. In order to extend ECRTP to HC over MPLS, each packet type defined in [ECRTP] would need to be identified in an appended packet type field in the ECRTP header.
[ECRTP]は、CRTPをパケット損失に対してより耐性にするメカニズムを使用し、ECRTPはフィードバックベースのエラー回復（Context_Stateパケット）の使用を最小限に抑えるのに役立ちます。したがって、ECRTPは、MPLを超えるHCをパケット損失に対してより寛容にし、頻繁に再同期を防ぐための候補方法です。ECRTPは、デフォルトの実装ではおそらく要件を満たさないため、セクション3（要件E）の並べ替え要件に対処するためにいくつかの実装適応が必要になる場合があります。ECRTPプロトコル拡張は、Full_Header、Context_State、および圧縮パケットタイプを識別するために必要になる場合があります。[CRTP-ENCAP] HC用に定義された個別のリンク層パケットタイプを指定します。個別のリンク層パケットタイプを使用すると、圧縮ヘッダーに追加のビットを追加してパケットタイプを識別する必要がなくなります。ただし、このアプローチは、MPLSカプセル化コンベンション[MPLS-Encap]には拡張されません。このアプローチでは、個別のリンク層パケットタイプは、各パケットタイプの個別のLSPに変換されます。ECRTPをMPLSでHCに拡張するには、[ECRTP]で定義された各パケットタイプをECRTPヘッダーのAppred Packet Typeフィールドで識別する必要があります。
[ROHC] is also very tolerant of packet loss, and therefore is a candidate method to guard against frequent resynchronizations. ROHC also achieves a somewhat better level of compression as compared to ECRTP. ROHC may need some implementation adaptations to address the reordering requirement in Section 3 (requirement e), since a default implementation will probably not meet the requirement (see [ROHC-REORD]). ROHC already has the capability to identify the packet type in the compression header, so no further extension is needed to identify packet type.
[ROHC]はパケットの損失にも非常に寛容であるため、頻繁に再同期を守る候補者の方法です。ROHCは、ECRTPと比較して、やや優れたレベルの圧縮を達成しています。ROHCは、デフォルトの実装ではおそらく要件を満たしていないため、セクション3（要件E）の並べ替え要件に対処するためにいくつかの実装適応が必要になる場合があります（[ROHC-Reord]を参照）。ROHCには、圧縮ヘッダーのパケットタイプを識別する機能がすでにあるため、パケットタイプを識別するためにさらに拡張する必要はありません。
Extensions to MPLS signaling may be needed to identify the LSP from HC to HD egress point, negotiate the HC algorithm used and protocol parameters, and negotiate the Session Context IDs (SCIDs) space between the ingress and egress routers on the MPLS LSP. For example, new objects may need to be defined for [RSVP-TE] to signal the SCID spaces between the ingress and egress routers, and the HC algorithm used to determine the context; these HC packets then contain the SCID identified by using the RSVP-TE objects. It is also desirable to signal HC over MPLS tunnels with the Label Distribution Protocol [LDP], since many RFC 2547 VPN [MPLS-VPN] implementations use LDP as the underlying LSP signaling mechanism, and LDP is very scalable. However, extensions to LDP may be needed to signal SCIDs between ingress and egress routers on HC over MPLS LSPs. For example, 'targeted LDP sessions' might be established for signaling SCIDs, or perhaps methods described in [LDP-PWE3] to signal pseudo-wires and multipoint-to-point LSPs might be extended to support signaling of SCIDs for HC over MPLS LSPs. The specific MPLS signaling protocol extensions to support these approved requirements need to be developed as a well-coordinated separate document in the appropriate IETF working groups. The IETF needs to support a coordinated process for the two solution documents, though they are in separate areas.
MPLSシグナリングへの拡張は、HCからHD出力ポイントへのLSPを識別し、使用されているHCアルゴリズムとプロトコルパラメーターをネゴシエートし、MPLS LSPのイングレスルーターと出口ルーター間のセッションコンテキストID（SCIDS）スペースをネゴシエートするために必要になる場合があります。たとえば、[RSVP-TE]の新しいオブジェクトを定義する必要がある場合があり、イングレスルーターと出口ルーターの間のSCIDスペースと、コンテキストを決定するために使用されるHCアルゴリズムを通知する必要があります。これらのHCパケットには、RSVP-TEオブジェクトを使用して識別されるSCIDが含まれます。また、多くのRFC 2547 VPN [MPLS-VPN]の実装を使用してLDPを基礎となるLSPシグナル伝達メカニズムとして使用し、LDPは非常にスケーラブルであるため、ラベル分布プロトコル[LDP]を使用してMPLSトンネルを介してHCを信号に信号を送信することも望ましいです。ただし、MPLS LSPを介したHCのイングレスルーターと出力ルーターの間のSCIDを通知するには、LDPへの拡張が必要になる場合があります。たとえば、「ターゲットLDPセッション」は、SCIDSのシグナル、または[LDP-PWE3]に記載されているメソッドのために確立される可能性があります。これらの承認された要件をサポートするための特定のMPLSシグナリングプロトコル拡張は、適切なIETFワーキンググループに適切に調整された個別のドキュメントとして開発する必要があります。IETFは、2つのソリューションドキュメントの調整されたプロセスをサポートする必要がありますが、それらは別々の領域にあります。
As illustrated in Figure 2, many VoIP flows are originated from customer sites, which are served by routers R1, R2, and R3, and terminated at several large customer call centers, which are served by R5, R6, and R7. R4 is a service-provider router, and all VoIP flows traverse R4. It is essential that the R4-R5, R4-R6, and R4-R7 low-speed links all use HC to allow a maximum number of simultaneous VoIP flows. To allow processing at R4 to handle the volume of simultaneous VoIP flows, it is desired to use HC over MPLS for these flows. With HC over MPLS, R4 does not need to do HC/HD for the flows to the call centers, enabling more scalability of the number of simultaneous VoIP flows with HC at R4.
図2に示すように、多くのVoIPフローは、ルーターR1、R2、およびR3が提供する顧客サイトから発信され、R5、R6、およびR7が提供するいくつかの大規模なカスタマーコールセンターで終了しました。R4はサービスプロバイダールーターであり、すべてのVoIPフローがR4をトラバースします。R4-R5、R4-R6、およびR4-R7低速リンクはすべてHCを使用して、最大数の同時VOIPフローを可能にすることが不可欠です。R4での処理が同時のVoIPフローの量を処理できるようにするには、これらのフローにMPLSよりもHCを使用することが望まれます。MPLSを超えるHCを使用すると、R4はコールセンターへのフローに対してHC/HDを実行する必要はなく、R4でHCと同時にVOIPフローの数のスケーラビリティをより強化します。
voice/C-HDR/MPLS-labels ______ voice/C-HDR/MPLS-labels
R1/HC---------------------->| |-----------------------> R5/HD
| |
voice/C-HDR/MPLS-labels| |voice/C-HDR/MPLS-labels
R2/HC---------------------->| R4 |-----------------------> R6/HD
| |
voice/C-HDR/MPLS-labels| |voice/C-HDR/MPLS-labels
R3/HC---------------------->|______|-----------------------> R7/HD
Note: HC = header compression C-HDR = compressed header HD = header decompression
注：HC =ヘッダー圧縮C-HDR =圧縮ヘッダーHD =ヘッダー減圧
Figure 2. Example Scenario for Application of HC over MPLS
図2. MPLSよりもHCを適用するための例のシナリオ
The high processing load of HC makes HC a target for denial-of-service attacks. For example, an attacker could send a high-bandwidth data stream through a network, with the headers in the data stream marked appropriately to cause HC to be applied. This would use large amounts of processing resources on the routers performing compression and decompression, and these processing resources might then be unavailable for other important functions on the router. This threat is not a new threat for HC, but is addressed and mitigated by HC over MPLS. That is, by reducing the need for performing compression and decompression cycles, as proposed in this document, the risk of this type of denial-of-service attack is reduced.
HCの高い処理荷重により、HCはサービス拒否攻撃のターゲットになります。たとえば、攻撃者はネットワークを介して高帯域幅データストリームを送信することができ、データストリームのヘッダーが適切にマークされ、HCを適用することができます。これにより、圧縮と減圧を実行するルーターに大量の処理リソースが使用され、これらの処理リソースは、ルーター上の他の重要な機能では利用できない場合があります。この脅威はHCにとって新しい脅威ではありませんが、MPLSよりもHCによって対処および緩和されています。つまり、このドキュメントで提案されているように、圧縮と減圧サイクルを実行する必要性を減らすことにより、このタイプのサービス拒否攻撃のリスクが減少します。
[cRTP] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", RFC 2508, February 1999.
[CRTP] Casner、S。およびV. Jacobson、「低速シリアルリンクのIP/UDP/RTPヘッダーの圧縮」、RFC 2508、1999年2月。
[cRTP-ENCAP] Engan, M., Casner, S., Bormann, C., and T. Koren, "IP Header Compression over PPP", RFC 3544, July 2003.
[CRTP-ENCAP] Engan、M.、Casner、S.、Bormann、C。、およびT. Koren、「PPP上のIPヘッダー圧縮」、RFC 3544、2003年7月。
[ECRTP] Koren, T., Casner, S., Geevarghese, J., Thompson, B., and P. Ruddy, "Enhanced Compressed RTP (CRTP) for Links with High Delay, Packet Loss and Reordering", RFC 3545, July 2003.
[ECRTP] Koren、T.、Casner、S.、Geevarghese、J.、Thompson、B。、およびP. Ruddy、「高度な遅延、パケット損失、並べ替えのリンクのための圧縮RTP（CRTP）の強化」、RFC 3545、2003年7月。
[KEY] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997.
[Key] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、RFC 2119、1997年3月。
[LDP] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and B. Thomas, "LDP Specification", RFC 3036, January 2001.
[LDP] Andersson、L.、Doolan、P.、Feldman、N.、Fredette、A。、およびB. Thomas、「LDP仕様」、RFC 3036、2001年1月。
[MPLS-ARCH] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[MPLS-ARCH] Rosen、E.、Viswanathan、A。、およびR. Callon、「Multiprotocolラベルスイッチングアーキテクチャ」、RFC 3031、2001年1月。
[ROHC] Bormann, C., et al., "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed ", RFC 3095, July 2001.
[ROHC] Bormann、C.、et al。、「堅牢なヘッダー圧縮（ROHC）：フレームワークと4つのプロファイル：RTP、UDP、ESP、および非圧縮」、RFC 3095、2001年7月。
[RSVP] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RSVP] Braden、R.、Zhang、L.、Berson、S.、Herzog、S。、およびS. Jamin、「リソース予約プロトコル（RSVP） - バージョン1機能仕様」、RFC 2205、1997年9月。
[RSVP-TE] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RSVP-TE] Awduche、D.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、「RSVP-TE：LSPトンネルのRSVPへの拡張」、RFC 3209、2001年12月。
[HC-MPLS-PROTO] Ash, G., Goode, B., Hand, J., Jonsson, L-E., Malis, A., and R. Zhang, "Protocol Extensions for Header Compression over MPLS", work in progress.
[Hc-Mpls-Proto] Ash、G.、Goode、B.、Hand、J.、Jonsson、L-E。、Malis、A。、およびR. Zhang、「MPLS上でのヘッダー圧縮のプロトコル拡張」、進行中の作業。
[LDP-PWE3] Martini, L., El-Aawar, N., Smith, T., and G. Heron, "Pseudowire Setup and Maintenance using the Label Distribution Protocol", work in progress.
[LDP-PWE3] Martini、L.、El-Aawar、N.、Smith、T。、およびG. Heron、「Pseudowireのセットアップとラベル分布プロトコルを使用したメンテナンス」、進行中の作業。
[MPLS-ENCAP] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.
[MPLS-ENCAP] Rosen、E.、Tappan、D.、Fedorkow、G.、Rekhter、Y.、Farinacci、D.、Li、T。、およびA. conta、「MPLSラベルスタックエンコーディング」、RFC 3032、2001年1月。
[MPLS-VPN] Rosen, E. and Y. Rekhter, "BGP/MPLS VPNs", RFC 2547, March 1999.
[MPLS-VPN] Rosen、E。およびY. Rekhter、「BGP/MPLS VPNS」、RFC 2547、1999年3月。
[ROHC-REORD] Pelletier, G., Jonsson, L-E., and K. Sandlund, "RObust Header Compression (ROHC): ROHC over Channels that can Reorder Packets", work in progress.
[Rohc-reord] Pelletier、G.、Jonsson、L-E。、およびK. Sandlund、「堅牢なヘッダー圧縮（ROHC）：パケットを再注文できるチャネル上のROHC」、進行中の作業。
The authors wish to thank the following people (in alphabetical order) for their helpful comments and suggestions: Loa Andersson, Scott Brim, Thomas Eriksson, Victoria Fineberg, Lars-Erik Jonsson, Allison Mankin, Colin Perkins, Kristofer Sandlund, and Magnus Westerlund.
著者は、Loa Andersson、Scott Brim、Thomas Eriksson、Victoria Fineberg、Lars-Erik Jonsson、Allison Mankin、Colin Perkins、Kristofer Sandlund、Magnus Westerlundなど、有益なコメントと提案について、次の人々（アルファベット順）に感謝したいと考えています。
Authors' Addresses
著者のアドレス
Jerry Ash AT&T Room MT D5-2A01 200 Laurel Avenue Middletown, NJ 07748, USA Phone: +1 732-420-4578 EMail: gash@att.com
ジェリーアッシュAT＆TルームMT D5-2A01 200ローレルアベニューミドルタウン、ニュージャージー州07748、米国電話：1 732-420-4578メール：gash@att.com
Bur Goode AT&T Phone: + 1 203-341-8705 EMail: bgoode@att.com
Bur Goode AT＆T電話：1 203-341-8705メール：bgoode@att.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
Raymond Zhang BT Infonet 2160 E. Grand Ave. El Segundo, CA 90025 USA EMail: raymond.zhang@bt.infonet.com
Raymond Zhang Bt Infonet 2160 E. Grand Ave. El Segundo、CA 90025 USAメール：raymond.zhang@bt.infonet.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（2005）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、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 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.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、貢献者、インターネット社会とインターネットエンジニアリングタスクフォースが代表する組織、またはインターネットエンジニアリングタスクフォースは、すべての保証を否認します。
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://ww.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エディター機能の資金は現在、インターネット協会によって提供されています。