YD/T 2901-2015
基本信息
标准号： YD/T 2901-2015
中文名称：跨机框信息同步通信协议(ICCP)技术要求
标准类别：通信行业标准(YD)
标准状态：现行
出版语种：简体中文
下载格式：.zip .pdf
下载大小：14124802
标准分类号
关联标准
出版信息
相关单位信息
标准简介
YD/T 2901-2015.Technical specification for Inter-Chassis communication protocol.
1范围
YD/T 2901规定了跨机架信息同步通信协议(ICCP) 技术要求，包括参考模型、协议需求、协议实体、协议格式以及客户应用方式。
YD/T 2901适用于利用ICCP实现的双归场景。
2规范性引用文件
下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅所注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本(包括所有的修改单)适用于本文件。
IETF RFC4447 使用LDP的伪线设置和维护(Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP))
IETF RFC5036 LDP 说明(LDP Specifcation)
IEEE802.1AX-2008 IEEE 局域网和城域网标准:链路聚合(IEEE Standard for Local and Metropolitan Area Networks - Link Aggregation)
3术语、 定义和缩略语
3.1术语和定义
下面术语和定义适用于本文件。
3.1.1
冗余组 Redundancy Group
同一管理城内的2个或多个PE节点组成一个冗余组(Redundancy Group, RG) ,针对特定业务实例，采用冗余机制进行保护。
3.1.2
冗余对象 Redundancy Object
冗余组保护的对象，可以是链路，端口,转发结构等通用对象。
3.1.3
跨机框通信协议 Inter-Chassis Communication Protocol
一种完成冗余组内PE之间的通信，同步配置和运行状态数据的协议。
1范围
YD/T 2901规定了跨机架信息同步通信协议(ICCP) 技术要求，包括参考模型、协议需求、协议实体、协议格式以及客户应用方式。
YD/T 2901适用于利用ICCP实现的双归场景。
2规范性引用文件
下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅所注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本(包括所有的修改单)适用于本文件。
IETF RFC4447 使用LDP的伪线设置和维护(Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP))
IETF RFC5036 LDP 说明(LDP Specifcation)
IEEE802.1AX-2008 IEEE 局域网和城域网标准:链路聚合(IEEE Standard for Local and Metropolitan Area Networks - Link Aggregation)
3术语、 定义和缩略语
3.1术语和定义
下面术语和定义适用于本文件。
3.1.1
冗余组 Redundancy Group
同一管理城内的2个或多个PE节点组成一个冗余组(Redundancy Group, RG) ,针对特定业务实例，采用冗余机制进行保护。
3.1.2
冗余对象 Redundancy Object
冗余组保护的对象，可以是链路，端口,转发结构等通用对象。
3.1.3
跨机框通信协议 Inter-Chassis Communication Protocol
一种完成冗余组内PE之间的通信，同步配置和运行状态数据的协议。
标准图片预览
标准内容
ICS33.040.40
中华人民共和国通信行业标准
YD/T2901-2015
跨机框信息同步通信协设议
（ICCP）技术要求
Technical specificationforInter-Chassiscommunicationprotocol2015-07-14发布
2015-10-01实施
中华人民共和国工业和信息化部发布前言·
1范围·
2规范性引用文件
3术语、定义和缩略语·
3.1术语和定义…
3.2缩略语
4参考模型和需求
4.1节点穴余保护参考模型
4.2跨机框通信协议需求
5LDP协议扩展说明
层级说明·
LDPICCP能力通告·
RG成员管理..
允余对象标识
应用连接管理
6ICCPPE节点故障检测机制
7ICCP消息格式
ICC编码
RG连接消息·
RG连接断开消息.
7.4RG通告消息
7.5RG应用数据消息
8应用扩展TLVs
8.1PW-RED连接TLV..
8.2多机框LACP(Multi-chassisLACP、mLACP）应用TLVs9LDPICCP能力协商TLV
10客户应用
10.1PW允余应用处理过程：
10.2接入链路亢余应用处理过程·：附录A(资料性附录）多机框MSP的应用·参考文献·
YD/T2901-2015
YD/T2901-2015
本标准按照GB/T1.1-2009给出的规则起草。请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别这些专利的责任。本标准由中国通信标准化协会提出并归口。本标准起草单位：中兴通信股份有限公司、中国移动通信集团公司。本标准主要起草人：马玉霞魏月华陈然黄璐。H
1范围
跨机框信息同步通信协议（ICCP）技术要求YD/T2901-2015
本标准规定了跨机架信息同步通信协议（ICCP）技术要求，包括参考模型、协议需求、协议实体协议格式以及客户应用方式。
本标准适用于利用ICCP实现的双归场景。2规范性引用文件
下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅所注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。IETFRFC4447使用LDP的伪线设置和维护（PseudowireSetupandMaintenanceUsingtheLabelDistributionProtocol (LDP))
IETFRFC5036LDP说明（LDPSpecification）IEEE802.1AX-2008IEEE局域网和城域网标准：链路聚合（IEEEStandardforLocalandMetropolitanAreaNetworks-LinkAggregation)3术语、定义和缩略语
3.1术语和定义
下面术语和定义适用于本文件。3.1.1
余组RedundancyGroup
同一管理域内的2个或多个PE节点组成一个穴余组（RedundancyGroup，RG），针对特定业务实例，采用元余机制进行保护。
穴余对象RedundancyObject
穴余组保护的对象，可以是链路，端口，转发结构等通用对象。3.1.3
跨机框通信协议Inter-ChassisCommunicationProtoco种完成穴余组内PE之间的通信，同步配置和运行状态数据的协议。3.2缩略语
下列缩略语适用于本文件。
Attachment Circuit
Associated Control Channel
Customer Edge
Digital SubscriberLineAccess Multiplexer接入电路
随路控制信道
用户边缘设备
数字用户线路接入复用器
YD/T2901-2015
LinkAggregation Control ProtocolInter-ChassiscommunicationprotocolLabel Distribution Protocol
Layer 2 Virtual Private NetworksMulti-Protocol Label Switchingmultiplex section ProtectionNegative Acknowlegment
ProviderEdge
Pseudo-Wire
Redundancy Group
Redundant Object
Redundant Object Identity
Synchronous Digital HierarchySynchronous Optical Network
Type-Length-Value
Virtual Private Network
参考模型和需求
4.1节点穴余保护参考模型
链路汇聚控制协议www.bzxz.net
跨机框通信协议
标签分发协议
二层虚拟专用网
多协议标签交换
复用段保护
否定应答
运营商边缘设备
允余组
允余对象
穴余对象标识
同步数字体系
同步光纤网
类型-长度-值
虚拟专用网
网络的高可用性对任何承载网以及应用VPN的网络来说都是关键指标。一般采用机框内或跨机框的亢余保护机制实现。本标准针对跨机框场景，即PE节点穴余。假设同一管理域内的2个或多个PE节点组成一个穴余组（RedundancyGroup，RG），针对特定业务实例，面向接入（接入链路、接入伪线等）和/或核心（伪线等）采用允余机制进行保护。允余组内的PE提供多归连接到任意单个设备（比如CE，DSLAM等）或者整个网络（比如接入网络）。图1为通用多归亢余模型。
多归节点
接入网络
多归网络
元余组
图1通用多归穴余模型
面向核心
在图1的拓扑中，面向接入节点/网络采用的几余机制可以是多种技术，比如伪线几余组（采用PWredundancy控制协议），IEEE802.1AX链路聚合组（采用LACP控制协议）、SONET/SDHAPS等。为2
YD/T2901-2015
了保证接入穴余机制运行正常，RG内的PE之间需要通信，即它们之间需要运行跨机框通信协议来同步配置和运行状态数据。如果PEs面向核心侧采用伪线元余保护机制，跨机框通信协议可以简化它的实现。需要说明的是，面向接入或核心所采用的具体技术不在本标准定义范围之内，而且本标准也不会影响其技术机制
跨机框通信协议消息在亢余组内PE之间传送。同一亢余组内的PE可能处于相同地理位置或者分布于不同的地理位置，它们之间的连接可能是专用背靠背链路，也可能是穿过分组交换网络的共享连接。不管PE之间采用何种连接方式，只要提供通道供跨机框通信协议消息传递，那么跨机框通信协议对其实现方式没有要求。
4.2跨机框通信协议需求
跨机框通信协议需要满足如下需求：ICCP应为几余组内的PEs通信提供控制通道：一应适用于多种客户应用（比如多机框LACP、PW余、多机框MSP等）。这意味着消息要支持扩展（比如基于TLV）。
一协议具有安全认证机制，应提供穴余组内的节点之间可靠的信息传送和有序传递。一应提供通用机制来监测亢余组内的PE的状态。该机制用于检测PE节点是否故障，并通知客户应用。客户应用根据AC与PW所采用的元余协议来触发保护倒换。为了给客户应用提供足够的反应时间从而达到次秒级业务恢复时间，要求远端节点的故障检测时间是次秒级别的。一应提供异步的事件驱动状态更新，独立于周期消息，是基于客户应用状态变化的快速通知。换句话说，携带应用数据的消息应按需发送，而不是基于定时器发送，从而最小化机框之间的状态同步延时。一应适用于多链路多跳的节点互连。当余组内的设备安置在不同的地理位置时，它们之间的连接由网络构成而非直连链路。因此，ICCP需适用于多跳的应用场景。另外，设备之间也可能存在多（元余）路径或连接，ICCP也需要适用于此情况。应保证亢余组内设备间通信安全。当亢余组的节点处于不同地理位置，并由共享网络连接时，这一点尤其重要。
一应充许运营商静态配置完余组成员：一应允许灵活的元余组成员关系。虽然每个元余组包含2个节点，可以覆盖大部分穴余应用场景，但ICCP不应排除支持一个完余组内多于2个节点。而且允许一个节点同时是多个RG的成员。5LDP协议扩展说明
5.1层级说明
为了满足上述需求，ICCP模型包含以下三层。一应用层：为使用ICCP的不同元余应用提供接口。ICCP仅考定义通用连接管理过程和在本层交换的消息格式。除此之外，它对客户的处理过程和状态机没有任何限制。一跨机框通信协议（InterChassisCommunicationprotocol，ICCP）层：该层向客户应用提供ICCP的公共服务集。它处理协议版本管理、RG成员、穴余对象标识、PE节点标识和ICCP连接管理。一传输层：该层提供ICCP消息的传输。它负责寻址、路由解析、流控、可靠有序的消息传递、连接的弹性/元余和PE节点的错误检测。互连链路的物理层不同，传输层可能不同。5.2LDPICCP能力通告
YD/T2901-2015
当一个PE设备配置了穴余组，如果它支持ICCP功能，则需要将这种能力通告给RG中其他LDP对等体（携带ICCPLDPcapabilityTLV的LDP消息）。如果其他LDP对等体支持动态能力通告，需要发送一个新的能力通告消息。能力通告消息中携带了ICCPcapabilityTLV中的S标志位置位，否则应在LDP的初始化消息中携带ICCPLDPcapabilityTLV，该过程与IETFRFC5561过程相同。5.3RG成员管理
ICCP提供一种PE节点管理RG成员的机制。当PE配置为RG成员时，它首先通告ICCP能力给对等体。接下来，PE发送一个RG连接消息给已经通告有ICCP能力的对等体，然后PE等待对等体发送RG连接消息。对于一个RG，只有当双方都发送和接收了ICCPRG连接消息后，两个设备之间的ICCP连接才被认为可以操作。
如果PE已经发送了RG连接消息却没有从对方接收到相应的RG连接（或者拒绝连接通知）消息，它将维持在等待回应RG连接消息（或通知消息）状态，直到接收到相应的RG连接消息后，RG才可操作。如果PE接收到拒绝连接通知消息，它将立即停止建立ICCP连接。PE从对等体接收到RG连接消息后，应重新建立连接，回应对方。如果下列条件之一满足，那么设备应发送拒绝连接消息：一PE不是RG成员：
同时建立的ICCP连接数量已经超过PE能处理的最大值。PE发送RG连接断开消息结束ICCP连接。这是一个单方行为，不需要对方的任何回应，ICCP连接状态机有6个状态，ICCP连接状态转换见表1。表1ICCP连接状态转换
NON EXISTENT
INITIALIZED
CAPSENT
CAPREC
CONNECTING
OPERATIONAL
LDP session建立
发送LDPICCP能力
触发事件
接收LDPICCP能力
（动作：发送LDPICCP能力）
LDPsession断开
接收LDPICCP能力
LDP session断开
发送RG连接消息
接收可接受的RG连接消息
（动作：发送RG连接消息）
接收任何其他ICCP消息
（动作：发送NAKTLV在RG通告消息）LDPsession断开
接收可接受的RG连接消息
接收任何其他ICCP消息
（动作：发送NAKTLV在RG通告消息）LDPsession断开
接收可接受的RG断开消息
发送RG连接断开消息
LDPsession断开
INITLALIZED
CAPSENT
CAPREC
新状态
NONEXISTENT
CAPREC
NON EXISTENT
CONNECTING
OPERATIONAL
CAPREC
NON EXISTENT
OPERATIONAL
CAPREC
NON EXISTENT
CAPREC
CAPREC
NONEXISTENT
5.4穴余对象标识
YD/T2901-2015
ICCP给客户应用提供了标识穴余保护对象，即链路、端口、转发结构和更多通用对象（比如接口、伪线、VLANs等）的统一机制。这些统称为元余对象（RedundantObjects、RO）。ICCP引入一个64比特标识来唯一标识RG中的ROs。这个标识称为穴余ID（RedundantObjectID、ROID），RG成员之间被保护对象应匹配。
5.5应用连接管理
ICCP发送应用相关的连接TLV（承载在RG连接消息中）给RG内每个对端PE。携带的信息用于在建立真正的应用连接之前的参数或属性协商。建立应用连接的过程和ICCP连接相似，只有当双方都发送和接收到携带适当的应用相关连接TLVs的RG连接消息，两个节点之间的应用连接才算建立。如果下列情形之一发生，那么PE应发送拒绝连接通知消息，拒绝应用连接请求包括：一应用不存在或者在RG没有配置：应用连接数量超过PE的处理能力。当PE接收到拒绝连接通知，它应停止建立应用连接，直到从对端PE接收到新的应用连接请求。当节点上某个应用停止或它不再与某个RG关联，那么该节点应发送携带应用相关的连接，断开TLV的RG连接，断开连接消息给对方PE。这是一个单向通知，不需要对方回应。在应用连接建立期间，PE可以和对方PE协商应用版本，如果没有达成一致，那么应用连接建立失败。支持的版本不一致时，可以采用后向兼容或不兼容方式。应用连接状态机有6个状态，应用连接状态转换见表2。表2应用连接状态转换
NON EXISTENT
CONNSENT
CONNREC
CONNECTING
ICCP连接建立
ICCP连接断开
发送应用连接TLV
接收应用连接TLV
接收任何其他应用TLV
（动作：发送NAKTLV）
接收NAKTLV
接收应用连接TLV，且A-bit-=1
（动作：发送应用连接TLV，且A-bit=1）接收任何其他应用TLV
（动作：发送NAKTLV）
ICCP连接断开
发送NAKTLV
发送应用连接TLV，且A-bit-1
接收任何应用TLV，除了连接TLV（动作：发送NAKTLV）
ICCP连接断开
接收应用连接TLV且A-bit-1
接收任何其他应用TLV
（动作：发送NAKTLV）
ICCP连接断开
NEWSTATE
NONEXISTENT
CONNSENT
CONNREC
OPERATIONAL
NONEXISTENT
CONNECTING
NON EXISTENT
OPERATIONAL
NON EXISTENT
YD/T2901-2015
OPERATIONAL
接收应用断开TLV
发送应用断开TLV
ICCP连接断开
ICCPPE节点故障检测机制
表2（续）
NEWSTATE
NON EXISTENT
当RG成员的对端PE节点不可达时，客户应根据AC或PW的元余协议触发保护倒换。ICCP本身并不定义保活机制监测对端PE节点的状态，需重用现有的故障检测机制，如BFD、IP可达性监测以及其他OAM机制等。需要说明的是，LDP会话丢失不能作为对端PE失效的可靠指示。比如：可能是对端PE遇到本地问题导致重新启动LDP会话，而PE节点仍然可以进行业务转发。7
ICCP消息格式
7.1ICC编码
7.1.1概述
LDP协议提供的可靠、有序、状态完整的消息传递，节点间的能力协商等属性，而这些也是ICCP所需的。因此，ICCP利用现有的LDP协议架构。IETFRFC5036定义了通用LDP消息结构，ICCP定义了一系列新的LDP消息类型来传递ICCP信息。所使用的LDP消息类型范围是0x700到0x07F。7.1.2ICCheader
每个ICCP消息由ICCLDPHeader、后面跟着的消息data组成。ICCHeader的格式见表3。表3ICCHeader格式
02345689012345689012345678901UMessage Type
MessageID
Type-0x0005(ICCRGID)
ICCRGID
各个字段含义如下：
MandatoryICC Parameters
Optional ICCParameters
中-中*
Message Length
Length-4
U-bit，未知消息比特。接收到的未知消息，如果U置O，那么需要回复通知消息给初始发送者；如果U置1，那么忽略未知消息。MessageType，指示ICCP消息类型，应在0x0700~0x070F的范围内。MessageLength，指示消息的字节长度，除了字段U-bit、MessageType和MessageLength的消息字节长度。
MessageID，消息ID，对方PE发送RG通知消息回应这个消息时，应该在通知消息中的“NAKTLV”中包含这个消息ID：
YD/T2901-2015
一ICCRGIDTLV、TLVtype为0x0005，长度为4，包含4字节RGID，用于标识发送者是这个RG的成员。
MandatoryICCParameters，可变长度的必选消息参数。一些消息没有必选参数。OptionalICCParamcters，可变长度的可选消息参数。一些消息没有可选参数。7.1.3ICC参数编码
ICC参数的通用格式见表4。
表4ICC参数编码
0123456789012345678902345678901UF
TLV(s)
各个字段含义如下：
Length
一U-bit，未知TLV比特。接收到的未知TLV，如果U置O，那么需要回复通知消息给初始发送者，然后整个消息被忽略：如果U置1，忽略未知TLV，消息的其他部分正常处理就像未知TLV不存在一样。
F-bit，转发未知TLV比特。只有当U-bit置1并且LDP消息包含未知TLV时，转发LDP消息。如果F置O，未知TLV不被转发：如果F置1，转发未知TLV。—Type，ICC参数类型。
一Length，TLV的字节长度，除了字段U-bit、F-bit、Type和Length的TLV字节长度。一TLV(S)，0或多个TLVs，根据消息类型变化。7.1.4ROID编码
余对象标识（ROID）唯一标识一个穴余对象、一个RG保护对象（比如链路、聚合组、VLAN等）。ROID编码见表5。
表5ROID编码
01234567890123456789012345678901ROD
ROID是一个8字节无符号整数，在相关的TLVs中使用。7.2RG连接消息
RG连接消息用来建立ICCPRG连接以及同一个RG内PEs之间单独的应用连接。没有携带应用连接TLV的RG连接消息只建立ICCPRG连接。携带有效应用连接TLV的RG连接消息，不仅建立应用连接，而且如果ICCPRG连接没有建立的话，也同时建立。PE向同一个RG内的每个PE发送RG连接消息。哪些PE属于同一个RG可以由配置或某种自动发现机制来决定。如果一个设备是多个RGs的成员，那么PE针对每个RG都会发送不同的连接消息。RG连接消息的格式如下：
ICCheader，消息类型为\RG连接消息”（Ox0700)：一ICCSenderNameTLV，包含发送者的主机名字；YD/T2901-2015
0个或1个应用相关连接TLV。
应用相关连接TLVs有：
一PW穴余组连接TLV：
mLACP连接TLV：
MSP连接TLV，其具体格式是可选的。这些TLVs的细节见第8章，MSP连接TLV相关内容参见附录A。7.2.1 ICC Sender Name TLV
带发送者主机名字的TLV，名字是UTF-8编码。它主要用于RG管理，易于网络操作，其格式如表6所示。
表6带发送者主机名字的TLV格式01234567890123456789012345678901uF
Type=0x0001
发送者名字
各个字段取值或含义如下：
一U及F为O：
Type为0x0001：
Length
Length，除了U-bit、F-bit、Type和Length字段外的TLV字节长度；一SenderName，发送者的主机名字，UTF-8编码，不超过80个字符。7.3RG连接断开消息
RG连接断开消息有两个目的：指示RG内某个应用连接关闭或者由于PE离开这个RG，使得ICCPRG连接自身断开。RG连接断开消息格式见表7。表7RG连接断开消息格式
01234567890123456789012345678901u
Message Type-0x0701
Type=0x0005 (ICC RG ID)
Disconnect Code TLV
MessageID
ICCRGID
OptionalApplication-specificDisconnectTLVOptional Parameter TLVs
各个字段取值或含义如下：
—U为0：
MessageType为0x0701：
Message Length
Length=4
小提示：此标准内容仅展示完整标准里的部分截取内容，若需要完整标准请到上方自行免费下载完整标准文档。
中华人民共和国通信行业标准
YD/T2901-2015
跨机框信息同步通信协设议
（ICCP）技术要求
Technical specificationforInter-Chassiscommunicationprotocol2015-07-14发布
2015-10-01实施
中华人民共和国工业和信息化部发布前言·
1范围·
2规范性引用文件
3术语、定义和缩略语·
3.1术语和定义…
3.2缩略语
4参考模型和需求
4.1节点穴余保护参考模型
4.2跨机框通信协议需求
5LDP协议扩展说明
层级说明·
LDPICCP能力通告·
RG成员管理..
允余对象标识
应用连接管理
6ICCPPE节点故障检测机制
7ICCP消息格式
ICC编码
RG连接消息·
RG连接断开消息.
7.4RG通告消息
7.5RG应用数据消息
8应用扩展TLVs
8.1PW-RED连接TLV..
8.2多机框LACP(Multi-chassisLACP、mLACP）应用TLVs9LDPICCP能力协商TLV
10客户应用
10.1PW允余应用处理过程：
10.2接入链路亢余应用处理过程·：附录A(资料性附录）多机框MSP的应用·参考文献·
YD/T2901-2015
YD/T2901-2015
本标准按照GB/T1.1-2009给出的规则起草。请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别这些专利的责任。本标准由中国通信标准化协会提出并归口。本标准起草单位：中兴通信股份有限公司、中国移动通信集团公司。本标准主要起草人：马玉霞魏月华陈然黄璐。H
1范围
跨机框信息同步通信协议（ICCP）技术要求YD/T2901-2015
本标准规定了跨机架信息同步通信协议（ICCP）技术要求，包括参考模型、协议需求、协议实体协议格式以及客户应用方式。
本标准适用于利用ICCP实现的双归场景。2规范性引用文件
下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅所注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。IETFRFC4447使用LDP的伪线设置和维护（PseudowireSetupandMaintenanceUsingtheLabelDistributionProtocol (LDP))
IETFRFC5036LDP说明（LDPSpecification）IEEE802.1AX-2008IEEE局域网和城域网标准：链路聚合（IEEEStandardforLocalandMetropolitanAreaNetworks-LinkAggregation)3术语、定义和缩略语
3.1术语和定义
下面术语和定义适用于本文件。3.1.1
余组RedundancyGroup
同一管理域内的2个或多个PE节点组成一个穴余组（RedundancyGroup，RG），针对特定业务实例，采用元余机制进行保护。
穴余对象RedundancyObject
穴余组保护的对象，可以是链路，端口，转发结构等通用对象。3.1.3
跨机框通信协议Inter-ChassisCommunicationProtoco种完成穴余组内PE之间的通信，同步配置和运行状态数据的协议。3.2缩略语
下列缩略语适用于本文件。
Attachment Circuit
Associated Control Channel
Customer Edge
Digital SubscriberLineAccess Multiplexer接入电路
随路控制信道
用户边缘设备
数字用户线路接入复用器
YD/T2901-2015
LinkAggregation Control ProtocolInter-ChassiscommunicationprotocolLabel Distribution Protocol
Layer 2 Virtual Private NetworksMulti-Protocol Label Switchingmultiplex section ProtectionNegative Acknowlegment
ProviderEdge
Pseudo-Wire
Redundancy Group
Redundant Object
Redundant Object Identity
Synchronous Digital HierarchySynchronous Optical Network
Type-Length-Value
Virtual Private Network
参考模型和需求
4.1节点穴余保护参考模型
链路汇聚控制协议www.bzxz.net
跨机框通信协议
标签分发协议
二层虚拟专用网
多协议标签交换
复用段保护
否定应答
运营商边缘设备
允余组
允余对象
穴余对象标识
同步数字体系
同步光纤网
类型-长度-值
虚拟专用网
网络的高可用性对任何承载网以及应用VPN的网络来说都是关键指标。一般采用机框内或跨机框的亢余保护机制实现。本标准针对跨机框场景，即PE节点穴余。假设同一管理域内的2个或多个PE节点组成一个穴余组（RedundancyGroup，RG），针对特定业务实例，面向接入（接入链路、接入伪线等）和/或核心（伪线等）采用允余机制进行保护。允余组内的PE提供多归连接到任意单个设备（比如CE，DSLAM等）或者整个网络（比如接入网络）。图1为通用多归亢余模型。
多归节点
接入网络
多归网络
元余组
图1通用多归穴余模型
面向核心
在图1的拓扑中，面向接入节点/网络采用的几余机制可以是多种技术，比如伪线几余组（采用PWredundancy控制协议），IEEE802.1AX链路聚合组（采用LACP控制协议）、SONET/SDHAPS等。为2
YD/T2901-2015
了保证接入穴余机制运行正常，RG内的PE之间需要通信，即它们之间需要运行跨机框通信协议来同步配置和运行状态数据。如果PEs面向核心侧采用伪线元余保护机制，跨机框通信协议可以简化它的实现。需要说明的是，面向接入或核心所采用的具体技术不在本标准定义范围之内，而且本标准也不会影响其技术机制
跨机框通信协议消息在亢余组内PE之间传送。同一亢余组内的PE可能处于相同地理位置或者分布于不同的地理位置，它们之间的连接可能是专用背靠背链路，也可能是穿过分组交换网络的共享连接。不管PE之间采用何种连接方式，只要提供通道供跨机框通信协议消息传递，那么跨机框通信协议对其实现方式没有要求。
4.2跨机框通信协议需求
跨机框通信协议需要满足如下需求：ICCP应为几余组内的PEs通信提供控制通道：一应适用于多种客户应用（比如多机框LACP、PW余、多机框MSP等）。这意味着消息要支持扩展（比如基于TLV）。
一协议具有安全认证机制，应提供穴余组内的节点之间可靠的信息传送和有序传递。一应提供通用机制来监测亢余组内的PE的状态。该机制用于检测PE节点是否故障，并通知客户应用。客户应用根据AC与PW所采用的元余协议来触发保护倒换。为了给客户应用提供足够的反应时间从而达到次秒级业务恢复时间，要求远端节点的故障检测时间是次秒级别的。一应提供异步的事件驱动状态更新，独立于周期消息，是基于客户应用状态变化的快速通知。换句话说，携带应用数据的消息应按需发送，而不是基于定时器发送，从而最小化机框之间的状态同步延时。一应适用于多链路多跳的节点互连。当余组内的设备安置在不同的地理位置时，它们之间的连接由网络构成而非直连链路。因此，ICCP需适用于多跳的应用场景。另外，设备之间也可能存在多（元余）路径或连接，ICCP也需要适用于此情况。应保证亢余组内设备间通信安全。当亢余组的节点处于不同地理位置，并由共享网络连接时，这一点尤其重要。
一应充许运营商静态配置完余组成员：一应允许灵活的元余组成员关系。虽然每个元余组包含2个节点，可以覆盖大部分穴余应用场景，但ICCP不应排除支持一个完余组内多于2个节点。而且允许一个节点同时是多个RG的成员。5LDP协议扩展说明
5.1层级说明
为了满足上述需求，ICCP模型包含以下三层。一应用层：为使用ICCP的不同元余应用提供接口。ICCP仅考定义通用连接管理过程和在本层交换的消息格式。除此之外，它对客户的处理过程和状态机没有任何限制。一跨机框通信协议（InterChassisCommunicationprotocol，ICCP）层：该层向客户应用提供ICCP的公共服务集。它处理协议版本管理、RG成员、穴余对象标识、PE节点标识和ICCP连接管理。一传输层：该层提供ICCP消息的传输。它负责寻址、路由解析、流控、可靠有序的消息传递、连接的弹性/元余和PE节点的错误检测。互连链路的物理层不同，传输层可能不同。5.2LDPICCP能力通告
YD/T2901-2015
当一个PE设备配置了穴余组，如果它支持ICCP功能，则需要将这种能力通告给RG中其他LDP对等体（携带ICCPLDPcapabilityTLV的LDP消息）。如果其他LDP对等体支持动态能力通告，需要发送一个新的能力通告消息。能力通告消息中携带了ICCPcapabilityTLV中的S标志位置位，否则应在LDP的初始化消息中携带ICCPLDPcapabilityTLV，该过程与IETFRFC5561过程相同。5.3RG成员管理
ICCP提供一种PE节点管理RG成员的机制。当PE配置为RG成员时，它首先通告ICCP能力给对等体。接下来，PE发送一个RG连接消息给已经通告有ICCP能力的对等体，然后PE等待对等体发送RG连接消息。对于一个RG，只有当双方都发送和接收了ICCPRG连接消息后，两个设备之间的ICCP连接才被认为可以操作。
如果PE已经发送了RG连接消息却没有从对方接收到相应的RG连接（或者拒绝连接通知）消息，它将维持在等待回应RG连接消息（或通知消息）状态，直到接收到相应的RG连接消息后，RG才可操作。如果PE接收到拒绝连接通知消息，它将立即停止建立ICCP连接。PE从对等体接收到RG连接消息后，应重新建立连接，回应对方。如果下列条件之一满足，那么设备应发送拒绝连接消息：一PE不是RG成员：
同时建立的ICCP连接数量已经超过PE能处理的最大值。PE发送RG连接断开消息结束ICCP连接。这是一个单方行为，不需要对方的任何回应，ICCP连接状态机有6个状态，ICCP连接状态转换见表1。表1ICCP连接状态转换
NON EXISTENT
INITIALIZED
CAPSENT
CAPREC
CONNECTING
OPERATIONAL
LDP session建立
发送LDPICCP能力
触发事件
接收LDPICCP能力
（动作：发送LDPICCP能力）
LDPsession断开
接收LDPICCP能力
LDP session断开
发送RG连接消息
接收可接受的RG连接消息
（动作：发送RG连接消息）
接收任何其他ICCP消息
（动作：发送NAKTLV在RG通告消息）LDPsession断开
接收可接受的RG连接消息
接收任何其他ICCP消息
（动作：发送NAKTLV在RG通告消息）LDPsession断开
接收可接受的RG断开消息
发送RG连接断开消息
LDPsession断开
INITLALIZED
CAPSENT
CAPREC
新状态
NONEXISTENT
CAPREC
NON EXISTENT
CONNECTING
OPERATIONAL
CAPREC
NON EXISTENT
OPERATIONAL
CAPREC
NON EXISTENT
CAPREC
CAPREC
NONEXISTENT
5.4穴余对象标识
YD/T2901-2015
ICCP给客户应用提供了标识穴余保护对象，即链路、端口、转发结构和更多通用对象（比如接口、伪线、VLANs等）的统一机制。这些统称为元余对象（RedundantObjects、RO）。ICCP引入一个64比特标识来唯一标识RG中的ROs。这个标识称为穴余ID（RedundantObjectID、ROID），RG成员之间被保护对象应匹配。
5.5应用连接管理
ICCP发送应用相关的连接TLV（承载在RG连接消息中）给RG内每个对端PE。携带的信息用于在建立真正的应用连接之前的参数或属性协商。建立应用连接的过程和ICCP连接相似，只有当双方都发送和接收到携带适当的应用相关连接TLVs的RG连接消息，两个节点之间的应用连接才算建立。如果下列情形之一发生，那么PE应发送拒绝连接通知消息，拒绝应用连接请求包括：一应用不存在或者在RG没有配置：应用连接数量超过PE的处理能力。当PE接收到拒绝连接通知，它应停止建立应用连接，直到从对端PE接收到新的应用连接请求。当节点上某个应用停止或它不再与某个RG关联，那么该节点应发送携带应用相关的连接，断开TLV的RG连接，断开连接消息给对方PE。这是一个单向通知，不需要对方回应。在应用连接建立期间，PE可以和对方PE协商应用版本，如果没有达成一致，那么应用连接建立失败。支持的版本不一致时，可以采用后向兼容或不兼容方式。应用连接状态机有6个状态，应用连接状态转换见表2。表2应用连接状态转换
NON EXISTENT
CONNSENT
CONNREC
CONNECTING
ICCP连接建立
ICCP连接断开
发送应用连接TLV
接收应用连接TLV
接收任何其他应用TLV
（动作：发送NAKTLV）
接收NAKTLV
接收应用连接TLV，且A-bit-=1
（动作：发送应用连接TLV，且A-bit=1）接收任何其他应用TLV
（动作：发送NAKTLV）
ICCP连接断开
发送NAKTLV
发送应用连接TLV，且A-bit-1
接收任何应用TLV，除了连接TLV（动作：发送NAKTLV）
ICCP连接断开
接收应用连接TLV且A-bit-1
接收任何其他应用TLV
（动作：发送NAKTLV）
ICCP连接断开
NEWSTATE
NONEXISTENT
CONNSENT
CONNREC
OPERATIONAL
NONEXISTENT
CONNECTING
NON EXISTENT
OPERATIONAL
NON EXISTENT
YD/T2901-2015
OPERATIONAL
接收应用断开TLV
发送应用断开TLV
ICCP连接断开
ICCPPE节点故障检测机制
表2（续）
NEWSTATE
NON EXISTENT
当RG成员的对端PE节点不可达时，客户应根据AC或PW的元余协议触发保护倒换。ICCP本身并不定义保活机制监测对端PE节点的状态，需重用现有的故障检测机制，如BFD、IP可达性监测以及其他OAM机制等。需要说明的是，LDP会话丢失不能作为对端PE失效的可靠指示。比如：可能是对端PE遇到本地问题导致重新启动LDP会话，而PE节点仍然可以进行业务转发。7
ICCP消息格式
7.1ICC编码
7.1.1概述
LDP协议提供的可靠、有序、状态完整的消息传递，节点间的能力协商等属性，而这些也是ICCP所需的。因此，ICCP利用现有的LDP协议架构。IETFRFC5036定义了通用LDP消息结构，ICCP定义了一系列新的LDP消息类型来传递ICCP信息。所使用的LDP消息类型范围是0x700到0x07F。7.1.2ICCheader
每个ICCP消息由ICCLDPHeader、后面跟着的消息data组成。ICCHeader的格式见表3。表3ICCHeader格式
02345689012345689012345678901UMessage Type
MessageID
Type-0x0005(ICCRGID)
ICCRGID
各个字段含义如下：
MandatoryICC Parameters
Optional ICCParameters
中-中*
Message Length
Length-4
U-bit，未知消息比特。接收到的未知消息，如果U置O，那么需要回复通知消息给初始发送者；如果U置1，那么忽略未知消息。MessageType，指示ICCP消息类型，应在0x0700~0x070F的范围内。MessageLength，指示消息的字节长度，除了字段U-bit、MessageType和MessageLength的消息字节长度。
MessageID，消息ID，对方PE发送RG通知消息回应这个消息时，应该在通知消息中的“NAKTLV”中包含这个消息ID：
YD/T2901-2015
一ICCRGIDTLV、TLVtype为0x0005，长度为4，包含4字节RGID，用于标识发送者是这个RG的成员。
MandatoryICCParameters，可变长度的必选消息参数。一些消息没有必选参数。OptionalICCParamcters，可变长度的可选消息参数。一些消息没有可选参数。7.1.3ICC参数编码
ICC参数的通用格式见表4。
表4ICC参数编码
0123456789012345678902345678901UF
TLV(s)
各个字段含义如下：
Length
一U-bit，未知TLV比特。接收到的未知TLV，如果U置O，那么需要回复通知消息给初始发送者，然后整个消息被忽略：如果U置1，忽略未知TLV，消息的其他部分正常处理就像未知TLV不存在一样。
F-bit，转发未知TLV比特。只有当U-bit置1并且LDP消息包含未知TLV时，转发LDP消息。如果F置O，未知TLV不被转发：如果F置1，转发未知TLV。—Type，ICC参数类型。
一Length，TLV的字节长度，除了字段U-bit、F-bit、Type和Length的TLV字节长度。一TLV(S)，0或多个TLVs，根据消息类型变化。7.1.4ROID编码
余对象标识（ROID）唯一标识一个穴余对象、一个RG保护对象（比如链路、聚合组、VLAN等）。ROID编码见表5。
表5ROID编码
01234567890123456789012345678901ROD
ROID是一个8字节无符号整数，在相关的TLVs中使用。7.2RG连接消息
RG连接消息用来建立ICCPRG连接以及同一个RG内PEs之间单独的应用连接。没有携带应用连接TLV的RG连接消息只建立ICCPRG连接。携带有效应用连接TLV的RG连接消息，不仅建立应用连接，而且如果ICCPRG连接没有建立的话，也同时建立。PE向同一个RG内的每个PE发送RG连接消息。哪些PE属于同一个RG可以由配置或某种自动发现机制来决定。如果一个设备是多个RGs的成员，那么PE针对每个RG都会发送不同的连接消息。RG连接消息的格式如下：
ICCheader，消息类型为\RG连接消息”（Ox0700)：一ICCSenderNameTLV，包含发送者的主机名字；YD/T2901-2015
0个或1个应用相关连接TLV。
应用相关连接TLVs有：
一PW穴余组连接TLV：
mLACP连接TLV：
MSP连接TLV，其具体格式是可选的。这些TLVs的细节见第8章，MSP连接TLV相关内容参见附录A。7.2.1 ICC Sender Name TLV
带发送者主机名字的TLV，名字是UTF-8编码。它主要用于RG管理，易于网络操作，其格式如表6所示。
表6带发送者主机名字的TLV格式01234567890123456789012345678901uF
Type=0x0001
发送者名字
各个字段取值或含义如下：
一U及F为O：
Type为0x0001：
Length
Length，除了U-bit、F-bit、Type和Length字段外的TLV字节长度；一SenderName，发送者的主机名字，UTF-8编码，不超过80个字符。7.3RG连接断开消息
RG连接断开消息有两个目的：指示RG内某个应用连接关闭或者由于PE离开这个RG，使得ICCPRG连接自身断开。RG连接断开消息格式见表7。表7RG连接断开消息格式
01234567890123456789012345678901u
Message Type-0x0701
Type=0x0005 (ICC RG ID)
Disconnect Code TLV
MessageID
ICCRGID
OptionalApplication-specificDisconnectTLVOptional Parameter TLVs
各个字段取值或含义如下：
—U为0：
MessageType为0x0701：
Message Length
Length=4
小提示：此标准内容仅展示完整标准里的部分截取内容，若需要完整标准请到上方自行免费下载完整标准文档。