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
        
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.

本文档指定了机箱间通信协议(ICCP),该协议为虚拟专用线服务(VPWS)和虚拟专用局域网服务(VPLS)应用程序启用提供商边缘(PE)设备冗余。该协议在一组两个或多个PE内运行,形成一个冗余组,以便在系统之间同步数据。它容纳多机箱连接电路冗余机制以及伪线冗余机制。

Status of This Memo

关于下段备忘

This is an Internet Standards Track document.

这是一份互联网标准跟踪文件。

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)的产品。它代表了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.

版权所有(c)2014 IETF信托基金和确定为文件作者的人员。版权所有。

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)自本文件出版之日起生效。请仔细阅读这些文件,因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本,并提供简化BSD许可证中所述的无担保。

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标准流程之外修改本文件,也不得在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
        
   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
        
      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
        
1. Introduction
1. 介绍

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)的任务关键型应用程序的客户签订的合同协议规定的潜在处罚。任何运营商网络都是如此,采用第二层虚拟专用网(L2VPN)技术的网络也不例外。通过采用机箱内和机箱间冗余机制,可以实现高度的网络可用性。本文件的重点是后者。本文档定义了机箱间通信协议(ICCP),该协议允许在构成冗余组(RG)的两个或多个提供商边缘节点(PE)之间同步状态和配置数据。该协议支持多机箱冗余机制,可用于连接电路或伪线(PWs)。术语“机箱”的正式定义见[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中的PEs之间运行标签分发协议(LDP)是正常的,并且LDP组件在任何情况下都将出现在PEs上,以建立和维护伪线。因此,ICCP被构建为在LDP内运行的二级协议,并利用LDP会话机制以及LDP运行所必需的底层TCP传输机制和基于TCP的安全机制。

2. Specification of Requirements
2. 需求说明

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].

本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。

3. ICCP Overview
3. ICCP概述
3.1. Redundancy Model and Topology
3.1. 冗余模型与拓扑

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

本文档的重点是PE节点冗余。假设操作员指定一组两个或多个PE节点以形成RG。RG的成员属于单一管理(例如,服务提供商),并对任何给定服务实例的访问(连接电路或访问伪线)和/或核心(伪线)采用公共冗余机制。然而,RG的成员可以为不相交的服务使用不同的冗余机制。PE设备可以提供任何类型的L2VPN服务,即虚拟专用线服务(VPWS)或虚拟专用LAN服务(VPLS)。实际上

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.

事实上,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中的PEs提供到单个设备(例如,客户边缘(CE)、数字用户线接入多路复用器(DSLAM))或整个网络(例如,接入网络)的多宿连接。下面的图1描述了该模型。

                                    +=================+
                                    |                 |
   Multi-homed         +----+       |  +-----+        |
   Node  ------------> | CE |-------|--| PE1 ||<------|---Pseudowire-->|
                       |    |--+   -|--|     ||<------|---Pseudowire-->|
                       +----+  |  / |  +-----+        |
                               | /  |     ||          |
                               |/   |     || ICCP     |--> Towards Core
              +-------------+  /    |     ||          |
              |             | /|    |  +-----+        |
              |    Access   |/ +----|--| PE2 ||<------|---Pseudowire-->|
              |   Network   |-------|--|     ||<------|---Pseudowire-->|
              |             |       |  +-----+        |
              |             |       |                 |
              +-------------+       |   Redundancy    |
                ^                   |     Group       |
                |                   +=================+
                |
         Multi-homed Network
        
                                    +=================+
                                    |                 |
   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所示的拓扑中,用于接入节点/网络的冗余机制可以是多种技术中的一种,例如,它可以是具有链路聚合控制协议(LACP)的IEEE 802.1AX链路聚合组或同步光网络自动保护交换(SONET APS)。该机制的具体内容超出了本文件的范围。然而,假设RG中的PEs需要彼此通信,以便接入冗余机制正确工作。因此,需要运行RG中PEs之间的机箱间通信协议,以便同步配置和/或运行状态数据。

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

此外,机箱间通信信道的存在允许简化伪线冗余机制。这主要是因为它允许RG内的PEs运行一些仲裁算法,以选择给定服务实例的伪线应处于活动或备用模式。PEs可以

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.

然后将仲裁结果通告给远程终端PE,而不是必须将握手过程嵌入到伪线冗余状态通信机制以及每一个其他可能的第2层状态通信机制中。

3.2. ICCP Interconnect Scenarios
3.2. ICCP互连方案

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.

在本节中提到“互连”时,我们关注的是机箱间通信协议消息传输的链路或网络,而不是PEs之间的正常数据通信。作为RG成员的PEs可以是物理上同一位置的,也可以是地理上冗余的。此外,要在其上运行ICCP的PEs之间的物理互连可以包括专用背靠背链路或通过分组交换网络(PSN)(例如MPLS核心网络)的共享连接。这将产生一个由四种互连方案组成的矩阵,如下小节所述。

