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
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).
著作権（C）インターネット協会（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.
ボイスオーバーIP（VoIP）は、通常のカプセル化音声/ RTP / UDP / IPを使用しています。 MPLSラベルが追加されると、これは、音声/ RTP / UDP / IP / MPLS-ラベルになります。音声ペイロードは、例えば、多くの場合、これ以上30バイト以内であるMPLS VPNのために、パケットのヘッダには、典型的には48バイトです。ヘッダ圧縮はかなり様々なそのような増強圧縮RTP（ECRTP）などの圧縮機構、及びロバストヘッダ圧縮（ROHC）を介してオーバーヘッドを低減することができます。私たちは、各ルータでの圧縮/解凍サイクルなしのMPLSラベルスイッチパス（LSP）の上にルート圧縮されたパケットのMPLSを使用して検討してください。このアプローチは、各ルータでのヘッダ圧縮を使用する同時フローの最大数の帯域幅効率ならびに処理のスケーラビリティを高めることができます。この文書では、我々は問題文の、目標と要件、およびシナリオの例を与えます。
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.
ボイスオーバーIP（VoIP）は、通常のカプセル化音声/ RTP / UDP / IPを使用しています。 MPLSラベル[MPLS-ARCH]が追加されると、これは、音声/ RTP / UDP / IP / MPLS-ラベルになります。音声ペイロードは、例えば、しばしばせいぜい30バイトでない間MPLS仮想プライベートネットワーク（VPN）（例えば、[MPLS-VPN]）の場合、パケットヘッダは、少なくとも48バイトです。ヘッダ圧縮（HC）への関心が大きく、このような強化された圧縮RTP [ECRTP]又はロバストヘッダ圧縮[ROHC]と同様に、様々な圧縮メカニズムを介してオーバーヘッドを低減する可能性を活用するために、また、HCのスケーラビリティを増加させることです。私たちは、各ルータでの圧縮/解凍サイクルなしのMPLSラベルスイッチパス（LSP）の上にルート圧縮されたパケットのMPLSを使用して検討してください。 MPLS能力を超えるようなHCは、帯域幅効率ならびに各ルータで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を実装するために、入口ルータ/ゲートウェイは、IPパケットにHCアルゴリズムを適用しなければならない、圧縮されたパケットは、MPLSラベルを使用して、MPLS LSPにルーティングされ、圧縮されたヘッダは、どこ出口ルータ/ゲートウェイに伸張されますHCセッションが終了します。図1は、いくつかのルータを横断するLSP上に確立されたMPLSセッション上HCを示すR1 / HCから - R1 / HCがHCが行われる入口ルータである> R4 / HD、および - > R2 - > R3 R4 / HDは、ヘッダ復元（HD）が行われる出口ルータです。さらに減圧/再圧縮サイクルなしで、RTP / UDP / IPヘッダのHCは、R1 / HCで行われ、そして圧縮されたパケットはR3に、R2とR1 / HCからMPLSラベルを使用してルーティングされ、最後にR4 / HDへ。 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
ルータR1オーバーMPLSにおけるヘッダ圧縮図1の例 - > 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パスではなく音声の音声/圧縮されたヘッダ/ MPLS-ラベルを輸送/ RTP / UDP / IP / 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で、かなり多くの帯域幅を保存することができました。例えば、単独のヘッダーのバックボーンネットワーク上の毎秒約20〜40ギガビットのために消費できた一日あたり300万ドル以上のコールで大規模な国内ネットワークの全体音声負荷のために圧縮されていないヘッダを運びます。このオーバーヘッドはかなりの帯域幅容量に変換できます。
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）が流れる必要がハイエンドケースのため300-500を超えるかもしれないが、そのアップリンクスピードと処理能力に依存して、約30-50典型的な顧客宅内ルータのためのものです。したがって、MPLSオーバーHCは、中間ノードでのコストのかかる処理要求を導入することなく、圧縮のメリットを得るために実行可能な代替であると思われます。 MPLS上にHCを使用して、ルータは、単に前方それによってルータが処理できる同時圧縮フローの最大数を増やす、減圧/再圧縮サイクルを行うことなく、パケットを圧縮しました。
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ネットワーク上でRTP / UDP / IPヘッダの輸送をより効率的にするために、一緒にMPLSラベルで、既存のHCの技術を使用することです。しかし、この時点では、そこにMPLSオーバー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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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。フローの多数、CにHCのスケーラビリティを増加させます。大幅パケット遅延、遅延変動、または損失確率、およびDを増加させません。できるだけ多くの標準プロトコルを使用して活用し、既存の作品。
Therefore the requirements for HC over MPLS are as follows:
次のようにそのためMPLSオーバー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。セッションコンテキストの損失に効率的な輸送、パケット損失に対する耐性、及び抵抗を提供するために、RTP / UDP / IPヘッダを圧縮するために既存のプロトコル（例えば、[ECRTP]、[ROHC]）を使用しなければなりません。 B。 MPLS LSP上HCを可能にし、それにより、回避しなければならないホップバイホップ圧縮/解凍サイクル（例えば、[HC-MPLS-プロト]）。 C。増加による遅延、パケット損失、およびジッタに増分パフォーマンスの低下を最小限にしなければなりません。 D。情報をコンテキスト識別信号及び制御するための標準プロトコルを使用しなければならない（例えば、[RSVP]、[RSVP-TE]、[LDP]）。電子。パケット並べ替えが間違って解凍器から転送するパケットを解凍引き起こしてはなりません。
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バイトのラベルがMPLSネットワークを通じてLSP上の出口LSPへのルータ（LSR）をイングレスラベルスイッチの切り替え可能にするIPパケットに付加されることを可能にします。物事の数は、パケットが順不同で配信される可能性がありますので、MPLSは、パケットが出力LSRで順番に到着することを保証するものではありません。たとえば、リンク障害は、LSPのルーティングが行われているMPLS高速リルートに、または内部ゲートウェイプロトコル（IGP）と他の考えられる理由の中で、他の経路に収束するラベル配布プロトコル（LDP）におそらく起因変更する可能性があります。他の原因は、IGPが原因LSPの「ルーズホップ」に再ルーティング、またはBGPルート変更がバックIGP再ルーティングに反映含むことができます。 HCアルゴリズムはHCアルゴリズムのIGPの再収束に必要な時間（典型的には秒のオーダー）は支持できないことがあり、約10パケット、の順に並び替え大きさを扱うことができるかもしれません。一方、MPLS高速リルートは、パケット並べ替えを処理する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パケットを送信します。
[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そのため、パケットロスのMPLSオーバーHCがより寛容にすると、頻繁な再同期化を防ぐために候補方法です。デフォルトの実装は、おそらく要件を満たしていないのでECRTPは、第3節（要件E）で並べ替え要件に対処するために、いくつかの実装の適応が必要な場合があります。 ECRTPプロトコル拡張はFULL_HEADER、CONTEXT_STATE、及び圧縮されたパケットの種類を識別するために必要とされ得ます。 [cRTPの-ENCAP]はHCに対して定義された別のリンク層パケットのタイプを指定します。別のリンク層パケットタイプを使用すると、パケットの種類を識別するために、圧縮ヘッダに余分なビットを追加する必要性を回避します。しかし、このアプローチは、別のリンク層のパケットタイプは、各パケットタイプのための別々のLSPに変換されたMPLSカプセル化規則[MPLS-ENCAP]によく延びていません。 MPLS上HCにECRTPを拡張するために、[ECRTP]で定義された各パケットタイプはECRTPヘッダで追加パケットタイプフィールドにおいて識別される必要があります。
[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]もパケット損失の非常に寛容であり、したがって、頻繁な再同期化を防ぐために、候補の方法です。 ECRTPと比較してROHCは、圧縮の幾分良好レベルを達成します。デフォルトの実装は、おそらく要件を満たしていますので、ROHCは、（[ROHC-REORD]参照）、第3（要件E）で並べ替え要件に対処するために、いくつかの実装の適応が必要な場合があります。 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シグナリングの拡張は、HD出力点にHCからLSPを識別使用HCアルゴリズム及びプロトコルパラメータをネゴシエートし、MPLS LSPに入力および出力ルータ間のセッションコンテキストID（SCIDs）空間を交渉するために必要とされてもよいです。例えば、新しいオブジェクトは、入口と出口ルーターとの間のSCIDスペース、およびコンテキストを決定するために使用されるHCアルゴリズムを知らせる[RSVP-TE]のために定義される必要があるかもしれません。これらのHCパケットは、RSVP-TEオブジェクトを使用して識別SCIDが含まれています。多くのRFC 2547 VPN [MPLS-VPN]実装は、基礎となるLSPシグナリングメカニズムとしてLDPを使用し、LDPは非常に拡張性があるので、ラベル配布プロトコル[LDP]でMPLSトンネル上HCをシグナリングすることも望ましいです。しかし、自民党への拡張は、MPLS LSPを超えるHCに入力および出力ルータ間SCIDsに信号を送るために必要とすることができます。例えば、SCIDsシグナリングのために確立されるかもしれない、またはおそらく方法は、疑似ワイヤを知らせる[LDP-PWE3]に記載のマルチポイント・ツー・ポイントのLSPは、MPLSのLSP上HCためSCIDsのシグナリングをサポートするように拡張されるかもしれない「LDPセッションがターゲット」 。これらの承認要件をサポートするためのプロトコル拡張を知らせる特定の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低速リンクのすべてが同時のVoIPフローの最大数を許可するようにHCを使用することが不可欠です。 R4での処理は同時のVoIPフローの量を処理できるようにするために、これらのフローのためのMPLS上でHCを使用することが望まれます。 MPLSオーバーHCで、R4は、コールセンターへの流れのためのHC / HDを行う必要はありません、同時VoIPの数のより多くのスケーラビリティを有効にすると、R4でHCと流れています。
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
Figure 2. Example Scenario for Application of HC over MPLS
MPLS上HCの適用については、図2の例のシナリオ
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サービス妨害（DoS）攻撃のターゲットになります。例えば、攻撃者は、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.ヤコブソン、RFC 2508、1999年2月 "低速シリアルリンクのIP / UDP / RTPヘッダの圧縮"。
[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.、ボルマン、C.、およびT.コレン、 "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.
、RFC 3545、 "高遅延、パケットロス・順序付きリンクの拡張圧縮RTP（CRTP）" [ECRTP]コレン、T.、Casner、S.、Geevarghese、J.、トンプソン、B.、およびP.ルディ、 2003年7月。
[KEY] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997.
[KEY]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、RFC 2119、1997年3月。
[LDP] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and B. Thomas, "LDP Specification", RFC 3036, January 2001.
[LDP]アンデション、L.、Doolan、P.、フェルドマン、N.、Fredette、A.、およびB.トーマス、 "LDP仕様"、RFC 3036、2001年1月。
[MPLS-ARCH] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[MPLS-ARCH]ローゼン、E.、Viswanathanの、A.、およびR. Callon、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]ボルマン、C.ら、 "ロバストヘッダ圧縮（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]ブレーデン、R.、チャン、L.、Berson氏、S.、ハーツォグ、S.、およびS.ヤミン、 "リソース予約プロトコル（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.、バーガー、L.、ガン、D.、李、T.、スリニヴァサン、V.、およびG.ツバメ、 "RSVP-TE：Extensionsが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]アッシュ、G.、グッド、B.、手、J.、ジョンソン、LE。、Malis、A.、およびR.張、 "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]マティーニ、L.、エル・Aawar、N.、スミス、T.、およびG.サギ、 "ラベル配布プロトコルを使用して擬似回線の設定とメンテナンス"。
[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]ローゼン、E.、タッパン、D.、Fedorkow、G.、Rekhter、Y.、ファリナッチ、D.、李、T.、およびA.コンタ、 "MPLSラベルスタックエンコーディング"、RFC 3032、 2001年1月。
[MPLS-VPN] Rosen, E. and Y. Rekhter, "BGP/MPLS VPNs", RFC 2547, March 1999.
[MPLS-VPN]ローゼン、E.およびY. Rekhter、 "BGP / MPLS VPNの"、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]ペルティエ、G.、ジョンソン、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.
ロア・アンダーソン、スコット・ブリム、トーマス・エリクソン、ビクトリアFineberg、ラース・エリックジョンソン、アリソンマンキン、コリンパーキンス、クリストファーSandlund、およびマグヌスウェスター：作者は彼らの役に立つコメントと提案のために（アルファベット順）以下の人々に感謝したいです。
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ローレルアベニューミドルタウン、NJ 07748、USA電話：+1 732-420-4578電子メール：gash@att.com
Bur Goode AT&T Phone: + 1 203-341-8705 EMail: bgoode@att.com
バール・グッドAT＆T電話：+ 1 203-341-8705 Eメール：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
ジム・ハンドAT＆TルームMT A2-1A03 200ローレルアベニューミドルタウン、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
レイモンド・チャンBTインフォネット2160 E.グランドアベニューエル・セグンド、CA 90025 USA電子メール：raymond.zhang@bt.infonet.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。