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