3.2.1. Co-located Dedicated Interconnect
3.2.1. 共位专用互连

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位于同一物理位置,例如存在点(POP)或中央办公室(co)。此外,专用链路为PEs之间的ICCP提供互连。

             +=================+     +-----------------+
             |CO               |     |                 |
             |  +-----+        |     |                 |
             |  | PE1 |________|_____|                 |
             |  |     |        |     |                 |
             |  +-----+        |     |                 |
             |     ||          |     |                 |
             |     || ICCP     |     |       Core      |
             |     ||          |     |      Network    |
             |  +-----+        |     |                 |
             |  | PE2 |________|_____|                 |
             |  |     |        |     |                 |
             |  +-----+        |     |                 |
             |                 |     |                 |
             +=================+     +-----------------+
        
             +=================+     +-----------------+
             |CO               |     |                 |
             |  +-----+        |     |                 |
             |  | PE1 |________|_____|                 |
             |  |     |        |     |                 |
             |  +-----+        |     |                 |
             |     ||          |     |                 |
             |     || ICCP     |     |       Core      |
             |     ||          |     |      Network    |
             |  +-----+        |     |                 |
             |  | PE2 |________|_____|                 |
             |  |     |        |     |                 |
             |  +-----+        |     |                 |
             |                 |     |                 |
             +=================+     +-----------------+
        

Figure 2: ICCP Co-located PEs Dedicated Interconnect Scenario

图2:ICCP共址PEs专用互连场景

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

鉴于PEs在这种情况下是背靠背连接的,因此可以依靠第2层冗余机制来保证ICCP互连的健壮性。例如,如果

interconnect comprises IEEE 802.3 Ethernet links, it is possible to provide link redundancy by means of IEEE 802.1AX Link Aggregation Groups.

互连包括IEEE 802.3以太网链路,可以通过IEEE 802.1AX链路聚合组提供链路冗余。

3.2.2. Co-located Shared Interconnect
3.2.2. 共位共享互连

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)。但是,与前面的场景不同,PEs之间没有专用链接。ICCP的互连通过PEs连接的核心网络提供。图3描述了这个模型。

              +=================+     +-----------------+
              |CO               |     |                 |
              |  +-----+        |     |                 |
              |  | PE1 |________|_____|                 |
              |  |     |<=================+             |
              |  +-----+   ICCP |     |  ||             |
              |                 |     |  ||             |
              |                 |     |  ||   Core      |
              |                 |     |  ||  Network    |
              |  +-----+        |     |  ||             |
              |  | PE2 |________|_____|  ||             |
              |  |     |<=================+             |
              |  +-----+        |     |                 |
              |                 |     |                 |
              +=================+     +-----------------+
        
              +=================+     +-----------------+
              |CO               |     |                 |
              |  +-----+        |     |                 |
              |  | PE1 |________|_____|                 |
              |  |     |<=================+             |
              |  +-----+   ICCP |     |  ||             |
              |                 |     |  ||             |
              |                 |     |  ||   Core      |
              |                 |     |  ||  Network    |
              |  +-----+        |     |  ||             |
              |  | PE2 |________|_____|  ||             |
              |  |     |<=================+             |
              |  +-----+        |     |                 |
              |                 |     |                 |
              +=================+     +-----------------+
        

Figure 3: ICCP Co-located PEs Shared Interconnect Scenario

图3:ICCP共址PEs共享互连场景

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层机制确保互连的弹性,以防连接故障。例如,可以使用具有快速重路由(FRR)和/或端到端备份LSP的RSVP标签交换路径(LSP)。

3.2.3. Geo-redundant Dedicated Interconnect
3.2.3. 地理冗余专用互连

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位于不同的物理位置,以提供地理冗余。例如,为了防止自然灾害等,这可能是可取的。提供专用互连以连接PEs。这是一个昂贵的选择,尤其是考虑到提供多个这样的链路以实现互连健壮性的可能性时。互连的弹性机制类似于位于同一位置的互连对应物中突出显示的机制。

              +=================+     +-----------------+
              |CO 1             |     |                 |
              |  +-----+        |     |                 |
              |  | PE1 |________|_____|                 |
              |  |     |        |     |                 |
              |  +-----+        |     |                 |
              +=====||==========+     |                 |
                    || ICCP           |       Core      |
              +=====||==========+     |      Network    |
              |  +-----+        |     |                 |
              |  | PE2 |________|_____|                 |
              |  |     |        |     |                 |
              |  +-----+        |     |                 |
              |CO 2             |     |                 |
              +=================+     +-----------------+
        
              +=================+     +-----------------+
              |CO 1             |     |                 |
              |  +-----+        |     |                 |
              |  | PE1 |________|_____|                 |
              |  |     |        |     |                 |
              |  +-----+        |     |                 |
              +=====||==========+     |                 |
                    || ICCP           |       Core      |
              +=====||==========+     |      Network    |
              |  +-----+        |     |                 |
              |  | PE2 |________|_____|                 |
              |  |     |        |     |                 |
              |  +-----+        |     |                 |
              |CO 2             |     |                 |
              +=================+     +-----------------+
        

Figure 4: ICCP Geo-redundant PEs Dedicated Interconnect Scenario

图4:ICCP地理冗余PEs专用互连场景

