RFC4247 日本語訳
4247 Requirements for Header Compression over MPLS. J. Ash, B. Goode,J. Hand, R. Zhang. November 2005. (Format: TXT=25127 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Ash
Request for Comments: 4247 B. Goode
Category: Informational J. Hand
AT&T
R. Zhang
BT Infonet
November 2005
コメントを求めるワーキンググループJ.灰の要求をネットワークでつないでください: 4247年のB.グードカテゴリ: 情報のJ.のAT&T R.チャンBT Infonet手の2005年11月
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)インターネット協会(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ラベルが加えられるとき、これはMPLS声/RTP/UDP/IP/ラベルになります。 MPLS VPNに関しては、パケットのヘッダーは通常48バイトですが、例えば、しばしば声のペイロードは30バイト未満です。 ヘッダー圧縮は様々な圧縮機構を通してオーバーヘッドをかなり下げることができます、高められた圧縮されたRTP(ECRTP)や体力を要しているヘッダー圧縮(ROHC)のように。 私たちは、圧縮/減圧サイクルなしで各ルータでMPLS Label Switched Path(LSP)の上に圧縮されたパケットを発送するのにMPLSを使用すると考えます。 このアプローチは各ルータにヘッダー圧縮を使用する同時の流れの最大数の処理スケーラビリティと同様に帯域幅効率を増加させることができます。 本書では、私たちは声明、目標、要件、および例のシナリオを問題に与えます。
Ash, et al. Informational [Page 1] RFC 4247 Requirements for Header Compression over MPLS November 2005
灰、他 MPLS2005年11月の間のヘッダー圧縮のための情報[1ページ]のRFC4247要件
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
1. 序論…2 2. 問題声明…3 2.1. 要件の仕様…4 3. 目標と要件…5 4. 候補濃度法と必要性…6 5. 例のシナリオ…7 6. セキュリティ問題…8 7. 標準の参照…8 8. 有益な参照…9 9. 承認…10
1. Introduction
1. 序論
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]が加えられるとき、これはMPLS声/RTP/UDP/IP/ラベルになります。 MPLS Virtual兵士のNetwork(VPN)(例えば、[MPLS-VPN])において、パケットのヘッダーは少なくとも48バイトですが、例えば、しばしば声のペイロードは30バイト未満です。 ヘッダー圧縮(HC)への関心は、高められた圧縮されたRTP[ECRTP]や体力を要しているヘッダー圧縮などの様々な圧縮機構[ROHC]を通してオーバーヘッドをかなり下げる可能性を利用して、また、HCのスケーラビリティを増加させることです。 私たちは、圧縮/減圧サイクルなしで各ルータでMPLS Label Switched Path(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を実行するために、イングレスルータ/ゲートウェイはHCアルゴリズムをIPパケットに適用しなければならないでしょう、そして、圧縮されたパケットはMPLSラベルを使用することでMPLS LSPに掘られました、そして、圧縮されたヘッダーはHCセッションが終わる出口ルータ/ゲートウェイで減圧されるでしょう。 図1はいくつかのルータに交差するLSPで確立されたMPLSセッションの間、HCを例証します、R1/HCから-->R2-->R3-->R4/HD。(そこでは、R1/HCがHCが実行されるところのイングレスルータであり、R4/HDはヘッダー減圧(HD)が完了しているところの出口ルータです)。 RTP/UDP/IPヘッダーのHCはR1/HCで実行されます、そして、圧縮されたパケットはR1/HCからR2までR3と、そして、最終的なR4/HDにMPLSラベルを使用することで発送されます、一層の減圧/再圧縮サイクルなしで。 必要であるようにRTP/UDP/IPヘッダーをR4/HDで減圧して、他のルータに送ることができます。
Ash, et al. Informational [Page 2] RFC 4247 Requirements for Header Compression over MPLS November 2005
灰、他 MPLS2005年11月の間のヘッダー圧縮のための情報[2ページ]のRFC4247要件
_____
| |
|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
|_____|
_____ | | |R1/HC| ヘッダー圧縮(HC)は働きました。|_____| | | MPLS圧縮された声/ヘッダー/ラベルV_____ | | | R2| |_____| | | MPLS圧縮された声/ヘッダー/ラベルV_____ | | | R3| |_____| | | MPLS圧縮された声/ヘッダー/ラベルV_____ | | |R4/HD| ヘッダー減圧(HD)は働きました。|_____|
Figure 1. Example of Header Compression over MPLS
over Routers R1-->R4
図1。 ルータR1の上のMPLSの上のヘッダー圧縮に関する例-->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圧縮された声/ヘッダー/ラベルを輸送します、1パケットあたり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では、例のシナリオを与えます。
2. Problem Statement
2. 問題声明
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
序論で説明されるように、MPLSの上のHCはHCメカニズムを通してヘッダーオーバーヘッドをかなり下げることができます。HCの必要性は帯域幅が、より少ないのですが、またそれも背骨施設で重要であるかもしれない低速リンクで重要であるかもしれません、特にコストが高いところで(例えばいくつかのグローバルな断面図)。 VoIPは声の圧縮機構(例えば、G.729)を通常使用するでしょう。
Ash, et al. Informational [Page 3] RFC 4247 Requirements for Header Compression over MPLS November 2005
灰、他 MPLS2005年11月の間のヘッダー圧縮のための情報[3ページ]のRFC4247要件
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.
帯域幅を保存する低速で国際的なルート。 HCと共に、かなり多くの帯域幅を救うことができました。 例えば、携帯が大きい国内のネットワークの全体の声の負荷のために3億でヘッダーを解凍したか、または、より多くの1日あたりの呼び出しがおよそ20-40の注文のときにヘッダーのために背骨ネットワークで単独で1秒あたりのギガビットを消費するかもしれません。 このオーバーヘッドはかなりの帯域幅容量に翻訳されることができました。
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を超えるかもしれませんが。 したがって、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.
したがって、提案はRTP/UDP/IPヘッダーの輸送をMPLSネットワークの上では、より効率的にするのにMPLSラベルと共に既存のHCのテクニックを使用することです。 しかしながら、このとき、MPLSの上にHCの規格が全くありません、そして、業者はそのようなテクニックを実行していません。
2.1. Specification of Requirements
2.1. 要件の仕様
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは中[主要な]で説明されるように本書では解釈されることであるべきですか?
Ash, et al. Informational [Page 4] RFC 4247 Requirements for Header Compression over MPLS November 2005
灰、他 MPLS2005年11月の間のヘッダー圧縮のための情報[4ページ]のRFC4247要件
3. Goals and Requirements
3. 目標と要件
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:
したがって、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。 効率的な輸送、パケット損失への寛容、およびセッション文脈bの損失への抵抗に備えるためにRTP/UDP/IPヘッダーを圧縮するのに、既存のプロトコル(例えば、[ECRTP]、[ROHC])を使用しなければなりません。 MPLS LSPの上にHCを許容して、その結果、ホップごとの圧縮/減圧サイクル(例えば、[HC-MPLS-プロト])cを避けなければなりません。 ジター増加する遅れ、パケット損失、およびdによる増加の性能退行を最小にしなければなりません。 文脈識別と制御情報(例えば、[RSVP]、[RSVP-TE][自由民主党])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バイトのラベルがLSPがMPLSネットワークを通してイングレスLabel Switching Router(LSR)から出口LSPに切り替わるのを許容するためにIPパケットに追加されるのを可能にします。 しかしながら、MPLSは、パケットが出口LSRに整然とした状態で到着するのを保証しません、多くのもので順序が狂ってパケットを届けることができたので。 例えば、LSPルーティングが失敗で変えることができたリンク、恐らくMPLSへの支払われるべきものが行われながら、速くコースを変更するか、またはInteriorに、ゲートウェイプロトコル(IGP)と別のものに一点に集まるLabel Distributionプロトコル(自由民主党)は他中で可能な理由を発送します。 他の原因はIGPが'ゆるいホップ'のためLSPで別ルートで送るインクルード、またはIGPに反射して戻るのが別ルートで送るBGPルート変化をそうすることができました。 HCアルゴリズムはおよそ10のパケットの注文のときに再命令の大きさを扱うことができるかもしれません。(パケットはIGP reconvergence(通常、秒の注文での)に必要である時間をHCアルゴリズムに支持できなくするかもしれません)。 他方では、MPLSは断食がHCアルゴリズムがパケット再命令を扱うためには十分であったかもしれない(50よりmsの注文での)なら速くコースを変更します。 再命令の問題は、MPLS解決策の上でHCの開発でさらに考えられる必要があります。
Ash, et al. Informational [Page 5] RFC 4247 Requirements for Header Compression over MPLS November 2005
灰、他 MPLS2005年11月の間のヘッダー圧縮のための情報[5ページ]のRFC4247要件
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に時々複数のルータを持つことができるので、Resynchronizationと性能は、考えられる必要があります。 複数のルータが経路にある状態でMPLS LSPの上のHCセッションにトンネルを堀ると、往復の遅れとパケット損失の可能性は高められるでしょう、そして、HC文脈はパケット損失のため無効にされるかもしれません。 長い丸い旅行遅れがかかわるとき、HCエラー回復メカニズムは問題を悪化させることができます。
4. Candidate Solution Methods and Needs
4. 候補濃度法と必要性
[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つの州が再連動するまで、それは文脈に関連しているパケットを落とすでしょう。 2時に文脈状態を再連動させるのは終わります、そして、減圧装置はCONTEXT_州パケットをコンプレッサーに伝えます、そして、コンプレッサーは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_州パケット)の使用を最小にするのを助けます。 したがって、ECRTPはパケット損失において、より許容性があるMPLSの上でHCを作って、頻繁な再連動に用心する候補方法です。 ECRTPはセクション3(要件e)に再命令要件を記述するためにいくつかの実現適合を必要とするかもしれません、デフォルト実現がたぶん条件を満たさないので。 ECRTPプロトコル拡張子が、FULL_HEADER、CONTEXT_州、および圧縮されたパケットタイプを特定するのに必要であるかもしれません。 [cRTP-ENCAP]はHCのために定義された別々のリンクレイヤパケットタイプを指定します。 別々のリンクレイヤパケットタイプを使用すると、パケットタイプを特定するために圧縮ヘッダーに余分なビットを加える必要性は避けられます。 しかしながら、このアプローチはMPLSカプセル化コンベンション[MPLS-ENCAP]によく達しません。(そこでは、別々のリンク層のパケットタイプがそれぞれのパケットタイプのために別々のLSPに翻訳します)。 MPLSの上でECRTPをHCに広げるために、[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はセクション3(要件e)に再命令要件を記述するためにいくつかの実現適合を必要とするかもしれません、デフォルト実現がたぶん条件を満たさないので([ROHC-REORD]を見てください)。 ROHCには圧縮ヘッダーというパケットタイプを特定する能力が既にあるので、さらなる拡大は全くパケットタイプを特定するのに必要ではありません。
Ash, et al. Informational [Page 6] RFC 4247 Requirements for Header Compression over MPLS November 2005
灰、他 MPLS2005年11月の間のヘッダー圧縮のための情報[6ページ]のRFC4247要件
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に関してイングレスと出口ルータの間のSession Context ID(SCIDs)スペースを交渉するのに必要であるかもしれません。 例えば、新しい物は、[RSVP-TE]がイングレスと出口ルータの間のSCID空間、および文脈を決定するのに使用されるHCアルゴリズムに合図するように定義される必要があるかもしれません。 そして、これらのHCパケットはRSVP-TE物を使用することによって特定されたSCIDを含んでいます。 また、MPLSトンネルの上でLabel Distributionプロトコル[自由民主党]でHCに合図するのも望ましいです、多くのRFC2547VPN[MPLS-VPN]実現が基本的なLSPシグナル伝達機構として自由民主党を使用して、自由民主党が非常にスケーラブルであるので。 しかしながら、自由民主党への拡大が、MPLS LSPsの上のHCでイングレスと出口ルータの間のSCIDsに合図するのに必要であるかもしれません。 例えば、'狙っている自由民主党のセッション'はシグナリングSCIDs、または恐らく疑似ワイヤに合図するために[自由民主党-PWE3]で説明された方法のために設立されるかもしれません、そして、多点からポイントへのLSPsはHCのためにMPLS LSPsの上でSCIDsのサポートシグナリングに広げられるかもしれません。 これらの承認された要件を支持するためにプロトコル拡大に合図する特定のMPLSは、よく連携している別々のドキュメントとして適切なIETFワーキンググループで開発される必要があります。 それらは分離した部分にありますが、IETFは、2通の解決策ドキュメントのために連携過程を支持する必要があります。
5. Example Scenario
5. 例のシナリオ
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.
サイトはルータによって役立たれています。多くのVoIP流れが図2で例証されるように顧客サイトから溯源される、R1、R2、R3であって、いくつかの大口顧客コールセンターで終えられます。(コールセンターはR5、R6、およびR7によって役立たれています)。 R4はサービスプロバイダールータです、そして、すべてのVoIP流れがR4を横断します。 最大数の同時のVoIP流れを許容するのはR4-R5、R4-R6、およびR4-R7の低速リンクがすべて、HCを使用するのが不可欠です。 R4での処理が同時のVoIP流れのボリュームを扱うのを許容するために、これらの流れにMPLSの上でHCを使用するのは必要です。 MPLSの上のHCと共に、R4は流れのためにコールセンターにHC/HDをする必要はありません、R4のHCと共に同時のVoIP流れの数の、より多くのスケーラビリティを可能にして。
Ash, et al. Informational [Page 7] RFC 4247 Requirements for Header Compression over MPLS November 2005
灰、他 MPLS2005年11月の間のヘッダー圧縮のための情報[7ページ]のRFC4247要件
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
C HDR/MPLS声/ラベル______ C HDR/MPLS声/ラベルR1/HC---------------------->| |----------------------->R5/HD| | C HDR/MPLS声/ラベル| |C HDR/MPLS声/ラベルR2/HC---------------------->| R4|----------------------->R6/HD| | C HDR/MPLS声/ラベル| |C HDR/MPLS声/ラベル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のアプリケーションのための例のシナリオ
6. Security Considerations
6. セキュリティ問題
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が適用されることを引き起こすために適切にマークされたデータ・ストリームにおけるヘッダーと共に。 これは圧縮と減圧を実行しながら、ルータで多量の処理リソースを使用するでしょう、そして、これらの処理リソースはそしてときにルータでの他の重要な機能を入手できないかもしれません。 この脅威は、MPLSの上でHCによってHCのための新しい脅威ではありませんが、記述されて、緩和されます。 すなわち、本書では提案されるように圧縮と減圧サイクルを実行する必要性を減少させることによって、このタイプのサービス不能攻撃の危険は減少します。
7. Normative References
7. 引用規格
[cRTP] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP
Headers for Low-Speed Serial Links", RFC 2508,
February 1999.
[cRTP]Casner、S.、およびRFC2508、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.
2003年7月の[cRTP-ENCAP]EnganとM.とCasnerとS.とボルマン、C.とT.コーレン、「pppの上のIPヘッダー圧縮」RFC3544。
[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]コーレン、T.、Casner、S.、Geevarghese、J.、トンプソン、B.、P. 非常に、「パケット損失とReordering、高値とのリンクへの高められた圧縮されたRTP(CRTP)は延着します」、RFC3545、2003年7月。
[KEY] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
[KEY] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、RFC2119、1997年3月。
Ash, et al. Informational [Page 8] RFC 4247 Requirements for Header Compression over MPLS November 2005
灰、他 MPLS2005年11月の間のヘッダー圧縮のための情報[8ページ]のRFC4247要件
[LDP] Andersson, L., Doolan, P., Feldman, N., Fredette, A.,
and B. Thomas, "LDP Specification", RFC 3036, January
2001.
[自由民主党] アンデションとL.とDoolanとP.とフェルドマンとN.とFredette、A.とB.トーマス、「自由民主党仕様」、RFC3036、2001年1月。
[MPLS-ARCH] Rosen, E., Viswanathan, A., and R. Callon,
"Multiprotocol Label Switching Architecture", RFC
3031, January 2001.
[MPLS-アーチ] ローゼンとE.とViswanathan、A.とR.Callon、「Multiprotocolラベル切り換え構造」、RFC3031、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」、RFC3095、7月2001日
[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の機能的な仕様」、RFC2205、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.、Srinivasan、V.、およびG.が飲み込まれる、「RSVP-Te:」 「LSP TunnelsのためのRSVPへの拡大」、RFC3209、2001年12月。
8. Informative References
8. 有益な参照
[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-プロト] 灰、G.、グード、B.、Hand(J.、イェンソン、L-E.、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.
[自由民主党-PWE3] マティーニ、L.、N.、スミス、T.、G.Heron、および「ラベル分配プロトコルを使用するPseudowireセットアップと維持」というEl-Aawarは進行中で働いています。
[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ラベルスタックコード化」、RFC3032(2001年1月)。
[MPLS-VPN] Rosen, E. and Y. Rekhter, "BGP/MPLS VPNs", RFC 2547,
March 1999.
1999年の[MPLS-VPN]ローゼンとE.とY.Rekhter、「BGP/MPLS VPNs」、RFC2547行進。
[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):」 「Channelsの上のそうすることができるROHC、Reorder Packets、」 仕事進行中です。
Ash, et al. Informational [Page 9] RFC 4247 Requirements for Header Compression over MPLS November 2005
灰、他 MPLS2005年11月の間のヘッダー圧縮のための情報[9ページ]のRFC4247要件
9. Acknowledgements
9. 承認
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アンデション、スコット縁、トーマス・エリクソン、ビクトリアFineberg、ラース-エリック・イェンソン、アリソン・マンキン、コリン・パーキンス、クリストファSandlund、およびマグヌス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
MT D5-2A01 200ローレルアベニューミドルタウン、ニュージャージー 07748、米国が電話をするジェリー灰のAT&T部屋: +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メール: 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
MT A2-1A03 200ローレルアベニューミドルタウン、ニュージャージー 07748、米国が電話をするジム手のAT&T部屋: +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 Infonet2160のE.の壮大なAve。 カリフォルニア90025エルセガンド(米国)はメールされます: raymond.zhang@bt.infonet.com
Ash, et al. Informational [Page 10] RFC 4247 Requirements for Header Compression over MPLS November 2005
灰、他 MPLS2005年11月の間のヘッダー圧縮のための情報[10ページ]のRFC4247要件
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Ash, et al. Informational [Page 11]
灰、他 情報[11ページ]
一覧
スポンサーリンク
