[要約] RFC 7275は、レイヤ2仮想プライベートネットワーク（L2VPN）プロバイダエッジ（PE）の冗長性のためのインターチャシス通信プロトコルに関するものです。このRFCの目的は、PEの冗長性を確保するために、異なるシャーシ間での通信を可能にするプロトコルを提供することです。
Internet Engineering Task Force (IETF) L. Martini
Request for Comments: 7275 S. Salam
Category: Standards Track A. Sajassi
ISSN: 2070-1721 Cisco
M. Bocci
Alcatel-Lucent
S. Matsushima
Softbank Telecom
T. Nadeau
Brocade
June 2014
Inter-Chassis Communication Protocol for Layer 2 Virtual Private Network (L2VPN) Provider Edge (PE) Redundancy
レイヤー2バーチャルプライベートネットワーク（L2VPN）プロバイダーエッジ（PE）冗長性のためのシャーシ間通信プロトコル
Abstract
概要
This document specifies an Inter-Chassis Communication Protocol (ICCP) that enables Provider Edge (PE) device redundancy for Virtual Private Wire Service (VPWS) and Virtual Private LAN Service (VPLS) applications. The protocol runs within a set of two or more PEs, forming a Redundancy Group, for the purpose of synchronizing data among the systems. It accommodates multi-chassis attachment circuit redundancy mechanisms as well as pseudowire redundancy mechanisms.
このドキュメントでは、仮想プライベートワイヤサービス（VPWS）および仮想プライベートLANサービス（VPLS）アプリケーションのプロバイダーエッジ（PE）デバイスの冗長化を可能にするシャーシ間通信プロトコル（ICCP）について説明します。プロトコルは、システム間でデータを同期する目的で、2つ以上のPEのセット内で実行され、冗長グループを形成します。マルチシャーシ接続回路の冗長メカニズムと疑似配線冗長メカニズムに対応しています。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7275.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7275で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日より前に公開または公開されたIETFドキュメントまたはIETFコントリビューションの素材が含まれている場合があります。 IETF標準プロセス外。このような資料の著作権を管理する人から適切なライセンスを取得せずに、このドキュメントをIETF標準プロセス外で変更したり、その派生物をIETF標準プロセス外で作成したりすることはできません。 RFCとして、またはそれを英語以外の言語に翻訳するための出版物。
Table of Contents
目次
1. Introduction ....................................................5
2. Specification of Requirements ...................................5
3. ICCP Overview ...................................................5
3.1. Redundancy Model and Topology ..............................5
3.2. ICCP Interconnect Scenarios ................................7
3.2.1. Co-located Dedicated Interconnect ...................7
3.2.2. Co-located Shared Interconnect ......................8
3.2.3. Geo-redundant Dedicated Interconnect ................8
3.2.4. Geo-redundant Shared Interconnect ...................9
3.3. ICCP Requirements .........................................10
4. ICC LDP Protocol Extension Specification .......................11
4.1. LDP ICCP Capability Advertisement .........................12
4.2. RG Membership Management ..................................12
4.2.1. ICCP Connection State Machine ......................13
4.3. Redundant Object Identification ...........................17
4.4. Application Connection Management .........................17
4.4.1. Application Versioning .............................18
4.4.2. Application Connection State Machine ...............19
4.5. Application Data Transfer .................................22
4.6. Dedicated Redundancy Group LDP Session ....................22
5. ICCP PE Node Failure / Isolation Detection Mechanism ...........22
6. ICCP Message Formats ...........................................23
6.1. Encoding ICC into LDP Messages ............................23
6.1.1. ICC Header .........................................24
6.1.2. ICC Parameter Encoding .............................26
6.1.3. Redundant Object Identifier Encoding ...............27
6.2. RG Connect Message ........................................27
6.2.1. ICC Sender Name TLV ................................28
6.3. RG Disconnect Message .....................................29
6.4. RG Notification Message ...................................31
6.4.1. Notification Message TLVs ..........................32
6.5. RG Application Data Message ...............................35
7. Application TLVs ...............................................35
7.1. Pseudowire Redundancy (PW-RED) Application TLVs ...........35
7.1.1. PW-RED Connect TLV .................................36
7.1.2. PW-RED Disconnect TLV ..............................37
7.1.2.1. PW-RED Disconnect Cause TLV ...............38
7.1.3. PW-RED Config TLV ..................................39
7.1.3.1. Service Name TLV ..........................41
7.1.3.2. PW ID TLV .................................42
7.1.3.3. Generalized PW ID TLV .....................43
7.1.4. PW-RED State TLV ...................................44
7.1.5. PW-RED Synchronization Request TLV .................45
7.1.6. PW-RED Synchronization Data TLV ....................46
7.2. Multi-Chassis LACP (mLACP) Application TLVs ...............48
7.2.1. mLACP Connect TLV ..................................48
7.2.2. mLACP Disconnect TLV ...............................49
7.2.2.1. mLACP Disconnect Cause TLV ................50
7.2.3. mLACP System Config TLV ............................51
7.2.4. mLACP Aggregator Config TLV ........................52
7.2.5. mLACP Port Config TLV ..............................54
7.2.6. mLACP Port Priority TLV ............................56
7.2.7. mLACP Port State TLV ...............................58
7.2.8. mLACP Aggregator State TLV .........................60
7.2.9. mLACP Synchronization Request TLV ..................61
7.2.10. mLACP Synchronization Data TLV ....................63
8. LDP Capability Negotiation .....................................65
9. Client Applications ............................................66
9.1. Pseudowire Redundancy Application Procedures ..............66
9.1.1. Initial Setup ......................................66
9.1.2. Pseudowire Configuration Synchronization ...........66
9.1.3. Pseudowire Status Synchronization ..................67
9.1.3.1. Independent Mode ..........................69
9.1.3.2. Master/Slave Mode .........................69
9.1.4. PE Node Failure or Isolation .......................70
9.2. Attachment Circuit Redundancy Application Procedures ......70
9.2.1. Common AC Procedures ...............................70
9.2.1.1. AC Failure ................................70
9.2.1.2. Remote PE Node Failure or Isolation .......70
9.2.1.3. Local PE Isolation ........................71
9.2.1.4. Determining Pseudowire State ..............71
9.2.2. Multi-Chassis LACP (mLACP) Application Procedures ..72
9.2.2.1. Initial Setup .............................72
9.2.2.2. mLACP Aggregator and Port Configuration ...74
9.2.2.3. mLACP Aggregator and Port Status
Synchronization ...........................75
9.2.2.4. Failure and Recovery ......................77
10. Security Considerations .......................................78
11. Manageability Considerations ..................................79
12. IANA Considerations ...........................................79
12.1. Message Type Name Space ..................................79
12.2. TLV Type Name Space ......................................79
12.3. ICC RG Parameter Type Space ..............................80
12.4. Status Code Name Space ...................................81
13. Acknowledgments ...............................................81
14. References ....................................................81
14.1. Normative References .....................................81
14.2. Informative References ...................................82
Network availability is a critical metric for service providers, as it has a direct bearing on their profitability. Outages translate not only to lost revenue but also to potential penalties mandated by contractual agreements with customers running mission-critical applications that require tight Service Level Agreements (SLAs). This is true for any carrier network, and networks employing Layer 2 Virtual Private Network (L2VPN) technology are no exception. A high degree of network availability can be achieved by employing intra-and inter-chassis redundancy mechanisms. The focus of this document is on the latter. This document defines an Inter-Chassis Communication Protocol (ICCP) that allows synchronization of state and configuration data between a set of two or more Provider Edge nodes (PEs) forming a Redundancy Group (RG). The protocol supports multi-chassis redundancy mechanisms that can be employed on either the attachment circuits or pseudowires (PWs). A formal definition of the term "chassis" can be found in [RFC2922]. For the purpose of this document, a chassis is an L2VPN PE node.
ネットワークの可用性は、サービスプロバイダーの収益性に直接影響するため、サービスプロバイダーにとって重要なメトリックです。停止は、収益の損失だけでなく、厳密なサービスレベル契約（SLA）を必要とするミッションクリティカルなアプリケーションを実行している顧客との契約上の合意によって義務付けられる潜在的なペナルティにもつながります。これはあらゆるキャリアネットワークに当てはまり、レイヤ2バーチャルプライベートネットワーク（L2VPN）テクノロジーを採用するネットワークも例外ではありません。シャーシ内およびシャーシ間冗長メカニズムを採用することにより、高度なネットワーク可用性を実現できます。このドキュメントの焦点は後者にあります。このドキュメントでは、冗長グループ（RG）を形成する2つ以上のプロバイダーエッジノード（PE）のセット間で状態および構成データの同期を可能にするシャーシ間通信プロトコル（ICCP）を定義します。このプロトコルは、接続回路または疑似配線（PW）のいずれかで使用できるマルチシャーシ冗長メカニズムをサポートしています。 「シャーシ」という用語の正式な定義は、[RFC2922]にあります。このドキュメントでは、シャーシはL2VPN PEノードです。
This document assumes that it is normal to run the Label Distribution Protocol (LDP) between the PEs in the RG, and that LDP components will in any case be present on the PEs to establish and maintain pseudowires. Therefore, ICCP is built as a secondary protocol running within LDP and taking advantage of the LDP session mechanisms as well as the underlying TCP transport mechanisms and TCP-based security mechanisms already necessary for LDP operation.
このドキュメントでは、RG内のPE間でラベル配布プロトコル（LDP）を実行するのが通常であり、LDPコンポーネントがPEに存在して疑似配線を確立および維持することを想定しています。したがって、ICCPはLDP内で実行されるセカンダリプロトコルとして構築され、LDPセッションメカニズムと、LDP操作にすでに必要な基になるTCPトランスポートメカニズムおよびTCPベースのセキュリティメカニズムを利用します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
The focus of this document is on PE node redundancy. It is assumed that a set of two or more PE nodes are designated by the operator to form an RG. Members of an RG fall under a single administration (e.g., service provider) and employ a common redundancy mechanism towards the access (attachment circuits or access pseudowires) and/or towards the core (pseudowires) for any given service instance. It is possible, however, for members of an RG to make use of disparate redundancy mechanisms for disjoint services. The PE devices may be offering any type of L2VPN service, i.e., Virtual Private Wire Service (VPWS) or Virtual Private LAN Service (VPLS). As a matter of fact, the use of ICCP may even be applicable for Layer 3 service redundancy, but this is considered to be outside the scope of this document.
このドキュメントの焦点は、PEノードの冗長性にあります。 ２つ以上のＰＥノードのセットがＲＧを形成するためにオペレータによって指定されると仮定される。 RGのメンバーは単一の管理（サービスプロバイダーなど）に属し、特定のサービスインスタンスのアクセス（接続回路またはアクセス疑似配線）および/またはコア（疑似配線）に共通の冗長メカニズムを採用しています。ただし、RGのメンバーは、ディスジョイントサービスに異なる冗長メカニズムを利用することができます。 PEデバイスは、任意のタイプのL2VPNサービス、つまり、仮想プライベートワイヤサービス（VPWS）または仮想プライベートLANサービス（VPLS）を提供している可能性があります。実際のところ、ICCPの使用はレイヤ3サービスの冗長性にも適用できる場合がありますが、これはこのドキュメントの範囲外と見なされます。
The PEs in an RG offer multi-homed connectivity to either individual devices (e.g., Customer Edge (CE), Digital Subscriber Line Access Multiplexer (DSLAM)) or entire networks (e.g., access network). Figure 1 below depicts the model.
RG内のPEは、個々のデバイス（たとえば、カスタマーエッジ（CE）、デジタル加入者回線アクセスマルチプレクサー（DSLAM））またはネットワーク全体（たとえば、アクセスネットワーク）へのマルチホーム接続を提供します。下の図1はモデルを示しています。
+=================+
| |
Multi-homed +----+ | +-----+ |
Node ------------> | CE |-------|--| PE1 ||<------|---Pseudowire-->|
| |--+ -|--| ||<------|---Pseudowire-->|
+----+ | / | +-----+ |
| / | || |
|/ | || ICCP |--> Towards Core
+-------------+ / | || |
| | /| | +-----+ |
| Access |/ +----|--| PE2 ||<------|---Pseudowire-->|
| Network |-------|--| ||<------|---Pseudowire-->|
| | | +-----+ |
| | | |
+-------------+ | Redundancy |
^ | Group |
| +=================+
|
Multi-homed Network
Figure 1: Generic Multi-Chassis Redundancy Model
図1：汎用マルチシャーシ冗長モデル
In the topology shown in Figure 1, the redundancy mechanism employed towards the access node/network can be one of a multitude of technologies, e.g., it could be IEEE 802.1AX Link Aggregation Groups with the Link Aggregation Control Protocol (LACP) or Synchronous Optical Network Automatic Protection Switching (SONET APS). The specifics of the mechanism are outside the scope of this document. However, it is assumed that the PEs in the RG are required to communicate with each other in order for the access redundancy mechanism to operate correctly. As such, it is required that an inter-chassis communication protocol among the PEs in the RG be run in order to synchronize configuration and/or running state data.
図1に示すトポロジでは、アクセスノード/ネットワークに向けて採用される冗長メカニズムは、多数のテクノロジーの1つである可能性があります。たとえば、リンク集約制御プロトコル（LACP）を備えたIEEE 802.1AXリンク集約グループまたは同期光ネットワーク自動保護切り替え（SONET APS）。メカニズムの詳細は、このドキュメントの範囲外です。ただし、RG内のPEは、アクセス冗長メカニズムが正しく動作するために、相互に通信する必要があると想定されています。このように、構成および/または実行状態データを同期するために、RG内のPE間のシャーシ間通信プロトコルを実行する必要があります。
Furthermore, the presence of the inter-chassis communication channel allows simplification of the pseudowire redundancy mechanism. This is primarily because it allows the PEs within an RG to run some arbitration algorithm to elect which pseudowire(s) should be in active or standby mode for a given service instance. The PEs can then advertise the outcome of the arbitration to the remote-end PE(s), as opposed to having to embed a handshake procedure into the pseudowire redundancy status communication mechanism as well as every other possible Layer 2 status communication mechanism.
さらに、シャーシ間通信チャネルの存在により、疑似配線冗長メカニズムを簡素化できます。これは主に、RG内のPEがアービトレーションアルゴリズムを実行して、特定のサービスインスタンスでアクティブまたはスタンバイモードにする必要がある疑似配線を選択できるようにするためです。次に、PEは、疑似配線冗長ステータス通信メカニズムやその他のすべての可能なレイヤー2ステータス通信メカニズムにハンドシェイク手順を埋め込む必要があるのとは対照的に、アービトレーションの結果をリモートエンドPEにアドバタイズできます。
When referring to "interconnect" in this section, we are concerned with the links or networks over which Inter-Chassis Communication Protocol messages are transported, and not normal data traffic between PEs. The PEs that are members of an RG may be either physically co-located or geo-redundant. Furthermore, the physical interconnect between the PEs over which ICCP is to run may comprise either dedicated back-to-back links or a shared connection through the packet switched network (PSN), e.g., MPLS core network. This gives rise to a matrix of four interconnect scenarios, as described in the following subsections.
このセクションで「相互接続」について言及するときは、シャーシ間通信プロトコルメッセージが転送されるリンクまたはネットワークに関係し、PE間の通常のデータトラフィックには関係しません。 RGのメンバーであるPEは、物理的に同じ場所に配置されるか、地理的に冗長になります。さらに、ＩＣＣＰが実行されるＰＥ間の物理的相互接続は、専用バックツーバックリンクまたはパケット交換ネットワーク（ＰＳＮ）、例えばＭＰＬＳコアネットワークを介した共有接続のいずれかを含み得る。これにより、次のサブセクションで説明するように、4つの相互接続シナリオのマトリックスが生成されます。
In this scenario, the PEs within an RG are co-located in the same physical location, e.g., point of presence (POP) or central office (CO). Furthermore, dedicated links provide the interconnect for ICCP among the PEs.
このシナリオでは、RG内のPEは同じ物理的な場所、たとえば、Point of Presence（POP）またはセントラルオフィス（CO）に同じ場所に配置されます。さらに、専用リンクは、PE間のICCPの相互接続を提供します。
+=================+ +-----------------+
|CO | | |
| +-----+ | | |
| | PE1 |________|_____| |
| | | | | |
| +-----+ | | |
| || | | |
| || ICCP | | Core |
| || | | Network |
| +-----+ | | |
| | PE2 |________|_____| |
| | | | | |
| +-----+ | | |
| | | |
+=================+ +-----------------+
Figure 2: ICCP Co-located PEs Dedicated Interconnect Scenario
図2：ICCP共存PE専用相互接続シナリオ
Given that the PEs are connected back-to-back in this case, it is possible to rely on Layer 2 redundancy mechanisms to guarantee the robustness of the ICCP interconnect. For example, if the interconnect comprises IEEE 802.3 Ethernet links, it is possible to provide link redundancy by means of IEEE 802.1AX Link Aggregation Groups.
この場合、PEがバックツーバックで接続されている場合、レイヤー2冗長メカニズムに依存してICCP相互接続の堅牢性を保証できます。たとえば、インターコネクトがIEEE 802.3イーサネットリンクで構成されている場合、IEEE 802.1AXリンクアグリゲーショングループを使用してリンクの冗長性を提供できます。
In this scenario, the PEs within an RG are co-located in the same physical location (POP, CO). However, unlike the previous scenario, there are no dedicated links between the PEs. The interconnect for ICCP is provided through the core network to which the PEs are connected. Figure 3 depicts this model.
このシナリオでは、RG内のPEは同じ物理的な場所（POP、CO）に同じ場所に配置されます。ただし、前のシナリオとは異なり、PE間に専用リンクはありません。 ICCPの相互接続は、PEが接続されているコアネットワークを通じて提供されます。図3は、このモデルを示しています。
+=================+ +-----------------+
|CO | | |
| +-----+ | | |
| | PE1 |________|_____| |
| | |<=================+ |
| +-----+ ICCP | | || |
| | | || |
| | | || Core |
| | | || Network |
| +-----+ | | || |
| | PE2 |________|_____| || |
| | |<=================+ |
| +-----+ | | |
| | | |
+=================+ +-----------------+
Figure 3: ICCP Co-located PEs Shared Interconnect Scenario
図3：ICCP共存PE共有相互接続シナリオ
Given that the PEs in the RG are connected over the PSN, PSN Layer mechanisms can be leveraged to ensure the resiliency of the interconnect against connectivity failures. For example, it is possible to employ RSVP Label Switched Paths (LSPs) with Fast Reroute (FRR) and/or end-to-end backup LSPs.
RG内のPEがPSNを介して接続されている場合、PSNレイヤーメカニズムを利用して、接続障害に対する相互接続の復元力を確保できます。たとえば、RSVPラベルスイッチドパス（LSP）とFast Reroute（FRR）および/またはエンドツーエンドバックアップLSPを使用することが可能です。
In this variation, the PEs within an RG are located in different physical locations to provide geographic redundancy. This may be desirable, for example, to protect against natural disasters or the like. A dedicated interconnect is provided to link the PEs. This is a costly option, especially when considering the possibility of providing multiple such links for interconnect robustness. The resiliency mechanisms for the interconnect are similar to those highlighted in the co-located interconnect counterpart.
このバリエーションでは、RG内のPEは異なる物理的な場所に配置され、地理的な冗長性を提供します。これは、例えば、自然災害などから保護するために望ましい場合があります。 PEをリンクするための専用インターコネクトが提供されます。これは、特にインターコネクトの堅牢性のためにこのようなリンクを複数提供する可能性を検討する場合、コストのかかるオプションです。相互接続の復元力メカニズムは、同じ場所に配置された相互接続の対応物で強調表示されているメカニズムと似ています。
+=================+ +-----------------+
|CO 1 | | |
| +-----+ | | |
| | PE1 |________|_____| |
| | | | | |
| +-----+ | | |
+=====||==========+ | |
|| ICCP | Core |
+=====||==========+ | Network |
| +-----+ | | |
| | PE2 |________|_____| |
| | | | | |
| +-----+ | | |
|CO 2 | | |
+=================+ +-----------------+
Figure 4: ICCP Geo-redundant PEs Dedicated Interconnect Scenario
図4：ICCP地理冗長PE専用相互接続シナリオ
In this scenario, the PEs of an RG are located in different physical locations and the interconnect for ICCP is provided over the PSN network to which the PEs are connected. This interconnect option is more likely to be the one used for geo-redundancy, as it is more economically appealing compared to the geo-redundant dedicated interconnect option. The resiliency mechanisms that can be employed to guarantee the robustness of the ICCP transport are PSN Layer mechanisms, as described in Section 3.2.2 above.
このシナリオでは、RGのPEは異なる物理的な場所に配置され、PEが接続されているPSNネットワークを介してICCPの相互接続が提供されます。この相互接続オプションは、地理的冗長性専用相互接続オプションと比較して経済的に魅力的であるため、地理的冗長性に使用されるオプションである可能性が高くなります。 ICCPトランスポートの堅牢性を保証するために使用できる回復力メカニズムは、上記のセクション3.2.2で説明されているPSNレイヤーメカニズムです。
+=================+ +-----------------+
|CO 1 | | |
| +-----+ | | |
| | PE1 |________|_____| |
| | |<=================+ |
| +-----+ ICCP | | || |
+=================+ | || |
| || Core |
+=================+ | || Network |
| +-----+ | | || |
| | PE2 |________|_____| || |
| | |<=================+ |
| +-----+ | | |
|CO 2 | | |
+=================+ +-----------------+
Figure 5: ICCP Geo-redundant PEs Shared Interconnect Scenario
図5：ICCP地理冗長PE共有相互接続シナリオ
The requirements for the Inter-Chassis Communication Protocol are as follows:
シャーシ間通信プロトコルの要件は次のとおりです。
i. ICCP MUST provide a control channel for communication between PEs in a Redundancy Group (RG). PE nodes may be co-located or remote (refer to Section 3.2 above). Client applications that make use of ICCP services MUST only use this channel to communicate control information and not data traffic. As such, the protocol SHOULD provide relatively low bandwidth, low delay, and highly reliable message transfer.
i. ICCPは、冗長グループ（RG）内のPE間の通信に制御チャネルを提供する必要があります。 PEノードは同じ場所に配置することも、リモートに配置することもできます（上記のセクション3.2を参照）。 ICCPサービスを利用するクライアントアプリケーションは、データトラフィックではなく制御情報の通信にのみこのチャネルを使用する必要があります。そのため、プロトコルは、比較的低い帯域幅、低い遅延、および信頼性の高いメッセージ転送を提供する必要があります（SHOULD）。
ii. ICCP MUST accommodate multiple client applications (e.g., multi-chassis LACP, PW redundancy, SONET APS). This implies that the messages SHOULD be extensible (e.g., TLV-based), and the protocol SHOULD provide a robust application registration and versioning scheme.
ii。 ICCPは複数のクライアントアプリケーションに対応する必要があります（例：マルチシャーシLACP、PW冗長性、SONET APS）。これは、メッセージが拡張可能である必要があり（たとえば、TLVベース）、プロトコルが堅牢なアプリケーション登録およびバージョン管理スキームを提供する必要があることを意味します。
iii. ICCP MUST provide reliable message transport and in-order delivery between nodes in an RG with secure authentication mechanisms built into the protocol. The redundancy applications that are clients of ICCP expect reliable message transfer and as such will assume that the protocol takes care of flow control and retransmissions. Furthermore, given that the applications will rely on ICCP to communicate data used to synchronize state machines on disparate nodes, it is critical that ICCP guarantees in-order message delivery. Loss of messages or out-of-sequence messages would have adverse effects on the operation of the client applications.
iii。 ICCPは、プロトコルに組み込まれた安全な認証メカニズムを使用して、RG内のノード間で信頼できるメッセージ転送と順序どおりの配信を提供する必要があります。 ICCPのクライアントである冗長アプリケーションは、信頼性のあるメッセージ転送を期待しているため、プロトコルがフロー制御と再送信を処理すると想定します。さらに、アプリケーションがICCPに依存して異種ノード上のステートマシンを同期するために使用されるデータを通信する場合、ICCPがメッセージの順序どおりの配信を保証することが重要です。メッセージが失われたり、順序が正しくなかったりしたメッセージは、クライアントアプリケーションの動作に悪影響を及ぼします。
iv. ICCP MUST provide a common mechanism to actively monitor the health of PEs in an RG. This mechanism will be used to detect PE node failure (or isolation from the MPLS network in the case of shared interconnect) and inform the client applications. The applications require that the mechanism trigger failover according to the procedures of the redundancy protocol employed on the attachment circuit (AC) and PW. The solution SHOULD achieve sub-second detection of loss of remote node (~50-150 msec) in order to give the client applications (redundancy mechanisms) enough reaction time to achieve sub-second service restoration times.
iv。 ICCPは、RG内のPEの状態をアクティブに監視するための共通のメカニズムを提供する必要があります。このメカニズムは、PEノードの障害（または共有相互接続の場合はMPLSネットワークからの分離）を検出し、クライアントアプリケーションに通知するために使用されます。アプリケーションでは、接続回路（AC）とPWで採用されている冗長プロトコルの手順に従って、メカニズムがフェイルオーバーをトリガーする必要があります。このソリューションは、クライアントアプリケーション（冗長メカニズム）に1秒未満のサービス復元時間を達成するのに十分な反応時間を与えるために、リモートノードの損失を1秒未満で検出する必要があります（約50〜150ミリ秒）。
v. ICCP SHOULD provide asynchronous event-driven state update, independent of periodic messages, for immediate notification of client applications' state changes. In other words, the transmission of messages carrying application data SHOULD be on-demand rather than timer-based to minimize inter-chassis state synchronization delay.
v. ICCPは、クライアントアプリケーションの状態変化を即座に通知するために、定期的なメッセージに関係なく、非同期のイベント駆動型の状態更新を提供する必要があります（SHOULD）。言い換えれば、アプリケーションデータを運ぶメッセージの送信は、シャーシ間状態の同期遅延を最小限に抑えるために、タイマーベースではなくオンデマンドである必要があります。
vi. ICCP MUST accommodate multi-link and multi-hop interconnects between nodes. When the devices within an RG are located in different physical locations, the physical interconnect between them will comprise a network rather than a link. As such, ICCP MUST accommodate the case where the interconnect involves multiple hops. Furthermore, it is possible to have multiple (redundant) paths or interconnects between a given pair of devices. This is true for both the co-located and geo-redundant scenarios. ICCP MUST handle this as well.
vi。 ICCPは、ノード間のマルチリンクおよびマルチホップ相互接続に対応する必要があります。 RG内のデバイスが物理的に異なる場所にある場合、それらの間の物理的な相互接続はリンクではなくネットワークを構成します。そのため、ICCPは、相互接続に複数のホップが含まれる場合に対応する必要があります。さらに、特定のデバイスのペア間に複数の（冗長な）パスまたは相互接続を設定することができます。これは、同じ場所に配置されたシナリオと地理的に冗長なシナリオの両方に当てはまります。 ICCPもこれを処理する必要があります。
vii. ICCP MUST ensure transport security between devices in an RG. This is especially important in the scenario where the members of an RG are located in different physical locations and connected over a shared network (e.g., PSN). In particular, ICCP MUST NOT accept connections arbitrarily from any device; otherwise, the state of client applications might be compromised. Furthermore, even if an ICCP connection request appears to come from an eligible device, its source address may have been spoofed. Therefore, some means of preventing source address spoofing MUST be in place.
vii。 ICCPは、RG内のデバイス間のトランスポートセキュリティを確保する必要があります。これは、RGのメンバーが異なる物理的な場所にあり、共有ネットワーク（PSNなど）を介して接続されているシナリオで特に重要です。特に、ICCPは任意のデバイスからの接続を任意に受け入れてはなりません（MUST NOT）。そうしないと、クライアントアプリケーションの状態が損なわれる可能性があります。さらに、適切なデバイスからICCP接続要求が送信されているように見えても、その送信元アドレスがスプーフィングされている可能性があります。したがって、送信元アドレスのスプーフィングを防ぐためのいくつかの手段を講じる必要があります。
viii. ICCP MUST allow the operator to statically configure members of an RG. Auto-discovery may be considered in the future.
viii。 ICCPでは、オペレーターがRGのメンバーを静的に構成できるようにする必要があります。自動検出は将来的に検討される可能性があります。
ix. ICCP SHOULD allow for flexible RG membership. It is expected that only two nodes in an RG will cover most of the redundancy applications for common deployments. ICCP SHOULD NOT preclude supporting more than two nodes in an RG by virtue of design. Furthermore, ICCP MUST allow a single node to be a member of multiple RGs simultaneously.
ix。 ICCPは、柔軟なRGメンバーシップを許可する必要があります（SHOULD）。 RG内の2つのノードのみが、一般的な展開の冗長アプリケーションのほとんどをカバーすることが期待されています。 ICCPは、設計上、RGで3つ以上のノードをサポートすることを排除すべきではありません。さらに、ICCPは、単一のノードが同時に複数のRGのメンバーになることを許可する必要があります。
To address the requirements identified in the previous section, ICCP is modeled to comprise three layers:
前のセクションで識別された要件に対処するために、ICCPは3つの層で構成されるようにモデル化されています。
i. Application Layer: This provides the interface to the various redundancy applications that make use of the services of ICCP. ICCP is concerned with defining common connection management procedures and the formats of the messages exchanged at this layer; however, beyond that, it does not impose any restrictions on the procedures or state machines of the clients, as these are deemed application specific and lie outside the scope of ICCP. This guarantees implementation interoperability without placing any unnecessary constraints on internal design specifics.
私。アプリケーション層：ICCPのサービスを利用するさまざまな冗長性アプリケーションへのインターフェースを提供します。 ICCPは、この層で交換される一般的な接続管理手順とメッセージの形式の定義に関係しています。ただし、それ以外は、クライアントの手順やステートマシンに制限を課すことはありません。これらはアプリケーション固有であると見なされ、ICCPの範囲外にあるためです。これにより、内部設計仕様に不要な制約を課すことなく、実装の相互運用性が保証されます。
ii. Inter-Chassis Communication (ICC) Layer: This layer implements the common set of services that ICCP offers to the client applications. It handles protocol versioning, RG membership, Redundant Object identification, PE node identification, and ICCP connection management.
ii。シャーシ間通信（ICC）レイヤー：このレイヤーはICCPがクライアントアプリケーションに提供するサービスの共通セットを実装します。プロトコルのバージョン管理、RGメンバーシップ、冗長オブジェクトの識別、PEノードの識別、およびICCP接続管理を処理します。
iii. Transport Layer: This layer provides the actual ICCP message transport. It is responsible for addressing, route resolution, flow control, reliable and in-order message delivery, connectivity resiliency/redundancy, and, finally, PE node failure detection. The Transport layer may differ, depending on the Physical Layer of the interconnect.
iii。トランスポート層：この層は、実際のICCPメッセージトランスポートを提供します。アドレッシング、ルート解決、フロー制御、信頼性の高い順序どおりのメッセージ配信、接続の復元力/冗長性、そして最後にPEノードの障害検出を担当します。トランスポート層は、相互接続の物理層によって異なる場合があります。
When an RG is enabled on a particular PE, an LDP session to every remote PE in that RG MUST be created, if one does not already exist. The capability of supporting ICCP MUST then be advertised to all of those LDP peers in that RG. This is achieved by using the methods described in [RFC5561] and advertising the "ICCP capability TLV". If an LDP peer supports the dynamic capability advertisement, this can be done by sending a new capability message with the S-bit set for the "ICCP capability TLV" when the first RG is enabled on the PE. If the peer does not support dynamic capability advertisements, then the "ICCP TLV" MUST be included in the LDP initialization procedures in the capability parameter [RFC5561].
RGが特定のPEで有効になっている場合、まだ存在していない場合は、そのRG内のすべてのリモートPEへのLDPセッションを作成する必要があります。 ICCPをサポートする機能は、そのRG内のすべてのLDPピアにアドバタイズされる必要があります。これは、[RFC5561]で説明されている方法を使用し、「ICCP機能TLV」をアドバタイズすることによって実現されます。 LDPピアが動的機能アドバタイズをサポートしている場合、これは、最初のRGがPEで有効になっているときに、「ICCP機能TLV」にSビットが設定された新しい機能メッセージを送信することで実行できます。ピアが動的機能アドバタイズをサポートしていない場合は、「ICCP TLV」を機能パラメーター[RFC5561]のLDP初期化手順に含める必要があります。
ICCP defines a mechanism that enables PE nodes to manage their RG membership. When a PE is configured to be a member of an RG, it will first advertise the ICCP capability to its peers. Subsequently, the PE sends an "RG Connect" message to the peers that have also advertised ICCP capability. The PE then waits for the peers to send their own "RG Connect" messages, if they haven't done so already. For a given RG, the ICCP connection between two devices is considered to be operational only when both devices have sent and received ICCP "RG Connect" messages for that RG.
ICCPは、PEノードがRGメンバーシップを管理できるようにするメカニズムを定義します。 PEがRGのメンバーになるように構成されている場合、PEは最初にICCP機能をピアにアドバタイズします。その後、PEはIRG機能もアドバタイズしたピアに「RG Connect」メッセージを送信します。 PEは、ピアがまだ送信していない場合は、ピアが独自の「RG Connect」メッセージを送信するのを待ちます。特定のRGについて、2つのデバイス間のICCP接続は、両方のデバイスがそのRGのICCP "RG Connect"メッセージを送受信した場合にのみ機能すると見なされます。
If a PE that has sent a particular "RG Connect" message doesn't receive a corresponding RG Connect (or a Notification message rejecting the connection) from a destination, it will remain in a state of expecting the corresponding "RG Connect" message (or Notification message). The RG will not become operational until the corresponding "RG Connect" message has been received. If a PE that has sent an "RG Connect" message receives a Notification message rejecting the connection, with a NAK TLV (Negative Acknowledgement TLV) (Section 6.4.1), it will stop attempting to bring up the ICCP connection immediately.
特定の「RG Connect」メッセージを送信したPEが、対応するRG Connect（または接続を拒否する通知メッセージ）を宛先から受信しない場合、対応する「RG Connect」メッセージを予期する状態のままになります（または通知メッセージ）。 RGは、対応する「RG Connect」メッセージが受信されるまで動作しません。 「RG Connect」メッセージを送信したPEが、NAK TLV（否定応答TLV）（セクション6.4.1）を使用して、接続を拒否する通知メッセージを受信すると、すぐにICCP接続を開始しようとするのを停止します。
A device MUST reject an incoming "RG Connect" message if at least one of the following conditions is satisfied:
次の条件の少なくとも1つが満たされた場合、デバイスは着信「RG Connect」メッセージを拒否する必要があります。
i. the PE is not a member of the RG;
i. PEはRGのメンバーではありません。
ii. the maximum number of simultaneous ICCP connections that the PE can handle is exceeded.
ii。 PEが処理できる同時ICCP接続の最大数を超えています。
Otherwise, the PE MUST bring up the connection by responding to the incoming "RG Connect" message with an appropriate RG Connect.
それ以外の場合、PEは適切なRG Connectで着信「RG Connect」メッセージに応答することにより、接続を確立する必要があります。
A PE sends an "RG Disconnect" message to tear down the ICCP connection for a given RG. This is a unilateral operation and doesn't require any acknowledgement from the other PEs. Note that the ICCP connection for an RG MUST be operational before any client application can make use of ICCP services in that RG.
PEは「RG Disconnect」メッセージを送信して、特定のRGのICCP接続を切断します。これは一方的な操作であり、他のPEからの確認応答を必要としません。 RGのICCP接続は、クライアントアプリケーションがそのRGでICCPサービスを利用する前に動作可能でなければならないことに注意してください。
A PE maintains an ICCP Connection state machine instance for every ICCP connection with a remote peer in the RG. This state machine is separate from any Application Connection state machine (Section 4.4.2). The ICCP Connection state machine reacts only to "RG Connect", "RG Disconnect", and "RG Notification" messages that do not contain any "Application TLVs". Actions and state transitions in the Application Connection state machines have no effect on the ICCP Connection state machine.
PEは、RG内のリモートピアとのICCP接続ごとにICCP接続状態マシンインスタンスを維持します。この状態マシンは、アプリケーション接続状態マシンとは別のものです（セクション4.4.2）。 ICCP接続状態マシンは、「アプリケーションTLV」を含まない「RG接続」、「RG切断」、および「RG通知」メッセージにのみ反応します。アプリケーション接続状態マシンのアクションと状態遷移は、ICCP接続状態マシンに影響を与えません。
The ICCP Connection state machine is defined to have six states, as follows:
ICCP接続状態マシンは、次のように6つの状態を持つように定義されています。
- NONEXISTENT: This state is the starting point for the state machine. It indicates that no ICCP connection exists and that there's no LDP session established between the PEs.
- NONEXISTENT：この状態は、状態マシンの開始点です。 ICCP接続が存在せず、PE間にLDPセッションが確立されていないことを示しています。
- INITIALIZED: This state indicates that an LDP session exists between the PEs but LDP ICCP capability information has not yet been exchanged between them.
- INITIALIZED：この状態は、LDPセッションがPE間に存在するが、LDP ICCP機能情報がまだそれらの間で交換されていないことを示します。
- CAPSENT: This state indicates that an LDP session exists between the PEs and that the local PE has advertised LDP ICCP capability to its peer.
- CAPSENT：この状態は、LDPセッションがPE間に存在し、ローカルPEがLDP ICCP機能をピアにアドバタイズしたことを示します。
- CAPREC: This state indicates that an LDP session exists between the PEs and that the local PE has both received and advertised LDP ICCP capability from/to its peer.
- CAPREC：この状態は、LDPセッションがPE間に存在し、ローカルPEがピアとの間でLDP ICCP機能を受信およびアドバタイズしたことを示します。
- CONNECTING: This state indicates that the local PE has initiated an ICCP connection to its peer and is awaiting its response.
- CONNECTING：この状態は、ローカルPEがピアへのICCP接続を開始し、その応答を待っていることを示します。
- OPERATIONAL: This state indicates that the ICCP connection is operational.
- OPERATIONAL：この状態は、ICCP接続が機能していることを示します。
The state transition table and state transition diagram follow.
状態遷移表と状態遷移図を以下に示します。
ICCP Connection State Transition Table
ICCP接続状態遷移表
STATE EVENT NEW STATE
--------------------------------------------------------------------
NONEXISTENT LDP session established INITIALIZED
INITIALIZED Transmit LDP ICCP capability CAPSENT
INITIALIZED送信LDP ICCP機能CAPSENT
Receive LDP ICCP capability CAPREC Action: Transmit LDP ICCP capability
LDP ICCP機能の受信CAPRECアクション：LDP ICCP機能の送信
LDP session torn down NONEXISTENT
LDPセッションがNONEXISTENTを破棄しました
CAPSENT Receive LDP ICCP capability CAPREC
CAPSENT受信LDP ICCP機能CAPREC
LDP session torn down NONEXISTENT
LDPセッションがNONEXISTENTを破棄しました
CAPREC Transmit RG Connect message CONNECTING
CAPREC送信RG接続メッセージ
Receive acceptable RG Connect message OPERATIONAL Action: Transmit RG Connect message
受け入れ可能なRG接続メッセージを受信します。操作：RG接続メッセージを送信します。
Receive any other ICCP message CAPREC Action: Transmit NAK TLV in RG Notification message
その他のICCPメッセージを受信するCAPRECアクション：RG通知メッセージでNAK TLVを送信する
LDP session torn down NONEXISTENT
LDPセッションがNONEXISTENTを破棄しました
CONNECTING Receive acceptable RG Connect message OPERATIONAL
CONNECTING受け入れ可能なRG Connectメッセージを受信OPERATIONAL
Receive any other ICCP message CAPREC Action: Transmit NAK TLV in RG Notification message
その他のICCPメッセージを受信するCAPRECアクション：RG通知メッセージでNAK TLVを送信する
LDP session torn down NONEXISTENT
LDPセッションがNONEXISTENTを破棄しました
OPERATIONAL Receive acceptable RG Disconnect message CAPREC
OPERATIONAL受け入れ可能なRG DisconnectメッセージCAPRECを受信
Transmit RG Disconnect message CAPREC
RG切断メッセージCAPRECを送信する
LDP session torn down NONEXISTENT
LDPセッションがNONEXISTENTを破棄しました
ICCP Connection State Transition Diagram
ICCP接続状態遷移図
+------------+
| |
+------------------>|NONEXISTENT | LDP session torn down
| | |<--------------------------+
| +------------+ |
| LDP session | ^ LDP session |
| established | | torn down |
| V | |
| +-----------+ |
LDP | | | Tx LDP ICCP |
session| |INITIALIZED| capability |
torn | +---| |---------------+ |
down | Rx other | +-----------+ | |
| ICCP msg/ |Rx LDP ICCP | |
| Tx NAK TLV | capability/ | |
| +---+ |Tx LDP ICCP capability | |
| | | | | |
| V | V V |
| +-----------+ Rx LDP ICCP +--------+ |
+---| | capability | | |
|CAPREC |<----------------------|CAPSENT |---------->+
+---| |-------------------+ | | |
| +-----------+ | +--------+ |
| ^ ^ | |
Tx | | | | |
RG | | |Rx RG Disconnect msg | |
Connect| | | or |Rx RG Connect msg/ |
msg | | |Tx RG Disconnect msg | Tx RG Connect msg |
| | | V |
| | | +------------+ |
| | +--------------------| | |
| | |OPERATIONAL |------------>+
| | | | |
| |Rx other ICCP msg/ +------------+ |
| | Tx NAK TLV ^ |
| | | |
| +----------+ Rx RG Connect msg | |
| | |---------------------+ |
+----->|CONNECTING| |
| |----------------------------------------->+
+----------+
ICCP offers its client applications a uniform mechanism for identifying links, ports, forwarding constructs, and, more generally, objects (e.g., interfaces, pseudowires, VLANs) that are being protected in a redundant setup. These are referred to as Redundant Objects (ROs). An example of an RO is a multi-chassis link-aggregation group that spans two PEs. ICCP introduces a 64-bit opaque identifier to uniquely identify ROs in an RG. This identifier, referred to as the Redundant Object ID (ROID), MUST match between RG members for the protected object in question; this allows separate systems in an RG to use a common handle to reference the protected entity, irrespective of its nature (e.g., physical or virtual) and in a manner that is agnostic to implementation specifics. Client applications that need to synchronize state pertaining to a particular RO SHOULD embed the corresponding ROID in their TLVs.
ICCPは、クライアントアプリケーションに、リンク、ポート、転送構造、より一般的には冗長構成で保護されているオブジェクト（インターフェース、疑似配線、VLANなど）を識別するための統一されたメカニズムを提供します。これらは、冗長オブジェクト（RO）と呼ばれます。 ROの例は、2つのPEにまたがるマルチシャーシリンク集約グループです。 ICCPは、64ビットの不透明な識別子を導入して、RG内のROを一意に識別します。冗長オブジェクトID（ROID）と呼ばれるこの識別子は、問題の保護オブジェクトのRGメンバー間で一致する必要があります。これにより、RG内の別々のシステムが、その性質（物理的または仮想など）に関係なく、実装の詳細にとらわれない方法で、共通のハンドルを使用して保護されたエンティティを参照できます。特定のROに関連する状態を同期する必要があるクライアントアプリケーションは、対応するROIDをTLVに埋め込む必要があります（SHOULD）。
ICCP provides a common set of procedures by which applications on one PE can connect to their counterparts on another PE, for the purpose of inter-chassis communication in the context of a given RG. The prerequisite for establishing an Application Connection is to have an operational ICCP RG connection between the two endpoints. It is assumed that the association of applications with RGs is known a priori, e.g., by means of device configuration. ICCP then sends an "Application Connect TLV" (carried in an "RG Connect" message), on behalf of each client application, to each remote PE within the RG. The client may piggyback application-specific information in that "Connect TLV", which, for example, can be used to negotiate parameters or attributes prior to bringing up the actual Application Connection. The procedures for bringing up the Application Connection are similar to those of the ICCP connection: an Application Connection between two nodes is up only when both nodes have sent and received "RG Connect" messages with the proper "Application Connect TLVs". A PE MUST send a Notification message to reject an Application Connection request if one of the following conditions is encountered:
ICCPは、特定のRGのコンテキストでシャーシ間通信を行うために、1つのPE上のアプリケーションが別のPE上の対応するアプリケーションに接続できるようにする一連の共通の手順を提供します。アプリケーション接続を確立するための前提条件は、2つのエンドポイント間にICCP RG接続が機能していることです。アプリケーションとRGの関連付けは、たとえばデバイス構成によって、事前にわかっていると想定されています。次にICCPは、各クライアントアプリケーションに代わって、「Application Connect TLV」（「RG Connect」メッセージで送信される）をRG内の各リモートPEに送信します。クライアントは、その「接続TLV」でアプリケーション固有の情報を便乗させることができます。これは、たとえば、実際のアプリケーション接続を開始する前にパラメーターまたは属性をネゴシエートするために使用できます。アプリケーション接続を開始する手順はICCP接続の手順と似ています。2つのノード間のアプリケーション接続は、両方のノードが適切な「アプリケーション接続TLV」を使用して「RG接続」メッセージを送受信した場合にのみ起動します。次の条件のいずれかが発生した場合、PEは通知メッセージを送信して、アプリケーション接続要求を拒否する必要があります。
i. the application doesn't exist or is not configured for that RG;
i. アプリケーションが存在しないか、そのRGに対して構成されていません。
ii. the Application Connection count exceeds the PE's capabilities.
ii。アプリケーション接続数がPEの機能を超えています。
When a PE receives such a rejection notification, it MUST stop attempting to bring up the Application Connection until it receives a new Application Connection request from the remote PE. This is done by responding to the incoming "RG Connect" message (carrying an "Application Connect TLV") with an appropriate "RG Connect" message (carrying a corresponding "Application Connect TLV").
PEがそのような拒否通知を受信した場合、リモートPEから新しいアプリケーション接続要求を受信するまで、アプリケーション接続を起動する試みを停止する必要があります。これは、適切な「RG接続」メッセージ（対応する「アプリケーション接続TLV」を運ぶ）で着信「RG接続」メッセージ（「アプリケーション接続TLV」を運ぶ）に応答することによって行われます。
When an application is stopped on a device or it is no longer associated with an RG, it MUST signal ICCP to trigger sending an "Application Disconnect TLV" (in the "RG Disconnect" message). This is a unilateral notification to the other PEs within an RG and as such doesn't trigger any response.
デバイス上でアプリケーションが停止した場合、またはRGに関連付けられなくなった場合、アプリケーションはICCPに信号を送り、「アプリケーション切断TLV」（「RG切断」メッセージ内）の送信をトリガーする必要があります。これは、RG内の他のPEへの一方的な通知であり、応答をトリガーしません。
During Application Connection setup, a given application on one PE can negotiate with its counterpart on a peer PE the proper application version to use for communication. If no common version is agreed upon, then the Application Connection is not brought up. This is achieved through the following set of rules:
アプリケーション接続のセットアップ中に、1つのPE上の特定のアプリケーションは、通信に使用する適切なアプリケーションバージョンをピアPE上の対応するアプリケーションとネゴシエートできます。共通バージョンが合意されていない場合、アプリケーション接続は起動されません。これは、次の一連のルールによって実現されます。
- If an application receives an "Application Connect TLV" with a version number that is higher than its own, it MUST send a Notification message with a "NAK TLV" indicating status code "Incompatible Protocol Version" and supplying the version that is locally supported by the PE.
- アプリケーションが自身のバージョン番号よりも高いバージョン番号の「Application Connect TLV」を受け取った場合、ステータスコード「Incompatible Protocol Version」を示し、ローカルでサポートされているバージョンを提供する「NAK TLV」を含む通知メッセージを送信する必要があります。 PE。
- If an application receives an "Application Connect TLV" with a version number that is lower than its own, it MAY respond with an RG Connect that has an "Application Connect TLV" using the same version that was received. Alternatively, the application MAY respond with a Notification message to reject the request using the "Incompatible Protocol Version" code and supply the version that is supported. This allows an application to operate in either backwards-compatible or incompatible mode.
- アプリケーションが自身のバージョン番号よりも小さいバージョン番号の「Application Connect TLV」を受信した場合、受信したのと同じバージョンを使用して「Application Connect TLV」を持つRG Connectで応答する場合があります。または、アプリケーションは、「互換性のないプロトコルバージョン」コードを使用してリクエストを拒否し、サポートされているバージョンを提供するために、通知メッセージで応答する場合があります。これにより、アプリケーションは下位互換モードまたは非互換モードで動作できます。
- If an application receives an "Application Connect TLV" with a version that is equal to its own, then the application MUST honor or reject the request based on whether the application is configured for the RG in question, and whether or not the Application Connection count has been exceeded.
- アプリケーションが自身のバージョンと同じバージョンの「Application Connect TLV」を受信した場合、アプリケーションは、問題のRGに対してアプリケーションが構成されているかどうか、およびアプリケーション接続数に基づいて、要求を受け入れるか拒否する必要があります。超えました。
A PE maintains one Application Connection state machine instance per ICCP application for every ICCP connection with a remote PE in the RG. Each application's state machine reacts only to the "RG Connect", "RG Disconnect", and "RG Notification" messages that contain an "Application TLV" specifying that particular application.
PEは、RG内のリモートPEとのICCP接続ごとに、ICCPアプリケーションごとに1つのアプリケーション接続状態マシンインスタンスを維持します。各アプリケーションの状態マシンは、その特定のアプリケーションを指定する「アプリケーションTLV」を含む「RG接続」、「RG切断」、および「RG通知」メッセージにのみ反応します。
The Application Connection state machine has six states, as follows:
アプリケーション接続状態マシンには、次の6つの状態があります。
- NONEXISTENT: This state indicates that the Application Connection does not exist, since there is no ICCP connection between the PEs.
- NONEXISTENT：この状態は、PE間にICCP接続がないため、アプリケーション接続が存在しないことを示します。
- RESET: This state indicates that an ICCP connection is operational between the PEs but that the Application Connection has not been initialized yet or has been resent.
- RESET：この状態は、PE間でICCP接続が機能しているが、アプリケーション接続がまだ初期化されていないか、再送信されたことを示します。
- CONNSENT: This state indicates that the local PE has requested initiation of an Application Connection with its peer but has not received a response yet.
- CONNSENT：この状態は、ローカルPEがピアとのアプリケーション接続の開始を要求したが、まだ応答を受け取っていないことを示しています。
- CONNREC: This state indicates that the local PE has received a request to initiate an Application Connection from its peer but has not responded yet.
- CONNREC：この状態は、ローカルPEがピアからアプリケーション接続を開始する要求を受信したが、まだ応答していないことを示します。
- CONNECTING: This state indicates that the local PE has transmitted to its peer an "Application Connection" message with the A-bit set to 1 and is awaiting the peer's response.
- CONNECTING：この状態は、ローカルPEがそのピアにAビットが1に設定された「アプリケーション接続」メッセージを送信し、ピアの応答を待っていることを示します。
- OPERATIONAL: This state indicates that the Application Connection is operational.
- OPERATIONAL：この状態は、アプリケーション接続が機能していることを示します。
The state transition table and state transition diagram follow.
状態遷移表と状態遷移図を以下に示します。
ICCP Application Connection State Transition Table
ICCPアプリケーション接続状態遷移表
STATE EVENT NEW STATE
-------------------------------------------------------------------
NONEXISTENT ICCP connection established RESET
RESET ICCP connection torn down NONEXISTENT
リセットICCP接続が切断されましたNONEXISTENT
Transmit Application Connect TLV CONNSENT
送信アプリケーション接続TLV CONNSENT
Receive Application Connect TLV CONNREC
受信アプリケーション接続TLV CONNREC
Receive any other Application TLV RESET Action: Transmit NAK TLV
その他のアプリケーションTLVリセットアクションを受信する：NAK TLVを送信する
CONNSENT Receive NAK TLV RESET
CONNSENT受信NAK TLVリセット
Receive Application Connect TLV OPERATIONAL with A-bit=1 Action: Transmit Application Connect TLV with A-bit=1
A-bit = 1でApplication Connect TLV OPERATIONALを受信するアクション：A-bit = 1でApplication Connect TLVを送信する
Receive any other Application TLV RESET Action: Transmit NAK TLV
その他のアプリケーションTLVリセットアクションを受信する：NAK TLVを送信する
ICCP connection torn down NONEXISTENT
ICCP接続がNONEXISTENTに切断されました
CONNREC Transmit NAK TLV RESET
CONNREC送信NAK TLVリセット
Transmit Application Connect TLV CONNECTING with A-bit=1
Transmit Application Connect TLV CONNECTING with A-bit = 1
Receive Application Connect TLV CONNREC
受信アプリケーション接続TLV CONNREC
Receive any Application TLV except RESET Connect Action: Transmit NAK TLV
RESET接続アクションを除くすべてのアプリケーションTLVを受信：NAK TLVを送信
ICCP connection torn down NONEXISTENT
ICCP接続がNONEXISTENTに切断されました
CONNECTING Receive Application Connect TLV OPERATIONAL with A-bit=1
CONNECTING RECEIVE Application Connect TLV OPERATIONAL with A-bit = 1
Receive any other Application TLV RESET Action: Transmit NAK TLV
その他のアプリケーションTLVリセットアクションを受信する：NAK TLVを送信する
ICCP connection torn down NONEXISTENT
ICCP接続がNONEXISTENTに切断されました
OPERATIONAL Receive Application Disconnect TLV RESET
OPERATIONAL受信アプリケーション切断TLVリセット
Transmit Application Disconnect TLV RESET
送信アプリケーション切断TLVリセット
ICCP connection torn down NONEXISTENT
ICCP接続がNONEXISTENTに切断されました
ICCP Application Connection State Transition Diagram
ICCPアプリケーション接続状態遷移図
+------------+
| |
+---------------->|NONEXISTENT | ICCP connection torn down
| | |<--------------------------+
| +------------+ |
| ICCP connection| ^ ICCP connection |
| established | | torn down |
| | | |
| V | Rx other App TLV/ |
| +-----------+<-----+ Tx NAK TLV |
ICCP | Rx App | | | |
connect| Connect TLV | RESET |------+ |
torn | +-------------| |---------------+ |
down | | +-----------+ Tx App | |
| | ^ ^ ^ ^ Connect TLV| |
| | Tx NAK | | | | | |
| | or | | | | | |
| | Rx non- | | | | | |
| | Connect | | | | | |
| V TLV/Tx NAK | | |Rx NAK TLV V |
| +-----------+ | | | |or +--------+ |
+-| |---+ | | +---------| | |
|CONNREC | | | Rx other |CONNSENT|---------->+
+-| |-+ | | App TLV/ | | |
| +-----------+ | | | Tx NAK +--------+ |
| ^---+ | | |Rx App Connect |
| Rx App | | |TLV (A=1)/ |
| Connect TLV | |Rx App Disconn | Tx App |
| | |or | Connect TLV |
| Tx App Connect | |Tx App Disconn V (A=1) |
| TLV (A=1) | | +------------+ |
| | +------| | |
| Rx other App | |OPERATIONAL |------------>+
| TLV/Tx NAK | | | |
| +------+ +------------+ |
| | ^ Rx App Connect |
| +----------+ | TLV (A=1) |
| | |---------------------+ |
+--->|CONNECTING| |
| |----------------------------------------->+
+----------+
When an application has information to transfer over ICCP, it triggers the transmission of an "Application Data" message. ICCP guarantees in-order and lossless delivery of data. An application may reject a message or a set of one or more TLVs within a message by using the Notification message with a "NAK TLV". Furthermore, an application may implement its own ACK mechanism, if deemed required, by defining an application-specific TLV to be transported in an "Application Data" message. Note that this document does not define a common ACK mechanism for applications.
アプリケーションがICCPを介して転送する情報を持っている場合、「アプリケーションデータ」メッセージの送信をトリガーします。 ICCPは、データの順序どおりの損失のない配信を保証します。アプリケーションは、「NAK TLV」を含む通知メッセージを使用して、メッセージまたはメッセージ内の1つ以上のTLVのセットを拒否する場合があります。さらに、アプリケーションは、「アプリケーションデータ」メッセージで転送されるアプリケーション固有のTLVを定義することにより、必要と思われる場合、独自のACKメカニズムを実装できます。このドキュメントでは、アプリケーションの一般的なACKメカニズムを定義していないことに注意してください。
It is left up to the application to define the procedures to handle the situation where a PE receives a "NAK TLV" in response to a transmitted "Application Data" message. Depending on the specifics of the application, it may be favorable to have the PE that sent the NAK explicitly request retransmission of data. On the other hand, for certain applications it may be more suitable to have the original sender of the "Application Data" message handle retransmissions in response to a NAK. ICCP supports both models.
送信された「アプリケーションデータ」メッセージに応答してPEが「NAK TLV」を受信する状況を処理する手順を定義するのはアプリケーションに任されています。アプリケーションの詳細によっては、NAKを送信したPEがデータの再送信を明示的に要求することが望ましい場合があります。一方、特定のアプリケーションでは、「アプリケーションデータ」メッセージの元の送信者にNAKへの応答として再送信を処理させる方が適切な場合があります。 ICCPは両方のモデルをサポートしています。
For certain ICCP applications, it is required that a fairly large amount of RG information be exchanged in a very short period of time. In order to better distribute the load in a multiple-processor system, and to avoid head-of-line blocking to other LDP applications, initiating a separate TCP/IP session between the two LDP speakers may be required.
特定のICCPアプリケーションでは、非常に短時間でかなり大量のRG情報を交換する必要があります。マルチプロセッサシステムで負荷をより適切に分散し、他のLDPアプリケーションへの行頭ブロッキングを回避するために、2つのLDPスピーカー間で個別のTCP / IPセッションを開始することが必要になる場合があります。
This procedure is OPTIONAL and does not change the operation of LDP or ICCP.
この手順はオプションであり、LDPまたはICCPの動作を変更しません。
A PE that requires a separate LDP session will advertise a separate LDP adjacency with a non-zero label space identifier. This will cause the remote peer to open a separate LDP session for this label space. No labels need to be advertised in this label space, as it is only used for one or a set of ICCP RGs. All relevant LDP and ICCP procedures still apply as described in [RFC5036] and this document.
個別のLDPセッションを必要とするPEは、ゼロ以外のラベルスペース識別子で個別のLDP隣接をアドバタイズします。これにより、リモートピアはこのラベルスペース用に別のLDPセッションを開きます。このラベルスペースは、1つまたは一連のICCP RGにのみ使用されるため、ラベルをアドバタイズする必要はありません。 [RFC5036]およびこのドキュメントで説明されているように、関連するすべてのLDPおよびICCP手順が引き続き適用されます。
ICCP provides its client applications a notification when a remote PE that is a member of the RG is no longer reachable. In the case of a dedicated interconnect, this indicates that the remote PE node has failed, whereas in the case of a shared interconnect this indicates that the remote PE node has either failed or become isolated from the MPLS network. This information is used by the client applications to trigger failover according to the procedures of the redundancy protocol employed on the AC and PW. To that end, ICCP does not define its own Keep-Alive mechanism for the purpose of monitoring the health of remote PE nodes but rather reuses existing fault detection mechanisms. The following mechanisms may be used by ICCP to detect PE node failure:
ICCPは、RGのメンバーであるリモートPEに到達できなくなったときに、クライアントアプリケーションに通知を提供します。専用インターコネクトの場合、これはリモートPEノードに障害が発生したことを示し、共有インターコネクトの場合、これはリモートPEノードに障害が発生したか、MPLSネットワークから分離されたことを示します。この情報は、クライアントアプリケーションによって使用され、ACおよびPWで採用されている冗長プロトコルの手順に従ってフェイルオーバーをトリガーします。そのため、ICCPはリモートPEノードの状態を監視する目的で独自のキープアライブメカニズムを定義していませんが、既存の障害検出メカニズムを再利用しています。 ICCPは、PEノードの障害を検出するために次のメカニズムを使用できます。
- Bidirectional Forwarding Detection (BFD)
- 双方向転送検出（BFD）
Run a BFD session [RFC5880] between the PEs that are members of a given RG, and use that to detect PE node failure. This assumes that resiliency mechanisms are in place to protect connectivity to the remote PE nodes, and hence loss of BFD periodic messages from a given PE node can only mean that the node itself has failed.
特定のRGのメンバーであるPE間でBFDセッション[RFC5880]を実行し、それを使用してPEノードの障害を検出します。これは、リモートPEノードへの接続を保護するための復元メカニズムが整っていることを前提としているため、特定のPEノードからのBFD定期メッセージの損失は、ノード自体に障害が発生したことを意味するだけです。
- IP Reachability Monitoring
- IP到達可能性モニタリング
It is possible for a PE to monitor IP-layer connectivity to other members of an RG that are participating in IGP/BGP. When connectivity to a given PE is lost, the local PE interprets that to mean loss of the remote PE node. This technique assumes that resiliency mechanisms are in place to protect the route to the remote PE nodes, and hence loss of IP reachability to a given node can only mean that the node itself has failed.
PEは、IGP / BGPに参加しているRGの他のメンバーへのIP層接続を監視できます。特定のPEへの接続が失われると、ローカルPEはそれをリモートPEノードの損失を意味すると解釈します。この手法は、リモートPEノードへのルートを保護するために回復力メカニズムが配備されていることを前提としているため、特定のノードへのIP到達可能性の損失は、ノード自体に障害が発生したことを意味するだけです。
It is worth noting here that loss of the LDP session with a PE in an RG is not a reliable indicator that the remote PE itself is down. It is possible, for example, that the remote PE could encounter a local event that would lead to resetting the LDP session, while the PE node would remain operational for traffic forwarding purposes.
ここで、RG内のPEとのLDPセッションが失われたことは、リモートPE自体がダウンしていることを示す信頼できる指標ではないことに注意してください。たとえば、リモートPEがローカルイベントに遭遇し、LDPセッションのリセットにつながる可能性がありますが、PEノードはトラフィック転送のために動作したままになる可能性があります。
This section defines the messages exchanged at the Application and ICC layers.
このセクションでは、アプリケーション層とICC層で交換されるメッセージを定義します。
ICCP requires reliable, in-order, stateful message delivery, as well as capability negotiation between PEs. LDP offers all of these features and is already in wide use in the applications that would also require the ICCP protocol extensions. For these reasons, ICCP takes advantage of the already-defined LDP protocol infrastructure.
ICCPには、PE間の機能ネゴシエーションだけでなく、信頼性の高い、順序正しく、ステートフルなメッセージ配信が必要です。 LDPはこれらすべての機能を提供し、ICCPプロトコル拡張も必要とするアプリケーションですでに広く使用されています。これらの理由により、ICCPはすでに定義されているLDPプロトコルインフラストラクチャを利用します。
[RFC5036], Section 3.5 defines a generic LDP message structure. A new set of LDP message types is defined to communicate the ICCP information. LDP message types in the range 0x0700 to 0x070F will be used for ICCP.
[RFC5036]、セクション3.5は一般的なLDPメッセージ構造を定義しています。 ICCP情報を通信するために、LDPメッセージタイプの新しいセットが定義されています。 ICCPでは、0x0700〜0x070Fの範囲のLDPメッセージタイプが使用されます。
Message types have been allocated by IANA; see Section 12 below for details.
メッセージタイプはIANAによって割り当てられています。詳細については、以下のセクション12を参照してください。
Every ICCP message comprises an ICC-specific LDP Header followed by message data. The format of the ICC Header is as follows:
すべてのICCPメッセージは、ICC固有のLDPヘッダーとそれに続くメッセージデータで構成されます。 ICCヘッダーの形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U| Message Type | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x0005 (ICC RG ID) | Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ICC RG ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Mandatory ICC Parameters |
~ ~
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Optional ICC Parameters |
~ ~
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- U-bit
- Uビット
Unknown message bit. Upon receipt of an unknown message, if U is clear (=0), a notification is returned to the message originator; if U is set (=1), the unknown message is silently ignored. Subsequent sections that define messages specify a value for the U-bit.
不明なメッセージビット。不明なメッセージを受信すると、Uがクリア（= 0）の場合、メッセージの発信者に通知が返されます。 Uが設定されている場合（= 1）、不明なメッセージは通知なく無視されます。メッセージを定義する後続のセクションでは、Uビットの値を指定します。
- Message Type
- メッセージタイプ
Identifies the type of the ICCP message. Must be in the range 0x0700 to 0x070F.
ICCPメッセージのタイプを識別します。 0x0700から0x070Fの範囲でなければなりません。
- Message Length
- メッセージの長さ
2-octet integer specifying the total length of this message in octets, excluding the "U-bit", "Message Type", and "Length" fields.
このメッセージの全長をオクテットで指定する2オクテット整数。「Uビット」、「メッセージタイプ」、および「長さ」フィールドは除きます。
- Message ID
- メッセージID
4-octet value used to identify this message. Used by the sending PE to facilitate identifying "RG Notification" messages that may apply to this message. A PE sending an "RG Notification" message in response to this message SHOULD include this Message ID in the "NAK TLV" of the "RG Notification" message; see Section 6.4.
このメッセージを識別するために使用される4オクテットの値。このメッセージに適用される可能性のある「RG通知」メッセージの識別を容易にするために送信側PEによって使用されます。このメッセージに応答して「RG通知」メッセージを送信するPEは、「RG通知」メッセージの「NAK TLV」にこのメッセージIDを含める必要があります。セクション6.4を参照してください。
- ICC RG ID TLV
- ICC RG ID TLV
A TLV of type 0x0005, length 4, containing a 4-octet unsigned integer designating the Redundancy Group of which the sending device is a member. RG ID value 0x00000000 is reserved by the protocol.
送信デバイスがメンバーである冗長グループを指定する4オクテットの符号なし整数を含む、タイプ0x0005、長さ4のTLV。 RG ID値0x00000000は、プロトコルによって予約されています。
- Mandatory ICC Parameters
- 必須のICCパラメータ
Variable-length set of required message parameters. Some messages have no required parameters.
必要なメッセージパラメータの可変長セット。一部のメッセージには必須パラメーターがありません。
For messages that have required parameters, the required parameters MUST appear in the order specified by the individual message specifications in the sections that follow.
必須パラメーターを持つメッセージの場合、必須パラメーターは、以降のセクションの個々のメッセージ仕様で指定された順序で出現する必要があります。
- Optional ICC Parameters
- オプションのICCパラメータ
Variable-length set of optional message parameters. Many messages have no optional parameters.
オプションのメッセージパラメータの可変長セット。多くのメッセージにはオプションのパラメーターがありません。
For messages that have optional parameters, the optional parameters may appear in any order.
オプションのパラメーターを持つメッセージの場合、オプションのパラメーターは任意の順序で表示されます。
The generic format of an ICC parameter is as follows:
ICCパラメータの一般的な形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV(s) |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- U-bit
- Uビット
Unknown TLV bit. Upon receipt of an unknown TLV, if U is clear (=0), a notification MUST be returned to the message originator and the entire message MUST be ignored; if U is set (=1), the unknown TLV MUST be silently ignored and the rest of the message processed as if the unknown TLV did not exist. Subsequent sections that define TLVs specify a value for the U-bit.
不明なTLVビット。不明なTLVを受信したときに、Uがクリア（= 0）の場合は、メッセージの発信者に通知を返し、メッセージ全体を無視する必要があります。 Uが設定されている場合（= 1）、不明なTLVは暗黙的に無視され、残りのメッセージは不明なTLVが存在しないかのように処理されます。 TLVを定義する後続のセクションでは、Uビットの値を指定します。
- F-bit
- Fビット
Forward unknown TLV bit. This bit applies only when the U-bit is set and the LDP message containing the unknown TLV is to be forwarded. If F is clear (=0), the unknown TLV is not forwarded with the LDP message; if F is set (=1), the unknown TLV is forwarded with the LDP message. Subsequent sections that define TLVs specify a value for the F-bit. By setting both the U- and F-bits, a TLV can be propagated as opaque data through nodes that do not recognize the TLV.
不明なTLVビットを転送します。このビットは、Uビットが設定されていて、不明なTLVを含むLDPメッセージが転送される場合にのみ適用されます。 Fがクリア（= 0）の場合、不明なTLVはLDPメッセージとともに転送されません。 Fが設定されている場合（= 1）、不明なTLVがLDPメッセージと共に転送されます。 TLVを定義する後続のセクションでは、Fビットの値を指定します。 UビットとFビットの両方を設定することにより、TLVは、TLVを認識しないノードを介して不透明なデータとして伝播できます。
- Type
- タイプ
14 bits indicating the ICC Parameter type.
ICCパラメータタイプを示す14ビット。
- Length
- 長さ
Length of the TLV in octets, excluding the "U-bit", "F-bit", "Type", and "Length" fields.
「Uビット」、「Fビット」、「タイプ」、および「長さ」フィールドを除く、オクテット単位のTLVの長さ。
- TLV(s): A set of 0 or more TLVs. Contents will vary according to the message type.
- TLV（s）：0個以上のTLVのセット。内容はメッセージの種類によって異なります。
The Redundant Object Identifier (ROID) is a generic opaque handle that uniquely identifies a Redundant Object (e.g., link, bundle, VLAN) that is being protected in an RG. It is encoded as follows:
冗長オブジェクト識別子（ROID）は、RGで保護されている冗長オブジェクト（リンク、バンドル、VLANなど）を一意に識別する汎用の不透明ハンドルです。次のようにエンコードされます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ROID |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where the ROID is an 8-octet field encoded as an unsigned integer. The ROID value of 0 is reserved.
ここで、ROIDは、符号なし整数としてエンコードされた8オクテットのフィールドです。 ROID値0は予約されています。
The ROID is carried within application-specific TLVs.
ROIDは、アプリケーション固有のTLV内で伝送されます。
The "RG Connect" message is used to establish the ICCP RG connection in addition to individual Application Connections between PEs in an RG. An "RG Connect" message with no "Application Connect TLV" signals establishment of the ICCP RG connection, whereas an "RG Connect" message with a valid "Application Connect TLV" signals the establishment of an Application Connection in addition to the ICCP RG connection if the latter is not already established.
「RG Connect」メッセージは、RG内のPE間の個々のアプリケーション接続に加えて、ICCP RG接続を確立するために使用されます。 「アプリケーション接続TLV」のない「RG接続」メッセージはICCP RG接続の確立を通知し、有効な「アプリケーション接続TLV」の「RG接続」メッセージはICCP RG接続に加えてアプリケーション接続の確立を通知します後者がまだ確立されていない場合。
An implementation MAY send a dedicated "RG Connect" message to set up the ICCP RG connection and a separate "RG Connect" message for each client application. However, all implementations MUST support the receipt of an "RG Connect" message that triggers the setup of the ICCP RG connection as well as a single Application Connection simultaneously.
実装は、専用の「RG Connect」メッセージを送信してICCP RG接続をセットアップし、クライアントアプリケーションごとに個別の「RG Connect」メッセージを送信する場合があります。ただし、すべての実装は、ICCP RG接続と単一のアプリケーション接続のセットアップを同時にトリガーする「RG接続」メッセージの受信をサポートする必要があります。
A PE sends an "RG Connect" message to declare its membership in a Redundancy Group. One such message should be sent to each PE that is a member of the same RG. The set of PEs to which "RG Connect" messages should be transmitted is known via configuration or an auto-discovery mechanism that is outside the scope of this specification. If a device is a member of multiple RGs, it MUST send separate "RG Connect" messages for each RG even if the receiving device(s) happens to be the same.
PEは「RG Connect」メッセージを送信して、冗長グループへのメンバーシップを宣言します。そのようなメッセージの1つは、同じRGのメンバーである各PEに送信する必要があります。 「RG Connect」メッセージの送信先となるPEのセットは、この仕様の範囲外である構成または自動検出メカニズムによって認識されます。デバイスが複数のRGのメンバーである場合、受信デバイスがたまたま同じであっても、RGごとに個別の「RG Connect」メッセージを送信する必要があります。
The format of the "RG Connect" message is as follows:
「RG Connect」メッセージの形式は次のとおりです。
i. ICC Header with Message type = "RG Connect Message" (0x0700)
i. メッセージタイプ=「RG接続メッセージ」のICCヘッダー（0x0700）
ii. ICC Sender Name TLV
ii。 ICC送信者名TLV
iii. Zero or one "Application Connect TLV"
iii。ゼロまたは1つの「Application Connect TLV」
The currently defined "Application Connect TLVs" are as follows:
現在定義されている「Application Connect TLV」は次のとおりです。
- PW-RED Connect TLV (Section 7.1.1)
- PW-RED Connect TLV（セクション7.1.1）
- mLACP Connect TLV (Section 7.2.1)
- mLACP Connect TLV（セクション7.2.1）
The details of these TLVs are discussed in Section 7.
これらのTLVの詳細については、セクション7で説明します。
The "RG Connect" message can contain zero or one "Application Connect TLV".
「RG Connect」メッセージには、ゼロまたは1つの「Application Connect TLV」を含めることができます。
The "ICC Sender Name TLV" carries the hostname of the sender, encoded in UTF-8 [RFC3629] format. This is used primarily for the purpose of management of the RG and easing network operations. The specific format is shown below:
「ICC Sender Name TLV」には、UTF-8 [RFC3629]形式でエンコードされた送信者のホスト名が含まれています。これは主に、RGの管理とネットワーク操作の緩和を目的として使用されます。特定の形式を以下に示します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type = 0x0001 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Name |
+ +-+-+-+-+-+-+-+-+-+
~ ~
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- U=F=0
- U = F = 0
- Type
- タイプ
Set to 0x0001 (from the ICC parameter name space).
（ICCパラメーター名前空間から）0x0001に設定します。
- Length
- 長さ
Length of the TLV in octets, excluding the "U-bit", "F-bit", "Type", and "Length" fields.
「Uビット」、「Fビット」、「タイプ」、および「長さ」フィールドを除く、オクテット単位のTLVの長さ。
- Sender Name
- 送信者名
An administratively assigned name of the sending device, encoded in UTF-8 format and limited to a maximum of 80 octets. This field does not include a terminating null character.
管理上割り当てられた送信デバイスの名前。UTF-8形式でエンコードされ、最大80オクテットに制限されています。このフィールドには、終端のnull文字は含まれません。
The "RG Disconnect" message serves a dual purpose: to signal that a particular Application Connection is being closed within an RG or that the ICCP RG connection itself is being disconnected because the PE wishes to leave the RG. The format of this message is as follows:
「RG Disconnect」メッセージは、特定のアプリケーション接続がRG内で閉じられていること、またはPEがRGからの離脱を望むためにICCP RG接続自体が切断されていることを通知するという2つの目的を果たします。このメッセージの形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U| Message Type = 0x0701 | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x0005 (ICC RG ID) | Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ICC RG ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Disconnect Code TLV |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Application Disconnect TLV |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameter TLVs |
+ +
| |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- U-bit
- Uビット
U=0
う＝０
- Message Type
- メッセージタイプ
The message type for the "RG Disconnect" message is set to 0x0701.
「RG Disconnect」メッセージのメッセージタイプは0x0701に設定されています。
- Length
- 長さ
Length of the TLV in octets, excluding the "U-bit", "Message Type", and "Message Length" fields.
オクテット単位のTLVの長さ。「Uビット」、「メッセージタイプ」、および「メッセージ長」フィールドは除きます。
- Message ID
- メッセージID
Defined in Section 6.1.1 above.
上記のセクション6.1.1で定義されています。
- ICC RG ID
- ICC RG ID
Defined in Section 6.1.1 above.
上記のセクション6.1.1で定義されています。
- Disconnect Code TLV
- 切断コードTLV
The format of this TLV is as follows:
このTLVの形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ICCP Status Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- U-bit and F-bit
- UビットとFビット
Both are set to 0.
どちらも0に設定されています。
- Type
- タイプ
Set to "Disconnect Code TLV" (0x0004).
「Disconnect Code TLV」（0x0004）に設定します。
- Length
- 長さ
Length of the TLV in octets, excluding the "U-bit", "F-bit", "Type", and "Length" fields.
「Uビット」、「Fビット」、「タイプ」、および「長さ」フィールドを除く、オクテット単位のTLVの長さ。
- ICCP Status Code
- ICCPステータスコード
A status code that reflects the reason for the disconnect message. Allowed values are "ICCP RG Removed" and "ICCP Application Removed from RG".
切断メッセージの理由を反映するステータスコード。許可される値は、「ICCP RG Removed」および「ICCP Application Removed from RG」です。
- Optional Application Disconnect TLV
- オプションのアプリケーション切断TLV
Zero or one "Application Disconnect TLV" (defined in Sections 7.1.2 and 7.2.2). If the "RG Disconnect" message has a status code of "RG Removed", then it MUST NOT contain any "Application Disconnect TLVs", as the sending PE is signaling that it has left the RG and thus is disconnecting the ICCP RG connection with all associated client Application Connections. If the message has a status code of "Application Removed from RG", then it MUST contain exactly one "Application Disconnect TLV", as the sending PE is only tearing down the connection for the specified application. Other applications, and the ICCP RG connection, are not to be affected.
ゼロまたは1つの「アプリケーション切断TLV」（セクション7.1.2および7.2.2で定義）。 「RG Disconnect」メッセージのステータスコードが「RG Removed」である場合、送信PEがRGを離れたことを通知し、したがってICCP RG接続を切断しているため、「Application Disconnect TLVs」を含めないでください。関連するすべてのクライアントアプリケーション接続。メッセージのステータスコードが「RGから削除されたアプリケーション」である場合、送信側PEは指定されたアプリケーションの接続のみを切断するため、「アプリケーション切断TLV」を1つだけ含める必要があります。他のアプリケーション、およびICCP RG接続は影響を受けません。
- Optional Parameter TLVs
- オプションパラメータTLV
None are defined for this message in this document. This is specified to allow for future extensions.
このドキュメントでは、このメッセージには何も定義されていません。これは、将来の拡張を考慮して指定されています。
A PE sends an "RG Notification" message to indicate one of the following: to reject an ICCP connection, to reject an Application Connection, to reject an entire message, or to reject one or more TLVs within a message. The Notification message MUST only be sent to a PE that is already part of an RG.
PEは「RG通知」メッセージを送信して、ICCP接続を拒否する、アプリケーション接続を拒否する、メッセージ全体を拒否する、またはメッセージ内の1つ以上のTLVを拒否します。通知メッセージは、すでにRGの一部であるPEにのみ送信する必要があります。
The "RG Notification" message MUST only be used to reject messages or TLVs corresponding to a single ICCP application. In other words, there is a limit of at most a single ICCP application per "RG Notification" message.
「RG通知」メッセージは、単一のICCPアプリケーションに対応するメッセージまたはTLVを拒否するためにのみ使用する必要があります。つまり、「RG通知」メッセージごとに最大で1つのICCPアプリケーションという制限があります。
The format of the "RG Notification" message is as follows:
「RG通知」メッセージの形式は次のとおりです。
i. ICC Header with Message type = "RG Notification Message" (0x0702)
i. メッセージタイプ=「RG通知メッセージ」のICCヘッダー（0x0702）
ii. Notification Message TLVs
ii。通知メッセージTLV
The currently defined Notification message TLVs are as follows:
現在定義されている通知メッセージのTLVは次のとおりです。
i. ICC Sender Name TLV
i. ICC送信者名TLV
ii. Negative Acknowledgement (NAK) TLV
いい。 ねがちゔぇ あｃｋのｗぇｄげめんｔ （なＫ） ＴＬＶ
The "ICC Sender Name TLV" uses the same format as the format used in the "RG Connect" message and was described above.
「ICC Sender Name TLV」は、「RG Connect」メッセージで使用されているフォーマットと同じフォーマットを使用し、上記で説明されています。
The "NAK TLV" is defined as follows:
「NAK TLV」は次のように定義されています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type = 0x0002 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ICCP Status Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rejected Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional TLV(s) |
+ +
| |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- U-bit and F-bit
- UビットとFビット
Both are set to 0.
どちらも0に設定されています。
- Type
- タイプ
Set to "NAK TLV" (0x0002).
「NAK TLV」（0x0002）に設定します。
- Length
- 長さ
Length of the TLV in octets, excluding the "U-bit", "F-bit", "Type", and "Length" fields.
「Uビット」、「Fビット」、「タイプ」、および「長さ」フィールドを除く、オクテット単位のTLVの長さ。
- ICCP Status Code
- ICCPステータスコード
A status code that reflects the reason for the "NAK TLV". Allowed values are as follows:
「NAK TLV」の理由を反映するステータスコード。使用できる値は次のとおりです。
i. Unknown ICCP RG (0x00010001)
i. 不明なICCP RG（0x00010001）
This code is used to reject a new incoming ICCP connection for an RG that is not configured on the local PE. When this code is used, the "Rejected Message ID" field MUST contain the message ID of the rejected "RG Connect" message.
このコードは、ローカルPEで構成されていないRGの新しい着信ICCP接続を拒否するために使用されます。このコードを使用する場合、「Rejected Message ID」フィールドには、拒否された「RG Connect」メッセージのメッセージIDが含まれている必要があります。
ii. ICCP Connection Count Exceeded (0x00010002)
ii。 ICCP接続数超過（0x00010002）
This is used to reject a new incoming ICCP connection that would cause the local PE's ICCP connection count to exceed its capabilities. When this code is used, the "Rejected Message ID" field MUST contain the message ID of the rejected "RG Connect" message.
これは、ローカルPEのICCP接続数が機能を超える原因となる新しい着信ICCP接続を拒否するために使用されます。このコードを使用する場合、「Rejected Message ID」フィールドには、拒否された「RG Connect」メッセージのメッセージIDが含まれている必要があります。
iii. ICCP Application Connection Count Exceeded (0x00010003)
iii。 ICCPアプリケーション接続数の超過（0x00010003）
This is used to reject a new incoming Application Connection that would cause the local PE's ICCP connection count to exceed its capabilities. When this code is used, the "Rejected Message ID" field MUST contain the message ID of the rejected "RG Connect" message and the corresponding "Application Connect TLV" MUST be included in the "Optional TLV".
これは、ローカルPEのICCP接続数が機能を超える原因となる新しい着信アプリケーション接続を拒否するために使用されます。このコードを使用する場合、「Rejected Message ID」フィールドには拒否された「RG Connect」メッセージのメッセージIDが含まれている必要があり、対応する「Application Connect TLV」は「Optional TLV」に含まれている必要があります。
iv. ICCP Application not in RG (0x00010004)
iv。 RGにないICCPアプリケーション（0x00010004）
This is used to reject a new incoming Application Connection when the local PE doesn't support the application or the application is not configured in the RG. When this code is used, the "Rejected Message ID" field MUST contain the message ID of the rejected "RG Connect" message and the corresponding "Application Connect TLV" MUST be included in the "Optional TLV".
これは、ローカルPEがアプリケーションをサポートしていない場合、またはアプリケーションがRGで構成されていない場合に、新しい着信アプリケーション接続を拒否するために使用されます。このコードを使用する場合、「Rejected Message ID」フィールドには拒否された「RG Connect」メッセージのメッセージIDが含まれている必要があり、対応する「Application Connect TLV」は「Optional TLV」に含まれている必要があります。
v. Incompatible ICCP Protocol Version (0x00010005)
v. 互換性のないICCPプロトコルバージョン（0x00010005）
This is used to reject a new incoming Application Connection when the local PE has an incompatible version of the application. When this code is used, the "Rejected Message ID" field MUST contain the message ID of the rejected "RG Connect" message and the corresponding "Application Connect TLV" MUST be included in the "Optional TLV".
これは、ローカルPEに互換性のないバージョンのアプリケーションがある場合に、新しい着信アプリケーション接続を拒否するために使用されます。このコードを使用する場合、「Rejected Message ID」フィールドには拒否された「RG Connect」メッセージのメッセージIDが含まれている必要があり、対応する「Application Connect TLV」は「Optional TLV」に含まれている必要があります。
vi. ICCP Rejected Message (0x00010006)
vi。 ICCP拒否メッセージ（0x00010006）
This is used to reject an "RG Application Data" message, or one or more TLVs within the message. When this code is used, the "Rejected Message ID" field MUST contain the message ID of the rejected "RG Application Data" message.
これは、「RG Application Data」メッセージ、またはメッセージ内の1つ以上のTLVを拒否するために使用されます。このコードを使用する場合、「Rejected Message ID」フィールドには、拒否された「RG Application Data」メッセージのメッセージIDが含まれている必要があります。
vii. ICCP Administratively Disabled (0x00010007)
vii。 ICCP管理上無効（0x00010007）
This is used to reject any ICCP messages from a peer from which the PE is not allowed to exchange ICCP messages due to local administrative policy.
これは、ローカル管理ポリシーのためにPEがICCPメッセージの交換を許可されていないピアからのICCPメッセージを拒否するために使用されます。
- Rejected Message ID
- 拒否されたメッセージID
If non-zero, a 4-octet value that identifies the peer message to which the "NAK TLV" refers. If zero, no specific peer message is being identified.
ゼロ以外の場合、「NAK TLV」が参照するピアメッセージを識別する4オクテットの値。ゼロの場合、特定のピアメッセージは識別されていません。
- Optional TLV(s)
- オプションのTLV
A set of one or more optional TLVs. If the status code is "Rejected Message", then this field contains the TLV or TLVs that were rejected. If the entire message is rejected, all of its TLVs MUST be present in this field; otherwise, the subset of TLVs that were rejected MUST be echoed in this field.
1つ以上のオプションのTLVのセット。ステータスコードが「拒否されたメッセージ」の場合、このフィールドには、拒否されたTLVが含まれます。メッセージ全体が拒否される場合、そのすべてのTLVがこのフィールドに存在する必要があります。それ以外の場合は、拒否されたTLVのサブセットをこのフィールドにエコーする必要があります。
If the status code is "Incompatible Protocol Version", then this field contains the original "Application Connect TLV" sent by the peer, in addition to the "Requested Protocol Version TLV" defined below:
ステータスコードが「互換性のないプロトコルバージョン」の場合、このフィールドには、以下で定義されている「要求されたプロトコルバージョンTLV」に加えて、ピアから送信された元の「アプリケーション接続TLV」が含まれます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type = 0x0003 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Connection Reference | Requested Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- U-bit and F-bit
- UビットとFビット
Both are set to 0.
どちらも0に設定されています。
- Type
- タイプ
Set to 0x0003 for "Requested Protocol Version TLV".
「Requested Protocol Version TLV」の場合は0x0003に設定します。
- Length
- 長さ
Length of the TLV in octets, excluding the "U-bit", "F-bit", "Type", and "Length" fields.
「Uビット」、「Fビット」、「タイプ」、および「長さ」フィールドを除く、オクテット単位のTLVの長さ。
- Connection Reference
- 接続リファレンス
Set to the "Type" field of the "Application Connect TLV" that was rejected because of incompatible version.
互換性のないバージョンのために拒否された「Application Connect TLV」の「Type」フィールドに設定します。
- Requested Version
- 要求されたバージョン
The version of the application supported by the transmitting device. For this version of the protocol, it is set to 0x0001.
送信デバイスがサポートするアプリケーションのバージョン。このバージョンのプロトコルでは、0x0001に設定されています。
The "RG Application Data" message is used to transport application data between PEs within an RG. A single message can be used to carry data from only one application. Multiple Application TLVs are allowed in a single message, as long as all of these TLVs belong to the same application. The format of the "Application Data" message is as follows:
「RG Application Data」メッセージは、RG内のPE間でアプリケーションデータを転送するために使用されます。単一のメッセージを使用して、1つのアプリケーションからのみデータを伝送できます。これらすべてのTLVが同じアプリケーションに属している限り、複数のアプリケーションTLVを1つのメッセージで許可できます。 「Application Data」メッセージのフォーマットは次のとおりです。
i. ICC Header with Message type = "RG Application Data Message" (0x0703)
i. メッセージタイプ=「RGアプリケーションデータメッセージ」のICCヘッダー（0x0703）
ii. Application-specific TLVs
ii。アプリケーション固有のTLV
The details of these TLVs are discussed in Section 7. All application-specific TLVs in one "RG Application Data" message MUST belong to a single application but MAY reference different ROs.
これらのTLVの詳細については、セクション7で説明します。1つの「RG Application Data」メッセージ内のすべてのアプリケーション固有のTLVは、単一のアプリケーションに属している必要がありますが、異なるROを参照する必要があります。
This section discusses the "ICCP TLVs" for the Pseudowire Redundancy application.
このセクションでは、疑似配線冗長アプリケーションの「ICCP TLV」について説明します。
This TLV is included in the "RG Connect" message to signal the establishment of a PW-RED Application Connection.
このTLVは「RG接続」メッセージに含まれており、PW-REDアプリケーション接続の確立を通知します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type = 0x0010 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol Version |A| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Sub-TLVs |
~ ~
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- U-bit and F-bit
- UビットとFビット
Both are set to 0.
どちらも0に設定されています。
- Type
- タイプ
Set to 0x0010 for "PW-RED Connect TLV".
「PW-RED Connect TLV」の場合は0x0010に設定します。
- Length
- 長さ
Length of the TLV in octets, excluding the "U-bit", "F-bit", "Type", and "Length" fields.
「Uビット」、「Fビット」、「タイプ」、および「長さ」フィールドを除く、オクテット単位のTLVの長さ。
- Protocol Version
- プロトコルバージョン
The version of this particular protocol for the purposes of ICCP. This is set to 0x0001.
ICCPのためのこの特定のプロトコルのバージョン。これは0x0001に設定されています。
- A-bit
- Aビット
Acknowledgement bit. Set to 1 if the sender has received a "PW-RED Connect TLV" from the recipient. Otherwise, set to 0.
確認ビット。送信者が受信者から「PW-RED Connect TLV」を受信した場合、1に設定されます。それ以外の場合は0に設定します。
- Reserved
- 予約済み
Reserved for future use.
将来の使用のために予約されています。
- Optional Sub-TLVs
- オプションのサブTLV
There are no optional sub-TLVs defined for this version of the protocol. This document does not impose any restrictions on the length of the sub-TLVs.
このバージョンのプロトコルには、オプションのサブTLVが定義されていません。このドキュメントでは、サブTLVの長さに制限はありません。
This TLV is used in an "RG Disconnect" message to indicate that the connection for the PW-RED application is to be terminated.
このTLVは「RG Disconnect」メッセージで使用され、PW-REDアプリケーションの接続が終了されることを示します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type = 0x0011 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Sub-TLVs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- U-bit and F-bit
- UビットとFビット
Both are set to 0.
どちらも0に設定されています。
- Type
- タイプ
Set to 0x0011 for "PW-RED Disconnect TLV".
「PW-RED Disconnect TLV」の場合は0x0011に設定します。
- Length
- 長さ
Length of the TLV in octets, excluding the "U-bit", "F-bit", "Type", and "Length" fields.
「Uビット」、「Fビット」、「タイプ」、および「長さ」フィールドを除く、オクテット単位のTLVの長さ。
- Optional Sub-TLVs
- オプションのサブTLV
The only optional sub-TLV defined for this version of the protocol is the "PW-RED Disconnect Cause TLV" defined in Section 7.1.2.1.
このバージョンのプロトコルに定義されている唯一のオプションのサブTLVは、7.1.2.1項で定義されている「PW-RED切断原因TLV」です。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type = 0x0019 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Disconnect Cause String |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- U-bit and F-bit
- UビットとFビット
Both are set to 0.
どちらも0に設定されています。
- Type
- タイプ
Set to 0x0019 for "PW-RED Disconnect Cause TLV".
「PW-RED Disconnect Cause TLV」の場合は0x0019に設定します。
- Length
- 長さ
Length of the TLV in octets, excluding the "U-bit", "F-bit", "Type", and "Length" fields.
「Uビット」、「Fビット」、「タイプ」、および「長さ」フィールドを除く、オクテット単位のTLVの長さ。
- Disconnect Cause String
- 切断原因文字列
Variable-length string specifying the reason for the disconnect, encoded in UTF-8 format. The string does not include a terminating null character. Used for network management.
切断の理由を指定する可変長文字列。UTF-8形式でエンコードされています。文字列には、終端のnull文字は含まれません。ネットワーク管理に使用されます。
The "PW-RED Config TLV" is used in the "RG Application Data" message and has the following format:
「PW-RED Config TLV」は「RG Application Data」メッセージで使用され、次の形式になります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type = 0x0012 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ROID |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW Priority | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Name TLV |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW ID TLV or Generalized PW ID TLV |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- U-bit and F-bit
- UビットとFビット
Both are set to 0.
どちらも0に設定されています。
- Type
- タイプ
Set to 0x0012 for "PW-RED Config TLV".
「PW-RED Config TLV」の場合は0x0012に設定します。
- Length
- 長さ
Length of the TLV in octets, excluding the "U-bit", "F-bit", "Type", and "Length" fields.
「Uビット」、「Fビット」、「タイプ」、および「長さ」フィールドを除く、オクテット単位のTLVの長さ。
- ROID
- ROID
As defined in Section 6.1.3.
セクション6.1.3で定義されています。
- PW Priority
- ΠΩΠριორიτη
2 octets. Pseudowire Priority. Used to indicate which PW has better priority to go into active state. Numerically lower numbers are better priority. In case of a tie, the PE with the numerically lower identifier (i.e., IP Address) has better priority.
2オクテット。疑似配線優先度。どのPWがアクティブ状態になるための優先度が高いかを示すために使用されます。数値が小さいほど優先順位が高くなります。同順位の場合、数値が小さい識別子（つまり、IPアドレス）を持つPEが優先されます。
- Flags
- 旗
Valid values are as follows:
有効な値は次のとおりです。
i. Synchronized (0x01)
i. 同期済み（0x01）
Indicates that the sender has concluded transmitting all pseudowire configuration for a given service.
送信者が特定のサービスのすべての疑似配線設定の送信を完了したことを示します。
ii. Purge Configuration (0x02)
ii。パージ構成（0x02）
Indicates that the pseudowire is no longer configured for PW-RED operation.
疑似配線がPW-RED操作用に構成されなくなったことを示します。
iii. Independent Mode (0x04)
iii。独立モード（0x04）
Indicates that the pseudowire is configured for redundancy using the Independent Mode of operation, per Section 5.1 of [RFC6870].
[RFC6870]のセクション5.1に従って、疑似配線が独立動作モードを使用して冗長性を構成されていることを示します。
iv. Independent Mode with Request Switchover (0x08)
iv。リクエストの切り替えを伴う独立モード（0x08）
Indicates that the pseudowire is configured for redundancy using the Independent Mode of operation with the use of the "Request Switchover" bit, per Section 6.3 of [RFC6870].
[RFC6870]のセクション6.3に従って、「Request Switchover」ビットを使用して、独立動作モードを使用する疑似配線が冗長構成になっていることを示します。
v. Master Mode (0x10)
v. マスターモード（0x10）
Indicates that the pseudowire is configured for redundancy using the Master/Slave Mode of operation, with the advertising PE acting as Master, per Section 5.2 of [RFC6870].
[RFC6870]のセクション5.2に従って、疑似配線がマスター/スレーブモードの動作を使用して冗長構成になり、アドバタイジングPEがマスターとして機能することを示します。
vi. Slave Mode (0x20)
我々。スレーブモード（0x20）
Indicates that the pseudowire is configured for redundancy using the Master/Slave Mode of operation, with the advertising PE acting as Slave, per Section 5.2 of [RFC6870].
[RFC6870]のセクション5.2に従い、マスター/スレーブモードの動作を使用して、疑似配線が冗長構成になっており、アドバタイジングPEがスレーブとして機能していることを示します。
- Sub-TLVs
- サブTLV
The "PW-RED Config TLV" includes the following two sub-TLVs:
「PW-RED Config TLV」には、次の2つのサブTLVが含まれています。
i. Service Name TLV
i. サービス名TLV
ii. One of the following: PW ID TLV or Generalized PW ID TLV
ii。次のいずれか：PW ID TLVまたはGeneralized PW ID TLV
The format of the sub-TLVs is defined in Sections 7.1.3.1 through 7.1.3.3.
サブTLVのフォーマットは、セクション7.1.3.1から7.1.3.3で定義されています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type = 0x0013 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Name |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- U-bit and F-bit
- UビットとFビット
Both are set to 0.
どちらも0に設定されています。
- Type
- タイプ
Set to 0x0013 for "Service Name TLV".
「サービス名TLV」の場合は0x0013に設定します。
- Length
- 長さ
Length of the TLV in octets, excluding the "U-bit", "F-bit", "Type", and "Length" fields.
「Uビット」、「Fビット」、「タイプ」、および「長さ」フィールドを除く、オクテット単位のTLVの長さ。
- Service Name
- サービス名
The name of the L2VPN service instance, encoded in UTF-8 format and up to 80 octets in length. The string does not include a terminating null character.
L2VPNサービスインスタンスの名前。UTF-8形式でエンコードされ、長さが最大80オクテットです。文字列には、終端のnull文字は含まれません。
This TLV is used to communicate the configuration of PWs for VPWS.
このTLVは、VPWSのPWの構成を通信するために使用されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type = 0x0014 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- U-bit and F-bit
- UビットとFビット
Both are set to 0.
どちらも0に設定されています。
- Type
- タイプ
Set to 0x0014 for "PW ID TLV".
「PW ID TLV」の場合は0x0014に設定します。
- Length
- 長さ
Length of the TLV in octets, excluding the "U-bit", "F-bit", "Type", and "Length" fields.
「Uビット」、「Fビット」、「タイプ」、および「長さ」フィールドを除く、オクテット単位のTLVの長さ。
- Peer ID
- ピアID
4-octet LDP Router ID of the peer at the far end of the PW.
PWの遠端にあるピアの4オクテットLDPルータID。
- Group ID
- グループID
Same as Group ID in [RFC4447], Section 5.2.
[RFC4447]のセクション5.2のグループIDと同じです。
- PW ID
- PW ID
Same as PW ID in [RFC4447], Section 5.2.
[RFC4447]のセクション5.2のPW IDと同じです。
This TLV is used to communicate the configuration of PWs for VPLS.
このTLVは、VPLSのPWの構成を通信するために使用されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type = 0x0015 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AGI Type | Length | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ AGI Value (continued) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AII Type | Length | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ SAII Value (continued) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AII Type | Length | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TAII Value (continued) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- U-bit and F-bit
- UビットとFビット
Both are set to 0.
どちらも0に設定されています。
- Type
- タイプ
Set to 0x0015 for "Generalized PW ID TLV".
「一般化されたPW ID TLV」の場合は0x0015に設定します。
- Length
- 長さ
Length of the TLV in octets, excluding the "U-bit", "F-bit", "Type", and "Length" fields.
「Uビット」、「Fビット」、「タイプ」、および「長さ」フィールドを除く、オクテット単位のTLVの長さ。
- AGI, AII, SAII, and TAII
- あぎ、 あいい、 さいい、 あんｄ たいい
Defined in [RFC4447], Section 5.3.2.
[RFC4447]、セクション5.3.2で定義されています。
The "PW-RED State TLV" is used in the "RG Application Data" message. This TLV is used by a device to report its PW status to other members in the RG.
「RG Application Data」メッセージでは「PW-RED State TLV」が使用されます。このTLVは、デバイスのPWステータスをRGの他のメンバーに報告するために使用されます。
The format of this TLV is as follows:
このTLVの形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type = 0x0016 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ROID |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local PW State |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote PW State |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- U-bit and F-bit
- UビットとFビット
Both are set to 0.
どちらも0に設定されています。
- Type
- タイプ
Set to 0x0016 for "PW-RED State TLV".
「PW-RED State TLV」の場合は0x0016に設定します。
- Length
- 長さ
Length of the TLV in octets, excluding the "U-bit", "F-bit", "Type", and "Length" fields.
「Uビット」、「Fビット」、「タイプ」、および「長さ」フィールドを除く、オクテット単位のTLVの長さ。
- ROID
- ROID
As defined in Section 6.1.3.
セクション6.1.3で定義されています。
- Local PW State
- ローカルPW状態
The status of the PW as determined by the sending PE, encoded in the same format as the "Status Code" field of the "PW Status TLV" defined in [RFC4447] and extended in [RFC6870].
The status of the PW as determined by the sending PE, encoded in the same format as the "Status Code" field of the "PW Status TLV" defined in [RFC4447] and extended in [RFC6870].
- Remote PW State
- リモートPW状態
The status of the PW as determined by the remote peer of the sending PE. Encoded in the same format as the "Status Code" field of the "PW Status TLV" defined in [RFC4447] and extended in [RFC6870].
送信側PEのリモートピアによって決定されるPWのステータス。 [RFC4447]で定義され、[RFC6870]で拡張された「PWステータスTLV」の「ステータスコード」フィールドと同じフォーマットでエンコードされています。
The "PW-RED Synchronization Request TLV" is used in the "RG Application Data" message. This TLV is used by a device to request that its peer retransmit configuration or operational state. The following information can be requested:
「PW-RED Synchronization Request TLV」は「RG Application Data」メッセージで使用されます。このTLVは、ピアが構成または動作状態を再送信することを要求するためにデバイスによって使用されます。以下の情報を要求できます。
- configuration and/or state for one or more pseudowires
- 1つまたは複数の疑似配線の設定および/または状態
- configuration and/or state for all pseudowires
- すべての疑似配線の構成および/または状態
- configuration and/or state for all pseudowires in a given service
- 特定のサービス内のすべての疑似配線の構成または状態、あるいはその両方
The format of the TLV is as follows:
TLVの形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type = 0x0017 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request Number |C|S| Request Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Sub-TLVs |
~ ~
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- U-bit and F-bit
- UビットとFビット
Both are set to 0.
どちらも0に設定されています。
- Type
- タイプ
Set to 0x0017 for "PW-RED Synchronization Request TLV".
「PW-RED Synchronization Request TLV」の場合は0x0017に設定します。
- Length
- 長さ
Length of the TLV in octets, excluding the "U-bit", "F-bit", "Type", and "Length" fields.
「Uビット」、「Fビット」、「タイプ」、および「長さ」フィールドを除く、オクテット単位のTLVの長さ。
- Request Number
- 要求番号
2 octets. Unsigned integer uniquely identifying the request. Used to match the request with a response. The value of 0 is reserved for unsolicited synchronization and MUST NOT be used in the "PW-RED Synchronization Request TLV". Given the use of TCP, there are no issues associated with the wrap-around of the Request Number.
2オクテット。リクエストを一意に識別する符号なし整数。リクエストとレスポンスを照合するために使用されます。値0は非送信請求同期用に予約されており、「PW-RED同期要求TLV」で使用してはなりません（MUST NOT）。 TCPを使用する場合、要求番号のラップアラウンドに関連する問題はありません。
- C-bit
- Cビット
Set to 1 if the request is for configuration data. Otherwise, set to 0.
要求が構成データに対するものである場合は、1に設定します。それ以外の場合は0に設定します。
- S-bit
- Sビット
Set to 1 if the request is for running state data. Otherwise, set to 0.
要求が実行状態データ用である場合は、1に設定します。それ以外の場合は0に設定します。
- Request Type
- リクエストの種類
14 bits specifying the request type, encoded as follows:
次のようにエンコードされた、要求タイプを指定する14ビット：
0x00 Request Data for specified pseudowire(s) 0x01 Request Data for all pseudowires in specified service(s) 0x3FFF Request All Data
0x00指定された疑似配線のデータを要求します0x01指定されたサービスのすべての疑似配線のデータを要求します0x3FFFすべてのデータを要求します
- Optional Sub-TLVs
- Optional Sub-TLVs
A set of zero or more TLVs, as follows:
次のゼロ以上のTLVのセット。
If the "Request Type" field is set to 0x00, then this field contains one or more "PW ID TLVs" or "Generalized PW ID TLVs". If the "Request Type" field is set to 0x01, then this field contains one or more "Service Name TLVs". If the "Request Type" field is set to 0x3FFF, then this field MUST be empty. This document does not impose any restrictions on the length of the sub-TLVs.
[Request Type]フィールドが0x00に設定されている場合、このフィールドには1つ以上の「PW ID TLV」または「Generalized PW ID TLV」が含まれています。 「リクエストタイプ」フィールドが0x01に設定されている場合、このフィールドには1つ以上の「サービス名TLV」が含まれます。 「リクエストタイプ」フィールドが0x3FFFに設定されている場合、このフィールドは空である必要があります。このドキュメントでは、サブTLVの長さに制限はありません。
The "PW-RED Synchronization Data TLV" is used in the "RG Application Data" message. A pair of these TLVs is used by a device to delimit a set of TLVs that are sent in response to a "PW-RED Synchronization Request TLV". The delimiting TLVs signal the start and end of the synchronization data and associate the response with its corresponding request via the "Request Number" field.
「PW-RED Synchronization Data TLV」は「RG Application Data」メッセージで使用されます。デバイスはこれらのTLVのペアを使用して、「PW-RED同期要求TLV」に応答して送信されるTLVのセットを区切ります。区切りのTLVは、同期データの開始と終了を通知し、「要求番号」フィールドを介して応答を対応する要求に関連付けます。
The "PW-RED Synchronization Data TLVs" are also used for unsolicited advertisements of complete PW-RED configuration and operational state data. In this case, the "Request Number" field MUST be set to 0.
「PW-RED Synchronization Data TLVs」は、完全なPW-RED構成および運用状態データの一方的な通知にも使用されます。この場合、「リクエスト番号」フィールドは0に設定する必要があります。
This TLV has the following format:
このTLVの形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type = 0x0018 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request Number | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- U-bit and F-bit
- UビットとFビット
Both are set to 0.
どちらも0に設定されています。
- Type
- タイプ
Set to 0x0018 for "PW-RED Synchronization Data TLV".
「PW-RED Synchronization Data TLV」の場合は0x0018に設定します。
- Length
- 長さ
Length of the TLV in octets, excluding the "U-bit", "F-bit", "Type", and "Length" fields.
「Uビット」、「Fビット」、「タイプ」、および「長さ」フィールドを除く、オクテット単位のTLVの長さ。
- Request Number
- Request Number
2 octets. Unsigned integer identifying the Request Number from the "PW-RED Synchronization Request TLV" that solicited this synchronization data response.
2オクテット。この同期データ応答を要求した「PW-RED Synchronization Request TLV」からの要求番号を識別する符号なし整数。
- Flags
- 旗
2 octets. Response flags encoded as follows:
2オクテット。次のようにエンコードされた応答フラグ：
0x00 Synchronization Data Start 0x01 Synchronization Data End
0x00同期データ開始0x01同期データ終了
This section discusses the "ICCP TLVs" for Ethernet attachment circuit redundancy using the multi-chassis LACP (mLACP) application.
このセクションでは、マルチシャーシLACP（mLACP）アプリケーションを使用したイーサネット接続回線の冗長性のための「ICCP TLV」について説明します。
This TLV is included in the "RG Connect" message to signal the establishment of an mLACP Application Connection.
このTLVは、「RG Connect」メッセージに含まれており、mLACPアプリケーション接続の確立を通知します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type = 0x0030 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol Version |A| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Sub-TLVs |
~ ~
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- U-bit and F-bit
- UビットとFビット
Both are set to 0.
Both are set to 0.
- Type
- Type
Set to 0x0030 for "mLACP Connect TLV".
「mLACP Connect TLV」の場合は0x0030に設定します。
- Length
- 長さ
Length of the TLV in octets, excluding the "U-bit", "F-bit", "Type", and "Length" fields.
Length of the TLV in octets, excluding the "U-bit", "F-bit", "Type", and "Length" fields.
- Protocol Version
- Protocol Version
The version of this particular protocol for the purposes of ICCP. This is set to 0x0001.
ICCPのためのこの特定のプロトコルのバージョン。これは0x0001に設定されています。
- A-bit
- Aビット
Acknowledgement bit. Set to 1 if the sender has received an "mLACP Connect TLV" from the recipient. Otherwise, set to 0.
Acknowledgement bit. Set to 1 if the sender has received an "mLACP Connect TLV" from the recipient. Otherwise, set to 0.
- Reserved
- 予約済み
Reserved for future use.
将来の使用のために予約されています。
- Optional Sub-TLVs
- Optional Sub-TLVs
There are no optional sub-TLVs defined for this version of the protocol.
このバージョンのプロトコルには、オプションのサブTLVが定義されていません。
This TLV is used in an "RG Disconnect" message to indicate that the connection for the mLACP application is to be terminated.
This TLV is used in an "RG Disconnect" message to indicate that the connection for the mLACP application is to be terminated.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type = 0x0031 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Sub-TLVs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- U-bit and F-bit
- U-bit and F-bit
Both are set to 0.
どちらも0に設定されています。
- Type
- タイプ
Set to 0x0031 for "mLACP Disconnect TLV".
「mLACP Disconnect TLV」の場合は0x0031に設定します。
- Length
- 長さ
Length of the TLV in octets, excluding the "U-bit", "F-bit", "Type", and "Length" fields.
「Uビット」、「Fビット」、「タイプ」、および「長さ」フィールドを除く、オクテット単位のTLVの長さ。
- Optional Sub-TLVs
- オプションのサブTLV
The only optional sub-TLV defined for this version of the protocol is the "mLACP Disconnect Cause TLV" defined in Section 7.2.2.1.
このバージョンのプロトコルに対して定義されている唯一のオプションのサブTLVは、セクション7.2.2.1で定義された「mLACP切断原因TLV」です。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type = 0x003A | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Disconnect Cause String |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- U-bit and F-bit
- UビットとFビット
Both are set to 0.
どちらも0に設定されています。
- Type
- Type
Set to 0x003A for "mLACP Disconnect Cause TLV".
Set to 0x003A for "mLACP Disconnect Cause TLV".
- Length
- 長さ
Length of the TLV in octets, excluding the "U-bit", "F-bit", "Type", and "Length" fields.
「Uビット」、「Fビット」、「タイプ」、および「長さ」フィールドを除く、オクテット単位のTLVの長さ。
- Disconnect Cause String
- 切断原因文字列
Variable-length string specifying the reason for the disconnect. Used for network management.
切断の理由を指定する可変長文字列。ネットワーク管理に使用されます。
The "mLACP System Config TLV" is sent in the "RG Application Data" message. This TLV announces the local node's LACP system parameters to the RG peers.
「mLACP System Config TLV」は「RG Application Data」メッセージで送信されます。このTLVは、ローカルノードのLACPシステムパラメータをRGピアに通知します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type = 0x0032 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| System ID |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | System Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Node ID |
+-+-+-+-+-+-+-+-+
- U-bit and F-bit
- UビットとFビット
Both are set to 0.
どちらも0に設定されています。
- Type
- Type
Set to 0x0032 for "mLACP System Config TLV".
「mLACP System Config TLV」の場合は0x0032に設定します。
- Length
- 長さ
Length of the TLV in octets, excluding the "U-bit", "F-bit", "Type", and "Length" fields.
「Uビット」、「Fビット」、「タイプ」、および「長さ」フィールドを除く、オクテット単位のTLVの長さ。
- System ID
- システムID
6-octet field encoding the System ID used by LACP, as specified in [IEEE-802.1AX], Section 5.3.2.
[IEEE-802.1AX]のセクション5.3.2で指定されている、LACPで使用されるシステムIDをエンコードする6オクテットのフィールド。
- System Priority
- システムの優先順位
2 octets encoding the LACP System Priority, as defined in [IEEE-802.1AX], Section 5.3.2.
[IEEE-802.1AX]のセクション5.3.2で定義されている、LACPシステムプライオリティをエンコードする2オクテット。
- Node ID
- ので いＤ
1 octet. LACP Node ID. Used to ensure that the LACP Port Numbers are unique across all devices in an RG. Valid values are in the range 0-7. Uniqueness of the LACP Port Numbers across RG members is ensured by encoding the Port Numbers as follows:
1オクテット。 LACPノードID。 LACPポート番号がRG内のすべてのデバイスで一意であることを確認するために使用されます。有効な値は0〜7の範囲です。 RGメンバー全体のLACPポート番号の一意性は、次のようにポート番号をエンコードすることによって保証されます。
- Most significant bit always set to 1
- 最上位ビットは常に1に設定されています
- The next 3 most significant bits set to Node ID
- The next 3 most significant bits set to Node ID
- Remaining 12 bits freely assigned by the system
- システムによって自由に割り当てられた残りの12ビット
The "mLACP Aggregator Config TLV" is sent in the "RG Application Data" message. This TLV is used to notify RG peers about the local configuration state of an Aggregator.
The "mLACP Aggregator Config TLV" is sent in the "RG Application Data" message. This TLV is used to notify RG peers about the local configuration state of an Aggregator.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type = 0x0036 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ROID |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Aggregator ID | MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Actor Key | Member Ports Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Agg Name Len | Aggregator Name |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
~ ~
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- U-bit and F-bit
- U-bit and F-bit
Both are set to 0.
どちらも0に設定されています。
- Type
- タイプ
Set to 0x0036 for "mLACP Aggregator Config TLV".
Set to 0x0036 for "mLACP Aggregator Config TLV".
- Length
- Length
Length of the TLV in octets, excluding the "U-bit", "F-bit", "Type", and "Length" fields.
「Uビット」、「Fビット」、「タイプ」、および「長さ」フィールドを除く、オクテット単位のTLVの長さ。
- ROID
- ROID
Defined in Section 6.1.3 above.
上記のセクション6.1.3で定義されています。
- Aggregator ID
- アグリゲーターID
2 octets. LACP Aggregator Identifier, as specified in [IEEE-802.1AX], Section 5.4.6.
2 octets. LACP Aggregator Identifier, as specified in [IEEE-802.1AX], Section 5.4.6.
- MAC Address
- Macアドレス
6 octets encoding the Aggregator Media Access Control (MAC) address.
Aggregator Media Access Control（MAC）アドレスをエンコードする6オクテット。
- Actor Key
- 俳優のキー
2 octets. LACP Actor Key for the corresponding Aggregator, as specified in [IEEE-802.1AX], Section 5.3.5.
2オクテット。 [IEEE-802.1AX]のセクション5.3.5で指定されている、対応するアグリゲーターのLACPアクターキー。
- Member Ports Priority
- メンバーポートの優先度
2 octets. LACP administrative port priority associated with all interfaces bound to the Aggregator. This field is valid only when the "Flags" field has "Priority Set" asserted.
2 octets. LACP administrative port priority associated with all interfaces bound to the Aggregator. This field is valid only when the "Flags" field has "Priority Set" asserted.
- Flags
- Flags
Valid values are as follows:
有効な値は次のとおりです。
i. Synchronized (0x01)
i. Synchronized (0x01)
Indicates that the sender has concluded transmitting all Aggregator configuration information.
送信者がすべてのアグリゲーター構成情報の送信を完了したことを示します。
ii. Purge Configuration (0x02)
ii. Purge Configuration (0x02)
Indicates that the Aggregator is no longer configured for mLACP operation.
AggregatorがmLACP操作用に構成されなくなったことを示します。
iii. Priority Set (0x04)
iii. Priority Set (0x04)
Indicates that the "Member Ports Priority" field is valid.
Indicates that the "Member Ports Priority" field is valid.
- Agg Name Len
- Agg Name Len
1 octet. Length of the "Aggregator Name" field in octets.
1オクテット。オクテット単位の「Aggregator Name」フィールドの長さ。
- Aggregator Name
- アグリゲーター名
Aggregator name, encoded in UTF-8 format, up to a maximum of 20 octets. Used for ease of management. The string does not include a terminating null character.
Aggregator name, encoded in UTF-8 format, up to a maximum of 20 octets. Used for ease of management. The string does not include a terminating null character.
The "mLACP Port Config TLV" is sent in the "RG Application Data" message. This TLV is used to notify RG peers about the local configuration state of a port.
The "mLACP Port Config TLV" is sent in the "RG Application Data" message. This TLV is used to notify RG peers about the local configuration state of a port.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type = 0x0033 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Number | MAC Address |
+-------------------------------+ +
| |
+---------------------------------------------------------------+
| Actor Key | Port Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Speed |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Port Name Len | Port Name |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
~ ~
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- U-bit and F-bit
- UビットとFビット
Both are set to 0.
どちらも0に設定されています。
- Type
- タイプ
Set to 0x0033 for "mLACP Port Config TLV".
Set to 0x0033 for "mLACP Port Config TLV".
- Length
- Length
Length of the TLV in octets, excluding the "U-bit", "F-bit", "Type", and "Length" fields.
「Uビット」、「Fビット」、「タイプ」、および「長さ」フィールドを除く、オクテット単位のTLVの長さ。
- Port Number
- Port Number
2 octets. LACP Port Number for the corresponding interface, as specified in [IEEE-802.1AX], Section 5.3.4. The Port Number MUST be encoded with the Node ID, as discussed above.
2オクテット。 [IEEE-802.1AX]、セクション5.3.4で指定されている、対応するインターフェイスのLACPポート番号。上記のように、ポート番号はノードIDでエンコードする必要があります。
- MAC Address
- Macアドレス
6 octets encoding the port MAC address.
ポートのMACアドレスをエンコードする6オクテット。
- Actor Key
- 俳優のキー
2 octets. LACP Actor Key for the corresponding interface, as specified in [IEEE-802.1AX], Section 5.3.5.
2オクテット。 [IEEE-802.1AX]のセクション5.3.5で指定されている、対応するインターフェースのLACPアクターキー。
- Port Priority
- ポートの優先順位
2 octets. LACP administrative port priority for the corresponding interface, as specified in [IEEE-802.1AX], Section 5.3.4. This field is valid only when the "Flags" field has "Priority Set" asserted.
2オクテット。 [IEEE-802.1AX]のセクション5.3.4で指定されている、対応するインターフェースのLACP管理ポートの優先度。このフィールドは、「フラグ」フィールドに「優先度セット」がアサートされている場合にのみ有効です。
- Port Speed
- ポート速度
4-octet integer encoding the port's current bandwidth in units of 1,000,000 bits per second. This field corresponds to the ifHighSpeed object of the IF-MIB [RFC2863].
1オクテット/秒の単位でポートの現在の帯域幅をエンコードする4オクテットの整数。このフィールドは、IF-MIB [RFC2863]のifHighSpeedオブジェクトに対応しています。
- Flags
- 旗
Valid values are as follows:
Valid values are as follows:
i. Synchronized (0x01)
i. 同期済み（0x01）
Indicates that the sender has concluded transmitting all member link port configurations for a given Aggregator.
送信者が、特定のアグリゲーターのすべてのメンバーリンクポート構成の送信を完了したことを示します。
ii. Purge Configuration (0x02)
ii。パージ構成（0x02）
Indicates that the port is no longer configured for mLACP operation.
ポートがmLACP操作用に構成されなくなったことを示します。
iii. Priority Set (0x04)
iii。優先度セット（0x04）
Indicates that the "Port Priority" field is valid.
Indicates that the "Port Priority" field is valid.
- Port Name Len
- ポート名Len
1 octet. Length of the "Port Name" field in octets.
1オクテット。オクテット単位の「ポート名」フィールドの長さ。
- Port Name
- Port Name
Corresponds to the ifName object of the IF-MIB [RFC2863]. Encoded in UTF-8 format and truncated to 20 octets. Port Name does not include a terminating null character.
Corresponds to the ifName object of the IF-MIB [RFC2863]. Encoded in UTF-8 format and truncated to 20 octets. Port Name does not include a terminating null character.
The "mLACP Port Priority TLV" is sent in the "RG Application Data" message. This TLV is used by a device to either advertise its operational Port Priority to other members in the RG or authoritatively request that a particular member of an RG change its port priority.
「mLACP Port Priority TLV」は「RG Application Data」メッセージで送信されます。デバイスはこのTLVを使用して、RG内の他のメンバーに動作中のポートプライオリティをアドバタイズするか、RGの特定のメンバーがポートプライオリティを変更するように正式に要求します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type = 0x0034 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OpCode | Port Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Aggregator ID | Last Port Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Current Port Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- U-bit and F-bit
- U-bit and F-bit
Both are set to 0.
どちらも0に設定されています。
- Type
- タイプ
Set to 0x0034 for "mLACP Port Priority TLV".
Set to 0x0034 for "mLACP Port Priority TLV".
- Length
- 長さ
Length of the TLV in octets, excluding the "U-bit", "F-bit", "Type", and "Length" fields.
「Uビット」、「Fビット」、「タイプ」、および「長さ」フィールドを除く、オクテット単位のTLVの長さ。
- OpCode
- OpCode
2 octets identifying the operational code point for the TLV, encoded as follows:
TLVの運用コードポイントを識別する2オクテット。次のようにエンコードされます。
0x00 Local Priority Change Notification 0x01 Remote Request for Priority Change
0x00ローカル優先度変更通知0x01リモート優先度変更要求
- Port Number
- ポート番号
2-octet field representing the LACP Port Number, as specified in [IEEE-802.1AX], Section 5.3.4. When the value of this field is 0, it denotes all ports bound to the Aggregator specified in the "Aggregator ID" field. When non-zero, the Port Number MUST be encoded with the Node ID, as discussed above.
[IEEE-802.1AX]、セクション5.3.4で指定されている、LACPポート番号を表す2オクテットフィールド。このフィールドの値が0の場合、「アグリゲーターID」フィールドで指定されたアグリゲーターにバインドされているすべてのポートを示します。ゼロ以外の場合、上記のように、ポート番号はノードIDでエンコードする必要があります。
- Aggregator ID
- アグリゲーターID
2 octets. LACP Aggregator Identifier, as specified in [IEEE-802.1AX], Section 5.4.6.
2 octets. LACP Aggregator Identifier, as specified in [IEEE-802.1AX], Section 5.4.6.
- Last Port Priority
- 最終ポート優先度
2 octets. LACP port priority for the corresponding interface, as specified in [IEEE-802.1AX], Section 5.3.4. For local ports, this field encodes the previous operational value of port priority. For remote ports, this field encodes the operational port priority last known to the PE via notifications received from its peers in the RG.
2 octets. LACP port priority for the corresponding interface, as specified in [IEEE-802.1AX], Section 5.3.4. For local ports, this field encodes the previous operational value of port priority. For remote ports, this field encodes the operational port priority last known to the PE via notifications received from its peers in the RG.
- Current Port Priority
- 現在のポートプライオリティ
2 octets. LACP port priority for the corresponding interface, as specified in [IEEE-802.1AX], Section 5.3.4. For local ports, this field encodes the new operational value of port priority being advertised by the PE. For remote ports, this field specifies the new port priority being requested by the PE.
2 octets. LACP port priority for the corresponding interface, as specified in [IEEE-802.1AX], Section 5.3.4. For local ports, this field encodes the new operational value of port priority being advertised by the PE. For remote ports, this field specifies the new port priority being requested by the PE.
The "mLACP Port State TLV" is used in the "RG Application Data" message. This TLV is used by a device to report its LACP port status to other members in the RG.
「mLACP Port State TLV」は「RG Application Data」メッセージで使用されます。このTLVは、デバイスのLACPポートステータスをRGの他のメンバーに報告するために使用されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type = 0x0035 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partner System ID |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Partner System Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partner Port Number | Partner Port Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partner Key | Partner State | Actor State |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Actor Port Number | Actor Key |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Selected | Port State | Aggregator ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- U-bit and F-bit
- U-bit and F-bit
Both are set to 0.
どちらも0に設定されています。
- Type
- タイプ
Set to 0x0035 for "mLACP Port State TLV".
「mLACPポート状態TLV」の場合は0x0035に設定します。
- Length
- Length
Length of the TLV in octets, excluding the "U-bit", "F-bit", "Type", and "Length" fields.
「Uビット」、「Fビット」、「タイプ」、および「長さ」フィールドを除く、オクテット単位のTLVの長さ。
- Partner System ID
- パートナーシステムID
6 octets. The LACP Partner System ID for the corresponding interface, encoded as a MAC address as specified in [IEEE-802.1AX], Section 5.4.2.2, item r.
6オクテット。 [IEEE-802.1AX]、セクション5.4.2.2、項目rで指定されているMACアドレスとしてエンコードされた、対応するインターフェイスのLACPパートナーシステムID。
- Partner System Priority
- パートナーシステムの優先度
2-octet field specifying the LACP Partner System Priority, as specified in [IEEE-802.1AX], Section 5.4.2.2, item q.
[IEEE-802.1AX]、セクション5.4.2.2、アイテムqで指定されている、LACPパートナーシステムの優先度を指定する2オクテットのフィールド。
- Partner Port Number
- パートナーポート番号
2 octets encoding the LACP Partner Port Number, as specified in [IEEE-802.1AX], Section 5.4.2.2, item u. The Port Number MUST be encoded with the Node ID, as discussed above.
[IEEE-802.1AX]、セクション5.4.2.2、アイテムuで指定されている、LACPパートナーポート番号をエンコードする2オクテット。上記のように、ポート番号はノードIDでエンコードする必要があります。
- Partner Port Priority
- パートナーポートプライオリティ
2-octet field encoding the LACP Partner Port Priority, as specified in [IEEE-802.1AX], Section 5.4.2.2, item t.
[IEEE-802.1AX]、セクション5.4.2.2、アイテムtで指定されている、LACPパートナーポートプライオリティをエンコードする2オクテットフィールド。
- Partner Key
- パートナーキー
2-octet field representing the LACP Partner Key, as defined in [IEEE-802.1AX], Section 5.4.2.2, item s.
[IEEE-802.1AX]、セクション5.4.2.2、アイテムsで定義されているLACPパートナーキーを表す2オクテットフィールド。
- Partner State
- Partner State
1-octet field encoding the LACP Partner State Variable, as defined in [IEEE-802.1AX], Section 5.4.2.2, item v.
[IEEE-802.1AX]、セクション5.4.2.2、アイテムvで定義されている、LACPパートナー状態変数をエンコードする1オクテットフィールド。
- Actor State
- 俳優の状態
1 octet encoding the LACP Actor State Variable for the port, as specified in [IEEE-802.1AX], Section 5.4.2.2, item m.
[IEEE-802.1AX]、セクション5.4.2.2、項目mで指定されている、ポートのLACPアクター状態変数をエンコードする1オクテット。
- Actor Port Number
- アクターポート番号
2-octet field representing the LACP Actor Port Number, as specified in [IEEE-802.1AX], Section 5.3.4. The Port Number MUST be encoded with the Node ID, as discussed above.
2-octet field representing the LACP Actor Port Number, as specified in [IEEE-802.1AX], Section 5.3.4. The Port Number MUST be encoded with the Node ID, as discussed above.
- Actor Key
- 俳優のキー
2-octet field encoding the LACP Actor Operational Key, as specified in [IEEE-802.1AX], Section 5.3.5.
2-octet field encoding the LACP Actor Operational Key, as specified in [IEEE-802.1AX], Section 5.3.5.
- Selected
- 選択済み
1 octet encoding the LACP "Selected" variable, defined in [IEEE-802.1AX], Section 5.4.8 as follows:
LACPの「選択された」変数をエンコードする1オクテット。[IEEE-802.1AX]のセクション5.4.8で次のように定義されています。
0x00 SELECTED 0x01 UNSELECTED 0x02 STANDBY
0x00選択済み0x01非選択0x02スタンバイ
- Port State
- ポートの状態
1 octet encoding the operational state of the port as follows:
次のようにポートの動作状態をエンコードする1オクテット：
0x00 Up 0x01 Down 0x02 Administratively Down 0x03 Test (e.g., IEEE 802.3ah OAM Intrusive Loopback mode)
0x00 Up 0x01 Down 0x02 Administratively Down 0x03 Test（e.g.、IEEE 802.3ah OAM Intrusive Loopback mode）
- Aggregator ID
- アグリゲーターID
2 octets. LACP Aggregator Identifier to which this port is bound based on the outcome of the LACP selection logic.
2オクテット。 LACP選択ロジックの結果に基づいて、このポートがバインドされるLACPアグリゲーターID。
The "mLACP Aggregator State TLV" is used in the "RG Application Data" message. This TLV is used by a device to report its Aggregator status to other members in the RG.
「mLACP Aggregator State TLV」は「RG Application Data」メッセージで使用されます。このTLVは、RG内の他のメンバーにアグリゲーターのステータスを報告するためにデバイスによって使用されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type = 0x0037 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partner System ID |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Partner System Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partner Key | Aggregator ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Actor Key | Agg State |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- U-bit and F-bit
- UビットとFビット
Both are set to 0.
Both are set to 0.
- Type
- タイプ
Set to 0x0037 for "mLACP Aggregator State TLV".
「mLACP Aggregator State TLV」の場合は0x0037に設定します。
- Length
- 長さ
Length of the TLV in octets, excluding the "U-bit", "F-bit", "Type", and "Length" fields.
Length of the TLV in octets, excluding the "U-bit", "F-bit", "Type", and "Length" fields.
- Partner System ID
- パートナーシステムID
6 octets. The LACP Partner System ID for the corresponding interface, encoded as a MAC address as specified in [IEEE-802.1AX], Section 5.4.2.2, item r.
6オクテット。 [IEEE-802.1AX]、セクション5.4.2.2、項目rで指定されているMACアドレスとしてエンコードされた、対応するインターフェイスのLACPパートナーシステムID。
- Partner System Priority
- パートナーシステムの優先度
2-octet field specifying the LACP Partner System Priority, as specified in [IEEE-802.1AX], Section 5.4.2.2, item q.
[IEEE-802.1AX]、セクション5.4.2.2、アイテムqで指定されている、LACPパートナーシステムの優先度を指定する2オクテットのフィールド。
- Partner Key
- Partner Key
2-octet field representing the LACP Partner Key, as defined in [IEEE-802.1AX], Section 5.4.2.2, item s.
[IEEE-802.1AX]、セクション5.4.2.2、アイテムsで定義されているLACPパートナーキーを表す2オクテットフィールド。
- Aggregator ID
- アグリゲーターID
2 octets. LACP Aggregator Identifier, as specified in [IEEE-802.1AX], Section 5.4.6.
2 octets. LACP Aggregator Identifier, as specified in [IEEE-802.1AX], Section 5.4.6.
- Actor Key
- 俳優のキー
2-octet field encoding the LACP Actor Operational Key, as specified in [IEEE-802.1AX], Section 5.3.5.
[IEEE-802.1AX]、セクション5.3.5で指定されている、LACPアクター操作キーをエンコードする2オクテットのフィールド。
- Agg State
- Agg State
1 octet encoding the operational state of the Aggregator as follows:
次のように、アグリゲーターの動作状態をエンコードする1オクテット：
0x00 Up 0x01 Down 0x02 Administratively Down 0x03 Test (e.g., IEEE 802.3ah OAM Intrusive Loopback mode)
0x00 Up 0x01 Down 0x02 Administratively Down 0x03 Test（e.g.、IEEE 802.3ah OAM Intrusive Loopback mode）
The "mLACP Synchronization Request TLV" is used in the "RG Application Data" message. This TLV is used by a device to request that its peer retransmit configuration or operational state. The following information can be requested:
「mLACP Synchronization Request TLV」は「RG Application Data」メッセージで使用されます。このTLVは、ピアが構成または動作状態を再送信することを要求するためにデバイスによって使用されます。以下の情報を要求できます。
- system configuration and/or state
- システム構成および/または状態
- configuration and/or state for a specific port
- configuration and/or state for a specific port
- configuration and/or state for all ports with a specific LACP Key
- 特定のLACPキーを持つすべてのポートの構成および/または状態
- configuration and/or state for all mLACP ports
- すべてのmLACPポートの構成および/または状態
- configuration and/or state for a specific Aggregator
- 特定のアグリゲーターの構成や状態
- configuration and/or state for all Aggregators with a specific LACP Key
- 特定のLACPキーを持つすべてのアグリゲーターの構成および/または状態
- configuration and/or state for all mLACP Aggregators
- すべてのmLACPアグリゲータの構成および/または状態
The format of the TLV is as follows:
TLVの形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type = 0x0038 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request Number |C|S| Request Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Number / Aggregator ID | Actor Key |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- U-bit and F-bit
- UビットとFビット
Both are set to 0.
どちらも0に設定されています。
- Type
- タイプ
Set to 0x0038 for "mLACP Synchronization Request TLV".
「mLACP同期要求TLV」の場合は0x0038に設定します。
- Length
- Length
Length of the TLV in octets, excluding the "U-bit", "F-bit", "Type", and "Length" fields.
「Uビット」、「Fビット」、「タイプ」、および「長さ」フィールドを除く、オクテット単位のTLVの長さ。
- Request Number
- Request Number
2 octets. Unsigned integer uniquely identifying the request. Used to match the request with a response. The value of 0 is reserved for unsolicited synchronization and MUST NOT be used in the "mLACP Synchronization Request TLV".
2オクテット。リクエストを一意に識別する符号なし整数。リクエストとレスポンスを照合するために使用されます。値0は非送信請求同期用に予約されており、「mLACP同期要求TLV」で使用してはなりません（MUST NOT）。
- C-bit
- Cビット
Set to 1 if the request is for configuration data. Otherwise, set to 0.
要求が構成データに対するものである場合は、1に設定します。それ以外の場合は0に設定します。
- S-bit
- Sビット
Set to 1 if the request is for running state data. Otherwise, set to 0.
要求が実行状態データ用である場合は、1に設定します。それ以外の場合は0に設定します。
- Request Type
- リクエストの種類
14 bits specifying the request type, encoded as follows:
次のようにエンコードされた、要求タイプを指定する14ビット：
0x00 Request System Data 0x01 Request Aggregator Data 0x02 Request Port Data 0x3FFF Request All Data
0x00システムデータの要求0x01アグリゲーターデータの要求0x02ポートデータの要求0x3FFFすべてのデータの要求
- Port Number / Aggregator ID
- ポート番号/アグリゲーターID
2 octets. When the "Request Type" field is set to "Request Port Data", this field encodes the LACP Port Number for the requested port. When the "Request Type" field is set to "Request Aggregator Data", this field encodes the Aggregator ID of the requested Aggregator. When the value of this field is 0, it denotes that information for all ports (or Aggregators) whose LACP Key is specified in the "Actor Key" field is being requested.
2オクテット。 「Request Type」フィールドが「Request Port Data」に設定されている場合、このフィールドは、要求されたポートのLACPポート番号をエンコードします。 「Request Type」フィールドが「Request Aggregator Data」に設定されている場合、このフィールドは、要求されたAggregatorのAggregator IDをエンコードします。このフィールドの値が0の場合、LACPキーが「Actor Key」フィールドで指定されているすべてのポート（またはアグリゲーター）の情報が要求されていることを示します。
- Actor Key
- 俳優のキー
2 octets. LACP Actor Key for the corresponding port or Aggregator. When the value of this field is 0 (and the Port Number / Aggregator ID field is 0 as well), it denotes that information for all ports or Aggregators in the system is being requested.
2オクテット。対応するポートまたはアグリゲーターのLACPアクターキー。このフィールドの値が0（およびポート番号/アグリゲーターIDフィールドも0）の場合、システム内のすべてのポートまたはアグリゲーターの情報が要求されていることを示します。
The "mLACP Synchronization Data TLV" is used in the "RG Application Data" message. A pair of these TLVs is used by a device to delimit a set of TLVs that are being transmitted in response to an "mLACP Synchronization Request TLV". The delimiting TLVs signal the start and end of the synchronization data and associate the response with its corresponding request via the "Request Number" field.
「mLACP Synchronization Data TLV」は「RG Application Data」メッセージで使用されます。デバイスはこれらのTLVのペアを使用して、「mLACP同期要求TLV」に応答して送信されるTLVのセットを区切ります。区切りのTLVは、同期データの開始と終了を通知し、「要求番号」フィールドを介して応答を対応する要求に関連付けます。
The "mLACP Synchronization Data TLVs" are also used for unsolicited advertisements of complete mLACP configuration and operational state data. The "Request Number" field MUST be set to 0 in this case. For such unsolicited synchronization, the PE MUST advertise all system, Aggregator, and port information, as done during the initialization sequence.
「mLACP同期データTLV」は、完全なmLACP構成および動作状態データの非請求アドバタイズにも使用されます。この場合、「リクエスト番号」フィールドを0に設定する必要があります。そのような要請されていない同期の場合、PEは、初期化シーケンス中に行われるように、すべてのシステム、アグリゲーター、およびポート情報を通知する必要があります。
This TLV has the following format:
このTLVの形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type = 0x0039 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request Number | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- U-bit and F-bit
- UビットとFビット
Both are set to 0.
どちらも0に設定されています。
- Type
- タイプ
Set to 0x0039 for "mLACP Synchronization Data TLV".
「mLACP同期データTLV」の場合は0x0039に設定します。
- Length
- 長さ
Length of the TLV in octets, excluding the "U-bit", "F-bit", "Type", and "Length" fields.
「Uビット」、「Fビット」、「タイプ」、および「長さ」フィールドを除く、オクテット単位のTLVの長さ。
- Request Number
- 要求番号
2 octets. Unsigned integer identifying the Request Number from the "mLACP Synchronization Request TLV" that solicited this synchronization data response.
2オクテット。この同期データ応答を要求した「mLACP同期要求TLV」からの要求番号を識別する符号なし整数。
- Flags
- 旗
2 octets. Response flags, encoded as follows:
2オクテット。次のようにエンコードされた応答フラグ：
0x00 Synchronization Data Start 0x01 Synchronization Data End
0x00同期データ開始0x01同期データ終了
As required in [RFC5561], the following TLV is defined to indicate the ICCP capability:
[RFC5561]での必要に応じて、次のTLVがICCP機能を示すために定義されています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| TLV Code Point = 0x0700 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Reserved | Reserved | Ver/Maj | Ver/Min |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- U-bit
- Uビット
SHOULD be 1 (ignore if not understood).
1にする必要があります（理解できない場合は無視してください）。
- F-bit
- Fビット
SHOULD be 0 (don't forward if not understood).
0にする必要があります（理解できない場合は転送しないでください）。
- TLV Code Point
- TLVコードポイント
The TLV type, which identifies a specific capability. The ICCP code point is listed in Section 12 below.
特定の機能を識別するTLVタイプ。 ICCPコードポイントは、以下のセクション12に記載されています。
- S-bit
- Sビット
State bit. Indicates whether the sender is advertising or withdrawing the ICCP capability. The State bit is used as follows:
状態ビット。送信者がICCP機能をアドバタイズしているか、撤回しているかを示します。状態ビットは次のように使用されます。
1 - The TLV is advertising the capability specified by the TLV Code Point.
1-TLVはTLVコードポイントで指定された機能をアドバタイズしています。
0 - The TLV is withdrawing the capability specified by the TLV Code Point.
0-TLVは、TLVコードポイントで指定された機能を撤回しています。
- Ver/Maj
- Ver / Maj
The major version revision of ICCP. This document specifies 1.0, and so this field is set to 1.
ICCPのメジャーバージョンリビジョン。このドキュメントでは1.0を指定しているため、このフィールドは1に設定されています。
- Ver/Min
- Ver / Min
The minor version revision of ICCP. This document specifies 1.0, and so this field is set to 0.
ICCPのマイナーバージョンリビジョン。このドキュメントでは1.0を指定しているため、このフィールドは0に設定されています。
ICCP capability is advertised to an LDP peer if there is at least one RG enabled on the local PE.
ローカルPEで有効なRGが少なくとも1つある場合、ICCP機能はLDPピアにアドバタイズされます。
This section defines the procedures for the Pseudowire Redundancy (PW-RED) application.
このセクションでは、疑似配線冗長（PW-RED）アプリケーションの手順を定義します。
It should be noted that the PW-RED application SHOULD NOT be enabled together with an AC redundancy application for the same service instance. This simplifies the operation of the multi-chassis redundancy solution (Figure 1) and eliminates the possibility of deadlock conditions between the AC and PW redundancy mechanisms.
PW-REDアプリケーションは、同じサービスインスタンスのAC冗長性アプリケーションと一緒に有効にしないでください。これにより、マルチシャーシ冗長ソリューション（図1）の操作が簡素化され、AC冗長メカニズムとPW冗長メカニズムの間のデッドロック状態の可能性がなくなります。
When an RG is configured on a system and multi-chassis pseudowire redundancy is enabled in that RG, the PW-RED application MUST send an "RG Connect" message with a "PW-RED Connect TLV" to each PE that is a member of the same RG. The sending PE MUST set the A-bit to 1 if it has already received a "PW-RED Connect TLV" from its peer; otherwise, the PE MUST set the A-bit to 0. If a PE that has sent the TLV with the A-bit set to 0 receives a "PW-RED Connect TLV" from a peer, it MUST repeat its advertisement with the A-bit set to 1. The PW-RED Application Connection is considered to be operational when both PEs have sent and received "PW-RED Connect TLVs" with the A-bit set to 1. Once the Application Connection becomes operational, the two devices can start exchanging "RG Application Data" messages for the PW-RED application.
システムでRGが構成されており、そのRGでマルチシャーシの疑似配線冗長性が有効になっている場合、PW-REDアプリケーションは、メンバーである各PEに「PW-RED Connect TLV」を含む「RG Connect」メッセージを送信する必要があります。同じRG。送信側PEは、ピアから「PW-RED Connect TLV」をすでに受信している場合、Aビットを1に設定する必要があります。それ以外の場合、PEはAビットを0に設定する必要があります。Aビットを0に設定してTLVを送信したPEがピアから「PW-RED Connect TLV」を受信した場合、PEはAでアドバタイズを繰り返す必要があります。 -bitが1に設定されます。両方のPEがAビットが1に設定された「PW-RED Connect TLV」を送受信した場合、PW-REDアプリケーション接続は動作していると見なされます。アプリケーション接続が動作可能になると、2つのデバイスPW-REDアプリケーションの「RGアプリケーションデータ」メッセージの交換を開始できます。
If a system receives an "RG Connect" message with a "PW-RED Connect TLV" that has a different Protocol Version, it must follow the procedures outlined in Section 4.4.1 above.
If a system receives an "RG Connect" message with a "PW-RED Connect TLV" that has a different Protocol Version, it must follow the procedures outlined in Section 4.4.1 above.
When the PW-RED application is disabled on the device or is unconfigured for the RG in question, the system MUST send an "RG Disconnect" message with a "PW-RED Disconnect TLV".
PW-REDアプリケーションがデバイスで無効にされているか、問題のRGに対して構成されていない場合、システムは「PW-RED Disconnect TLV」を含む「RG Disconnect」メッセージを送信する必要があります。
A system MUST advertise its local PW configuration to other PEs that are members of the same RG. This allows the PEs to build a view of the redundant nodes and pseudowires that are protecting the same service instances. The advertisement MUST be initiated when the PW-RED Application Connection first comes up. To that end, the system sends "RG Application Data" messages with "PW-RED Config TLVs" as part of an unsolicited synchronization. A PE MUST use a pair of "PW-RED Synchronization Data TLVs" to delimit the set of TLVs that are being sent as part of this unsolicited advertisement.
システムは、ローカルPW構成を同じRGのメンバーである他のPEに通知する必要があります。これにより、PEは、同じサービスインスタンスを保護している冗長ノードと疑似配線のビューを構築できます。アドバタイズは、PW-REDアプリケーション接続が最初に起動したときに開始する必要があります。そのために、システムは非送信請求同期の一部として「PW-RED Config TLV」を含む「RGアプリケーションデータ」メッセージを送信します。 PEは「PW-RED同期データTLV」のペアを使用して、この非送信請求アドバタイズの一部として送信されるTLVのセットを区切る必要があります。
In the case of a configuration change, a PE MUST re-advertise the most up-to-date information for the affected pseudowires.
設定が変更された場合、PEは影響を受ける疑似配線の最新情報を再アドバタイズする必要があります。
As part of the configuration synchronization, a PE advertises the ROID associated with the pseudowire. This is used to correlate the pseudowires that are protecting each other on different PEs. A PE also advertises the configured PW redundancy mode. This can be one of the following four options: Master Mode, Slave Mode, Independent Mode, or Independent Mode with Request Switchover. If the received redundancy mode does not match the locally configured mode for the same ROID, then the PE MUST respond with an "RG Notification" message to reject the "PW-RED Config TLV". The PE MUST disable the associated local pseudowire until a satisfactory "PW-RED Config TLV" is received from the peer. This guarantees that device misconfiguration does not lead to network-wide problems (e.g., by creating forwarding loops). The PE SHOULD also raise an alarm to alert the operator. If a PE receives a "NAK TLV" for an advertised "PW-RED Config TLV", it MUST disable the associated pseudowire and SHOULD raise an alarm to alert the operator.
PEは設定同期の一部として、疑似配線に関連付けられたROIDをアドバタイズします。これは、異なるPEで相互に保護している疑似配線を関連付けるために使用されます。 PEは、設定されたPW冗長モードもアドバタイズします。これは、マスターモード、スレーブモード、独立モード、または要求切り替えを伴う独立モードの4つのオプションのいずれかになります。受信した冗長モードが同じROIDに対してローカルに構成されたモードと一致しない場合、PEは「RG通知」メッセージで応答して、「PW-RED Config TLV」を拒否する必要があります。 PEは、ピアから十分な「PW-RED Config TLV」が受信されるまで、関連付けられたローカル疑似配線を無効にする必要があります。これにより、デバイスの設定ミスがネットワーク全体に問題を引き起こさないことが保証されます（転送ループが作成されるなど）。 PEはまた、オペレーターに警告するためにアラームを発生させる必要があります（SHOULD）。 PEがアドバタイズされた「PW-RED Config TLV」の「NAK TLV」を受信した場合、関連する疑似配線を無効にし、オペレーターに警告するためにアラームを発生させる必要があります（SHOULD）。
Furthermore, a PE advertises in its "PW-RED Config TLVs" a priority value that is used to determine the precedence of a given pseudowire to assume the active role in a redundant setup. A PE also advertises a Service Name that is global in the context of an RG and is used to identify which pseudowires belong to the same service. Finally, a PE also advertises the pseudowire identifier as part of this synchronization.
さらに、PEは、「PW-RED Config TLV」で優先値をアドバタイズします。これは、冗長セットアップでアクティブな役割を引き受けるために、特定の疑似配線の優先順位を決定するために使用されます。 PEは、RGのコンテキストでグローバルであり、どのサービスが同じサービスに属しているかを識別するために使用されるサービス名もアドバタイズします。最後に、PEはこの同期の一部として疑似配線識別子もアドバタイズします。
PEs that are members of an RG synchronize pseudowire status for the purpose of identifying, on a per-ROID basis, which pseudowire will be actively used for forwarding and which pseudowire(s) will be placed in standby state.
RGのメンバーであるPEは、ROIDごとに、どの疑似回線が転送にアクティブに使用され、どの疑似回線がスタンバイ状態になるかを識別する目的で、疑似回線ステータスを同期します。
Synchronization of pseudowire status is done by sending the "PW-RED State TLV" whenever the pseudowire state changes on a PE. This includes changes to the local end as well as the remote end of the pseudowire.
疑似配線の状態の同期は、疑似配線の状態がPEで変化するたびに「PW-RED State TLV」を送信することによって行われます。これには、疑似配線のローカルエンドとリモートエンドの変更が含まれます。
A PE may request that its peer retransmit previously advertised PW-RED state. This is useful, for instance, when the PE is recovering from a soft failure. To request such a retransmission, a PE MUST send a set of one or more "PW-RED Synchronization Request TLVs".
PEは、ピアが以前にアドバタイズされたPW-RED状態を再送信することを要求する場合があります。これは、たとえば、PEがソフト障害から回復しているときに役立ちます。そのような再送信を要求するには、PEは1つ以上の「PW-RED同期要求TLV」のセットを送信する必要があります。
A PE MUST respond to a "PW-RED Synchronization Request TLV" by sending the requested data in a set of one or more "PW-RED TLVs" delimited by a pair of "PW-RED Synchronization Data TLVs". The TLVs comprising the response MUST be ordered such that the "Synchronization Response TLV" with the "Synchronization Data Start" flag precedes the various other "PW-RED TLVs" encoding the requested data. These, in turn, MUST precede the "Synchronization Data TLV" with the "Synchronization Data End" flag. It is worth noting that the response may span multiple "RG Application Data" messages; however, the above TLV ordering MUST be retained across messages, and only a single pair of "Synchronization Data TLVs" must be used to delimit the response across all "Application Data" messages.
PEは、「PW-RED同期データTLV」のペアで区切られた1つ以上の「PW-RED TLV」のセットで要求されたデータを送信することにより、「PW-RED同期要求TLV」に応答する必要があります。応答を構成するTLVは、「同期データ開始」フラグの付いた「同期応答TLV」が、要求されたデータをエンコードする他のさまざまな「PW-RED TLV」に先行するように順序付けられなければなりません。次に、これらは「同期データTLV」の前に「同期データ終了」フラグを付けなければなりません。応答が複数の「RG Application Data」メッセージにまたがることがあることに注意する価値があります。ただし、上記のTLVの順序はメッセージ全体で保持する必要があり、「同期データTLV」のペアを1つだけ使用して、すべての「アプリケーションデータ」メッセージで応答を区切る必要があります。
A PE MAY re-advertise its PW-RED state in an unsolicited manner. This is done by sending the appropriate Config and State TLVs delimited by a pair of "PW-RED Synchronization Data TLVs" and using a "Request Number" of 0.
PEは、PW-RED状態を一方的な方法で再アドバタイズする場合があります。これは、「PW-RED同期データTLV」のペアで区切られた適切な構成と状態のTLVを送信し、「リクエスト番号」を0として使用することで行われます。
While a PE has a pending synchronization request for a pseudowire or a service, it SHOULD silently ignore all TLVs for said pseudowire or service that are received prior to the synchronization response and that carry the same type of information being requested. This saves the system from the burden of updating state that will ultimately be overwritten by the synchronization response. Note that TLVs pertaining to other pseudowires or services are to continue to be processed per normal procedures in the interim.
PEには疑似配線またはサービスの保留中の同期要求がありますが、同期応答の前に受信され、要求されている同じタイプの情報を運ぶ、疑似配線またはサービスのすべてのTLVを黙って無視する必要があります。これにより、最終的に同期応答によって上書きされる状態を更新する負担からシステムが節約されます。他の疑似配線またはサービスに関連するTLVは、その間、通常の手順に従って引き続き処理されることに注意してください。
If a PE receives a synchronization request for a pseudowire or service that doesn't exist or is not known to the PE, then it MUST trigger an unsolicited synchronization of all pseudowire information (i.e., replay the initialization sequence).
PEが存在しない、またはPEに認識されていない疑似配線またはサービスの同期要求を受信した場合、すべての疑似配線情報の非送信請求同期をトリガーする必要があります（つまり、初期化シーケンスを再生します）。
In the subsections that follow, we describe the details of pseudowire status synchronization for each of the PW redundancy modes defined in [RFC6870].
次のサブセクションでは、[RFC6870]で定義されている各PW冗長モードの疑似配線ステータス同期の詳細について説明します。
This section covers the operation in Independent Mode with or without Request Switchover capability.
このセクションでは、リクエストスイッチオーバー機能の有無にかかわらず、独立モードでの操作について説明します。
In this mode, the operator must ensure that for a given RO the PW Priority values configured for all associated pseudowires on a given PE are collectively higher (or lower) than those configured on other PEs in the same RG. If this condition is not satisfied after the PEs have exchanged "PW-RED State TLVs", a PE MUST disable the associated pseudowire(s) and SHOULD raise an alarm to alert the operator. Note that the PW Priority MAY be the same as the PW Precedence as defined in [RFC6870].
このモードでは、オペレーターは、特定のROに対して、特定のPE上のすべての関連する疑似配線に構成されたPW優先度の値が、同じRG内の他のPEに構成された値よりも高い（または低い）ことを確認する必要があります。 PEが「PW-RED状態のTLV」を交換した後でこの条件が満たされない場合、PEは関連する疑似配線を無効にし、オペレータに警告するアラームを発生させる必要があります。 PW Priorityは、[RFC6870]で定義されているPW Precedenceと同じでもよいことに注意してください。
For a given RO, after all of the PEs in an RG have exchanged their "PW-RED State TLVs", the PE with the best PW Priority (i.e., least numeric value) advertises active Preferential Forwarding status in LDP on all of its associated pseudowires, whereas all other PEs in the RG advertise standby Preferential Forwarding status in LDP on their associated pseudowires.
特定のROについて、RG内のすべてのPEが「PW-RED状態TLV」を交換した後、最高のPW優先度（つまり、最小の数値）を持つPEは、関連するすべてのLDPでアクティブな優先転送ステータスをアドバタイズします。一方、RG内の他のすべてのPEは、関連する疑似配線上でLDPのスタンバイ優先転送ステータスをアドバタイズします。
If the service is VPWS, then only a single pseudowire per service will be selected for forwarding. This is the pseudowire that is independently advertised with active Preferential Forwarding status on both endpoints, as described in [RFC6870].
サービスがVPWSの場合、サービスごとに1つの疑似回線のみが転送用に選択されます。これは、[RFC6870]で説明されているように、両方のエンドポイントでアクティブな優先転送ステータスで個別にアドバタイズされる疑似配線です。
If the service is VPLS, then one or multiple pseudowires per service will be selected for forwarding. These are the pseudowires that are independently advertised with active Preferential Forwarding status on both PW endpoints, as described in [RFC6870].
サービスがVPLSの場合、サービスごとに1つまたは複数の疑似配線が転送用に選択されます。これらは、[RFC6870]で説明されているように、両方のPWエンドポイントでアクティブな優先転送ステータスで個別にアドバタイズされる疑似配線です。
In this mode, the operator must ensure that for a given RO the PW Priority values configured for all associated pseudowires on a given PE are collectively higher (or lower) than those configured on other PEs in the same RG. If this condition is not satisfied after the PEs have exchanged "PW-RED State TLVs", a PE MUST disable the associated pseudowire(s) and SHOULD raise an alarm to alert the operator. Note that the PW Priority MAY be the same as the PW Precedence as defined in [RFC6870]. In addition, the operator must ensure that for a given RO all of the PEs in the RG are consistently configured as Master or Slave.
このモードでは、オペレーターは、特定のROに対して、特定のPE上のすべての関連する疑似配線に構成されたPW優先度の値が、同じRG内の他のPEに構成された値よりも高い（または低い）ことを確認する必要があります。 PEが「PW-RED状態のTLV」を交換した後でこの条件が満たされない場合、PEは関連する疑似配線を無効にし、オペレータに警告するアラームを発生させる必要があります。 PW Priorityは、[RFC6870]で定義されているPW Precedenceと同じでもよいことに注意してください。さらに、オペレーターは、特定のROについて、RG内のすべてのPEがマスターまたはスレーブとして一貫して構成されていることを確認する必要があります。
In the context of a given RO, if the PEs in the RG are acting as Master, then the PE with the best PW Priority (i.e., least numeric value) advertises active Preferential Forwarding status in LDP on only a single pseudowire, following the procedures in Sections 5.2 and 6.2 of [RFC6870], whereas all of the other pseudowires on other PEs in the RG are advertised with standby Preferential Forwarding status in LDP.
特定のROのコンテキストで、RG内のPEがマスターとして機能している場合、PWプライオリティが最高（つまり、数値が最小）のPEは、手順に従って、単一の疑似配線でのみLDPのアクティブな優先転送ステータスをアドバタイズします。 [RFC6870]のセクション5.2および6.2で、RG内の他のPE上の他のすべての疑似配線は、LDPでスタンバイの優先転送ステータスでアドバタイズされます。
When a PE node detects that a remote PE that is a member of the same RG is no longer reachable (using the mechanisms described in Section 5), the local PE determines if it has redundant PWs for the affected services. If the local PE has the highest priority (after the failed PE), then it becomes the active node for the services in question and subsequently activates its associated PW(s).
PEノードが、同じRGのメンバーであるリモートPEが（セクション5で説明されているメカニズムを使用して）到達できなくなったことを検出すると、ローカルPEは、影響を受けるサービスに冗長PWがあるかどうかを判断します。ローカルPEの優先度が最も高い場合（障害が発生したPEの後に）、それは問題のサービスのアクティブノードになり、その後、関連付けられたPWをアクティブにします。
This section describes generic procedures for AC redundancy applications, independent of the type of the AC (ATM, FR, or Ethernet).
This section describes generic procedures for AC redundancy applications, independent of the type of the AC (ATM, FR, or Ethernet).
When the AC redundancy mechanism on the active PE detects a failure of the AC, it should send an ICCP "Application Data" message to inform the redundant PEs of the need to take over. The AC failures can be categorized into the following scenarios:
アクティブPEのAC冗長性メカニズムは、ACの障害を検出すると、ICCPの「アプリケーションデータ」メッセージを送信して、冗長PEに引き継ぐ必要があることを通知します。 AC障害は、次のシナリオに分類できます。
- Failure of CE interface connecting to PE
- PEに接続するCEインターフェイスの障害
- Failure of CE uplink to PE
- PEへのCEアップリンクの障害
- Failure of PE interface connecting to CE
- Failure of PE interface connecting to CE
When a PE node detects that a remote PE that is a member of the same RG is no longer reachable (using the mechanisms described in Section 5), the local PE determines if it has redundant ACs for the affected services. If the local PE has the highest priority (after the failed PE), then it becomes the active node for the services in question and subsequently activates its associated ACs.
PEノードが同じRGのメンバーであるリモートPEが（セクション5で説明されているメカニズムを使用して）到達できなくなったことを検出すると、ローカルPEは影響を受けるサービスに冗長ACがあるかどうかを判断します。ローカルPEの優先度が最も高い場合（障害が発生したPEの後に）、ローカルPEは問題のサービスのアクティブノードになり、その後、関連するACをアクティブにします。
When a PE node detects that it has been isolated from the core network (i.e., all core-facing interfaces/links are not operational), then it should ensure that its AC redundancy mechanism will change the status of any active ACs to standby. The AC redundancy application SHOULD then send ICCP "Application Data" messages in order to trigger failover to a standby PE. Note that this works only in the case of dedicated interconnect (Sections 3.2.1 and 3.2.3), since ICCP will still have a path to the peer, even though the PE is isolated from the MPLS core network.
PEノードがコアネットワークから隔離されていることを検出すると（つまり、コアに面するすべてのインターフェイス/リンクが動作していない）、そのAC冗長メカニズムによってアクティブなACのステータスがスタンバイに変更されることを確認する必要があります。 AC冗長性アプリケーションは、スタンバイPEへのフェイルオーバーをトリガーするためにICCP「アプリケーションデータ」メッセージを送信する必要があります（SHOULD）。 PEがMPLSコアネットワークから分離されている場合でも、ICPはピアへのパスを保持するため、これは専用インターコネクト（セクション3.2.1および3.2.3）の場合にのみ機能することに注意してください。
If the PEs in an RG are running an AC redundancy application over ICCP, then the Independent Mode of PW redundancy, as defined in [RFC6870], MUST be used. On a given PE, the Preferential Forwarding status of the PW (active or standby) is derived from the state of the associated AC(s). This simplifies the operation of the multi-chassis redundancy solution (Figure 1) and eliminates the possibility of deadlock conditions between the AC and PW redundancy mechanisms. The rules by which the PW status is derived from the AC status are as follows:
RGのPEがICCPを介してAC冗長性アプリケーションを実行している場合、[RFC6870]で定義されているPW冗長性の独立モードを使用する必要があります。特定のPEでは、PW（アクティブまたはスタンバイ）の優先転送ステータスは、関連するACの状態から導出されます。これにより、マルチシャーシ冗長ソリューション（図1）の操作が簡素化され、AC冗長メカニズムとPW冗長メカニズムの間のデッドロック状態の可能性がなくなります。 PWステータスがACステータスから導出されるルールは次のとおりです。
- VPWS
- ΒΠΩΣ
For VPWS, there's a single AC per service instance. If the AC is active, then the PW status should be active. If the AC is standby, then the PW status should be standby.
VPWSの場合、サービスインスタンスごとに1つのACがあります。 ACがアクティブの場合、PWステータスはアクティブになります。 ACがスタンバイの場合、PWステータスはスタンバイでなければなりません。
- VPLS
- VPLS
For VPLS, there could be multiple ACs per service instance (i.e., Virtual Switch Instance (VSI) [RFC4026]). If AT LEAST ONE AC is active, then the PW status should be active. If ALL ACs are standby, then the PW status should be standby.
VPLSの場合、サービスインスタンスごとに複数のACが存在する可能性があります（つまり、仮想スイッチインスタンス（VSI）[RFC4026]）。 AT LEAST ONE ACがアクティブの場合、PWステータスがアクティブになります。すべてのACがスタンバイの場合、PWステータスはスタンバイでなければなりません。
In this case, the PW-RED application is not used to synchronize PW status between PEs. Rather, the AC redundancy application should synchronize AC status between PEs, in order to establish which AC (and subsequently which PE) is active or standby for a given service. When that is determined, each PE will then derive its local PW's state according to the rules described above. The Preferential Forwarding status bit, described in [RFC6870], is used to advertise PW status to the remote peers.
この場合、PW-REDアプリケーションは、PE間のPWステータスの同期には使用されません。むしろ、AC冗長性アプリケーションはPE間でACステータスを同期させて、特定のサービスに対してどのAC（およびその後どのPE）がアクティブまたはスタンバイであるかを確立する必要があります。それが決定されると、各PEは、上記のルールに従ってローカルPWの状態を導出します。 [RFC6870]で説明されている優先転送ステータスビットは、リモートピアにPWステータスを通知するために使用されます。
This section defines the procedures that are specific to the multi-chassis LACP (mLACP) application, which is applicable for Ethernet ACs.
このセクションでは、イーサネットACに適用できるマルチシャーシLACP（mLACP）アプリケーションに固有の手順を定義します。
When an RG is configured on a system and mLACP is enabled in that RG, the mLACP application MUST send an "RG Connect" message with an "mLACP Connect TLV" to each PE that is a member of the same RG. The sending PE MUST set the A-bit to 1 in said TLV if it has received a corresponding "mLACP Connect TLV" from its peer PE; otherwise, the sending PE MUST set the A-bit to 0. If a PE receives an "mLACP Connect TLV" from its peer after sending said TLV with the A-bit set to 0, it MUST resend the TLV with the A-bit set to 1. A system considers the mLACP Application Connection to be operational when it has sent and received "mLACP Connect TLVs" with the A-bit set to 1. When the mLACP Application Connection between a pair of PEs is operational, the two devices can start exchanging "RG Application Data" messages for the mLACP application. This involves having each PE advertise its mLACP configuration and operational state in an unsolicited manner. A PE SHOULD use the following sequence when advertising its mLACP state upon initial Application Connection setup:
システムでRGが構成され、そのRGでmLACPが有効になっている場合、mLACPアプリケーションは、「mLACP Connect TLV」を含む「RG Connect」メッセージを、同じRGのメンバーである各PEに送信する必要があります。送信側PEは、対応する「mLACP Connect TLV」をピアPEから受信した場合、そのTLVでAビットを1に設定する必要があります。それ以外の場合、送信側PEはAビットを0に設定する必要があります。PEがAビットを0に設定してTLVを送信した後に、ピアから「mLACP Connect TLV」を受信した場合、PEはAビットを使用してTLVを再送信する必要がありますシステムは、Aビットが1に設定された「mLACP Connect TLV」を送受信したときに、mLACPアプリケーション接続が動作していると見なします。1組のPE間のmLACPアプリケーション接続が動作している場合、2つのデバイスmLACPアプリケーションの「RG Application Data」メッセージの交換を開始できます。これには、各PEがそのmLACP設定と動作状態を任意の方法でアドバタイズする必要があります。 PEは、アプリケーション接続の初期設定時にmLACP状態をアドバタイズするときに、次のシーケンスを使用する必要があります（SHOULD）。
- Advertise system configuration
- システム構成をアドバタイズする
- Advertise Aggregator configuration
- アグリゲーター構成のアドバタイズ
- Advertise port configuration
- ポート構成のアドバタイズ
- Advertise Aggregator state
- アグリゲーターの状態を通知する
- Advertise port state
- Advertise port state
A PE MUST use a pair of "mLACP Synchronization Data TLVs" to delimit the entire set of TLVs that are being sent as part of this unsolicited advertisement.
PEは「mLACP同期データTLV」のペアを使用して、この非送信請求アドバタイズメントの一部として送信されるTLVのセット全体を区切る必要があります。
If a system receives an "RG Connect" message with an "mLACP Connect TLV" that has a different Protocol Version, it MUST follow the procedures outlined in Section 4.4.1 above.
システムが、異なるプロトコルバージョンを持つ「mLACP Connect TLV」を含む「RG Connect」メッセージを受信した場合、上記のセクション4.4.1で概説されている手順に従う必要があります。
After the mLACP Application Connection has been established, every PE MUST communicate its system-level configuration to its peers via the use of the "mLACP System Config TLV". This allows every PE to discover the Node ID and the locally configured System ID and System Priority values of its peers.
mLACPアプリケーション接続が確立された後、すべてのPEは、「mLACPシステム構成TLV」を使用して、システムレベルの構成をピアに通信する必要があります。これにより、すべてのPEが、ノードIDと、ローカルで構成されたピアのシステムIDおよびシステムプライオリティ値を検出できます。
If a PE receives an "mLACP System Config TLV" from a remote peer advertising the same Node ID value as the local system, then the PE MUST respond with an "RG Notification" message to reject the "mLACP System Config TLV". The PE MUST suspend the mLACP application until a satisfactory "mLACP System Config TLV" is received from the peer. It SHOULD also raise an alarm to alert the operator. Furthermore, if a PE receives a "NAK TLV" for an "mLACP System Config TLV" that it has advertised, the PE MUST suspend the mLACP application and SHOULD raise an alarm to alert the network operator of potential device misconfiguration.
PEがローカルシステムと同じノードID値をアドバタイズするリモートピアから「mLACPシステム構成TLV」を受信した場合、PEは「RG通知」メッセージで応答して、「mLACPシステム構成TLV」を拒否する必要があります。 PEは、ピアから満足のいく「mLACPシステム構成TLV」が受信されるまで、mLACPアプリケーションを一時停止する必要があります。また、オペレーターに警告するためにアラームを発生させる必要があります。さらに、PEがアドバタイズした「mLACP System Config TLV」の「NAK TLV」を受信した場合、PEはmLACPアプリケーションを一時停止し、デバイスの設定ミスの可能性をネットワークオペレーターに警告するアラームを発生させる必要があります。
If a PE receives an "mLACP System Config TLV" from a new peer advertising the same Node ID value as another existing peer with which the local system has an established mLACP Application Connection, then the PE MUST respond to the new peer with an "RG Notification" message to reject the "mLACP System Config TLV" and MUST ignore the offending TLV.
If a PE receives an "mLACP System Config TLV" from a new peer advertising the same Node ID value as another existing peer with which the local system has an established mLACP Application Connection, then the PE MUST respond to the new peer with an "RG Notification" message to reject the "mLACP System Config TLV" and MUST ignore the offending TLV.
If the Node ID of a particular PE changes due to administrative configuration action, the PE MUST then inform its peers to purge the configuration of all previously advertised ports and/or Aggregators and MUST replay the initialization sequence by sending an unsolicited synchronization of the system configuration, Aggregator configuration, port configuration, Aggregator state, and port state.
管理構成アクションのために特定のPEのノードIDが変更された場合、PEはピアに通知して、以前にアドバタイズされたすべてのポートやアグリゲーターの構成を削除し、システム構成の非送信請求同期を送信して初期化シーケンスを再生する必要があります。 、アグリゲーター構成、ポート構成、アグリゲーター状態、およびポート状態。
It is necessary for all PEs in an RG to agree upon the System ID and System Priority values to be used ubiquitously. To achieve this, every PE MUST use the values for the two parameters that are supplied by the PE with the numerically lowest value (among RG members) of System Aggregation Priority. This guarantees that the PEs always agree on uniform values that yield the highest System Priority.
RG内のすべてのPEが、ユビキタスに使用されるシステムIDとシステムプライオリティの値に同意する必要があります。これを達成するために、すべてのPEは、システムアグリゲーションプライオリティの数値的に最も低い値（RGメンバーの中で）を持つPEによって提供される2つのパラメーターの値を使用する必要があります。これにより、PEが常に最高のシステムプライオリティをもたらす均一な値に同意することが保証されます。
When the mLACP application is disabled on the device or is unconfigured for the RG in question, the system MUST send an "RG Disconnect" message with an "mLACP Disconnect TLV".
mLACPアプリケーションがデバイスで無効にされているか、問題のRGに対して設定されていない場合、システムは「mLACP Disconnect TLV」を含む「RG Disconnect」メッセージを送信する必要があります。
A system MUST synchronize the configuration of its mLACP-enabled Aggregators and ports with other RG members. This is achieved via the use of "mLACP Aggregator Config TLVs" and "mLACP Port Config TLVs", respectively. An implementation MUST advertise the configuration of Aggregators prior to advertising the configuration of any of their associated member ports.
システムは、そのmLACP対応アグリゲーターとポートの構成を他のRGメンバーと同期させる必要があります。これは、それぞれ「mLACP Aggregator Config TLV」と「mLACP Port Config TLV」を使用することで実現されます。実装は、関連するメンバーポートの構成をアドバタイズする前に、アグリゲーターの構成をアドバタイズする必要があります。
The PEs in an RG MUST all agree on the MAC address to be associated with a given Aggregator. It is possible to achieve this via consistent configuration on member PEs. However, in order to protect against possible misconfiguration, a system MUST use, for any given Aggregator, the MAC address supplied by the PE with the numerically lowest System Aggregation Priority in the RG.
RG内のPEはすべて、特定のアグリゲーターに関連付けられるMACアドレスに同意する必要があります。これは、メンバーPEでの一貫した構成によって実現できます。ただし、構成ミスの可能性を防ぐために、システムは、特定のアグリゲーターに対して、RGで数値的に最も低いシステムアグリゲーション優先順位を持つPEによって提供されたMACアドレスを使用する必要があります。
A system that receives an "mLACP Aggregator Config TLV" with an ROID-to-Key association that is different from its local association MUST reject the corresponding TLV and disable the Aggregator with the same ROID. Furthermore, it SHOULD raise an alarm to alert the operator. Similarly, a system that receives a "NAK TLV" in response to a transmitted "mLACP Aggregator Config TLV" MUST disable the associated Aggregator and SHOULD raise an alarm to alert the network operator.
ローカルアソシエーションとは異なるROIDとキーの関連付けを持つ「mLACP Aggregator Config TLV」を受信するシステムは、対応するTLVを拒否し、同じROIDでアグリゲーターを無効にする必要があります。さらに、それはオペレーターに警告するためにアラームを発する必要があります。同様に、送信された「mLACP Aggregator Config TLV」に応答して「NAK TLV」を受信するシステムは、関連付けられたAggregatorを無効にし、ネットワークオペレーターに警告するアラームを発生させる必要があります。
A system MAY enforce a restriction that all ports that are to be bundled together on a given PE share the same Port Priority value. If so, the system MUST advertise this common priority in the "mLACP Aggregator Config TLV" and assert the "Priority Set" flag in that TLV. Furthermore, the system in this case MUST NOT advertise individual Port Priority values in the associated "mLACP Port Config TLVs" (i.e., the "Priority Set" flag in these TLVs should be 0).
システムは、特定のPEで一緒にバンドルされるすべてのポートが同じポートプライオリティ値を共有するという制限を実施する場合があります。その場合、システムは「mLACP Aggregator Config TLV」でこの共通の優先順位を通知し、そのTLVで「優先順位セット」フラグをアサートする必要があります。さらに、この場合のシステムは、関連付けられた「mLACP Port Config TLV」の個々のポートプライオリティ値をアドバタイズしてはなりません（つまり、これらのTLVの「Priority Set」フラグは0である必要があります）。
A system MAY support individual Port Priority values to be configured on ports that are to be bundled together on a PE. If so, the system MUST advertise the individual Port Priority values in the appropriate "mLACP Port Config TLVs" and MUST NOT assert the "Priority Set" flag in the corresponding "mLACP Aggregator Config TLV".
システムは、PEで一緒にバンドルされるポートに設定される個々のポートプライオリティ値をサポートする場合があります。その場合、システムは適切な「mLACP Port Config TLV」で個々のポートプライオリティ値をアドバタイズしなければならず、対応する「mLACP Aggregator Config TLV」で「Priority Set」フラグをアサートしてはなりません。
When the configurations of all ports for member links associated with a given Aggregator have been sent by a device, it asserts that fact by setting the "Synchronized" flag in the last port's "mLACP Port Config TLV". If an Aggregator doesn't have any candidate member ports configured, this is indicated by asserting the "Synchronized" flag in its "mLACP Aggregator Config TLV".
特定のAggregatorに関連付けられたメンバーリンクのすべてのポートの構成がデバイスによって送信された場合、最後のポートの「mLACP Port Config TLV」に「Synchronized」フラグを設定することにより、その事実を表明します。 Aggregatorに候補のメンバーポートが構成されていない場合、これはその「mLACP Aggregator Config TLV」の「Synchronized」フラグをアサートすることで示されます。
Furthermore, for a given port/Aggregator, an implementation MUST advertise the port/Aggregator configuration prior to advertising its state (via the "mLACP Port State TLV" or "mLACP Aggregator State TLV"). If a PE receives an "mLACP Port State TLV" or "mLACP Aggregator State TLV" for a port or Aggregator that it had not previously learned via an appropriate "Port Config TLV" or "Aggregator Config TLV", then the PE MUST request synchronization of the configuration and state of all mLACP ports as well as all mLACP Aggregators from its respective peer. During a synchronization (solicited or unsolicited), if a PE receives a "State TLV" for a port or Aggregator that it has not learned before, then the PE MUST send a "NAK TLV" for the offending TLV. The PE MUST NOT request resynchronization in this case.
さらに、特定のポート/アグリゲーターについて、実装はその状態をアドバタイズする前にポート/アグリゲーター構成をアドバタイズする必要があります（「mLACPポートステートTLV」または「mLACPアグリゲーターステートTLV」を介して）。 PEが、適切な「Port Config TLV」または「Aggregator Config TLV」を介して以前に学習していないポートまたはアグリゲーターの「mLACP Port State TLV」または「mLACP Aggregator State TLV」を受信した場合、PEは同期を要求する必要があります。それぞれのピアからのすべてのmLACPポートおよびすべてのmLACPアグリゲーターの構成と状態の。同期中（送信請求または非送信請求）、PEが以前に学習したことがないポートまたはアグリゲーターの「状態TLV」を受信した場合、PEは問題のあるTLVの「NAK TLV」を送信する必要があります。この場合、PEは再同期を要求してはならない（MUST NOT）。
When mLACP is unconfigured on a port/Aggregator, a PE MUST send a "Port/Aggregator Config TLV" with the "Purge Configuration" flag asserted. This allows receiving PEs to purge any state maintained for the decommissioned port/Aggregator. If a PE receives a "Port/Aggregator Config TLV" with the "Purge Configuration" flag asserted and the PE is not maintaining any state for that port/Aggregator, then it MUST silently discard the TLV.
mLACPがポート/アグリゲーターで構成解除されている場合、PEは、「パージ構成」フラグがアサートされた「ポート/アグリゲーター構成TLV」を送信する必要があります。これにより、受信したPEは、廃止されたポート/アグリゲーターに対して維持されている状態をすべて削除できます。 PEが「Purge Configuration」フラグがアサートされた「Port / Aggregator Config TLV」を受信し、PEがそのポート/ Aggregatorの状態を維持していない場合は、TLVをサイレントに破棄する必要があります。
PEs within an RG need to synchronize their state machines for proper mLACP operation with a multi-homed device. This is achieved by having each system advertise its Aggregators and ports running state in "mLACP Aggregator State TLVs" and "mLACP Port State TLVs", respectively. Whenever any LACP parameter for an Aggregator or a port -- whether on the Partner (i.e., multi-homed device) side or the Actor (i.e., PE) side -- is changed, a system MUST transmit an updated TLV for the affected Aggregator and/or port. Moreover, when the administrative or operational state of an Aggregator or port changes, the system MUST transmit an updated Aggregator or Port State TLV to its peers.
RG内のPEは、マルチホームデバイスとの適切なmLACP動作のために、ステートマシンを同期する必要があります。これは、各システムにそれぞれ「mLACPアグリゲーター状態TLV」および「mLACPポート状態TLV」でアグリゲーターとポートの実行状態を通知させることで実現されます。アグリゲーターまたはポートのLACPパラメーター（パートナー（マルチホームデバイス）側またはアクター（PE）側のいずれか）が変更された場合、システムは影響を受けるアグリゲーターの更新されたTLVを送信する必要がありますおよび/またはポート。さらに、アグリゲーターまたはポートの管理または運用状態が変化した場合、システムは更新されたアグリゲーターまたはポート状態TLVをそのピアに送信する必要があります。
If a PE receives an Aggregator or Port State TLV where the Actor Key doesn't match what was previously received in a corresponding "Aggregator Config TLV" or "Port Config TLV", the PE MUST then request synchronization of the configuration and state of the affected Aggregator or port. If such a mismatch occurs between the Config and State TLVs as part of a synchronization (solicited or unsolicited), then the PE MUST send a "NAK TLV" for the "State TLV". Furthermore, if a PE receives a "Port State TLV" with the "Aggregator ID" set to a value that doesn't map to some Aggregator that the PE had learned via a previous "Aggregator Config TLV", then the PE MUST request synchronization of the configuration and state of all Aggregators and ports. If the above anomaly occurs during a synchronization, then the PE MUST send a "NAK TLV" for the offending "Port State TLV".
PEがアグリゲーターまたはポート状態TLVを受信し、アクターキーが対応する「アグリゲーター構成TLV」または「ポート構成TLV」で以前に受信したものと一致しない場合、PEは構成と状態の同期を要求する必要があります。影響を受けるアグリゲーターまたはポート。そのような不一致が同期の一部としてConfig TLVとState TLVの間で発生した場合（送信請求または非送信請求）、PEは「State TLV」の「NAK TLV」を送信する必要があります。さらに、PEが「ポート状態TLV」を受信した場合、「Aggregator ID」は、PEが以前の「Aggregator Config TLV」を介して学習した一部のAggregatorにマップしない値に設定されている場合、PEは同期を要求する必要があります。すべてのアグリゲーターとポートの構成と状態の。同期中に上記の異常が発生した場合、PEは問題のある「ポート状態TLV」に対して「NAK TLV」を送信する必要があります。
A PE MAY request that its peer retransmit previously advertised state. This is useful, for example, when the PE is recovering from a soft failure and attempting to relearn state. To request such retransmissions, a PE MUST send a set of one or more "mLACP Synchronization Request TLVs".
PEは、そのピアが以前にアドバタイズされた状態を再送信することを要求できます。これは、たとえば、PEがソフト障害から回復して状態の再学習を試みている場合に役立ちます。そのような再送信を要求するには、PEは1つ以上の「mLACP同期要求TLV」のセットを送信する必要があります。
A PE MUST respond to an "mLACP Synchronization Request TLV" by sending the requested data in a set of one or more mLACP TLVs delimited by a pair of "mLACP Synchronization Data TLVs". The TLVs comprising the response MUST be ordered in the "RG Application Data" message(s) such that the "Synchronization Response TLV" with the "Synchronization Data Start" flag precedes the various other mLACP TLVs encoding the requested data. These, in turn, MUST precede the "Synchronization Data TLV" with the "Synchronization Data End" flag. Note that the response may span multiple "RG Application Data" messages -- for example, when MTU limits are exceeded; however, the above ordering MUST be retained across messages, and only a single pair of "Synchronization Data TLVs" MUST be used to delimit the response across all "Application Data" messages.
PEは、「mLACP同期データTLV」のペアで区切られた1つ以上のmLACP TLVのセットで要求されたデータを送信することにより、「mLACP同期要求TLV」に応答する必要があります。応答を構成するTLVは、「RG Application Data」メッセージで「同期データ開始」フラグの付いた「同期応答TLV」が、要求されたデータをエンコードする他のさまざまなmLACP TLVの前に来るように順序付けする必要があります。次に、これらは「同期データTLV」の前に「同期データ終了」フラグを付けなければなりません。応答は、たとえばMTU制限を超えた場合など、複数の「RG Application Data」メッセージにまたがることがあることに注意してください。ただし、上記の順序はメッセージ全体で維持する必要があり、「同期データTLV」のペアを1つだけ使用して、すべての「アプリケーションデータ」メッセージ全体で応答を区切る必要があります。
A PE device MAY re-advertise its mLACP state in an unsolicited manner. This is done by sending the appropriate Config and State TLVs delimited by a pair of "mLACP Synchronization Data TLVs" and using a "Request Number" of 0.
PEデバイスは、未承諾の方法でそのmLACP状態を再アドバタイズできます（MAY）。これは、「mLACP同期データTLV」のペアで区切られた適切な構成および状態TLVを送信し、0の「リクエスト番号」を使用して行われます。
While a PE has a pending synchronization request for a system, Aggregator, or port, it SHOULD silently ignore all TLVs for said system, Aggregator, or port that are received prior to the synchronization response and that carry the same type of information being requested. This saves the system from the burden of updating state that will ultimately be overwritten by the synchronization response. Note that TLVs pertaining to other systems, Aggregators, or ports are to continue to be processed per normal procedures in this case.
PEには、システム、アグリゲーター、またはポートに対する保留中の同期要求がありますが、同期応答の前に受信され、要求されている同じタイプの情報を運ぶ、そのシステム、アグリゲーター、またはポートのすべてのTLVを黙って無視する必要があります。これにより、最終的に同期応答によって上書きされる状態を更新する負担からシステムが節約されます。この場合、他のシステム、アグリゲーター、またはポートに関連するTLVは、通常の手順に従って処理され続けることに注意してください。
If a PE receives a synchronization request for an Aggregator, port, or key that doesn't exist or is not known to the PE, then it MUST trigger an unsolicited synchronization of all system, Aggregator, and port information (i.e., replay the initialization sequence).
PEが、存在しないか、PEに認識されていないアグリゲーター、ポート、またはキーの同期要求を受信した場合、すべてのシステム、アグリゲーター、およびポート情報の非送信請求同期をトリガーする必要があります（つまり、初期化を再生します）シーケンス）。
If a PE learns, as part of a synchronization operation from its peer, that the latter is advertising a Node ID value that is different from the value previously advertised, then the PE MUST purge all Port/Aggregator data previously learned from that peer prior to the last synchronization.
PEが、ピアからの同期操作の一部として、以前にアドバタイズされた値とは異なるノードID値をアドバタイズしていることを学習した場合、PEは、以前にそのピアから以前に学習したすべてのポート/アグリゲーターデータをパージする必要があります。最後の同期。
When a PE that is active for a multi-chassis link aggregation group encounters a core isolation fault, it SHOULD attempt to fail over to a peer PE that hosts the same RO. The default failover procedure is to have the failed PE bring down the link or links towards the multi-homed CE (e.g., by bringing down the line protocol). This will cause the CE to fail over to the other member link or links of the bundle that are connected to the other PE(s) in the RG. Other procedures for triggering failover are possible; such procedures are outside the scope of this document.
マルチシャーシリンク集約グループでアクティブなPEがコア分離障害に遭遇した場合、同じROをホストするピアPEへのフェイルオーバーを試行する必要があります（SHOULD）。デフォルトのフェイルオーバー手順では、障害が発生したPEがリンクを1つまたは複数のマルチホームCEに向けて（たとえば、ラインプロトコルを停止することによって）停止します。これにより、CEは、RG内の他のPEに接続されているバンドルの他のメンバーリンクにフェールオーバーします。フェイルオーバーをトリガーする他の手順が可能です。そのような手順は、このドキュメントの範囲外です。
Upon recovery from a previous fault, a PE MAY reclaim the active role for a multi-chassis link aggregation group if configured for revertive protection. Otherwise, the recovering PE may assume the standby role when configured for non-revertive protection. In the revertive scenario, a PE SHOULD assume the active role within the RG by sending an "mLACP Port Priority TLV" to the currently active PE, requesting that the latter change its port priority to a value that is lower (i.e., numerically larger) for the Aggregator in question.
以前の障害から回復すると、リバーティブ保護用に構成されている場合、PEはマルチシャーシリンクアグリゲーショングループのアクティブな役割を再利用できます。そうしないと、復元するPEが非復元保護用に構成されている場合、スタンバイの役割を引き受けることがあります。リバーティブシナリオでは、PEは「mLACPポートプライオリティTLV」を現在アクティブなPEに送信することにより、RG内でアクティブな役割を引き受ける必要があります。後者は、ポートプライオリティを低い値（つまり、数値的に大きい値）に変更するように要求します。問題のアグリゲーターのために。
If a system is operating in a mode where different ports of a bundle are configured with different Port Priorities, then the system MUST NOT advertise or request changes of Port Priority values for aggregated ports collectively (i.e., by using a "Port Number" of 0 in the "mLACP Port Priority TLV"). This is to avoid ambiguity in the interpretation of the "Last Port Priority" field.
バンドルの異なるポートが異なるポートプライオリティで設定されているモードでシステムが動作している場合、システムは集約されたポートのポートプライオリティ値の変更をまとめてアドバタイズまたはリクエストしてはなりません（つまり、「ポート番号」を0にして） 「mLACP Port Priority TLV」）。これは、「Last Port Priority」フィールドの解釈のあいまいさを回避するためです。
If a PE receives an "mLACP Port Priority TLV" requesting a priority change for a port or Aggregator that is not local to the device, then the PE MUST re-advertise the local configuration of the system, as well as the configuration and state of all of its mLACP ports and Aggregators.
PEが、デバイスに対してローカルではないポートまたはアグリゲーターの優先度の変更を要求する「mLACPポートプライオリティTLV」を受信した場合、PEは、システムのローカル構成、および構成と状態を再アドバタイズしなければなりません（MUST）。そのすべてのmLACPポートとアグリゲーター。
If a PE receives an "mLACP Port Priority TLV" in which the remote system is advertising priority change for a port or Aggregator that the local PE had not previously learned via an appropriate "Port Config TLV" or "Aggregator Config TLV", then the PE MUST request synchronization of the configuration and state of all mLACP ports as well as all mLACP Aggregators from its respective peer.
PEが「mLACPポートプライオリティTLV」を受信した場合、リモートシステムは、ローカルPEが適切な「ポート構成TLV」または「アグリゲーター構成TLV」を介して以前に学習しなかったポートまたはアグリゲーターの優先度の変更をアドバタイズします。 PEは、対応するピアからのすべてのmLACPポートとすべてのmLACPアグリゲータの構成と状態の同期を要求する必要があります。
ICCP SHOULD only be used in well-managed and highly monitored networks. It ought not be deployed on or over the public Internet. ICCP is not intended to be applicable when the Redundancy Group spans PEs in different administrative domains.
ICCPは、適切に管理され、高度に監視されたネットワークでのみ使用する必要があります（SHOULD）。公衆インターネット上またはそれを介して展開すべきではありません。 ICCPは、冗長グループが異なる管理ドメインのPEにまたがる場合に適用されることを意図していません。
The security considerations described in [RFC5036] and [RFC4447] that apply to the base LDP specification and to the PW LDP control protocol extensions apply to the capability mechanism described in this document. In particular, ICCP implementations MUST provide a mechanism to select to which LDP peers the ICCP capability will be advertised, and from which LDP peers the ICCP messages will be accepted. Therefore, an incoming ICCP connection request MUST NOT be accepted unless its source IP address is known to be the source of an "eligible" ICCP peer. The set of eligible peers could be preconfigured (as a list of either IP addresses or address/mask combinations), or it could be discovered dynamically via some secure discovery protocol. The TCP Authentication Option (TCP-AO), as defined in [RFC5925], SHOULD be used. This provides integrity and authentication for the ICCP messages and eliminates the possibility of source address spoofing. However, for backwards compatibility and/or to accommodate the ease of migration, the LDP MD5 authentication key option, as described in Section 2.9 of [RFC5036], MAY be used instead.
[RFC5036]および[RFC4447]で説明されているセキュリティの考慮事項は、ベースLDP仕様とPW LDP制御プロトコル拡張に適用され、このドキュメントで説明されている機能メカニズムに適用されます。特に、ICCP実装は、どのLDPピアにICCP機能をアドバタイズするか、どのLDPピアからICCPメッセージを受け入れるかを選択するメカニズムを提供する必要があります。したがって、着信ICCP接続要求は、そのソースIPアドレスが「適格」なICCPピアのソースであることがわかっている場合を除いて、受け入れてはなりません（MUST NOT）。適格なピアのセットは、（IPアドレスまたはアドレス/マスクの組み合わせのリストとして）事前構成することも、安全な検出プロトコルを介して動的に検出することもできます。 [RFC5925]で定義されているTCP認証オプション（TCP-AO）を使用する必要があります（SHOULD）。これによりICCPメッセージの整合性と認証が提供され、送信元アドレスのスプーフィングの可能性がなくなります。ただし、下位互換性や移行を容易にするために、[RFC5036]のセクション2.9で説明されているLDP MD5認証キーオプションを代わりに使用できます。
The security framework and considerations for MPLS in general, and LDP in particular, as described in [RFC5920] apply to this document. Moreover, the recommendations of [RFC6952] and mechanisms of [LDP-CRYPTO] aimed at addressing LDP's vulnerabilities are applicable as well.
[RFC5920]で説明されている一般的なMPLS、特にLDPのセキュリティフレームワークと考慮事項は、このドキュメントに適用されます。さらに、LDPの脆弱性に対処することを目的とした[RFC6952]の推奨事項と[LDP-CRYPTO]のメカニズムも適用できます。
Furthermore, activity on the attachment circuits may cause security threats or be exploited to create denial-of-service attacks. For example, a malicious CE implementation may trigger continuously varying LACP messages that lead to excessive ICCP exchanges. Also, excessive link bouncing of the attachment circuits may lead to the same effect. Similar arguments apply to the inter-PE MPLS links. Implementations SHOULD provide mechanisms to perform control-plane policing and mitigate these types of attacks.
さらに、接続回路でのアクティビティは、セキュリティの脅威を引き起こしたり、サービス拒否攻撃を作成するために悪用される可能性があります。たとえば、悪意のあるCEの実装により、継続的に変化するLACPメッセージがトリガーされ、過剰なICCP交換が発生する可能性があります。また、接続回路の過度のリンクバウンスも同じ効果をもたらす可能性があります。同様の引数が、PE間MPLSリンクに適用されます。実装は、コントロールプレーンポリシングを実行し、これらのタイプの攻撃を軽減するメカニズムを提供する必要があります（SHOULD）。
Implementations SHOULD generally minimize the number of parameters required to configure ICCP in order to help make ICCP easier to use. Implementations SHOULD allow the user to control the RGID via configuration, as this is required to support flexible grouping of PEs in RGs. Furthermore, implementations SHOULD provide mechanisms to troubleshoot the correct operation of ICCP; this includes providing mechanisms to diagnose ICCP connections as well as Application Connections. Implementations MUST provide a means for the user to indicate the IP addresses of remote PEs that are to be members of a given RG. Automatic discovery of RG membership MAY be supported; this topic is outside the scope of this specification.
実装では、一般にICCPを使いやすくするためにICCPの構成に必要なパラメータの数を最小限に抑える必要があります。実装では、RG内のPEの柔軟なグループ化をサポートする必要があるため、ユーザーは構成を介してRGIDを制御できるようにする必要があります（SHOULD）。さらに、実装はICCPの正しい動作をトラブルシューティングするメカニズムを提供する必要があります。これには、アプリケーション接続だけでなくICCP接続を診断するメカニズムの提供も含まれます。実装は、ユーザーが特定のRGのメンバーになるリモートPEのIPアドレスを示す手段を提供する必要があります。 RGメンバーシップの自動検出がサポートされる場合があります。このトピックはこの仕様の範囲外です。
This document uses several new LDP message types. IANA maintains the "Message Type Name Space" registry as defined by [RFC5036]. The following values have been assigned:
このドキュメントでは、いくつかの新しいLDPメッセージタイプを使用します。 IANAは、[RFC5036]で定義されている「メッセージタイプ名前空間」レジストリを維持します。以下の値が割り当てられています。
Message Type Description
------------- ----------------------------
0x0700 RG Connect Message
0x0701 RG Disconnect Message
0x0702 RG Notification Message
0x0703 RG Application Data Message
0x0704-0x070F Reserved for future ICCP use
This document uses a new LDP TLV type. IANA maintains the "TLV Type Name Space" registry as defined by [RFC5036]. The following value has been assigned:
このドキュメントでは、新しいLDP TLVタイプを使用しています。 IANAは、[RFC5036]で定義されている「TLV Type Name Space」レジストリを維持しています。次の値が割り当てられています。
TLV Type Description
-------- -------------------
0x0700 ICCP capability TLV
IANA has created a registry called "ICC RG Parameter Types", within the "Pseudowire Name Spaces (PWE3)" registry. ICC RG parameter types are 14-bit values. Parameter Type values 1 through 0x003A are specified in this document. Parameter Type values 0x003B through 0x1FFF are to be assigned by IANA, using the "Expert Review" policy defined in [RFC5226]. Parameter Type values 0x2000 through 0x2FFF, 0x3FFF, and 0 are to be allocated using the "IETF Review" policy defined in [RFC5226]. Parameter Type values 0x3000 through 0x3FFE are reserved for vendor proprietary extensions and are to be assigned by IANA, using the "First Come First Served" policy defined in [RFC5226].
IANAは、「疑似配線名前空間（PWE3）」レジストリー内に、「ICC RGパラメーター・タイプ」と呼ばれるレジストリーを作成しました。 ICC RGパラメータタイプは14ビット値です。このドキュメントでは、パラメータタイプ値1〜0x003Aが指定されています。パラメータタイプ値0x003B〜0x1FFFは、[RFC5226]で定義されている「エキスパートレビュー」ポリシーを使用して、IANAによって割り当てられます。パラメータタイプ値0x2000〜0x2FFF、0x3FFF、および0は、[RFC5226]で定義されている「IETFレビュー」ポリシーを使用して割り当てられます。パラメータタイプ値0x3000から0x3FFEはベンダー独自の拡張用に予約されており、[RFC5226]で定義されている「先着順」ポリシーを使用して、IANAによって割り当てられます。
Initial ICC parameter type space value allocations are specified below:
初期ICCパラメータタイプのスペース値の割り当てを以下に示します。
Parameter Type Description
-------------- ----------------------------------
0x0001 ICC Sender Name
0x0002 NAK TLV
0x0003 Requested Protocol Version TLV
0x0004 Disconnect Code TLV
0x0005 ICC RG ID TLV
0x0006-0x000F Reserved
0x0010 PW-RED Connect TLV
0x0011 PW-RED Disconnect TLV
0x0012 PW-RED Config TLV
0x0013 Service Name TLV
0x0014 PW ID TLV
0x0015 Generalized PW ID TLV
0x0016 PW-RED State TLV
0x0017 PW-RED Synchronization Request TLV
0x0018 PW-RED Synchronization Data TLV
0x0019 PW-RED Disconnect Cause TLV
0x001A-0x002F Reserved
0x0030 mLACP Connect TLV
0x0031 mLACP Disconnect TLV
0x0032 mLACP System Config TLV
0x0033 mLACP Port Config TLV
0x0034 mLACP Port Priority TLV
0x0035 mLACP Port State TLV
0x0036 mLACP Aggregator Config TLV
0x0037 mLACP Aggregator State TLV
0x0038 mLACP Synchronization Request TLV
0x0039 mLACP Synchronization Data TLV
0x003A mLACP Disconnect Cause TLV
This document uses several new Status codes. IANA maintains the "Status Code Name Space" registry as defined by [RFC5036]. The following values have been assigned; the "E" column is the required setting of the Status Code E-bit.
このドキュメントでは、いくつかの新しいステータスコードを使用しています。 IANAは、[RFC5036]で定義されている「ステータスコード名前空間」レジストリを維持しています。次の値が割り当てられています。 「E」列は、ステータスコードEビットの必須設定です。
Range/Value E Description
------------ ----- ------------------------------------------
0x00010001 0 Unknown ICCP RG
0x00010002 0 ICCP Connection Count Exceeded
0x00010003 0 ICCP Application Connection Count Exceeded
0x00010004 0 ICCP Application not in RG
0x00010005 0 Incompatible ICCP Protocol Version
0x00010006 0 ICCP Rejected Message
0x00010007 0 ICCP Administratively Disabled
0x00010010 0 ICCP RG Removed
0x00010011 0 ICCP Application Removed from RG
The authors wish to acknowledge the important contributions of Dennis Cai, Neil McGill, Amir Maleki, Dan Biagini, Robert Leger, Sami Boutros, Neil Ketley, and Mark Christopher Sains.
著者は、デニス・カイ、ニール・マギル、アミール・マレキ、ダン・ビアジーニ、ロバート・レジェ、サミ・ブトロス、ニール・ケトリー、マーク・クリストファー・サインの重要な貢献に感謝したいと思います。
The authors also thank Daniel Cohn, Lizhong Jin, and Ran Chen for their valuable input, discussions, and comments.
著者はまた、Daniel Cohn、Lizhong Jin、Ran Chenの貴重な意見、議論、コメントに感謝します。
[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月。
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, October 2007.
[RFC5036] Andersson、L.、Ed。、Minei、I.、Ed。、and B. Thomas、Ed。、 "LDP Specification"、RFC 5036、October 2007。
[RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL. Le Roux, "LDP Capabilities", RFC 5561, July 2009.
[RFC5561]トーマス、B。、ラザ、K。、アガーワル、S。、アガーワル、R。、およびJL。 Le Roux、「LDP Capabilities」、RFC 5561、2009年7月。
[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。、Rosen、E.、El-Aawar、N.、Smith、T.、and G. Heron、 "Pseudowire Setup and Maintenance Using the Label Distribution Protocol（LDP）"、RFC 4447 、2006年4月。
[IEEE-802.1AX] IEEE Std. 802.1AX-2008, "IEEE Standard for Local and metropolitan area networks--Link Aggregation", IEEE Computer Society, November 2008.
[IEEE-802.1AX] IEEE Std。 802.1AX-2008、「IEEE Standard for Local and Metropolitan Area Networks-Link Aggregation」、IEEE Computer Society、2008年11月。
[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000.
[RFC2863] McCloghrie、K。およびF. Kastenholz、「The Interfaces Group MIB」、RFC 2863、2000年6月。
[RFC6870] Muley, P., Ed., and M. Aissaoui, Ed., "Pseudowire Preferential Forwarding Status Bit", RFC 6870, February 2013.
[RFC6870] Muley、P。、編、およびM. Aissaoui、編、「Pseudowire優先転送ステータスビット」、RFC 6870、2013年2月。
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010.
[RFC5920] Fang、L。、編、「MPLSおよびGMPLSネットワークのセキュリティフレームワーク」、RFC 5920、2010年7月。
[RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of BGP, LDP, PCEP, and MSDP Issues According to the Keying and Authentication for Routing Protocols (KARP) Design Guide", RFC 6952, May 2013.
[RFC6952] Jethanandani、M.、Patel、K。、およびL. Zheng、「BGP、LDP、PCEP、およびMSDPの分析によるルーティングプロトコルのキーイングおよび認証（KARP）設計ガイド」、RFC 6952、5月2013。
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, June 2010.
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, June 2010.
[RFC2922] Bierman, A. and K. Jones, "Physical Topology MIB", RFC 2922, September 2000.
[RFC2922] Bierman、A。およびK. Jones、「Physical Topology MIB」、RFC 2922、2000年9月。
[RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual Private Network (VPN) Terminology", RFC 4026, March 2005.
[RFC4026] Andersson、L.およびT. Madsen、「Provider Provisioned Virtual Private Network（VPN）Terminology」、RFC 4026、2005年3月。
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, June 2010.
[RFC5880] Katz、D。およびD. Ward、「Bidirectional Forwarding Detection（BFD）」、RFC 5880、2010年6月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629] Yergeau、F。、「UTF-8、ISO 10646の変換フォーマット」、STD 63、RFC 3629、2003年11月。
[LDP-CRYPTO] Zheng, L., Chen, M., and M. Bhatia, "LDP Hello Cryptographic Authentication", Work in Progress, June 2014.
[LDP-CRYPTO] Zheng、L.、Chen、M。、およびM. Bhatia、「LDP Hello Cryptographic Authentication」、Work in Progress、2014年6月。
Authors' Addresses
著者のアドレス
Luca Martini Cisco Systems, Inc. 9155 East Nichols Avenue, Suite 400 Englewood, CO 80112 United States EMail: lmartini@cisco.com
Luca Martini Cisco Systems, Inc. 9155 East Nichols Avenue, Suite 400 Englewood, CO 80112 United States EMail: lmartini@cisco.com
Samer Salam Cisco Systems, Inc. 595 Burrard Street, Suite 2123 Vancouver, BC V7X 1J1 Canada EMail: ssalam@cisco.com
Samer Salam Cisco Systems、Inc. 595 Burrard Street、Suite 2123 Vancouver、BC V7X 1J1 Canada EMail：ssalam@cisco.com
Ali Sajassi Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 United States EMail: sajassi@cisco.com
Ali Sajassi Cisco Systems、Inc. 170 West Tasman Drive San Jose、CA 95134アメリカ合衆国Eメール：sajassi@cisco.com
Matthew Bocci Alcatel-Lucent Voyager Place Shoppenhangers Road Maidenhead Berks, SL6 2PJ UK EMail: matthew.bocci@alcatel-lucent.com
Matthew Bocci Alcatel-Lucent Voyager Place Shoppenhangers Road Maidenhead Berks、SL6 2PJ UKメール：matthew.bocci@alcatel-lucent.com
Satoru Matsushima Softbank Telecom 1-9-1, Higashi-Shinbashi, Minato-ku Tokyo 105-7304 Japan EMail: satoru.matsushima@g.softbank.co.jp
Satoru Matsushima Softbank Telecom 1-9-1, Higashi-Shinbashi, Minato-ku Tokyo 105-7304 Japan EMail: satoru.matsushima@g.softbank.co.jp
Thomas Nadeau Brocade EMail: tnadeau@brocade.com
トーマスナドーブロケードEメール：tnadeau@brocade.com