3.2.4. Geo-redundant Shared Interconnect
3.2.4. 地理冗余共享互连

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的PEs位于不同的物理位置,ICCP的互连通过PEs所连接的PSN网络提供。此互连选项更有可能用于地理冗余,因为与地理冗余专用互连选项相比,它在经济上更具吸引力。可用于保证ICCP传输健壮性的弹性机制为PSN层机制,如上文第3.2.2节所述。

              +=================+     +-----------------+
              |CO 1             |     |                 |
              |  +-----+        |     |                 |
              |  | PE1 |________|_____|                 |
              |  |     |<=================+             |
              |  +-----+   ICCP |     |  ||             |
              +=================+     |  ||             |
                                      |  ||   Core      |
              +=================+     |  ||  Network    |
              |  +-----+        |     |  ||             |
              |  | PE2 |________|_____|  ||             |
              |  |     |<=================+             |
              |  +-----+        |     |                 |
              |CO 2             |     |                 |
              +=================+     +-----------------+
        
              +=================+     +-----------------+
              |CO 1             |     |                 |
              |  +-----+        |     |                 |
              |  | PE1 |________|_____|                 |
              |  |     |<=================+             |
              |  +-----+   ICCP |     |  ||             |
              +=================+     |  ||             |
                                      |  ||   Core      |
              +=================+     |  ||  Network    |
              |  +-----+        |     |  ||             |
              |  | PE2 |________|_____|  ||             |
              |  |     |<=================+             |
              |  +-----+        |     |                 |
              |CO 2             |     |                 |
              +=================+     +-----------------+
        

Figure 5: ICCP Geo-redundant PEs Shared Interconnect Scenario

图5:ICCP地理冗余PEs共享互连场景

3.3. ICCP Requirements
3.3. ICCP要求

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)中的PEs之间的通信提供控制通道。PE节点可位于同一地点或远程(参考上文第3.2节)。使用ICCP服务的客户端应用程序必须仅使用此通道来传输控制信息,而不是数据流量。因此,协议应提供相对较低的带宽、低延迟和高度可靠的消息传输。

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.

