[要約] RFC 4906は、MPLS上でのレイヤ2フレームの転送に関する標準化されたプロトコルを提案しています。その目的は、MPLSネットワーク上でのレイヤ2トラフィックの効率的な転送を実現することです。
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
MPLS上のレイヤー2フレームの輸送
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）The IETF Trust（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および関連ドキュメントで説明されている擬似ワイヤーのエッジエッジからエッジワーキンググループ仕様に取って代わられました。
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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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.
このドキュメントでは、いわゆる「ドラフトマルティニ」プロトコルについて説明します。これは、多くの展開された実装で使用されています。このドキュメントとその内容は、その後、擬似ワイヤーエミュレーションエッジからエッジワーキンググループの仕様に取って代わられました：[RFC4447]、[RFC4448]、[RFC4717]、[RFC4618]、[RFC4618]、[RFC4619]、[RFC4553]、[RFC453]、[RFC4553]、[RFC4553]]、および関連文書。このドキュメントは、現在の実装のドキュメントとして機能し、新しい実装に使用してはなりません。このドキュメントとの後方互換性のある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".
イングレスラベルスイッチングルーター（LSR）R1から、介在するMPLSネットワーク全体で、LSR R2を出力するように、レイヤー2 PDUを輸送することが望ましいとします。R1からR2へのラベルスイッチパス（LSP）があると仮定します。つまり、R1はパケットにラベルを押し込み、結果をその隣接のいずれかに送信することにより、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に伝えません。実際、最後から2番目のホップポップが使用されている場合、R2は対応するラベルさえ表示されない場合があります。（R1自体が最後から2番目のホップである場合、トンネルラベルがプッシュされることさえありません。）したがって、ペイロードがIPパケットではない場合、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がレイヤー2 PDUをR2に送信すると、まずラベルスタックにVCラベルを押し、次に（R1がR2に隣接していない場合）トンネルラベルを押します。トンネルラベルは、MPLSパケットをR1からR2に取得します。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の間の一般的なルーティングカプセル化（GRE） - カプセル化されたMPLSトンネルである可能性があることに注意してください。この場合、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はVCラベルから発信インターフェイスとAAL5 PDUのVPI / VCI（仮想パス識別子 /仮想回路識別子）値を推測できる必要があります。ペイロードがフレームリレー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に分布する必要があります。これには、R1とR2の間にLDPセッションを作成する必要があります。このLDPセッションは、レイヤー2 PDU [RFC3036]と同じ経路に沿って必ずしも輸送されるわけではないことに注意する必要があります。さらに、LDPを使用してVCラベルを配布する場合、リベラルラベル保持モードを使用する必要があります。ただし、[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「VC」を単一の「トンネル」で一緒に運ぶことができることに注意してください。したがって、ネットワークバックボーンでは非常によくスケーリングされます。
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 EDGE LSRは、フレームリレーPVCステータスシグナル伝達をフレームリレーネットワークに提供する必要があります。MPLS EDGE LSRが、[Q.933] Annex A.5で定義されているように、実装契約frf.1.1で引用されているAnnex A.5で定義されているサービスを検出した場合、フレームリレーDLCIに対応するラベルを撤回する必要があります。出口LSRは、出力フレームリレーVCの[Q.933]で定義されているように、対応するエラーとアラームを生成する必要があります。
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モードに従ってカプセル化されています。このモードにより、MPLSネットワークを介して特定のATM PVCで別の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.
このモードは、イーサネットポートモードに似ています。Ingress LSR R1のIngress ATMポートで受信されたすべてのセルは、[RFC4905]、ATMセルモードに従ってカプセル化され、LSPを介して出力LSR、R2に送信されます。このモードにより、ATMポートを他の1つのATMポートのみに接続できます。[RFC4905]により、複数のセルを単一のMPLSフレームにグループ化できます。ATMセルのグループ化は、Ingress LSR、R1での透過にオプションです。出力LSR R2が細胞の連結をサポートする場合、侵入LSR、R1は、FEC要素の一部として受信された「連結ATM細胞の最大数」パラメーターまで細胞を連結する必要があります。
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ポートで、[RFC4905]、ATMセルモードに従ってカプセル化され、LSPを横切って送信されます。出口lsr r2へ。ATMセルのグループ化は、Ingress LSR、R1での透過にオプションです。出力LSR R2が細胞の連結をサポートする場合、侵入LSR、R1は、FEC要素の一部として受信された「フレーム内の連結ATM細胞の最大数」パラメーターまで細胞を連結する必要があります。
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は、Tビットセット[RFC4905]のVCラベルを含むATM VC LSPに着信MPLSフレームを廃棄する必要があります。AAL5 SDU輸送モードで動作する場合、[RFC4905]で定義されたTビットを使用してOAMセルの輸送をサポートするLSR、または3つの細胞輸送モードのいずれかで動作するLSRは、[Fast]セクション8で概説されている手順に従う必要があります。[itu.g.707]で指定された該当する手順に加えて、モード0のみ。
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から受信され、このATM VCを輸送しているLSRが1のループバック表示値を搭載し、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.
Ingress 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.
Ingress 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）を提供する場合があります。Ingress LSRがILMIメッセージを受信して、ATMエッジスイッチがVCを削除したことを示す場合、または物理インターフェイスがダウンした場合、障害に関連付けられているすべてのVCのラベルマッピングを引き出す必要があります。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 Edge 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 Edge 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下流の未承諾モードを使用して分布しています。LSRSは、[RFC3036]のセクション2.4.2および2.5で説明されている拡張発見メカニズムを使用してLDPセッションを確立します。この目的のために、新しいタイプのFEC要素が定義されています。FEC要素タイプは128です。LDPVCラベルごとに、単一のVC FEC要素のみを宣伝する必要があります。仮想回路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 0x0002 ATM AAL5 VCC TRANSPRESTION 0x0003 ATM透明セル輸送0x0004イーサネットVLAN 0x0005イーサネット0x0006 HDLC 0x0007 PPP 0x8008 CEM [CEM] 0x0009 ATM VCCセル輸送
- 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.
ビット15 = 1このVCに存在するコントロールワード。ビット15 = 0この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は、ポートインデックス、または仮想トンネルインデックスとして使用することを目的としています。構成を簡素化するために、Ingressの特定のVC IDは、出力ルーターへの輸送のための仮想トンネルの一部になる可能性があります。グループIDは、物理的なポート障害時にリモートLSRにワイルドカードラベルの引き出しを送信するのに非常に便利です。
- VC ID
- VC ID
A non-zero 32-bit connection ID that, together with the VC type, identifies a particular VC.
VCタイプとともに特定のVCを識別する非ゼロ32ビット接続ID。
- 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.
0x01 4オクテットのインターフェイスMTU。0x02 4連結ATM細胞の最大数。0x03から最大82オプションインターフェイス説明文字列。0x04 4 CEM [CEM]ペイロードバイト。0x05 4 CEMオプション。
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.
長さフィールドは、パラメーター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-OCTET値。これは、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
- オプションのインターフェイス説明文字列
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.
CEMストリーム上のすべてのパケットに48〜1,023オクテットのすべてのパケットに含まれるTDMペイロードオクテットの数を示す2-OCTET値。特定のCEMストリームのすべてのパケットには、同じ数のペイロードバイトがあります。ペイロードには2つのJ1が含まれている可能性があるため、パケットサイズがSTS-1 SPEの場合、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.
これらのVCSをセットアップするために送信されるラベルマッピングメッセージには、C = 1が必要です。これらのタイプの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.
-私。受信したラベルマッピングメッセージのc = 0の場合、c = 0でラベルマッピングメッセージを送信すると、コントロールワードは使用されません。
-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でラベルマッピングメッセージを送信し、コントロールワードが使用されます。
-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.
-私。送信されたラベルマッピングメッセージで指定された同じCビット値を持つラベルマッピングメッセージ。VCセットアップが完了するようになり、C = 1の場合は制御単語が使用されますが、C = 0の場合は使用されません。
-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のラベルマッピングメッセージですが、送信されたラベルマッピングメッセージには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のラベルマッピングメッセージですが、送信されたラベルマッピングメッセージにはC = 1があります。この場合、「間違ったCビット」ステータスコードを使用してラベルの撤回メッセージを送信し、その後、C = 0のラベルマッピングメッセージが続きます。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.
両方のエンドポイントがコントロールワードの使用を好む場合、この手順により使用されます。いずれかのEndPointがコントロールワードを使用しないことを好む場合、またはコントロールワードをサポートしない場合、この手順により使用されません。1つのエンドポイントがコントロールワードを使用することを好むが、もう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には、最初のComeで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のパケットnは、nが間隔[1,32768]にネットワークを通過するため、レーベルを再評価した後、気質ルーターがそのパケットを受信することが可能です。ラベルはインポジションルーターによってリリースされているため、気質ルーターは次のパケットがシーケンス番号1で到着することを期待する必要があります。賦課ルーターがシーケンス数の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タイプフィールドが含まれています。VCタイプ値0は予約されています。VCタイプの値1〜10は、このドキュメントで定義されています。VCタイプ値11〜63は、RFC 2434で定義された「IETFコンセンサス」ポリシーを使用してIANAによって割り当てられます。VCタイプ値64〜127は、RFC 2434で定義された「First Come First Serve」ポリシーを使用してIANAによって割り当てられます。。VCタイプ値128〜32767はベンダー固有であり、この範囲の値は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で定義された「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の基礎となるセキュリティ問題には影響しません。より詳細なセキュリティ上の考慮事項については、[RFC447]のセクション8にも説明されています。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Martini、L.、Ed。、Ed。、Rosen、E.、El-Aawar、N.、Smith、T。、およびG. Heron、「擬似ワイヤー分布プロトコル（LDP）を使用した擬似ワイヤーのセットアップとメンテナンス」、RFC 4447、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] Bryant、S.、Swallow、G.、Martini、L。、およびD. McPherson、「Pseudowire Emulation Edge-to-Edge（PWE3）MPLS PSNを介して使用するコントロールワード」、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.、Pate、P.、Cohen、R.、Ed。、およびD. Zelig、「同期光ネットワーク/同期デジタル階層（SONET/SDH）回路エミュレーション（CEP）（CEP）（CEP）（CEP）（CEP）（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.、ed。、およびYJ。Stein、ed。、「パケット（TDM）を超える構造と存在時の時代分割多重化（TDM）（SATOP）」、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] Martini、L.、Ed。、Kawa、C.、Ed。、およびA. Malis、ed。、「マルチプロトコルラベルスイッチング（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] Martini、L.、Jayakumar、J.、Bocci、M.、El-Aawar、N.、Brayley、J.、およびG. Koleyni、「MPLSネットワーク上の非同期移転モード（ATM）の輸送のためのカプセル化方法」"、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] Martini、L.、Rosen、E.、Heron、G。、およびA. Malis、「MPLSネットワーク上のPPP/高レベルデータリンク制御（HDLC）の輸送のためのカプセル化方法」、RFC 4618、2006年9月。
[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.
[RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and B. Thomas, "LDP Specification", RFC 3036, January 2001.
[RFC3036] Andersson、L.、Doolan、P.、Feldman、N.、Fredette、A。、およびB. Thomas、「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 Geneva 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] Rosen、E.、Tappan、D.、Fedorkow、G.、Rekhter、Y.、Farinacci、D.、Li、T。、およびA. conta、「Mpls Label Stack ending」、RFC 3032、2001年1月。
[ANSI.T1.105] American National Standards Institute, "Synchronous Optical Network Formats," ANSI T1.105-1995.
[ANSI.T1.105] American National Standards Institute、「同期光ネットワーク形式」、ANSI T1.105-1995。
[ITU.G.707] ITU Recommendation G.707, "Network Node Interface For The Synchronous Digital Hierarchy", 1996.
[ITU.G.707] ITU推奨G.707、「同期デジタル階層のネットワークノードインターフェイス」、1996。
[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.
[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. Martini、「MPLS（CEM）カプセル化上のSONET/SDHサーキットエミュレーションサービス」、2007年6月の進行中の作業。
[FAST] ATM Forum, "Frame Based ATM over SONET/SDH Transport (FAST)", af-fbatm-0151.000, July 2000.
[Fast] ATMフォーラム、「SONET/SDH Transport（Fast）上のフレームベースのATM」、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 UKメール：giles.heron@tellabs.com
Dimitri Stratton Vlachos Mazu Networks, Inc. 125 Cambridgepark Drive Cambridge, MA 02140 EMail: d@mazunetworks.com Dan Tappan Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA 01824 EMail: tappan@cisco.com
Dimitri Stratton Vlachos Mazu Networks、Inc。125 CambridgePark Drive Cambridge、MA 02140 Email：d@mazunetworks.com Dan Tappan Cisco Systems、Inc。250 Apollo Drive Chelmsford、MA 01824メール
Jayakumar Jayakumar, Cisco Systems Inc. 225, E.Tasman, MS-SJ3/3, San Jose, CA 95134 EMail: jjayakum@cisco.com
Jayakumar Jayakumar、Cisco Systems Inc. 225、E.Tasman、MS-SJ3/3、サンノゼ、CA 95134メール：jjayakum@cisco.com
Alex Hamilton, Cisco Systems Inc. 285 W. Tasman, MS-SJCI/3/4, San Jose, CA 95134 EMail: tahamilt@cisco.com
Alex Hamilton、Cisco Systems Inc. 285 W. Tasman、MS-SJCI/3/4、San Jose、CA 95134メール：tahamilt@cisco.com
Steve Vogelsang Laurel Networks, Inc. Omega Corporate Center 1300 Omega Drive Pittsburgh, PA 15205 EMail: sjv@laurelnetworks.com
Steve Vogelsang Laurel Networks、Inc。Omega Corporate Center 1300 Omega Drive Pittsburgh、PA 15205メール：sjv@laurelnetworks.com
John Shirron Laurel Networks, Inc. Omega Corporate Center 1300 Omega Drive Pittsburgh, PA 15205 EMail: jshirron@laurelnetworks.com
John Shirron Laurel Networks、Inc。Omega Corporate Center 1300 Omega Drive Pittsburgh、PA 15205メール：jshirron@laurelnetworks.com
Toby Smith Network Appliance, Inc. 800 Cranberry Woods Drive Suite 300 Cranberry Township, PA 16066 EMail: tob@netapp.com Andrew G. Malis Tellabs 90 Rio Robles Dr. San Jose, CA 95134 EMail: Andy.Malis@tellabs.com
Toby Smith Network Appliance、Inc。800 Cranberry Woods Drive Suite 300 Cranberry Township、PA 16066 Email：tob@netapp.com Andrew G. Malis Tellabs 90 Rio Robles Dr. San Jose、CA 95134メール：andy.malis@tellabs.com
Vinai Sirkay Reliance Infocomm Dhirubai Ambani Knowledge City Navi Mumbai 400 709 India EMail: vinai@sirkay.com
Vinai Sirkali Reliance Infocomm Dhirubhai Ambani Knowledge City Navi Mumbai 400 709インドメール：vinai@sirkay.com
Vasile Radoaca Nortel Networks 600 Technology Park Billerica MA 01821 EMail: vasile@nortelnetworks.com
Vasile Radoaca Nortel Networks 600 Technology Park Billerica MA 01821メール：vasile@nortelnetworks.com
Chris Liljenstolpe Alcatel 11600 Sallie Mae Dr. 9th Floor Reston, VA 20193 EMail: chris.liljenstolpe@alcatel.com
Chris Liljenstolpe Alcatel 11600 Sallie Mae Dr. 9th Floor Reston、VA 20193メール：chris.liljenstolpe@alcatel.com
Dave Cooper Global Crossing 960 Hamlin Court Sunnyvale, CA 94089 EMail: dcooper@gblx.net
Dave Cooper Global Crossing 960 Hamlin Court Sunnyvale、CA 94089メール：dcooper@gblx.net
Kireeti Kompella Juniper Networks 1194 N. Mathilda Ave Sunnyvale, CA 94089 EMail: kireeti@juniper.net
Kireeti Kompella Juniper Networks 1194 N. Mathilda Ave Sunnyvale、CA 94089メール：kireeti@juniper.net
Authors' Addresses
著者のアドレス
Luca Martini Cisco Systems, Inc. 9155 East Nichols Avenue, Suite 400 Englewood, CO 80112 EMail: lmartini@cisco.com
Luca Martini Cisco Systems、Inc。9155 East Nichols Avenue、Suite 400 Englewood、Co 80112メール：lmartini@cisco.com
Nasser El-Aawar Level 3 Communications, LLC. 1025 Eldorado Blvd. Broomfield, CO 80021 EMail: nna@level3.net
Nasser El-Aawarレベル3 Communications、LLC。1025 Eldorado Blvd.Broomfield、Co 80021メール：nna@level3.net
Eric Rosen Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA 01824 EMail: erosen@cisco.com
Eric Rosen Cisco Systems、Inc。250 Apollo Drive Chelmsford、MA 01824メール：erosen@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、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は、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://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エディター機能の資金は現在、インターネット協会によって提供されています。