Network Working Group L. Martini, Ed.
Request for Comments: 4906 E. Rosen, Ed.
Category: Historic Cisco Systems, Inc.
N. El-Aawar, Ed.
Level 3 Communications, LLC
June 2007
Transport of Layer 2 Frames Over MPLS
Status of This Memo
このメモのステータス
This memo defines a Historic Document for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための歴史的な文書を定義します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
Abstract
抽象
This document describes methods for transporting the Protocol Data Units (PDUs) of layer 2 protocols such as Frame Relay, Asynchronous Transfer Mode (ATM) Adaption Layer 5 (AAL5), and Ethernet, and for providing a Synchronized Optical Network (SONET) circuit emulation service across an MPLS network. This document describes the so-called "draft-martini" protocol, which has since been superseded by the Pseudowire Emulation Edge to Edge Working Group specifications described in RFC 4447 and related documents.
この文書では、フレームリレー、非同期転送モード（ATM）の適応レイヤ5（AAL5）、およびイーサネットなどのレイヤ2プロトコルのプロトコルデータユニット（PDU）を輸送するための、および同期光ネットワーク（SONET）回線エミュレーションを提供する方法を説明しMPLSネットワーク上のサービス。この文書では、以来、RFC 4447および関連するドキュメントで説明したワーキンググループの仕様をEdgeに擬似ワイヤエミュレーションエッジに取って代わられている、いわゆる「ドラフト・マティーニ」プロトコルを、説明しています。
Table of Contents
目次
1. Introduction ....................................................3
2. Specification of Requirements ...................................3
3. Special Note ....................................................3
4. Tunnel Labels and Virtual Circuit (VC) Labels ...................4
5. Protocol-Specific Details .......................................5
5.1. Frame Relay ................................................5
5.2. ATM ........................................................6
5.2.1. ATM AAL5 VCC Transport ..............................6
5.2.2. ATM Transparent Cell Transport ......................6
5.2.3. ATM VCC and VPC Cell Transport ......................6
5.2.4. OAM Cell Support ....................................6
5.2.5. ILMI Support ........................................7
5.3. Ethernet VLAN ..............................................7
5.4. Ethernet ...................................................8
5.5. HDLC .......................................................8
5.6. PPP ........................................................8
6. LDP .............................................................8
6.1. Interface Parameters Field ................................10
6.2. C Bit Handling Procedures .................................12
6.2.1. VC Types for Which the Control Word is REQUIRED ....12
6.2.2. VC Types for Which the Control Word is NOT
Mandatory ..........................................12
6.2.3. Status Codes .......................................15
6.3. LDP Label Withdrawal Procedures ...........................15
6.4. Sequencing Considerations .................................15
6.4.1. Label Mapping Advertisements .......................15
6.4.2. Label Mapping Release ..............................16
7. IANA Considerations ............................................16
8. Security Considerations ........................................16
9. Normative References ...........................................17
10. Informative References ........................................18
11. Co-Authors ....................................................18
In an MPLS network, it is possible to carry the Protocol Data Units (PDUs) of layer 2 protocols by prepending an MPLS label stack to these PDUs. This document specifies the necessary label distribution procedures for accomplishing this using the encapsulation methods in [RFC4905]. We restrict discussion to the case of point-to-point transport. Quality of service (QoS)-related issues are not discussed in this document. This document describes methods for transporting a number of protocols; in some cases, transporting a particular protocol may have several modes of operation. Each of these protocols and/or modes may be implemented independently.
MPLSネットワークでは、これらのPDUにMPLSラベルスタックを付加することにより、レイヤ2プロトコルのプロトコルデータユニット（PDU）を実行することが可能です。このドキュメントは[RFC4905]でのカプセル化方法を用いてこれを達成するために必要なラベル分配手順を指定します。私たちは、ポイント・ツー・ポイントの輸送の場合に議論を制限します。サービスの品質（QoS）は、問題はこのドキュメントで説明されていません - 関連しました。この文書では、多くのプロトコルを輸送するための方法を説明し、いくつかのケースでは、特定のプロトコルを輸送することはいくつかの動作モードを有することができます。これらのプロトコルおよび/またはモードの各々は、独立して実現されてもよいです。
An accompanying document [CEM] also describes a method for transporting time division multiplexed (TDM) digital signals (TDM circuit emulation) over a packet-oriented MPLS network. The transmission system for circuit-oriented TDM signals is the Synchronous Optical Network (SONET) [ANSI.T1.105] / Synchronous Digital Hierarchy (SDH) [ITU.G.707]. To support TDM traffic, which includes voice, data, and private leased line service, the MPLS network must emulate the circuit characteristics of SONET/SDH payloads. MPLS labels and a new circuit emulation header are used to encapsulate TDM signals and provide the Circuit Emulation Service over MPLS (CEM).
添付文書は、[CEM]また、パケット指向型MPLSネットワーク上で時分割多重（TDM）デジタル信号（TDM回路エミュレーション）を輸送するための方法を記載しています。回路指向のTDM信号の伝送方式は、同期光ネットワーク（SONET）ANSI.T1.105] /同期デジタルハイアラーキ（SDH）ITU.G.707]です。音声、データ、およびプライベート専用線サービスを含んでTDMトラフィックを、サポートするために、MPLSネットワークは、SONET / SDHペイロードの回路特性をエミュレートする必要があります。 MPLSラベルと新しい回線エミュレーションヘッダはTDM信号をカプセル化し、MPLS（CEM）で回線エミュレーションサービスを提供するために使用されます。
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 [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
This document describes the so-called "draft-martini" protocol, which is used in many deployed implementations. This document and its contents have since been superseded by the Pseudowire Emulation Edge to Edge Working Group specifications: [RFC4447], [RFC4385], [RFC4448], [RFC4717], [RFC4618], [RFC4619], [RFC4553], [RFC4842], and related documents. This document serves as a documentation of current implementations, and MUST NOT be used for new implementations. The PWE3 Label Distribution Protocol (LDP) control document [RFC4447], which is backward compatible with this document, MUST be used for all new implementations of this protocol.
この文書は、多くの展開の実装で使用されている、いわゆる「ドラフト・マティーニ」プロトコルを、説明しています。この文書およびその内容は、以来、ワーキンググループの仕様をEdgeにスードワイヤ・エミュレーション・エッジによって取って代わられています[RFC4447]、[RFC4385]、[RFC4448]、[RFC4717]、[RFC4618]、[RFC4619]、[RFC4553]、[RFC4842 ]、及び関連文書。このドキュメントは、現在の実装のドキュメントとして機能し、新しい実装のために使用してはいけません。本文書との下位互換性があるPWE3ラベル配布プロトコル（LDP）コントロールドキュメント[RFC4447]は、このプロトコルの全ての新しい実装のために使用されなければなりません。
Suppose it is desired to transport layer 2 PDUs from ingress Label Switching Router (LSR) R1 to egress LSR R2, across an intervening MPLS network. We assume that there is a Label Switched Path (LSP) from R1 to R2. That is, we assume that R1 can cause a packet to be delivered to R2 by pushing some label onto the packet and sending the result to one of its adjacencies. Call this label the "tunnel label", and the corresponding LSP the "tunnel LSP".
介在するMPLSネットワーク上で、出口LSR R2にルータ（LSR）R1イングレスラベルスイッチからレイヤ2 PDUを搬送することが望まれると仮定する。私たちは、R1からR2へのラベルスイッチパス（LSP）があることを前提としています。つまり、私たちは、R1は、パケット上にいくつかのラベルをプッシュし、その隣接の1に結果を送信することにより、パケットがR2に配信される可能性がありますことを前提としています。 「トンネルラベル」このラベルを呼び出して、対応するLSP「トンネルLSP」。
The tunnel LSP merely gets packets from R1 to R2; the corresponding label doesn't tell R2 what to do with the payload. In fact, if penultimate hop popping is used, R2 may never even see the corresponding label. (If R1 itself is the penultimate hop, a tunnel label may not even get pushed on.) Thus, if the payload is not an IP packet, there must be a label, which becomes visible to R2, that tells R2 how to treat the received packet. Call this label the "VC label".
トンネルLSPは単にR1からR2にパケットを取得します。対応するラベルは、ペイロードをどうするかR2を教えてくれありません。最後から二番目のホップポッピングが使用されている場合、実際には、R2でも対応するラベルを見ることはないことがあります。 （R1自体は最後から二番目のホップである場合、トンネルラベルが偶数で押されないことがあります。）したがって、ペイロードがIPパケットでない場合、R2に見えるようになるラベルが存在しなければならない、すなわち治療する方法をR2に指示しますパケットを受信しました。 「VCラベル」このラベルを呼び出します。
So when R1 sends a layer 2 PDU to R2, it first pushes a VC label on its label stack, and then (if R1 is not adjacent to R2) pushes on a tunnel label. The tunnel label gets the MPLS packet from R1 to R2; the VC label is not visible until the MPLS packet reaches R2. R2's disposition of the packet is based on the VC label.
そうR1がR2にレイヤ2 PDUを送信するとき、それは最初にラベルスタックにVCラベルを押し、その後は（R1がR2に隣接していない場合）、トンネルラベルに押します。トンネルラベルは、R1からR2へのMPLSパケットを取得します。 MPLSパケットがR2に到達するまでVCラベルは表示されません。パケットのR2の配置はVCラベルに基づいています。
Note that the tunnel could be a Generic Routing Encapsulation (GRE)- encapsulated MPLS tunnel between R1 and R2. In this case, R1 would be adjacent to R2, and only the VC label would be used, and the intervening network need only carry IP packets.
R1とR2の間に封入されたMPLSトンネル - トンネルは総称ルーティングカプセル化（GRE）とすることができることに留意されたいです。この場合、R1はR2に隣接するだろう、とだけVCラベルが使用されるだろう、と介在するネットワークは、IPパケットを運ぶだけです。
If the payload of the MPLS packet is, for example, an ATM AAL5 PDU, the VC label will generally correspond to a particular ATM VC at R2. That is, R2 needs to be able to infer from the VC label the outgoing interface and the VPI/VCI (Virtual Path Identifier / Virtual Circuit Identifier) value for the AAL5 PDU. If the payload is a Frame Relay PDU, then R2 needs to be able to infer from the VC label the outgoing interface and the DLCI (Data Link Connection Identifier) value. If the payload is an Ethernet frame, then R2 needs to be able to infer from the VC label the outgoing interface, and perhaps the VLAN identifier. This process is unidirectional, and will be repeated independently for bidirectional operation. It is REQUIRED to assign the same VC ID, and VC type for a given circuit in both directions. The group ID (see below) MUST NOT be required to match in both directions. The transported frame MAY be modified when it reaches the egress router. If the header of the transported layer 2 frame is modified, this MUST be done at the egress LSR only.
MPLSパケットのペイロードである場合、例えば、ATM AAL5 PDU、VCラベルは、一般的にR2に特定のATM VCに対応することになります。すなわち、R2が発信インタフェースとAAL5 PDUのVPI / VCI（仮想パス識別子/仮想回線識別子）値をラベルVCから推測できるようにする必要があります。ペイロードは、フレームリレーPDUである場合、R2は、VCラベルから発信インターフェイスとDLCI（データリンク接続識別子）値を推測することができる必要があります。ペイロードがイーサネットフレームである場合、R2は、VCラベルから発信インターフェイス、及び恐らくVLAN識別子を推測することができる必要があります。このプロセスは、単方向で、かつ双方向動作のために独立して繰り返されます。両方向に所与の回路に対して同じVC ID、およびVCタイプを割り当てるために必要とされます。グループIDは、（下記参照）両方の方向に一致させるために必要とされてはいけません。それが出口ルータに到達したときに輸送フレームに変更してもよいです。輸送レイヤ2フレームのヘッダが変更された場合、これが唯一の出口LSRで行われなければなりません。
Note that the VC label must always be at the bottom of the label stack, and the tunnel label, if present, must be immediately above the VC label. Of course, as the packet is transported across the MPLS network, additional labels may be pushed on (and then popped off) as needed. Even R1 itself may push on additional labels above the tunnel label. If R1 and R2 are directly adjacent LSRs, then it may not be necessary to use a tunnel label at all.
存在する場合、すぐにVCラベルを超えていなければならない、VCラベルは、常にラベルスタックの最下部、およびトンネルラベルでなければならないことに注意してください。パケットがMPLSネットワークを横切って輸送されるように、必要に応じてもちろん、追加のラベルが上に押され（そしてポップ）されてもよいです。さえR1自体は、トンネルラベル上記追加のラベルに押すことができます。 R1及びR2は、直接隣接のLSRである場合、すべてのトンネルラベルを使用する必要はないかもしれません。
This document does not specify a method for distributing the tunnel label or any other labels that may appear above the VC label on the stack. Any acceptable method of MPLS label distribution will do.
この文書では、トンネルラベルまたはスタック上のVCラベルの上に表示される可能性のある他のラベルを配布するための方法を指定しません。 MPLSラベル配布の任意の許容可能な方法を行います。
This document does specify a method for assigning and distributing the VC label. Static label assignment MAY be used, and implementations SHOULD provide support for this. When signaling is used, the VC label MUST be distributed from R2 to R1 using LDP in the downstream unsolicited mode; this requires that an LDP session be created between R1 and R2. It should be noted that this LDP session is not necessarily transported along the same path as the Layer 2 PDUs [RFC3036]. In addition, when using LDP to distribute the VC label, liberal label retention mode SHOULD be used. However, as required in [RFC3036], the label request operation (mainly used by conservative label retention mode) MUST be implemented. VC labels MUST be allocated from the per-platform label space.
この文書では、VCラベルを割り当て、分配する方法を指定しません。スタティックラベルの割り当てを使用することができ、実装は、このためのサポートを提供する必要があります。シグナリングが使用される場合、VCラベルは下流迷惑モードLDPを使用して、R2からR1に分配されなければなりません。これは、LDPセッションがR1とR2の間に作成されている必要があります。なお、このLDPセッションが必ずしもレイヤ2 PDU [RFC3036]と同じ経路に沿って搬送されていないことに留意すべきです。 VCラベルを配布するためにLDPを使用する場合に加えて、リベラルラベル保持モードを使用する必要があります。 [RFC3036]で必要に応じて、しかし、（主に保守的なラベル保持モードで使用）、ラベル要求操作が実施されなければなりません。 VCラベルはプラットフォームごとのラベルスペースから割り当てなければなりません。
Note that this technique allows an unbounded number of layer 2 "VCs" to be carried together in a single "tunnel". Thus, it scales quite well in the network backbone.
この技術は、単一の「トンネル」で一緒に実施されるべき層2「VCS」の無制限の数を可能にすることに留意されたいです。このように、ネットワークバックボーンに非常によくスケール。
While this document currently defines the emulation of Frame Relay and ATM Permanent Virtual Circuit (PVC) services, it specifically does not preclude future enhancements to support switched service (Switched Virtual Circuit (SVC) and Switched Permanent Virtual Circuit (SPVC)) emulation.
この文書は現在、フレームリレーやATM固定接続（PVC）のサービスのエミュレーションを定義しますが、それを具体的にサポートするために、将来の拡張を妨げるものではないサービスに切り替え（スイッチドバーチャルサーキット（SVC）をし、恒久仮想回線（SPVC）交換）エミュレーションを。
The Frame Relay PDUs are encapsulated according to the procedures defined in [RFC4905]. The MPLS edge LSR MUST provide Frame Relay PVC status signaling to the Frame Relay network. If the MPLS edge LSR detects a service affecting condition, as defined in [Q.933] Annex A.5 cited in Implementation Agreement FRF.1.1, it MUST withdraw the label that corresponds to the frame relay DLCI. The egress LSR SHOULD generate the corresponding errors and alarms as defined in [Q.933] on the egress Frame relay VC.
フレームリレーPDUは[RFC4905]で定義された手順に従ってカプセル化されます。 MPLSエッジLSRは、フレームリレーネットワークへのシグナリングフレームリレーPVCのステータスを提供しなければなりません。 MPLSエッジLSRは、[Q.933]で定義される条件に影響を与えるサービスを、検出された場合は附属書A.5が実装契約FRF.1.1に引用は、フレームリレーDLCIに対応するラベルを撤回しなければなりません。 EgressフレームリレーVCの[Q.933]で定義されるように出口LSRは、対応するエラーとアラームを生成する必要があります。
ATM AAL5 Common Part Convergence Sublayer - Service Data Units (CPCS-SDUs) are encapsulated according to [RFC4905] ATM AAL5 CPCS-SDU mode. This mode allows the transport of ATM AAL5 CSPS-SDUs traveling on a particular ATM PVC across the MPLS network to another ATM PVC.
ATM AAL5共通部コンバージェンスサブレイヤ - サービスデータユニット（CPCS-SDUは）[RFC4905] ATM AAL5 CPCS-SDUモードに従ってカプセル化されます。このモードは、別のATM PVCにMPLSネットワークを横切って特定のATM PVCを走行ATM AAL5 CSPS-SDUの輸送を可能にします。
This mode is similar to the Ethernet port mode. Every cell that is received at the ingress ATM port on the ingress LSR, R1, is encapsulated according to [RFC4905], ATM cell mode, and sent across the LSP to the egress LSR, R2. This mode allows an ATM port to be connected to only one other ATM port. [RFC4905] allows for grouping of multiple cells into a single MPLS frame. Grouping of ATM cells is OPTIONAL for transmission at the ingress LSR, R1. If the Egress LSR R2 supports cell concatenation, the ingress LSR, R1, should only concatenate cells up to the "Maximum Number of concatenated ATM cells" parameter received as part of the FEC element.
このモードでは、イーサネットポートモードと同様です。入口LSR、R1上の入口ATMポートで受信されるすべてのセルは、ATMセルモードは、[RFC4905]に記載のカプセル化、および出口LSR、R2にLSPを介して送信されます。このモードは、ATMポートが一つだけ、他のATMポートに接続することができます。 [RFC4905]は、単一のMPLSフレームに複数のセルをグループ化することを可能にします。 ATMセルのグループは、入口LSR、R1に送信するためのオプションです。出口LSR R2がセル連結をサポートしている場合、入口LSR、R1は、唯一の「連結ATMセルの最大数」のセルを連結しなければならないパラメータは、FEC要素の一部として受信しました。
This mode is similar to the ATM AAL5 Virtual Channel Connection (VCC) transport except that cells are transported. Every cell that is received on a pre-defined ATM PVC or ATM Permanent Virtual Path (PVP), at the ingress ATM port on the ingress LSR, R1, is encapsulated according to [RFC4905], ATM cell mode, and sent across the LSP to the egress LSR R2. Grouping of ATM cells is OPTIONAL for transmission at the ingress LSR, R1. If the egress LSR R2 supports cell concatenation, the ingress LSR, R1, MUST only concatenate cells up to the "Maximum Number of concatenated ATM cells in a frame" parameter received as part of the FEC element.
このモードでは、細胞が輸送されることを除いてATM AAL5仮想チャネル接続（VCC）の輸送に似ています。事前定義されたATM PVCまたはATM永久仮想パス（PVP）で受信されるすべてのセルは、入口LSR、R1上の入口ATMポートで、ATMセルモードは、[RFC4905]に記載のカプセル化され、そしてLSPを介して送信されます出口LSR R2へ。 ATMセルのグループは、入口LSR、R1に送信するためのオプションです。出口LSR R2がセル連結をサポートしている場合、入口LSR、R1、唯一の「フレームに連結されたATMセルの最大数」のセルを連結しなければならないパラメータは、FEC要素の一部として受信しました。
Operations and Management (OAM) cells MAY be transported on the VC LSP. When the LSR is operating in AAL5 CPCS-SDU transport mode, if it does not support transport of ATM cells, the LSR MUST discard incoming MPLS frames on an ATM VC LSP that contain a VC label with the T bit set [RFC4905]. When operating in AAL5 SDU transport mode, an LSR that supports transport of OAM cells using the T bit defined in [RFC4905], or an LSR operating in any of the three cell transport modes, MUST follow the procedures outlined in [FAST] Section 8 for mode 0 only, in addition to the applicable procedures specified in [ITU.G.707].
運用及び管理（OAM）セルはVC LSPに輸送することができます。 LSRは、AAL5 CPCS-SDUの転送モードで動作しているとき、それはATMセルの転送をサポートしていない場合、LSRは、[RFC4905]をビットセットTとVCラベルを含むATM VC LSP上の着信MPLSフレームを捨てなければなりません。 AAL5 SDU輸送[RFC4905]で定義されたTビットを使用して、OAMセルの輸送をサポートするモード、LSR、または3つの細胞輸送モードのいずれかで動作するLSRで動作しているとき、[FAST]セクション8に概説された手順に従わなければなりませんモード0の場合のみ、[ITU.G.707]で指定された適用手順に加えました。
AN LSR that does not support transport of OAM cells across an LSP MAY provide OAM support on ATM PVCs using the following procedures:
LSP全体でOAMセルの輸送をサポートしていないLSRは、以下の手順を使用したATM PVCでOAMのサポートを提供することができます。
A pair of LSRs MAY emulate a bidirectional ATM VC by two unidirectional LSPs. If an F5 end-to-end OAM cell is received from a ATM VC, by either LSR that is transporting this ATM VC, with a loopback indication value of 1, and the LSR has a label mapping for the ATM VC, then the LSR MUST decrement the loopback indication value and loop back the cell on the ATM VC. Otherwise, the loopback cell MUST be discarded by the LSR.
LSRのペアは、2つの単方向のLSPによって双方向ATM VCをエミュレートすることができます。 F5エンドツーエンドOAMセルがATM VCから受信された場合に、1のループバック指示値と、このATM VCを輸送し、LSRは、ATM VCのためのラベルマッピングを有するいずれかのLSRによって、その後、LSR ATM VC上のセルをループバック指示値とループバックデクリメントしなければなりません。それ以外の場合は、ループバックセルはLSRによって捨てなければなりません。
The ingress LSR, R1, may also optionally be configured to periodically generate F5 end-to-end loopback OAM cells on a VC. If the LSR fails to receive a response to an F5 end-to-end loopback OAM cell for a pre-defined period of time it MUST withdraw the label mapping for the VC.
入口LSR、R1は、また、必要に応じて定期的にVCにF5エンドツーエンドループバックOAMセルを生成するように構成されてもよいです。 LSRは、時間の事前定義された期間のためのF5エンドツーエンドループバックOAMセルに対する応答を受信できなかった場合には、VCのためのラベルマッピングを撤回しなければなりません。
If an ingress LSR, R1, receives an AIS (Alarm Indication Signal) F5 OAM cell, or R1 fails to receive a pre-defined number of the End-to-End loop OAM cells, or a physical interface goes down, it MUST withdraw the label mappings for all VCs associated with the failure. When a VC label mapping is withdrawn, the egress LSR, R2, MUST generate AIS F5 OAM cells on the VC associated with the withdrawn label mapping. In this mode it is very useful to apply a unique group ID to each interface. In the case where a physical interface goes down, a wild card label withdraw can be sent to all LDP neighbors, greatly reducing the signaling response time.
イングレスLSR、R1は、AIS（アラーム表示信号）F5 OAMセルを受信、またはR1は、事前に定義されたエンドツーエンドループOAMセルの数、または物理インターフェイスがダウンの受信に失敗した場合、それは撤回しなければなりません失敗に関連付けられているすべてのVCのためのラベルマッピング。 VCラベルマッピングが引き抜かれるときに、出口LSR、R2は、引き出さラベルマッピングに関連付けられているVCにAIS F5 OAMセルを生成しなければなりません。このモードでは、各インターフェイスに固有のグループIDを適用することは非常に便利です。物理インターフェイスがダウンした場合には、ワイルドカードのラベルが撤退大幅シグナリング応答時間を短縮、すべてのLDPネイバーに送信することができます。
An MPLS edge LSR MAY provide an ATM Integrated Local Management Interface (ILMI) to the ATM edge switch. If an ingress LSR receives an ILMI message indicating that the ATM edge switch has deleted a VC, or if the physical interface goes down, it MUST withdraw the label mappings for all VCs associated with the failure. When a VC label mapping is withdrawn, the egress LSR SHOULD notify its client of this failure by deleting the VC using ILMI.
MPLSエッジLSRは、ATMエッジスイッチにATM統合ローカル管理インターフェイス（ILMI）を提供することができます。入口LSRは、ATMエッジスイッチはVCを削除した、または物理インターフェイスがダウンした場合、それは失敗に関連付けられているすべてのVCのためのラベルマッピングを撤回しなければならないことを示すILMIメッセージを受信した場合。 VCラベルマッピングが撤回された場合、出力LSRはILMIを使用してVCを削除することによって、この失敗のそのクライアントに通知する必要があります。
The Ethernet frame will be encapsulated according to the procedures in [RFC4905]. It should be noted that if the VLAN identifier is modified by the egress LSR, according to the procedures outlined above, the Ethernet spanning tree protocol might fail to work properly. If the LSR detects a failure on the Ethernet physical port, or the port is administratively disabled, it MUST withdraw the label mappings for all VCs associated with the port.
イーサネットフレームは、[RFC4905]の手順に従ってカプセル化されるであろう。 VLAN識別子が出口LSRによって変更された場合、上記で概説した手順に従って、スパニングツリープロトコル、イーサネットが正常に動作しないかもしれないことに留意すべきです。 LSRがイーサネット物理ポート上の障害を検出するか、ポートが管理上無効になっている場合は、ポートに関連付けられているすべてのVCのためのラベルマッピングを撤回しなければなりません。
The Ethernet frame will be encapsulated according to the procedures in [RFC4905]. If the LSR detects a failure on the Ethernet physical port, or the port is administratively disabled, the corresponding VC label mapping MUST be withdrawn.
イーサネットフレームは、[RFC4905]の手順に従ってカプセル化されるであろう。 LSRがイーサネット物理ポート上の障害を検出するか、ポートが管理上無効にされている場合、対応するVCラベルマッピングが撤回されなければなりません。
HDLC (High-Level Data Link Control) frames are encapsulated according to the procedures in [RFC4905]. If the MPLS edge LSR detects that the physical link has failed, or the port is administratively disabled, it MUST withdraw the label mapping that corresponds to the HDLC link.
HDLC（ハイレベルデータリンク制御）フレームは、[RFC4905]の手順に従ってカプセル化されます。 MPLSエッジLSRは、物理リンクに障害が発生したことを検出し、またはポートが管理上無効になっている場合、それはHDLCリンクに対応するラベルマッピングを撤回しなければなりません。
PPP frames are encapsulated according to the procedures in [RFC4905]. If the MPLS edge LSR detects that the physical link has failed, or the port is administratively disabled, it MUST withdraw the label mapping that corresponds to the PPP link.
PPPフレームは、[RFC4905]の手順に従ってカプセル化されます。 MPLSエッジLSRは、物理リンクに障害が発生したことを検出し、またはポートが管理上無効になっている場合、それはPPPリンクに対応するラベルマッピングを撤回しなければなりません。
The VC label bindings are distributed using the LDP downstream unsolicited mode described in [RFC3036]. The LSRs will establish an LDP session using the Extended Discovery mechanism described in sections 2.4.2 and 2.5 of [RFC3036]; for this purpose, a new type of FEC element is defined. The FEC element type is 128. Only a single VC FEC element MUST be advertised per LDP VC label. The Virtual Circuit FEC element is defined as follows:
VCラベルバインディングは、[RFC3036]に記載のLDP下流迷惑モードを使用して分配されます。 LSRは、セクション2.4.2及び[RFC3036]の2.5に記載の拡張ディスカバリメカニズムを使用して、LDPセッションを確立します。この目的のために、FEC要素の新しいタイプが定義されています。 FEC要素型は、単一のVC FEC要素はLDP VCラベルごとに公示しなければならない128です。次のように仮想回線FEC要素が定義されています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VC tlv |C| VC Type |VC info Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VC ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface parameters |
| " |
| " |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- VC Type
- VCタイプ
A 15-bit quantity containing a value that represents the type of VC. Assigned values are:
VCの種類を表す値を含む15ビットの数量。割り当てられた値は以下のとおりです。
VC Type Description
VCタイプ説明
0x0001 Frame Relay DLCI 0x0002 ATM AAL5 VCC transport 0x0003 ATM transparent cell transport 0x0004 Ethernet VLAN 0x0005 Ethernet 0x0006 HDLC 0x0007 PPP 0x8008 CEM [CEM] 0x0009 ATM VCC cell transport 0x000A ATM VPC cell transport
0x0001のフレームリレーDLCI 0×0002 ATM AAL5 VCC輸送0x0003 ATM透明細胞輸送0x0004はイーサネットVLAN 0x0005イーサネット0x0006 HDLC 0x0007 PPP 0x8008 CEM [CEM] 0x0009 ATM VCCセル輸送0x000A ATM VPCセル輸送
- Control word bit (C)
- 制御ワードビット（C）
The highest order bit (C) of the VC type is used to flag the presence of a control word (defined in [RFC4905]) as follows:
次のようにVCタイプの最上位ビット（C）は（[RFC4905]で定義された）制御ワードの存在フラグに使用されます。
bit 15 = 1 control word present on this VC.
bit 15 = 0 no control word present on this VC.
Please see Section 6.2, "C Bit Handling Procedures", for further explanation.
さらに説明については、6.2節、「取り扱い手順Cビット」を参照してください。
- VC information length
- VCの情報長
Length of the VC ID field and the interface parameters field in octets. If this value is 0, then it references all VCs using the specified group ID, and there is no VC ID present, nor any interface parameters.
VC IDフィールドとオクテットでのインタフェースパラメータフィールドの長さ。この値が0であれば、それは指定されたグループIDを使用してすべてのVCを参照し、VC IDの存在、また任意のインターフェイスパラメータなしはありません。
- Group ID
- グループID
An arbitrary 32-bit value, which represents a group of VCs that is used to create groups in the VC space. The group ID is intended to be used as a port index, or a virtual tunnel index. To simplify configuration, a particular VC ID at ingress could be part of the virtual tunnel for transport to the egress router. The group ID is very useful to send wild card label withdrawals to remote LSRs upon physical port failure.
VC空間内のグループを作成するために使用されるVCの基を表し、任意の32ビット値、。グループIDは、ポートインデックス、または仮想トンネルのインデックスとして使用されることが意図されています。構成を簡単にするために、入口での特定のVC IDが出口ルータへの輸送のための仮想トンネルの一部とすることができます。グループIDは、物理ポートの障害時にリモートのLSRにワイルドカードラベルの引き出しを送信するために非常に便利です。
- VC ID
- それをデコード
A non-zero 32-bit connection ID that, together with the VC type, identifies a particular VC.
、一緒にVCタイプの非ゼロの32ビット接続IDは、特定のVCを識別する。
- Interface parameters
- インターフェイスパラメータ
This variable length field is used to provide interface-specific parameters, such as interface MTU.
この可変長フィールドは、インターフェースのMTUなどのインターフェイス固有のパラメータを提供するために使用されます。
This field specifies interface-specific parameters. When applicable, it MUST be used to validate that the LSRs, and the ingress and egress ports at the edges of the circuit, have the necessary capabilities to interoperate with each other. The field structure is defined as follows:
このフィールドには、インターフェイス固有のパラメータを指定します。適用可能な場合、のLSR、回路のエッジで入力および出力ポートは、相互運用するために必要な能力を有することを検証するために使用されなければなりません。次のようにフィールド構造が定義されています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parameter ID | Length | Variable Length Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Variable Length Value |
| " |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The parameter ID is defined as follows:
次のようにパラメータIDが定義されています。
Parameter ID Length Description
パラメータID長さ説明
0x01 4 Interface MTU in octets.
0x02 4 Maximum Number of concatenated ATM cells.
0x03 up to 82 Optional Interface Description string.
0x04 4 CEM [CEM] Payload Bytes.
0x05 4 CEM options.
The Length field is defined as the length of the interface parameter including the Parameter ID and Length field itself. Processing of the interface parameters should continue when encountering unknown interface parameters, and they MUST be silently ignored.
Lengthフィールドは、パラメータIDと長さフィールド自体を含むインタフェースパラメータの長さとして定義されます。未知のインターフェイスパラメータに遭遇したときのインターフェイスパラメータの処理は継続すべきである、と彼らは黙って無視しなければなりません。
- Interface MTU
- インターフェイスのMTU
A 2-octet value indicating the MTU in octets. This is the Maximum Transmission Unit, excluding encapsulation overhead, of the egress packet interface that will be transmitting the decapsulated PDU that is received from the MPLS network. This parameter is applicable only to VC types 1, 2, 4, 5, 6, and 7, and is REQUIRED for these VC types. If this parameter does not match in both directions of a specific VC, that VC MUST NOT be enabled.
オクテット内のMTUを示す2オクテット値。これは、MPLSネットワークから受信されデカプセル化PDUを送信する出力パケットインタフェースのカプセル化オーバーヘッドを除く、最大伝送単位です。このパラメータは、VCタイプ1、2、4、5、6、及び7にも適用可能であり、これらのVC型に必要とされます。このパラメータは、特定のVCの両方の方向に一致しない場合は、VCが有効にされてはならないこと。
- Maximum Number of concatenated ATM cells
- 連結されたATMセルの最大数
A 2-octet value specifying the maximum number of concatenated ATM cells that can be processed as a single PDU by the egress LSR. An ingress LSR transmitting concatenated cells on this VC can concatenate a number of cells up to the value of this parameter, but MUST NOT exceed it. This parameter is applicable only to VC types 3, 9, and 0x0a, and is REQUIRED for these VC types. This parameter does not need to match in both directions of a specific VC.
出口LSRによって単一PDUとして処理することができる連結ATMセルの最大数を指定する2オクテットの値。このVCに連結されたセルを送信入口LSRは、このパラメータの値まで細胞の数を連結することができ、それを超えてはなりません。このパラメータは、VCタイプ3、9、とは0x0Aに適用可能であり、これらのVCタイプのために必要です。このパラメータは、特定のVCの両方の方向に一致する必要はありません。
- Optional Interface Description string
- オプションのインターフェイスの説明string
This arbitrary, OPTIONAL interface description string can be used to send an administrative description text string to the remote LSR. This parameter is OPTIONAL, and is applicable to all VC types. The interface description parameter string length is variable, and can be from 0 to 80 octets.
この任意の、オプションのインターフェースの説明文字列は、リモートLSRに行政説明テキスト文字列を送信するために使用することができます。このパラメータはオプションであり、すべてのVCタイプに適用されます。インタフェース記述パラメータの文字列の長さは可変であり、0〜80オクテットであることができます。
- Payload Bytes
- ペイロードバイト
A 2-octet value indicating the number of TDM payload octets contained in all packets on the CEM stream from 48 to 1,023 octets. All of the packets in a given CEM stream have the same number of payload bytes. Note that there is a possibility that the packet size may exceed the Synchronous Payload Envelope (SPE) size in the case of an STS-1 SPE, which could cause two pointers to be needed in the CEM header, since the payload may contain two J1 bytes for consecutive SPEs. For this reason, the number of payload bytes must be less than or equal to 783 for STS-1 SPEs.
48 1,023オクテットからCEMストリーム上のすべてのパケットに含まれるTDMペイロードのオクテットの数を示す2オクテットの値。所与CEMストリーム内のパケットの全ては、ペイロードバイトの数が同じです。ペイロードは、2つのJ1を含有することができるので、二つのポインタは、CEMヘッダに必要とさせる可能性がある、パケットのサイズはSTS-1 SPEの場合に同期ペイロード・エンベロープ（SPE）サイズを超える可能性があることに注意してください連続したSPEのバイト。この理由のために、ペイロードバイトの数はSTS-1 SPEのためのより少ない又は783に等しくなければなりません。
- CEM Options
- CEMオプション
An optional 16-bit value of CEM flags. See [CEM] for the definition of the bit values.
CEMフラグの任意の16ビット値。ビット値の定義については、[CEM]を参照してください。
The Label Mapping messages which are sent in order to set up these VCs MUST have c=1. When a Label Mapping message for a VC of one of these types is received, and c=0, a Label Release MUST be sent, with an "Illegal C-bit" status code. In this case, the VC will not come up.
これらのVCを設定するために送信されたラベルマッピングメッセージは、c = 1を持たなければなりません。これらのタイプのいずれかのVCのラベルマッピングメッセージを受信したとき、およびc = 0、ラベルリリースは「無効なCビットの」ステータスコードと、送信されなければなりません。この場合、VCは起動しません。
If a system is capable of sending and receiving the control word on VC types for which the control word is not mandatory, then each such VC endpoint MUST be configurable with a parameter that specifies whether the use of the control word is PREFERRED or NOT PREFERRED. For each VC, there MUST be a default value of this parameter. This specification does NOT state what the default value should be.
システムは、制御ワードは必須されていないVCタイプにコントロールワードを送信および受信することが可能である場合、そのような各VCエンドポイントは、制御ワードの使用が好ましいまたは好ましくないかどうかを指定するパラメータで設定していなければなりません。各VCのために、このパラメータのデフォルト値があるに違いありません。この仕様は、デフォルト値がどうあるべきかを述べるしません。
If a system is NOT capable of sending and receiving the control word on VC types for which the control word is not mandatory, then it behaves exactly as if it were configured for the use of the control word to be NOT PREFERRED.
システムは、制御ワードは必須されていないVCタイプにコントロールワードを送信および受信することができるされていない場合、それが好ましくないされる制御ワードを使用するように構成されているかのように、それは正確に動作します。
If a Label Mapping message for the VC has already been received, but no Label Mapping message for the VC has yet been sent, then the procedure is the following:
VCのためのラベルマッピングメッセージが既に受信されているが、VCのためのラベルマッピングメッセージはまだ送信されていない場合は、手順は次のとおりです。
-i. If the received Label Mapping message has c=0, send a Label Mapping message with c=0, and the control word is not used.
-私。受信されたLabel MappingメッセージがC = 0を有する場合、C = 0とLabel Mappingメッセージを送信し、制御ワードは使用されません。
-ii. If the received Label Mapping message has c=1, and the VC is locally configured such that the use of the control word is preferred, then send a Label Mapping message with c=1, and the control word is used.
-II。受信したラベルマッピングメッセージは、C = 1を有し、VCが局所的に制御ワードの使用が好適であるように構成されている場合、C = 1とLabel Mappingメッセージを送信し、制御ワードが使用されます。
-iii. If the received Label Mapping message has c=1, and the VC is locally configured such that the use of the control word is not preferred or the control word is not supported, then act as if no Label Mapping message for the VC had been received (i.e., proceed to the next paragraph).
-III。受信したラベルマッピングメッセージは、C = 1を有し、VCが局所的に制御ワードの使用が好まれないように構成されるか、または制御ワードがサポートされていない場合、VCのためのラベルマッピングメッセージが受信されなかったかのように作用します（すなわち、次の段落に進みます）。
If a Label Mapping message for the VC has not already been received (or if the received Label Mapping message had c=1, and either local configuration says that the use of the control word is not preferred or the control word is not supported), then send a Label Mapping message in which the c bit is set to correspond to the locally configured preference for use of the control word. (That is, set c=1 if locally configured to prefer the control word, set c=0 if locally configured to prefer not to use the control word or if the control word is not supported).
VCのためのラベルマッピングメッセージは、すでに受信されていない場合（または受信ラベルマッピングメッセージは、c = 1を持っていた場合、いずれかのローカルコンフィギュレーション制御ワードの使用が好まれていないか、または制御ワードがサポートされていないと述べています）、次いで、Cビットは制御ワードの使用のためにローカルに設定優先に対応するように設定されたラベルマッピングメッセージを送信します。 （局所的に制御ワードを好むように構成されている場合、ローカルに制御ワードを使用しないように構成されている場合、または制御ワードがサポートされていない場合、つまり、セットC = 1、C = 0に設定）。
The next action depends on what control message is next received for that VC. The possibilities are:
次のアクションは、そのVCのために、次に受信されるものを制御メッセージに依存します。可能性があります。
-i. A Label Mapping message with the same c bit value as specified in the Label Mapping message that was sent. VC setup is now complete, and the control word is used if c=1 but not used if c=0.
-私。送信されたLabel Mappingメッセージで指定されたものと同じCビット値を持つLabel Mappingメッセージ。 VCの設定はこれで完了であり、c = 0の場合、C = 1が、使用されていない場合は制御ワードが使用されています。
-ii. A Label Mapping message with c=1, but the Label Mapping message that was sent has c=0. In this case, ignore the received Label Mapping message, and continue to wait for the next control message for the VC.
-II。 C = 1とLabel Mappingメッセージが、送信されたLabel Mappingメッセージは、c = 0を有しています。この場合、受け取ったラベルマッピングメッセージを無視し、VCのための次の制御メッセージを待ち続けています。
-iii. A Label Mapping message with c=0, but the Label Mapping message that was sent has c=1. In this case, send a Label Withdraw message with a "Wrong C-bit" status code, followed by a Label Mapping message that has c=0. VC setup is now complete, and the control word is not used.
-III。 C = 0とLabel Mappingメッセージが、送信されたLabel Mappingメッセージは、c = 1を有しています。この場合、ラベルは、C = Oを有するLabel Mappingメッセージに続いて、「間違ったCビットの」ステータスコードとメッセージを撤回送ります。 VCのセットアップが完了しました、そして制御ワードが使用されていません。
-iv. A Label Withdraw message with the "Wrong C-bit" status code. Treat as a normal Label Withdraw, but do not respond. Continue to wait for the next control message for the VC.
-iv。ラベルは、「間違ったCビットの」ステータスコードとメッセージを撤回します。通常のラベルとして扱い撤回が、応答しません。 VCのための次の制御メッセージを待ち続け。
If, at any time after a Label Mapping message has been received, a corresponding Label Withdraw or Release is received, the action taken is the same as for any Label Withdraw or Release that might be received at any time.
、ラベルマッピングメッセージの後に任意の時点で受信された場合、対応するラベルが撤回またはリリースが受信され、実行されたアクションは撤回またはそのリリースをいつでも受信される可能性があります任意のラベルと同じです。
If both endpoints prefer the use of the control word, this procedure will cause it to be used. If either endpoint prefers not to use the control word, or does not support the control word, this procedure will cause it not to be used. If one endpoint prefers to use the control word but the other does not, the one that prefers not to use it is has no extra protocol to execute; it just waits for a Label Mapping message that has c=0.
両方のエンドポイントが制御ワードの使用を好む場合は、この手順は、それが使用されるようになります。どちらかのエンドポイントが制御ワードを使用しないことを好む、または制御ワードをサポートしていない場合は、この手順を使用してはならないことの原因となります。一方のエンドポイントは、制御ワードを使用することを好むが、他にはない場合は、それを使用しないことを好む1は、実行するための余分なプロトコルを持っていません。それはちょうど、C = 0を持っているラベルマッピングメッセージを待ちます。
The following diagram illustrates the above procedures:
次の図は、上記の手順を示す図です。
------------------
Y | Received Label | N
-------| Mapping Msg? |--------------
| ------------------ |
| |
-------------- |
| | |
| | |
------- ------- |
| C=0 | | C=1 | |
------- ------- |
| | |
| | |
| ---------------- |
| | Control Word | N |
| | Capable? |----------- |
| ---------------- | |
| Y | | |
| | | |
| ---------------- | |
| | Control Word | N | |
| | Preferred? |---- | |
| ---------------- | | |
| Y | | | |
| | | | ----------------
| | | | | Control Word |
| | | | | Preferred? |
| | | | ----------------
| | | | N | Y |
| | | | | |
Send Send Send Send Send Send
C=0 C=1 C=0 C=0 C=0 C=1
| | | |
----------------------------------
| If receive the same as sent, |
| VC setup is complete. If not: |
----------------------------------
| | | |
------------------- -----------
| Receive | | Receive |
| C=1 | | C=0 |
------------------- -----------
| |
Wait for the Send
next message Wrong C-Bit
|
Send Label Mapping
Message with C=0
RFC 3036 has a range of Status Code values, which are assigned by IANA on a First Come, First Served basis. These are in the range 0x20000000-0x3effffff. The following new status codes are defined:
RFC 3036は、来てまず最初に添え基づき、IANAによって割り当てられたステータスコードの値の範囲を持っています。これらは、範囲0x20000000-0x3effffffです。次の新しいステータスコードが定義されています。
0x20000001 "Illegal C-Bit"
0x20000002 "Wrong C-Bit"
As mentioned above, the Group ID field can be used to withdraw all VC labels associated with a particular group ID. This procedure is OPTIONAL, and if it is implemented, the LDP label withdraw message should be as follows: the VC information length field is set to 0, the VC ID field is not present, and the interface parameters field is not present. For the purpose of this document, this is called the "wild card withdraw procedure", and all LSRs implementing this design are REQUIRED to accept such a withdraw message, but are not required to send it.
上述したように、グループIDフィールドは、特定のグループIDに関連付けられたすべてのVCラベルを引き出すために使用することができます。この手順はオプションであり、それが実装されている場合、LDPラベルは次のようにメッセージがなければならない撤退：VC情報長フィールドが0に設定され、VC IDフィールドが存在せず、インタフェースパラメータフィールドが存在しません。このドキュメントの目的のために、これは「ワイルドカード手続きを取り下げる」と呼ばれ、この設計を実装するすべてのLSRは、そのような撤退のメッセージを受け入れるために必要とされているが、それを送信する必要はありません。
The interface parameters field MUST NOT be present in any LDP VC label withdrawal message or release message. A wild card release message MUST include only the group ID. A Label Release message initiated from the imposition router must always include the VC ID.
インタフェースパラメータフィールドは、任意のLDP VCラベル離脱メッセージまたは解放メッセージ中に存在してはなりません。ワイルドカード解放メッセージは、グループIDを含まなければなりません。賦課ルータから開始ラベル解放メッセージは常にVC IDを含める必要があります。
In the case where the router considers the sequence number field in the control word, it is important to note the following when advertising labels.
ルータは、制御ワードのシーケンス番号フィールドを考慮した場合には、次の広告のラベルを注意することが重要です。
After a label has been withdrawn by the disposition router and/or released by the imposition router, care must be taken to not re-advertise (reuse) the released label until the disposition router can be reasonably certain that old packets containing the released label no longer persist in the MPLS network.
ラベルが気質ルータによって撤回および/または賦課ルータによって解放された後に処分ルータが合理的に確信できるまで、注意が放出された標識を（再利用）を再宣伝しないように注意する必要がありません放出された標識を含む古いパケット長いMPLSネットワークに固執。
This precaution is required to prevent the imposition router from restarting packet forwarding with sequence number of 1 when it receives the same label mapping if there are still older packets persisting in the network with sequence number between 1 and 32768. For example, if there is a packet with sequence number=n where n is in the interval[1,32768] traveling through the network, it would be possible for the disposition router to receive that packet after it re-advertises the label. Since the label has been released by the imposition router, the disposition router SHOULD be expecting the next packet to arrive with sequence number of 1. Receipt of a packet with sequence number equal to n will result in n packets potentially being rejected by the disposition router until the imposition router imposes a sequence number of n+1 into a packet. Possible methods to avoid this are for the disposition router to always advertise a different VC label, or for the disposition router to wait for a sufficient time before attempting to re-advertise a recently released label. This is only an issue when sequence number processing at the disposition router is enabled.
この予防措置は、例えば、1と32768の間のシーケンス番号を有するネットワークで持続古いパケットは依然として存在する場合がある場合、それは、同じラベルマッピングを受信したときに1のシーケンス番号を持つパケット転送を再開から賦課ルータを防止するために必要とされますnがネットワークを介して走行区間[1,32768]である場合、それは再アドバタイズした後に配置ルータはそのパケットを受信するためのラベルをシーケンス番号を持つパケットは= N、それは可能であろう。ラベルは賦課ルータによって解放されているので、配置ルータは次のパケットがnに等しいシーケンス番号を有するパケットの1領収書の配列番号で到着することを期待すべきは、潜在的に配置ルータによって拒否されたn個のパケットをもたらします賦課ルータまでパケット内にN + 1のシーケンス番号を課します。これを回避することが可能な方法は、気質ルータが常に異なるVCラベルをアドバタイズするために、または再宣伝最近リリースされたラベルを試みる前に十分な時間を待つ気質ルータのためのものです。これは、処分ルーターのシーケンス番号処理が有効になっているだけの問題です。
In situations where the imposition router wants to restart forwarding of packets with sequence number 1, the router shall 1) send a label mapping release to the disposition router, and 2) send a label mapping request to the disposition router. When sequencing is supported, advertisement of a VC label in response to a label mapping request MUST also consider the issues discussed in Section 6.4.1.
賦課ルータはシーケンス番号1のパケットの転送を再開したい状況では、ルータは、1）気質ルータにラベルマッピングリリースを送信しなければならない、そして2）気質ルータにラベルマッピング要求を送信します。シーケンシングがサポートされている場合は、ラベルマッピング要求に応じて、VCラベルの広告も、6.4.1項で述べた問題点を考慮する必要があります。
As specified in this document, a Virtual Circuit FEC element contains the VC Type field. VC Type value 0 is reserved. VC Type values 1 through 10 are defined in this document. VC Type values 11 through 63 are to be assigned by IANA using the "IETF Consensus" policy defined in RFC 2434. VC Type values 64 through 127 are to be assigned by IANA, using the "First Come First Served" policy defined in RFC 2434. VC Type values 128 through 32767 are vendor-specific, and values in this range are not to be assigned by IANA.
この文書で指定されているように、仮想回線FEC要素は、VC Typeフィールドが含まれています。 VC Type値0は予約されています。 VCタイプ値は、1から10までは、この文書で定義されています。 VCタイプ63を介して、11は、RFC 2434で定義された「IETFコンセンサス」ポリシーを使用して、VCタイプは、RFC 2434で定義された「最初に来る最初に配信」ポリシーを使用して、127を通る64はIANAによって割り当てられる値はIANAによって割り当てられる値。VCタイプ32767 128がベンダー固有の値、およびこの範囲の値は、IANAによって割り当てられるべきではありません。
As specified in this document, a Virtual Circuit FEC element contains the Interface Parameters field, which is a list of one or more parameters, and each parameter is identified by the Parameter ID field. Parameter ID value 0 is reserved. Parameter ID values 1 through 5 are defined in this document. Parameter ID values 6 through 63 are to be assigned by IANA using the "IETF Consensus" policy defined in RFC 2434. Parameter ID values 64 through 127 are to be assigned by IANA, using the "First Come First Served" policy defined in RFC 2434. Parameter ID values 128 through 255 are vendor-specific, and values in this range are not to be assigned by IANA.
この文書で指定されているように、仮想回線FEC要素には、1つのまたは複数のパラメータのリストであるインターフェイスパラメータのフィールドが含まれ、各パラメータは、パラメータIDフィールドによって識別されます。パラメータID値0は予約されています。パラメータID値は、1〜5は、本文書で定義されています。パラメータID値6〜63は、RFC 2434で定義されたポリシー「まず最初に配信是非」を用い、IANAによって割り当てられる64 127を介して値RFC 2434パラメータIDで定義された「IETFコンセンサス」ポリシーを使用して、IANAによって割り当てられます。パラメータIDは、128〜255は、ベンダー固有の値、およびこの範囲の値は、IANAによって割り当てられるべきではありません。
This document does not affect the underlying security issues of MPLS, described in [RFC3032]. More detailed security considerations are also described in Section 8 of [RFC4447].
この文書では、[RFC3032]で説明したMPLSの基本的なセキュリティ問題には影響しません。より詳細なセキュリティ上の考慮事項はまた、[RFC4447]のセクション8に記載されています。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[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]、RFC 4447マティーニ、L.、エド。、ローゼン、E.、エルAawar、N.、スミス、T.、およびG.サギ、 "ラベル配布プロトコル（LDP）を使用して疑似回線の設定とメンテナンス" 、2006年4月。
[RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN", RFC 4385, February 2006.
[RFC4385]ブライアント、S.、ツバメ、G.、マティーニ、L.、およびD.マクファーソン、 "MPLS PSNの上の使用のための擬似回線エミュレーションエッジツーエッジ（PWE3）制御ワード"、RFC 4385、2006年2月。
[RFC4842] Malis, A., Pate, P., Cohen, R., Ed., and D. Zelig, "Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Circuit Emulation over Packet (CEP)", RFC 4842, April 2007.
[RFC4842] Malis、A.、パテ、P.、コーエン、R.、編、及びD.カメレオンマン、 "同期光ネットワーク/同期デジタル階層（SONET / SDH）パケット（CEP）を超える回線エミュレーション"、RFC 4842 、2007年4月。
[RFC4553] Vainshtein, A., Ed., and YJ. Stein, Ed., "Structure-Agnostic Time Division Multiplexing (TDM) over Packet (SAToP)", RFC 4553, June 2006.
[RFC4553] Vainshtein、A.編、及びYJ。スタイン、エド。、 "パケット（のSAToP）以上の構造に依存しない時分割多重（TDM）"、RFC 4553、2006年6月。
[RFC4619] Martini, L., Ed., Kawa, C., Ed., and A. Malis, Ed., "Encapsulation Methods for Transport of Frame Relay over Multiprotocol Label Switching (MPLS) Networks", RFC 4619, September 2006.
[RFC4619]マティーニ、L.、エド。、カワ、C.、エド。、およびA. Malis、エド。、 "フレームリレーの輸送のためのカプセル化方法マルチプロトコルラベルの上に（MPLS）ネットワークの切り替え"、RFC 4619、2006年9月。
[RFC4717] Martini, L., Jayakumar, J., Bocci, M., El-Aawar, N., Brayley, J., and G. Koleyni, "Encapsulation Methods for Transport of Asynchronous Transfer Mode (ATM) over MPLS Networks", RFC 4717, December 2006.
[RFC4717]マルティーニ、MPLSネットワークの上の非同期転送モードのトランスポート（ATM）のためのL.、Jayakumar、J.、ボッチ、M.、エルAawar、N.、Brayley、J.、およびG. Koleyni、「カプセル化方法」、RFC 4717、2006年12月。
[RFC4618] Martini, L., Rosen, E., Heron, G., and A. Malis, "Encapsulation Methods for Transport of PPP/High-Level Data Link Control (HDLC) over MPLS Networks", RFC 4618, September 2006.
[RFC4618]マティーニ、L.、ローゼン、E.、ヘロン、G.、およびA. Malis、RFC 4618、2006年9月 "MPLSネットワーク上のPPP /ハイレベルデータリンク制御（HDLC）の輸送のためのカプセル化方法" 。
[RFC4448] Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron, "Encapsulation Methods for Transport of Ethernet over MPLS Networks", RFC 4448, April 2006.
[RFC4448]マティーニ、L.、エド。、ローゼン、E.、エル・Aawar、N.、およびG.サギ、 "MPLSネットワーク上のイーサネットの輸送のためのカプセル化方法"、RFC 4448、2006年4月。
[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.トーマス、 "LDP仕様"、RFC 3036、2001年1月。
[Q.933] ITU-T Recommendation Q.933, and Q.922 Specification for Frame Mode Basic call control, ITU Geneva 1995.
[Q.933] ITU-T勧告Q.933、およびQ.922仕様フレームモード基本呼制御、ITU、ジュネーブ1995年。
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.
[RFC3032]ローゼン、E.、タッパン、D.、Fedorkow、G.、Rekhter、Y.、ファリナッチ、D.、李、T.、およびA.コンタ、 "MPLSラベルスタックエンコーディング"、RFC 3032、2001年1月。
[ANSI.T1.105] American National Standards Institute, "Synchronous Optical Network Formats," ANSI T1.105-1995.
[ANSI.T1.105]米国規格協会、「同期光ネットワークフォーマット、」ANSI T1.105-1995。
[ITU.G.707] ITU Recommendation G.707, "Network Node Interface For The Synchronous Digital Hierarchy", 1996.
1996 [ITU.G.707] ITU勧告G.707、「同期デジタル階層のためのネットワークノードインタフェース」。
[RFC4905] Martini, L., Ed., Rosen, E., Ed., and N. El-Aawar, Ed., "Encapsulation Methods for Transport of Layer 2 Frames over MPLS Networks", RFC 4905, June 2007.
[RFC4905]マティーニ、L.、エド。、ローゼン、E.、エド。、およびN.エルAawar、エド。、 "フレームMPLSネットワークでのレイヤ2の輸送のためのカプセル化方法"、RFC 4905、2007年6月。
[CEM] Malis, A., Brayley, J., Vogelsang., S., Shirron, J., and L. Martini, "SONET/SDH Circuit Emulation Service Over MPLS (CEM) Encapsulation", Work in Progress, June 2007.
[CEM] Malis、A.、Brayley、J.、Vogelsangの。、S.、Shirron、J.、およびL.マティーニ、 "SONET / SDH回線エミュレーションサービスオーバーMPLS（CEM）カプセル化"、進歩、2007年6月での作業。
[FAST] ATM Forum, "Frame Based ATM over SONET/SDH Transport (FAST)", af-fbatm-0151.000, July 2000.
[FAST] ATMフォーラム、 "SONET / SDHトランスポート上でフレーム・ベースATM（FAST）"、AF-fbatm-0151.000、2000年7月。
Giles Heron Tellabs Abbey Place 24-28 Easton Street High Wycombe Bucks HP11 1NT UK EMail: giles.heron@tellabs.com
ジャイルズヘロンテラブスアビー場所24-28イーストンストリートハイウィコムバックスHP11 1NT英国のEメール：giles.heron@tellabs.com
Dimitri Stratton Vlachos Mazu Networks, Inc. 125 Cambridgepark Drive Cambridge, MA 02140 EMail: d@mazunetworks.com
ディミトリ・ストラットンVlachos媽祖ネットワークス株式会社125 Cambridgeparkドライブケンブリッジ、MA 02140 Eメール：d@mazunetworks.com
Dan Tappan Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA 01824 EMail: tappan@cisco.com
ダンタッパンシスコシステムズ社250アポロドライブチェルムズフォード、MA 01824 Eメール：tappan@cisco.com
Jayakumar Jayakumar, Cisco Systems Inc. 225, E.Tasman, MS-SJ3/3, San Jose, CA 95134 EMail: jjayakum@cisco.com
Jayakumar Jayakumar、シスコシステムズ株式会社225、E.Tasman、MS-SJ3 / 3、サンノゼ、CA 95134 Eメール：jjayakum@cisco.com
Alex Hamilton, Cisco Systems Inc. 285 W. Tasman, MS-SJCI/3/4, San Jose, CA 95134 EMail: tahamilt@cisco.com
アレックス・ハミルトン、シスコシステムズ株式会社285 W.タスマン、MS-SJCI / 3月4日、サンノゼ、CA 95134 Eメール：tahamilt@cisco.com
Steve Vogelsang Laurel Networks, Inc. Omega Corporate Center 1300 Omega Drive Pittsburgh, PA 15205 EMail: sjv@laurelnetworks.com
スティーブVogelsangのローレルネットワークス株式会社オメガコーポレートセンター1300オメガドライブピッツバーグ、PA 15205 Eメール：sjv@laurelnetworks.com
John Shirron Laurel Networks, Inc. Omega Corporate Center 1300 Omega Drive Pittsburgh, PA 15205 EMail: jshirron@laurelnetworks.com
ジョンShirronローレルネットワークス株式会社オメガコーポレートセンター1300オメガドライブピッツバーグ、PA 15205 Eメール：jshirron@laurelnetworks.com
Toby Smith Network Appliance, Inc. 800 Cranberry Woods Drive Suite 300 Cranberry Township, PA 16066 EMail: tob@netapp.com
トビー・スミスネットワーク・アプライアンス株式会社800クランベリーウッズドライブスイート300クランベリータウンシップ、PA 16066 Eメール：tob@netapp.com
Andrew G. Malis Tellabs 90 Rio Robles Dr. San Jose, CA 95134 EMail: Andy.Malis@tellabs.com
アンドリューG. Malisテラブス90リオロブレス博士サンノゼ、CA 95134 Eメール：Andy.Malis@tellabs.com
Vinai Sirkay Reliance Infocomm Dhirubai Ambani Knowledge City Navi Mumbai 400 709 India EMail: vinai@sirkay.com
リライアンスインフォコムsirikayビナイ市ナビムンバイ400 709、インド、ダーラブハイ・アンバニkanauledji電子メール：వినయ్@సిరికాయ్.కం
Vasile Radoaca Nortel Networks 600 Technology Park Billerica MA 01821 EMail: vasile@nortelnetworks.com
バシレRadoaca Nortel Networksの600テクノロジーパークビレリカMA 01821 Eメール：vasile@nortelnetworks.com
Chris Liljenstolpe Alcatel 11600 Sallie Mae Dr. 9th Floor Reston, VA 20193 EMail: chris.liljenstolpe@alcatel.com
クリスLiljenstolpeアルカテル11600サリーメイ博士は9階レストン、バージニア州20193 Eメール：chris.liljenstolpe@alcatel.com
Dave Cooper Global Crossing 960 Hamlin Court Sunnyvale, CA 94089 EMail: dcooper@gblx.net
デイブ・クーパーグローバル・クロッシング960ハムリン法廷サニーベール、CA 94089 Eメール：dcooper@gblx.net
Kireeti Kompella Juniper Networks 1194 N. Mathilda Ave Sunnyvale, CA 94089 EMail: kireeti@juniper.net
Kireeti Kompellaジュニパーネットワークスの1194 N.マチルダアベニューサニーベール、CA 94089 Eメール：kireeti@juniper.net
Authors' Addresses
著者のアドレス
Luca Martini Cisco Systems, Inc. 9155 East Nichols Avenue, Suite 400 Englewood, CO 80112 EMail: lmartini@cisco.com
ルカ・マティーニシスコシステムズ株式会社9155東ニコルズアベニュー、スイート400イングルウッド、CO 80112 Eメール：lmartini@cisco.com
Nasser El-Aawar Level 3 Communications, LLC. 1025 Eldorado Blvd. Broomfield, CO 80021 EMail: nna@level3.net
ナセルエルAawarレベル3コミュニケーションズ、LLC。 1025エルドラドブールバード。ブルームフィールド、CO 80021 Eメール：nna@level3.net
Eric Rosen Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA 01824 EMail: erosen@cisco.com
エリック・ローゼンシスコシステムズ社250アポロドライブチェルムズフォード、MA 01824 Eメール：erosen@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。