二,。ICCP必须适应多个客户端应用程序(例如,多机箱LACP、PW冗余、SONET AP)。这意味着消息应该是可扩展的(例如,基于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中PEs的健康状况。该机制将用于检测PE节点故障(或在共享互连的情况下与MPLS网络隔离),并通知客户端应用程序。应用程序要求该机制根据连接电路(AC)和PW上采用的冗余协议的程序触发故障切换。该解决方案应实现次秒的远程节点丢失检测(~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应提供异步事件驱动的状态更新,独立于定期消息,以便立即通知客户端应用程序的状态更改。换句话说,承载应用程序数据的消息的传输应该是按需的,而不是基于计时器的,以最小化机箱间状态同步延迟。

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.

七,。ICCP必须确保RG中设备之间的传输安全。这在RG成员位于不同物理位置并通过共享网络(例如,PSN)连接的场景中尤其重要。特别是,ICCP不得任意接受来自任何设备的连接;否则,客户端应用程序的状态可能会受到影响。此外,即使ICCP连接请求似乎来自合格的设备,其源地址也可能被伪造。因此,必须采取一些措施防止源地址欺骗。

viii. ICCP MUST allow the operator to statically configure members of an RG. Auto-discovery may be considered in the future.

八,。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.

ICCP应允许灵活的RG成员资格。预计一个RG中只有两个节点将覆盖大多数通用部署的冗余应用程序。ICCP不应排除通过设计支持RG中两个以上的节点。此外,ICCP必须允许单个节点同时成为多个RG的成员。

4. ICC LDP Protocol Extension Specification
4. ICC LDP协议扩展规范

To address the requirements identified in the previous section, ICCP is modeled to comprise three layers:

为了满足上一节中确定的需求,ICCP建模为包括三层:

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

i. 应用层:它为使用ICCP服务的各种冗余应用程序提供接口。ICCP负责定义公共连接管理过程和在该层交换的消息格式;然而,除此之外,它没有施加任何限制

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的范围。这保证了实现的互操作性,而不会对内部设计细节施加任何不必要的约束。

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.

二,。机箱间通信(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.

三、传输层:该层提供实际的ICCP报文传输。它负责寻址、路由解析、流控制、可靠有序的消息传递、连接弹性/冗余,以及PE节点故障检测。传输层可能不同,这取决于互连的物理层。

4.1. LDP ICCP Capability Advertisement
4.1. LDP ICCP能力广告

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].

当在特定PE上启用RG时,必须创建到该RG中每个远程PE的LDP会话(如果还不存在)。然后,必须向该RG中的所有LDP对等方公布支持ICCP的能力。这是通过使用[RFC5561]中描述的方法并宣传“ICCP能力TLV”实现的。如果LDP对等方支持动态能力通告,则当PE上启用第一个RG时,可通过发送新的能力消息,其中S位设置为“ICCP能力TLV”。如果对等方不支持动态能力播发,则“ICCP TLV”必须包含在LDP初始化过程中的能力参数[RFC5561]中。

4.2. RG Membership Management
4.2. RG会员管理

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的成员时,它将首先向其对等方公布ICCP功能。随后,PE将“RG Connect”消息发送给也已公布ICCP能力的对等方。PE然后等待对等方发送他们自己的“RG Connect”消息,如果他们还没有这样做的话。对于给定的RG,只有当两个设备都已发送和接收该RG的ICCP“RG Connect”消息时,两个设备之间的ICCP连接才被认为是可操作的。

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

如果发送特定“RG Connect”消息的PE没有从目标接收到相应的RG Connect(或拒绝连接的通知消息),则其将保持预期相应“RG Connect”消息的状态(或

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”消息之前,RG将无法运行。如果发送“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:

如果至少满足以下条件之一,则设备必须拒绝传入的“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.

二,。超过了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断开连接”消息以断开给定RG的ICCP连接。这是一个单边操作,不需要其他PE的任何确认。请注意,RG的ICCP连接必须是可操作的,然后任何客户端应用程序才能使用该RG中的ICCP服务。

4.2.1. ICCP Connection State Machine
4.2.1. 连接状态机

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 Connect”、“RG Disconnect”和“RG Notification”消息作出反应。应用程序连接状态机中的操作和状态转换对ICCP连接状态机没有影响。

The ICCP Connection state machine is defined to have six states, as follows:

ICCP连接状态机定义为六种状态,如下所示:

- 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.

- 不存在:此状态是状态机的起点。这表明不存在ICCP连接,并且PEs之间没有建立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.

- 已初始化:此状态表示PEs之间存在LDP会话,但它们之间尚未交换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:此状态表示PEs之间存在LDP会话,并且本地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:该状态表示PEs之间存在LDP会话,并且本地PE已从/向其对等方接收并公布LDP ICCP能力。

- CONNECTING: This state indicates that the local PE has initiated an ICCP connection to its peer and is awaiting its response.

- 正在连接:此状态表示本地PE已启动与其对等方的ICCP连接,并正在等待其响应。

- OPERATIONAL: This state indicates that the ICCP connection is 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
        
    STATE         EVENT                                     NEW STATE
   --------------------------------------------------------------------
    NONEXISTENT   LDP session established                   INITIALIZED
        

INITIALIZED Transmit LDP ICCP capability CAPSENT

已初始化发送LDP ICCP能力

Receive LDP ICCP capability CAPREC Action: Transmit LDP ICCP capability

接收LDP ICCP能力CAPREC动作:发送LDP ICCP能力

LDP session torn down NONEXISTENT

自民党会议被推翻不存在

CAPSENT Receive LDP ICCP capability CAPREC

CAPSENT接收LDP ICCP能力CAPREC

LDP session torn down NONEXISTENT

自民党会议被推翻不存在

CAPREC Transmit RG Connect message CONNECTING

CAPREC传输RG连接消息连接

Receive acceptable RG Connect message OPERATIONAL Action: Transmit RG Connect message

接收可接受的RG Connect消息操作操作:发送RG Connect消息

Receive any other ICCP message CAPREC Action: Transmit NAK TLV in RG Notification message

接收任何其他ICCP消息CAPREC操作:在RG通知消息中传输NAK TLV

LDP session torn down NONEXISTENT

自民党会议被推翻不存在

CONNECTING Receive acceptable RG Connect message OPERATIONAL

连接接收可接受的RG Connect消息可操作

Receive any other ICCP message CAPREC Action: Transmit NAK TLV in RG Notification message

接收任何其他ICCP消息CAPREC操作:在RG通知消息中传输NAK TLV

LDP session torn down NONEXISTENT

自民党会议被推翻不存在

OPERATIONAL Receive acceptable RG Disconnect message CAPREC

操作接收可接受的RG断开消息CAPREC

Transmit RG Disconnect message CAPREC

发送RG断开连接信息CAPREC

LDP session torn down 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|                                          |
                 |          |----------------------------------------->+
                 +----------+
        
                              +------------+
                              |            |
          +------------------>|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|                                          |
                 |          |----------------------------------------->+
                 +----------+
        
4.3. Redundant Object Identification
4.3. 冗余对象识别

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)。这些被称为冗余对象(ROs)。RO的一个示例是跨两个PE的多机箱链路聚合组。ICCP引入64位不透明标识符,以唯一标识RG中的ROs。该标识符(称为冗余对象ID(ROID))必须在相关受保护对象的RG成员之间匹配;这允许RG中的独立系统使用公共句柄引用受保护实体,而不管其性质如何(例如,物理或虚拟),并且以与实现细节无关的方式引用。需要同步与特定RO相关的状态的客户端应用程序应在其TLV中嵌入相应的ROID。

4.4. Application Connection Management
4.4. 应用程序连接管理

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提供了一套通用程序,通过这些程序,一个PE上的应用程序可以连接到另一个PE上的应用程序,以便在给定RG的上下文中进行机箱间通信。建立应用程序连接的先决条件是在两个端点之间具有可操作的ICCP RG连接。假定应用与RGs的关联是先验的,例如通过设备配置。然后,ICCP代表每个客户端应用程序向RG内的每个远程PE发送“Application Connect TLV”(在“RG Connect”消息中携带)。客户端可以在该“连接TLV”中携带特定于应用程序的信息,例如,该信息可用于在启动实际应用程序连接之前协商参数或属性。启动应用程序连接的过程与ICCP连接的过程类似:只有当两个节点都发送和接收了带有适当“应用程序连接TLV”的“RG Connect”消息时,两个节点之间的应用程序连接才会启动。如果遇到以下情况之一,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.

二,。应用程序连接计数超过了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 Connect”消息(携带相应的“Application Connect TLV”)响应传入的“RG Connect”消息(携带“Application Connect 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的单方面通知,因此不会触发任何响应。

4.4.1. Application Versioning
4.4.1. 应用程序版本控制

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:

在应用程序连接设置期间,一个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.

- 如果应用程序接收到版本号高于其自身版本号的“应用程序连接TLV”,则它必须发送带有“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.

- 如果应用程序接收到版本号低于其自身版本号的“应用程序连接TLV”,它可能会使用与接收到的版本相同的具有“应用程序连接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.

- 如果应用程序收到版本等于其自身版本的“应用程序连接TLV”,则应用程序必须根据应用程序是否为相关RG配置以及是否已超过应用程序连接计数来接受或拒绝请求。

4.4.2. Application Connection State Machine
4.4.2. 应用程序连接状态机

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.

对于RG中与远程PE的每个ICCP连接,PE为每个ICCP应用程序维护一个应用程序连接状态机实例。每个应用程序的状态机仅对包含指定特定应用程序的“应用程序TLV”的“RG连接”、“RG断开连接”和“RG通知”消息作出反应。

The Application Connection state machine has six states, as follows:

应用程序连接状态机有六种状态,如下所示:

- NONEXISTENT: This state indicates that the Application Connection does not exist, since there is no ICCP connection between the PEs.

- 不存在:此状态表示应用程序连接不存在,因为PEs之间没有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.

- 重置:此状态表示PEs之间的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.

- ConnSsent:此状态表示本地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.

- 连接:此状态表示本地PE已向其对等方发送A位设置为1的“应用程序连接”消息,并正在等待对等方的响应。

- OPERATIONAL: This state indicates that the Application Connection is 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
        
     STATE          EVENT                                  NEW STATE
   -------------------------------------------------------------------
     NONEXISTENT    ICCP connection established            RESET
        

RESET ICCP connection torn down NONEXISTENT

重置ICCP连接已断开不存在

Transmit Application Connect TLV CONNSENT

发送应用程序连接TLV CONNSTENT

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

连接发送接收NAK TLV重置

Receive Application Connect TLV OPERATIONAL with A-bit=1 Action: Transmit Application Connect TLV with A-bit=1

接收应用程序连接TLV可操作且A位=1操作:发送应用程序连接TLV且A位=1

Receive any other Application TLV RESET Action: Transmit NAK TLV

接收任何其他应用程序TLV重置操作:传输NAK TLV

ICCP connection torn down NONEXISTENT

ICCP连接已断开不存在

CONNREC Transmit NAK TLV RESET

CONNREC传输NAK TLV重置

Transmit Application Connect TLV CONNECTING with A-bit=1

传输应用程序连接TLV连接A位=1

Receive Application Connect TLV CONNREC

接收应用程序连接TLV CONNREC

Receive any Application TLV except RESET Connect Action: Transmit NAK TLV

接收任何应用程序TLV,重置连接操作除外:传输NAK TLV

ICCP connection torn down NONEXISTENT

ICCP连接已断开不存在

CONNECTING Receive Application Connect TLV OPERATIONAL with A-bit=1

连接接收应用程序连接TLV操作,A位=1

Receive any other Application TLV RESET Action: Transmit NAK TLV

接收任何其他应用程序TLV重置操作:传输NAK TLV

ICCP connection torn down NONEXISTENT

ICCP连接已断开不存在

OPERATIONAL Receive Application Disconnect TLV RESET

操作接收应用程序断开TLV重置

Transmit Application Disconnect TLV RESET

传输应用断开TLV复位

ICCP connection torn down NONEXISTENT

ICCP连接已断开不存在

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|                                          |
                 |          |----------------------------------------->+
                 +----------+
        
                              +------------+
                              |            |
            +---------------->|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|                                          |
                 |          |----------------------------------------->+
                 +----------+
        
4.5. Application Data Transfer
4.5. 应用程序数据传输

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”的通知消息来拒绝消息或消息中一个或多个TLV的集合。此外,如果认为需要,应用程序可以通过定义要在“应用程序数据”消息中传输的特定于应用程序的TLV来实现其自己的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支持这两种模型。

4.6. Dedicated Redundancy Group LDP Session
4.6. 专用冗余组LDP会话

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应用程序的线路头阻塞,可能需要在两个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会话。无需在此标签空间中公布标签,因为它仅用于一个或一组ICCP RG。所有相关LDP和ICCP程序仍适用[RFC5036]和本文件所述。

5. ICCP PE Node Failure / Isolation Detection Mechanism
5. ICCP PE节点故障/隔离检测机制

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

当作为RG成员的远程PE不再可访问时,ICCP向其客户端应用程序提供通知。在专用互连的情况下,这表示远程PE节点发生故障,而在共享互连的情况下,这表示远程PE节点发生故障或与MPLS网络隔离。客户端应用程序使用此信息来

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:

根据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节点出于业务转发目的将保持操作。

6. ICCP Message Formats
6. ICCP消息格式

This section defines the messages exchanged at the Application and ICC layers.

本节定义了在应用程序层和ICC层交换的消息。

6.1. Encoding ICC into LDP Messages
6.1. 将ICC编码为LDP消息

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要求可靠、有序、有状态的消息传递,以及PEs之间的能力协商。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消息结构。定义了一组新的LDP消息类型来传递ICCP信息。ICCP将使用0x0700至0x070F范围内的LDP消息类型。

Message types have been allocated by IANA; see Section 12 below for details.

IANA已分配消息类型;详情见下文第12节。

6.1.1. ICC Header
6.1.1. ICC标题

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                     |
     ~                                                               ~
     +                                                               +
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
      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-用于标识此消息的八位字节值。发送PE用于帮助识别可能适用于此消息的“RG通知”消息。为响应此消息而发送“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.

0x0005类型的TLV,长度为4,包含一个4-八位无符号整数,指定发送设备所属的冗余组。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.

对于具有可选参数的消息,可选参数可以按任意顺序显示。

6.1.2. ICC Parameter Encoding
6.1.2. ICC参数编码

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)                                                      |
     ~                                                               ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
      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为clear(=0),则未知TLV不与LDP消息一起转发;如果设置了F(=1),未知TLV将与LDP消息一起转发。定义TLV的后续部分指定F位的值。通过同时设置U位和F位,TLV可以作为不透明数据通过不识别TLV的节点传播。

- Type

- 类型

14 bits indicating the ICC Parameter type.

14位,表示ICC参数类型。

- Length

- 长

Length of the TLV in octets, excluding the "U-bit", "F-bit", "Type", and "Length" fields.

TLV的长度(以八位字节为单位),不包括“U位”、“F位”、“类型”和“长度”字段。

- TLV(s): A set of 0 or more TLVs. Contents will vary according to the message type.

- TLV(s):一组0个或多个TLV。内容将根据消息类型而有所不同。

6.1.3. Redundant Object Identifier Encoding
6.1.3. 冗余对象标识符编码

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                             |
     +                                                               +
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
      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中。

6.2. RG Connect Message
6.2. RG连接消息

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”消息用于建立ICCP RG连接,以及RG中PE之间的单个应用程序连接。不带“应用程序连接TLV”的“RG Connect”消息表示ICCP RG连接的建立,而带有效“应用程序连接TLV”的“RG Connect”消息表示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”消息。但是,所有实现必须支持接收“RG Connect”消息,该消息同时触发ICCP 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”消息以声明其在冗余组中的成员身份。应向属于同一RG成员的每个PE发送一条此类消息。“RG Connect”消息应传输到的一组PEs通过配置或自动发现机制(不在本规范范围内)已知。如果一个设备是多个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

二,。ICC发送方名称TLV

iii. Zero or one "Application Connect TLV"

iii.零或一个“应用程序连接TLV”

The currently defined "Application Connect TLVs" are as follows:

当前定义的“应用程序连接TLV”如下所示:

- PW-RED Connect TLV (Section 7.1.1)

- PW-RED连接TLV(第7.1.1节)

- mLACP Connect TLV (Section 7.2.1)

- mLACP连接TLV(第7.2.1节)

The details of these TLVs are discussed in Section 7.

第7节讨论了这些TLV的详细信息。

The "RG Connect" message can contain zero or one "Application Connect TLV".

“RG Connect”消息可以包含零个或一个“Application Connect TLV”。

6.2.1. ICC Sender Name TLV
6.2.1. ICC发送方名称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发送方名称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                                                  |
     +                                             +-+-+-+-+-+-+-+-+-+
     ~                                             ~
     |      ...                                    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
      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).

设置为0x0001(从ICC参数名称空间)。

- Length

- 长

Length of the TLV in octets, excluding the "U-bit", "F-bit", "Type", and "Length" fields.

TLV的长度(以八位字节为单位),不包括“U位”、“F位”、“类型”和“长度”字段。

- 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个八位字节。此字段不包括终止的空字符。

6.3. RG Disconnect Message
6.3. RG断开连接消息

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断开连接)消息具有双重用途:表示RG内的特定应用程序连接正在关闭,或者ICCP RG连接本身正在断开,因为PE希望离开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|   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                     |
     +                                                               +
     |                                                               |
     ~                                                               ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
      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

U=0

- Message Type

- 消息类型

The message type for the "RG Disconnect" message is set to 0x0701.

“RG断开”消息的消息类型设置为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                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
        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).

设置为“断开连接代码TLV”(0x0004)。

- Length

- 长

Length of the TLV in octets, excluding the "U-bit", "F-bit", "Type", and "Length" fields.

TLV的长度(以八位字节为单位),不包括“U位”、“F位”、“类型”和“长度”字段。

- 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移除”和“ICCP应用程序从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.

零或一个“应用断开TLV”(定义见第7.1.2节和第7.2.2节)。如果“RG Disconnect”消息的状态代码为“RG Removed”,则该消息不得包含任何“Application Disconnect TLV”,因为发送PE发出信号表明其已离开RG,从而断开ICCP RG连接与所有相关客户端应用程序连接的连接。如果消息的状态代码为“Application Removed from RG”,则它必须仅包含一个“Application Disconnect TLV”,因为发送PE仅断开指定应用程序的连接。其他应用程序和ICCP RG连接不受影响。

- Optional Parameter TLVs

- 可选参数TLV

None are defined for this message in this document. This is specified to allow for future extensions.

此文档中未为此邮件定义任何内容。这是为了允许将来扩展而指定的。

6.4. RG Notification Message
6.4. RG通知消息

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连接、拒绝应用程序连接、拒绝整个消息或拒绝消息中的一个或多个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通知”消息最多只能有一个ICCP应用程序。

The format of the "RG Notification" message is as follows:

“RG通知”信息的格式如下:

i. ICC Header with Message type = "RG Notification Message" (0x0702)

i. 消息类型为“RG通知消息”(0x0702)的ICC标头

ii. Notification Message TLVs

二,。通知消息TLV

The currently defined Notification message TLVs are as follows:

当前定义的通知消息TLV如下所示:

i. ICC Sender Name TLV

i. ICC发送方名称TLV

ii. Negative Acknowledgement (NAK) TLV

二,。否定确认(NAK)TLV

6.4.1. Notification Message TLVs
6.4.1. 通知消息TLV

The "ICC Sender Name TLV" uses the same format as the format used in the "RG Connect" message and was described above.

“ICC发送方名称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)                              |
     +                                                               +
     |                                                               |
     ~                                                               ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
      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.

TLV的长度(以八位字节为单位),不包括“U位”、“F位”、“类型”和“长度”字段。

- 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(0x0000001)

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连接。使用此代码时,“拒绝的消息ID”字段必须包含被拒绝的“RG Connect”消息的消息ID。

ii. ICCP Connection Count Exceeded (0x00010002)

二,。超过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连接。使用此代码时,“拒绝的消息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连接计数超过其能力的新传入应用程序连接。使用此代码时,“拒绝的消息ID”字段必须包含拒绝的“RG Connect”消息的消息ID,“可选TLV”中必须包含相应的“应用程序连接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中配置应用程序时,这用于拒绝新的传入应用程序连接。使用此代码时,“拒绝的消息ID”字段必须包含拒绝的“RG Connect”消息的消息ID,“可选TLV”中必须包含相应的“应用程序连接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具有不兼容版本的应用程序时,这用于拒绝新的传入应用程序连接。使用此代码时,“拒绝的消息ID”字段必须包含拒绝的“RG Connect”消息的消息ID,“可选TLV”中必须包含相应的“应用程序连接TLV”。

vi. ICCP Rejected Message (0x00010006)

六、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应用程序数据”消息或消息中的一个或多个TLV。使用此代码时,“拒绝的消息ID”字段必须包含被拒绝的“RG应用程序数据”消息的消息ID。

vii. ICCP Administratively Disabled (0x00010007)

七,。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.

如果非零,则为4个八位字节的值,用于标识“NAK TLV”所指的对等消息。如果为零,则未识别特定的对等消息。

- 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.

一组一个或多个可选TLV。如果状态代码为“已拒绝消息”,则此字段包含已拒绝的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           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
        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".

“请求的协议版本TLV”设置为0x0003。

- Length

- 长

Length of the TLV in octets, excluding the "U-bit", "F-bit", "Type", and "Length" fields.

TLV的长度(以八位字节为单位),不包括“U位”、“F位”、“类型”和“长度”字段。

- Connection Reference

- 连接引用

Set to the "Type" field of the "Application Connect TLV" that was rejected because of incompatible version.

设置为“应用程序连接TLV”的“类型”字段,该字段因版本不兼容而被拒绝。

- Requested Version

- 要求的版本

The version of the application supported by the transmitting device. For this version of the protocol, it is set to 0x0001.

传输设备支持的应用程序版本。对于此版本的协议,它设置为0x0001。

6.5. RG Application Data Message
6.5. RG应用程序数据消息

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应用程序数据”消息用于在RG内的PE之间传输应用程序数据。一条消息只能用于承载来自一个应用程序的数据。一条消息中允许多个应用程序TLV,只要所有这些TLV都属于同一个应用程序。“应用程序数据”信息的格式如下:

i. ICC Header with Message type = "RG Application Data Message" (0x0703)

i. 消息类型为“RG应用程序数据消息”(0x0703)的ICC标头

ii. Application-specific TLVs

二,。特定于应用程序的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.

第7节讨论了这些TLV的详细信息。一条“RG应用程序数据”消息中的所有特定于应用程序的TLV必须属于单个应用程序,但可能引用不同的ROs。

7. Application TLVs
7. 应用TLV
7.1. Pseudowire Redundancy (PW-RED) Application TLVs
7.1. 伪线冗余(PW-RED)应用TLV

This section discusses the "ICCP TLVs" for the Pseudowire Redundancy application.

本节讨论伪线冗余应用的“ICCP TLV”。

7.1.1. PW-RED Connect TLV
7.1.1. PW-RED连接TLV

This TLV is included in the "RG Connect" message to signal the establishment of a PW-RED Application Connection.

该TLV包含在“RG Connect”消息中,以指示建立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                        |
     ~                                                               ~
     |                                                               |
     +                                 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |             ...                 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
      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.

TLV的长度(以八位字节为单位),不包括“U位”、“F位”、“类型”和“长度”字段。

- Protocol Version

- 协议版本

The version of this particular protocol for the purposes of ICCP. This is set to 0x0001.

为ICCP的目的,本特定协议的版本。这设置为0x0001。

- A-bit

- 一点儿

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的长度施加任何限制。

7.1.2. PW-RED Disconnect TLV
7.1.2. PW-RED断开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断开”消息,以指示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                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
      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断开TLV”设置为0x0011。

- Length

- 长

Length of the TLV in octets, excluding the "U-bit", "F-bit", "Type", and "Length" fields.

TLV的长度(以八位字节为单位),不包括“U位”、“F位”、“类型”和“长度”字段。

- 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”。

7.1.2.1. PW-RED Disconnect Cause 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                  |
     ~                                                               ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
      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断开原因TLV”设置为0x0019。

- Length

- 长

Length of the TLV in octets, excluding the "U-bit", "F-bit", "Type", and "Length" fields.

TLV的长度(以八位字节为单位),不包括“U位”、“F位”、“类型”和“长度”字段。

- 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格式编码。该字符串不包含终止的空字符。用于网络管理。

7.1.3. PW-RED Config TLV
7.1.3. PW-RED配置TLV

The "PW-RED Config TLV" is used in the "RG Application Data" message and has the following format:

“RG应用程序数据”消息中使用了“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 = 0x0012           |    Length                     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                              ROID                             |
     +                                                               +
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      PW Priority              |            Flags              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                  Service Name TLV                             |
     ~                                                               ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |            PW ID TLV or Generalized PW ID 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 = 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配置TLV”设置为0x0012。

- Length

- 长

Length of the TLV in octets, excluding the "U-bit", "F-bit", "Type", and "Length" fields.

TLV的长度(以八位字节为单位),不包括“U位”、“F位”、“类型”和“长度”字段。

- 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)

二,。清除配置(0x02)

Indicates that the pseudowire is no longer configured for PW-RED operation.

表示不再为PW-RED操作配置伪导线。

iii. Independent Mode (0x04)

三、独立模式(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节,通过使用“请求切换”位,使用独立操作模式将伪线配置为冗余。

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)

vi.从模式(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配置TLV”包括以下两个子TLV:

i. Service Name TLV

i. 服务名称TLV

ii. One of the following: PW ID TLV or Generalized PW ID TLV

二,。以下选项之一:PW ID TLV或广义PW ID TLV

The format of the sub-TLVs is defined in Sections 7.1.3.1 through 7.1.3.3.

第7.1.3.1至7.1.3.3节定义了子TLV的格式。

7.1.3.1. Service Name TLV
7.1.3.1. 服务名称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 = 0x0013          |    Length                     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        Service Name                           |
     ~                                                               ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
      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.

TLV的长度(以八位字节为单位),不包括“U位”、“F位”、“类型”和“长度”字段。

- 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个八位字节。该字符串不包含终止的空字符。

7.1.3.2. PW ID TLV
7.1.3.2. PW-ID-TLV

This TLV is used to communicate the configuration of PWs for VPWS.

该TLV用于传达VPWS的PWs配置。

      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                                 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
      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.

TLV的长度(以八位字节为单位),不包括“U位”、“F位”、“类型”和“长度”字段。

- 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相同。

7.1.3.3. Generalized PW ID TLV
7.1.3.3. 广义PW-ID-TLV

This TLV is used to communicate the configuration of PWs for VPLS.

该TLV用于传达VPL的PWs配置。

      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)                      ~
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
      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.

TLV的长度(以八位字节为单位),不包括“U位”、“F位”、“类型”和“长度”字段。

- AGI, AII, SAII, and TAII

- AGI,所有,Sai,和Tai

Defined in [RFC4447], Section 5.3.2.

定义见[RFC4447]第5.3.2节。

7.1.4. PW-RED State TLV
7.1.4. PW-RED状态TLV

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应用数据”消息中使用了“PW-RED状态TLV”。该TLV由设备用于向RG中的其他成员报告其PW状态。

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                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
      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状态TLV”设置为0x0016。

- Length

- 长

Length of the TLV in octets, excluding the "U-bit", "F-bit", "Type", and "Length" fields.

TLV的长度(以八位字节为单位),不包括“U位”、“F位”、“类型”和“长度”字段。

- 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].

由发送PE确定的PW状态,编码格式与[RFC4447]中定义并在[RFC6870]中扩展的“PW状态TLV”的“状态代码”字段相同。

- 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”的“状态代码”字段相同。

7.1.5. PW-RED Synchronization Request TLV
7.1.5. PW-RED同步请求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:

“RG应用程序数据”消息中使用了“PW-RED同步请求TLV”。设备使用此TLV请求其对等方重新传输配置或操作状态。可要求提供以下信息:

- configuration and/or state for one or more pseudowires

- 一条或多条伪导线的配置和/或状态

- 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                          |
     ~                                                               ~
     |                                                               |
     +                                 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |             ...                 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
      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同步请求TLV”设置为0x0017。

- Length

- 长

Length of the TLV in octets, excluding the "U-bit", "F-bit", "Type", and "Length" fields.

TLV的长度(以八位字节为单位),不包括“U位”、“F位”、“类型”和“长度”字段。

- 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”中使用。考虑到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

- 可选子TLV

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.

如果“请求类型”字段设置为0x00,则此字段包含一个或多个“PW ID TLV”或“广义PW ID TLV”。如果“请求类型”字段设置为0x01,则此字段包含一个或多个“服务名称TLV”。如果“请求类型”字段设置为0x3FFF,则此字段必须为空。本文件不对子TLV的长度施加任何限制。

7.1.6. PW-RED Synchronization Data TLV
7.1.6. PW-RED同步数据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.

“RG应用程序数据”消息中使用了“PW-RED同步数据TLV”。设备使用这些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同步数据TLV”还用于完整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                     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
      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同步数据TLV”设置为0x0018。

- Length

- 长

Length of the TLV in octets, excluding the "U-bit", "F-bit", "Type", and "Length" fields.

TLV的长度(以八位字节为单位),不包括“U位”、“F位”、“类型”和“长度”字段。

- 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同步请求TLV”中的请求号的无符号整数。

- Flags

- 旗帜

2 octets. Response flags encoded as follows:

2个八位组。响应标志编码如下:

0x00 Synchronization Data Start 0x01 Synchronization Data End

0x00同步数据开始0x01同步数据结束

7.2. Multi-Chassis LACP (mLACP) Application TLVs
7.2. 多机箱LACP(mLACP)应用TLV

This section discusses the "ICCP TLVs" for Ethernet attachment circuit redundancy using the multi-chassis LACP (mLACP) application.

本节讨论使用多机箱LACP(mLACP)应用程序实现以太网连接电路冗余的“ICCP TLV”。

7.2.1. mLACP Connect TLV
7.2.1. mLACP连接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         |