以太网OAM

版权声明：本文内容并非原创，以下内容为网上搜索的到资源整理以及相关协议的翻译。

定义：以太网OAM全称为以太网Operations Administration and Maintenance，即针对以太网的操作管理和维护。
以太网OAM主要功能可分为以下两部分：

• 故障管理
  • 通过定时或手动发送检测报文来探测网络的连通性。
  • 提供类似IP网络中的Ping（Packet Internet Groper）和Traceroute的功能，对以太网进行故障确认和故障定位。
  • 和保护倒换协议配合，当检测到连通性故障后触发保护倒换，以实现网络业务中断小于等于50毫秒的运营级可靠性目标。
• 性能管理

  性能管理主要是指对网络中的丢包、时延、抖动进行衡量，也包括对网络中各类流量进行统计。性能管理通常在用户接入点实施。有了性能管理工具，运营商可通过网管系统监测网络运行情况、定位故障，确认网络转发能力是否符合与用户签订的SLA（Service Level Agreement）。

以太网OAM能够有效提高以太网的网络管理能力和维护能力，保障网络的稳定运行。

目的：以太网技术自诞生起，以其简单易用、价格低廉的特点逐步成为局域网的主导技术。

以太网最初主要应用于局域网。局域网对可靠性、稳定性要求都较低，因此以太网一直缺乏运行维护管理机制，这一点已经成为阻碍以太网发展的严重障碍。因此，在以太网上实现OAM（Operations Administration and Maintenance）成为一个必然的发展趋势。

链路级以太网OAM

链路级以太网OAM技术，如遵循IEEE 802.3ah协议的EFM OAM（Ethernet in the First Mile OAM），针对两台直连设备之间的链路，提供链路连通性检测功能、链路故障监控功能、远端故障通知功能、远端环回功能。

CE设备是用户网络边缘设备。CE设备用来连接用户网络和运营商网络。与CE设备不同，PE设备是运营商网络边缘设备，它用来连接运营商网络和用户网络。

遵循IEEE 802.3ah协议的EFM OAM是Ethernet in the First Mile OAM（以太最后一公里OAM）的简称。它属于链路级以太网OAM技术，是一种较为简单的OAM协议，提供点到点的故障检测，主要用于两台直连设备之间链路的OAM检测。

网络级以太网OAM

遵循IEEE 802.1ag协议规定的以太网CFM（Connectivity Fault Management），属于网络级以太网OAM技术针对网络实现端到端的连通性故障检测、故障通知、故障确认和故障定位功能，可用于监测整个网络的连通性，定位网络的连通性故障，并可与保护倒换技术相配合，提高网络的可靠性。

CFM作为以太网的OAM，主要提供了链路连通性检测、环回功能和链路跟踪功能。

以太网技术简单易用、价格低廉、且带宽可不断提高，无论是作为一种业务还是作为一种网络结构在企业网、广域网范围内都已经得到广泛应用。随着以太网推广的范围逐渐扩大，对以太网OAM功能的需求也越来越强烈。但是传统以太网可维护、可运营能力比较弱，以太网OAM的出现很好的解决了这一问题。

OAM故障联动

OAM故障联动用于在不同的检测协议之间传递故障信息，例如在同属于以太网OAM的EFM OAM和以太网CFM之间传递故障信息，在以太网OAM和BFD之间传递故障信息等。随着以太网OAM、BFD、MPLS OAM等检测协议的不断推广运用，OAM故障联动模块将承担起更多的使用场景。

EFM OAM与以太网CFM的比较：

本文主要涉及网络级OAM的实现与应用，链路级以太网OAM（EFM）暂时不做讨论。

参考协议

以太网CFM原理描述

CFM（Connectivity Fault Management，标准协议802.1ag）定义了基于以太网承载网络的连接检测的OAM功能，包括CC/LB/LT，适用于大规模组网的端到端场景，是网络级的OAM。

基本概念

• MD

  维护域MD（Maintenance Domain）是指对其实施以太网CFM管理的一个网络或一个网络的一部分，一个MD通常由一个统一的ISP（Internet Service Provider）或者运营商进行管理。

  每个MD有一个级别，取值范围是0～7，值越大MD的级别越高。低级别MD的802.1ag协议报文进入高级别的MD后被丢弃，高级别MD的802.1ag协议报文可以穿越低级别的MD。

  在实际应用中，如果某个MD内还包含另一个范围较小的MD，在对大的MD进行连通性检测时，802.1ag协议报文需要穿越小的MD，则可将大MD的级别配置得比小MD高，以实现802.1ag协议报文穿越。

  例如在[图2-7]所示网络中，MD2包含在MD1中，MD1的802.1ag协议报文需要穿越MD2。因此，将MD1的级别配置为6，MD2的级别配置为3，这样MD1内的802.1ag协议报文就可以穿越MD2实现整个MD1的连通性故障管理，而MD2的802.1ag协议报文不会扩散到MD1中。

• 默认MD

  standard2007标准版本规定，每台设备上可配置一个默认MD。默认MD可用于使高优先级MD感知低优先级MD内部拓扑。

  如[图2-8]所示，在MD嵌套场景下，高优先级MD中的设备可能是低优先级MD的边缘设备和中间设备。当高优先级MD内的802.1ag协议报文穿越低优先级MD时，报文会透传；在没有配置默认MD的情况下，如果需要感知低优先级MD内部拓扑，需要在低优先级MD内设备上的指定端口上创建指定优先级的MIP节点，用以回复LBR或LTR报文给高优先级MD中的设备。

  如果在低级别MD中的设备上配置与高优先级MD相同级别的默认MD，则设备基于默认MD按规则自动生成相应级别的MIP节点回复LBR或LTR报文给高优先级MD中的设备，这样高级别MD就能感知低级别MD中拓扑结构的变化，也实现了整个MD1的连通性故障管理。

  默认MD的级别必须高于本设备配置MEP节点所有MD的级别，和高优先级MD的级别相等，用于高级别CCM报文穿越，创建MIP节点回复LTR报文。

  IEEE802.1ag标准版本规定，每台设备上可配置一个默认MD，一个默认MD可以关联多个VLAN。VLAN内的端口将基于默认MD按规则自动创建MIP节点。

说明：

在配置了默认MD的设备上，默认MD关联的VLAN一定不能关联MA。 

• MA

  维护联盟MA（Maintenance Association）是MD的一部分。一个MD可以划分成一个或多个MA。以太网CFM对每个MA分别进行连通性故障检测。

  在运营商的网络中，通常一个VLAN对应一个业务实例，通过划分MA可实现对传输某个业务实例的网络的连通性故障检测。

  MA的级别等于它所在的MD的级别。

• MEP

  如[图2-9]所示，维护联盟边缘节点MEP（Maintenance association End Point）是MA的边缘节点。

  MEP位于设备的接口上，手工创建。MEP的级别等于它所在的MD的级别。

  图2-9 MEP和MIP

对于运行以太网CFM的网络中的任意一台设备，该设备上的MEP称为本地MEP，同一MA内其它设备上的MEP对本设备而言称为远端维护联盟边缘节点RMEP（Remote Maintenance association End Point）。 MEP又分为outward型MEP和inward型MEP，方向向外的MEP称为outward型MEP，方向向内的MEP称为inward型MEP。 inward型MEP发出的802.1ag协议报文通过当前MA关联VLAN内的所有接口（除MEP所在接口）向外发送，即在当前MA关联的VLAN内广播；outward型MEP发出的协议报文直接通过该MEP所在的接口向外发送。 MEP的方向是MEP必需的参数，如[图2-10]所示，图中的三角形表示在该端口上配置的MEP。 图2-10 outward和inward型MEP 

注意：

如果配置MEP类型为outward，报文会穿透Block接口，可能会引起MAC震荡。 

维护端点MEP（Maintenance association End Point）确定了维护域MD的范围和边界，是维护联盟MA的边缘节点。维护端点所属的维护联盟和维护域确定了该维护端点所发出报文的业务和级别。维护端点的级别决定了其所能处理的报文的级别，维护端点所发出报文的级别就是该维护端点的级别。当维护端点收到高于自己级别的报文时，不会进行处理，而是将其按原有路径转发；而当维护端点收到小于或者等于自己级别的报文时，才会进行处理。

维护端点位于设备的接口上，手工创建。维护端点的级别等于它所在的维护域的级别。

对于运行以太网CFM的网络中的任意一台设备，该设备上的MEP称为本地MEP，同一MA内其它设备上的MEP对本设备而言称为远端维护联盟边缘节点RMEP（Remote Maintenance association End Point）。

维护端点具有方向型，分为inward型MEP和outward型，如[图2-4]所示。

• inward型MEP不向它所在端口发送报文，而是向设备的其它端口发送报文。
• outward型MEP向它所在端口发送报文。

图2-4 MEP方向示意图

• MIP

  如[图2-10]所示，维护联盟内部节点MIP（Maintenance association Intermediate Point）是MA的内部节点。

  MIP位于设备的接口上，是按规则自动创建的，MIP的创建规则有三种,如[表2-1]所示

  表2-1 MIP的创建规则

  MIP创建规则	说明
  default型	如果指定MD或默认MD所属的接口不存在更高级别的MEP，并且不存在更低级别的MIP，则可以在该接口上创建MIP。
  explicit型	如果在指定MD或默认MD所属的接口存在更低级的MEP但不存在更高级别的MEP，而且不存在更低级别的MIP，则可以创建MIP。在本类型下，接口上只有已配置了更低级别的MEP才可能创建MIP。
  none型	不自动创建MIP

  如果，设备SwitchA已经基于MD1配置了MIP节点的创建规则为default，MIP节点创建过程如下：

  1. 比较各个MEP，找出最高级别的MEP，最高级别的MEP为5。（MEP的级别由自身所属的MD决定。）
  2. 选择高于5级MEP的最小MD，MD的级别为6。
  3. 创建级别为6的MIP节点。
     如果级别6或者大于级别6的MD都不存在，则MIP节点将无法创建。
     如果SwitchA上已经存在级别为1的MIP节点，则MIP节点按规则也无法创建。

     
     
     
     

• MP
  MEP和MIP统称为维护节点MP（Maintenance Point）。
  
  

CFM协议报文

CFM是通过携带不同标记的CFM协议报文实现链路的故障检测和定位的，其协议报文格式如[图3-1]所示。

各字段含义如[表3-3]所示。

表3-3 CFM协议各字段的含义

表3-4 不同类型的CFM协议报文

Continuity Check Message Group Destination MAC Addresses 见下表，DMac的最后一位由MD level决定：

Linktrace Message Group Destination MAC Addresses 见下表，DMac的最后一位由MD level决定：

1.3.1 Encoding of CFM Protocol Data Units

1.3.1.1 Structure, representation, and encoding

所有CFM PDU均应包含整数个八位字节.

CFM PDU中的八位字节从1开始编号，并按放入使用的MAC内部子层服务（ISS或EISS）实例的请求或指示的MAC服务数据单元（MSDU）的顺序递增。 由CFM实体提供。

八位位组中的位按照从高到低的顺序从1到8进行编号，其中1是八位位组中的最低有效位。

如果使用图表表示CFM PDU中的八位位组和位，则在页面上显示的八位位组比在页面上相同高度处的后续八位位组和在后续八位位组的左侧显示的八位位低。 同一八位位组中其他位左侧显示的位编号更高

在将两个或多个连续八位位组表示为十六进制值的情况下，左侧显示的是编号较低的八位位组，第一个八位位组后面的每个八位位组后面都带有连字符，例如01-80-C2-00-00-00。

当使用连续的八位位组编码二进制数时，较低的八位位组数具有更大的有效值。 当八位位组中的连续位用于编码二进制数时，较高的位号具有最高有效值。 当连续八位位组中的位用于编码二进制数时，较低的八位位组号构成该数位的更高有效位。 标志被编码为单个位，如果该位取值为1，则将其设置为（True），否则将其清除（False）。 八位位组中的其余位可用于编码其他协议字段。

1.3.1.2 CFM encapsulation

标识CFM PDU的方式取决于介质。 对于使用“类型/长度”字段的介质，例如IEEE 802.3介质，标识由两个八位字节组成，其中包含表21-1中所示的类型值（以十六进制表示）。 需要LLC封装的媒体（例如IEEE 802.11）使用表21-2中所示的SNAP编码（以十六进制表示）。

1.3.1.3 CFM request and indication parameters

• destination_address parameter
  就它们所针对的CFM实体而言，有三类CFM PDU：
  a）针对服务实例（CCM）中所有MEP的那些；
  b）在一个服务实例（LTM）中，在某个MD级别上，寻址到与发射MP紧邻的一组MP的那些；和
  c）那些针对单个特定MP（LBM，LBR，LTR）的文件。

  
  
  
  
  
  
  
  

承载属于两个不同MA但处于相同MD级别的CFM PDU的帧以与数据帧在由那些MA监视的相应服务实例中彼此区分的相同方式彼此区分。

在支持VLAN的网桥中，区分服务实例的是VID。监视通过其VID区分的服务实例的CCM使用表8-9中列出的组MAC地址作为destination_address。监视VID区分的服务实例的LTM使用表8-10中所示的LTM.destination_address的除最后三位外的所有其他位均由操作码（CCM或LTM）固定。如这两张表所示，destination_address的最后三位与CFM PDU标头的MD Level字段匹配。

• source_address parameter
  发送PDU的MP的个人MAC地址。 这是发送MP的MAC地址。 MP的MAC地址不一定是唯一的； 在同一网桥端口上配置的MP可以共享相同的MAC地址。 用于分配组织唯一标识符（OUI）的原则要求通用唯一的MAC地址（U / L位= 0的那些地址，请参阅IEEE Std 802-2001，9.2）不用于与物理实例分开创建MP MAC地址 IEEE 802 MAC。 有关将MAC地址分配给MP的讨论，请参见J.6。
  
  

1.3.1.4 Common CFM Header

1. MD Level
   （最高3位）整数，标识数据包的维护域级别（MD Level）。 较高的数字表示较高的维护协会，这些协会的物理覆盖面最大，客户的CFM数据包的价值最高。 较低的数字对应较低的维护协会，即物理联系范围更有限的维护协会，单个网桥或物理链路的值最低
   
   
2. Version
   （最低5位）协议版本号，始终为0。在收到时被忽略。
   
   
3. OpCode
   （1个字节）OpCode字段指定CFM PDU其余部分的格式和含义。 OpCode字段的某些值保留供IEEE 802.1和/或其他组织分配。 表21-4中显示了各种CFM PDU类型的值。 分配新的OpCode值时，以刺激响应方式运行的CFM PDU对（例如LBM / LBR或LTM / LTR对）将使用偶数/奇数对值，以使两者的奇数（数字较大） 值是刺激，响应是偶数（数值较小）
   
   

4. Flags
   （1个八位位组）对于每个操作码分别定义了标志字段的使用
   
   
5. First TLV Offset
   （1个字节）偏移量，从第一个TLV偏移字段之后的第一个八位字节开始，一直到CFM PDU中的第一个TLV。 对于每个操作码字段值，应按照规范中的指示发送“第一TLV偏移”字段的值，如下所示（21.6.2、21.7.2、21.8.2和21.9.2）
   
   

1.3.1.5 TLV Format

TLV代表类型，长度，值，并表示对PDU中的可变长度和/或可选信息进行编码的方法。 TLV不与任何特定的单词或八位字节边界对齐。 TLV彼此跟随，TLV之间没有填充。

• General format for CFM TLVs
  
  
  

• Organization-Specific TLV
  类型=31。任何组织都可以定义TLV以用于连接故障管理。 表21-7中显示了此类TLV的格式。 “ OUI”是可从IEEE获得的组织唯一标识符。 12子类型是必需的，因此，如果OUI的所有者需要更多特定于组织的TLV，则不需要附加的OUI。
  

  
  
  
  

提供此TLV类别是为了允许不同的组织（例如IEEE 802.1，IEEE 802.3，ITU-T以及各个软件和设备供应商）定义TLV，这些TLV将信息发布到连接到同一媒体的远程实体，但必须遵守以下规定： 限制条件：

• Sender ID TLV
  类型=1。标识在其上配置了传输MP的网桥，并且还可以包括该网桥的管理地址。 允许的值是包含在IEEE 802.1AB LLDP的9.5.2和9.5.9中的机箱ID TLV和管理地址TLV中包含的值，这些值已修改为适合CFM TLV，如表21-8所示。 是否发送发件人I
  D TLV，以及TLV中包含哪些信息，由受管理对象控制[12.14.3.1.3中的项目e），12.14.5.1.3中的d），项目12.14.6.1中的d）。 .3]。
  

  
  
  
  
  
  

注—管理地址域和管理地址的内容是根据MIB模块定义的。 因此，需要一个已发布的MIB模块来定义可以在“管理地址域”字段中使用的特定值。 但是，系统使用“管理地址域”字段并不要求系统可以通过SNMP进行管理。 例如，已发布的MIB模块可以为ITU-T X.25（1996）[B15]上的专有命令行解释器定义一个TransportDomain。

• Port Status TLV
  类型=2。端口状态TLV指示发送MEP所在的网桥端口传递普通数据的能力，而与MAC的状态无关。 该TLV的值由MEP变量enableRmepDefect（20.9.2）驱动，如表21-10所示。 表21-9列出了该TLV的格式。 端口状态TLV值的任何更改都会触发该网桥端口的MEP的CCM的一次额外传输。
  

  
  
  
  

在桥中配置的MEP，该位置与端口状态和VID成员集的单个值不相关，例如，在通过多个运行树实例的桥上，图22-9中位置5的MEP MSTP，不得传输端口状态TLV。

• Interface Status TLV
  类型=4。接口状态TLV指示配置发送CCM的MEP所在的接口（不一定是其所在的接口，请参阅J.6）或IETF RFC中的下一个较低接口的状态。 2863 IF-MIB。 表21-11列出了该TLV的格式。 枚举值如表21-12所示。 这些值对应于IETF RFC 2863中ifOperStatus的值。
  

  
  
  
  

• Data TLV
  类型=3。零个或多个八位位组的任意数据。 具有多种用途，包括传输不同的帧大小以测试MTU功能以及测试特定于数据的错误相关性。 数据TLV可以包含在LBM和LBR中，但不能包含在任何其他CFM PDU中。 除LBR外，任何CFM PDU的接收方均不得检查或解释数据TLV的内容。 数据TLV的格式如表21-13所示。
  

  
  
  
  

• End TLV
  需要。 类型=0。不存在“长度”和“值”字段。 结束TLV是CFM PDU中的最后一个TLV。 （缺少末尾TLV不会使接收到的CFM PDU无效，但是在某些情况下，如果帧不接收额外的报头（例如MACsec或其他VLAN标签），则帧错误可能会导致错误。）末尾TLV的格式如下所示： 表21-14
  

  
  
  
  

1.3.1.6 Continuity Check Message format

• Flags
  （1个八位位组）公共CFM标头的标志字段分为三部分，用于CCM，如下所示：
  a）RDI字段（21.6.1.1）;
  标志字段的最高有效位是RDI位。 如果设置了发送MEP的presentRDI变量（20.9.6），则此位设置为1；否则设置为0。
  b）保留字段（21.6.1.2）；
  不包括RDI字段和CCM间隔字段的标志字段的位由发送MP设置为0，并且不由接收MP检查[20.46.2中的项目b）]。
  c）CCM间隔字段（21.6.1.3）
  标志字段的最低有效三位构成CCM间隔字段。 CCM间隔字段的编码如表21-16所示。

  
  
  
  
  
  
  
  
  
  
  
  
  
  

• First TLV Offset
  （1个八位位组）CCM中“通用CFM报头”的“第一个TLV偏移”字段的发送方式为70。
  
  
• Sequence Number
  （4个八位位组）MEP在此字段中传输0或将CCIsentCCMs变量（20.10.2）的内容复制到该字段。
  
  
• Maintenance association End Point Identifier
  （2个八位位组）包含一个整数值。 该TLV指定从哪个MEP发送CCM
  Validation Test: MEPID is in the range 1–8191.

  
  
  
  

• Maintenance Association Identifier
  （48个八位位组）此字段包含发送MEP的MAID。 它分为六个子字段，必要时还加上一个八位字节填充，以填充其固定长度。 子字段是：
  a) Maintenance Domain Name Format (21.6.5.1);
  b) Maintenance Domain Name Length (21.6.5.2);
  c) Maintenance Domain Name (21.6.5.3);
  d) Short MA Name Format (21.6.5.4);
  e) Short MA Name Length (21.6.5.5); and
  f) Short MA Name (21.6.5.5).
  这些字段的总长度（包括填充）（如果存在）应为48个八位位组。 维护关联标识符字段有两种可能的格式，如表21-17和表21-18所示，具体取决于是否存在维护域名。
  

  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  

• Defined by ITU-T Y.1731
  （16个八位位组）ITU-T Y.1731（2006）定义了该字段的使用。 应在该字段中发送值为0
  
  
• Optional CCM TLVs
  在其规范允许的范围内，应在传输的每个CCM中包括以下TLV：
  a）发件人ID TLV（21.5.3）;
  b）端口状态TLV（21.5.4）; 和
  c）接口状态TLV（21.5.5）。
  下列TLV可以包含在发送的任何CCM中：
  d）特定于组织的TLV（21.5.2）。
  通过发送CCM的MEP可以以任何顺序放置本节中的可选CCM TLV。 接收方MP不得依赖CCM中可选CCM TLV的任何特定顺序来正常运行。

  
  
  
  
  
  
  
  
  
  
  
  
  
  

1.3.1.7 Loopback Message and Loopback Reply formats

1.3.1.8 Linktrace Message Format

1.3.1.9 Linktrace Reply Format

CFM实体管理

1.4.1 Maintenance Domain list managed object

• 维护域的名字（格式见802.1ag协议文档表【21-19】21.6.5.1）中的格式说明符）；
  
  
  

• 对该维护域的维护域托管对象的引用；

• 维护域的名字，格式见表21-19（21.6.5.1）中的格式说明符；默认
  值是字符串（格式4）“默认”；
  
  
• 要创建维护域的MD级别，默认值为0；
  输出：
  
  

1. 由于无效的维护域名，操作被拒绝；
2. 由于维护域名已经存在，操作被拒绝；
3. 由于MD级无效，操作被拒绝；
4. 接受操作;

1.4.2 CFM Stack managed object

1. 非法输入拒绝操作
2. 在指示的桥接端口或聚合端口上未在指示的MD级别和方向上配置MP
3. 配置了MEP
4. 配置了MHF
   b)MP的MA关联到的维护域管理对象（MD），或者表明没有与MP关联的维护域
   c)与MP关联的维护联盟管理对象（MA），或者表明没有与该MP关联的MA
   d)如果配置了MEP，则其MEPID；否则为0
   e)MP的MAC地址

   
   
   
   
   
   
   
   

1.4.3 Default MD Level managed object

1. 读取默认MD level管理对象；
   目的：
   读取与任何MA无关的vid上控制MHFs的默认参数表
   输入：
   VID值
   输出：
   a. 与VID相关的MHF的VIDs列表；这个列表第一个通常是MA的协议VID（Primary VID），如果列表为空，表示VID未指定给任何MA；
   b. 一个布尔值，指示该条目是有效的还是已被与相同VID和MD级别关联的维护联盟（MA）管理对象的存在所覆盖，并在其上配置了Up MEP。 如果此维护域（MD）对象有效，则为true。
   c. （可写）将要创建MHFs的MD level；
   d. （可写）一个枚举值，指示管理实体是否可以为此VID创建MHF，即defMHFnone（默认值1），defMHFdefault（2）或defMHFexplicit（3）;
   e. （可写）一个枚举值，它表示要在默认维护域中配置的MP发送的ID TLV（21.5.3）中包含的内容，包括sendIdNone（1，默认值），sendIdChassis（2） ，sendIdManage（3）或sendIdChassisManage（4）。

   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   

2. 写入默认MD level；
   目的：
   在默认参数表中写入条目以控制不与任何MA关联的VID上的MHF
   输入：
   a）VID列表，0表示没有VID。列表中的第一个VID是协议VID；
   b）1.4.3.1 读取默认MD level管理对象中的对象之一；
   输出：
   操作状态将采用下面情况值之一：

   
   
   
   
   
   
   
   
   
   
   
   
   
   

3. 操作被拒绝，因为创建或将这些VID分配给此MD level超出某些网桥端口支持的MD level的数量
4. 操作被拒绝，因为提供的VIDs在别的MA中已被使用，例如协议VID或是其他VID；
5. 操作下发成功。

1.4.4 Configuration Error List managed object

这个主要是记录端口下的一些错误配置，用以查询，暂时可以先忽略。

1.4.5 Maintenance Domain managed objects

每个网桥可以有任意数量的维护域管理对象（MD）。 为了使用包含该维护域名称的MAID创建MA，需要维护域管理对象。 从该维护域管理对象，可以访问并控制与此维护域管理对象关联的所有维护关联管理对象（MA）。

1. 如何读取MD信息？
   输入：
   MD相关信息
   输出：
   a）操作失败，因为相关MD不存在；
   b）（可写）一个枚举值，指示管理实体是否可以为此维护域创建MHF，可以是defMHFnone（默认值1），defMHFdefault（2）或 defMHFexplicit（3）
   c）（可写）一个枚举值，它表示要在此维护域中配置的MP发送的sender ID TLV（21.5.3）中包含的内容，包括sendIdNone（默认值），sendIdChassis（2）， sendIdManage（3）或sendIdChassisManage（4）
   d）（可写）要发送故障警报的网络地址，或指示“不发送故障警报”的值。默认值为“不发送”；
   f）显示的维护域管理对象中的对维护联盟管理对象（MA）（12.14.6）的相关信息

   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   

2. 如何写MD相关信息？
   输入：
   参考MD信息相关内容
   输出：
   由于维护域不存在，操作被拒绝；
   由于所选的管理对象为只读，操作被拒绝；
   由于所选管理对象的值无效，操作被拒绝；

   
   
   
   
   
   
   
   
   
   
   
   

3. 创建MA对象
   输入：
   a）对特定维护域管理对象的引用；
   b）该维护域内的MA的简称MA名称，包括表21-20（21.6.5.4）中的格式说明符，默认值为包含主要字段的2字节整数（格式3）VID；如果MA未附加到VID，则为0
   

   
   
   
   
   
   
   
   

1.4.6 Maintenance Association managed object

1. 读取MA相关信息：
   a）运行状态。这采用以下值之一：
   1）由于不存在MA而拒绝了操作；
   2）接受操作；
   b）此MA监视的VID，如果MA未附加到任何VID，则为0。第一个VID返回的是MA的primary VID；
   c）（可写的）枚举值，指示管理实体是否可以为MA创建MHFs，参数：defMHFnone（1），defMHFdefault（2），defMHFexplicit（3）或defMHFdefer（4），（22.2.3），默认值为defMHFdefer;
   d）（可写的）枚举值，指示由该MA中配置的MP发送的发件人ID TLV（21.5.3）中将包含什么（如果有的话）：
   1）sendIdNone：不发送发件人ID TLV；
   2）sendIdChassis：发送发送者ID TLV的Chassis ID长度，Chassis ID子类型和Chassis ID字段，但不发送管理地址长度或管理地址字段；
   3）sendIdManage：发送发送方ID TLV的管理地址长度和管理地址，但发送Chassis ID长度为0，不发送Chassis ID子类型和Chassis ID字段；
   4）sendIdChassisManage：Chassis ID长度，Chassis ID子类型，Chassis ID，管理地址长度和管理地址字段全部发送；
   5）sendIdDefer ：（默认值）发件人ID TLV的内容由12.14.5.1.3中的维护域管理对象d）确定；
   e）（可写的）除0以外的枚举值，表示MA中所有MEP使用的CCM传输间隔（20.8.1，21.6.1.3）（默认为1 s）；
   f）（可写）要向其发送故障警报（12.14.7.7）的网络地址，指示“未指定”的值，或指示“不发送故障警报”的值。如果“未指定”，使用的地址是来自维护域管理对象的地址[12.14.5.1.3中的项目e]]；

   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   

2. 写MA相关信息
   操作状态。 这采用以下值之一：
   1）由于不存在MA而拒绝了操作；
   2）由于所选管理对象为只读而拒绝了操作；
   3）由于缺乏设置此变量的权限，操作被拒绝；
   4）由于所选管理对象的值无效，操作被拒绝；
   5）接受操作。

   
   
   
   
   
   
   
   
   
   
   
   

3. 创建MEP管理对象
   在特定网桥端口或聚合端口上的维护协会管理对象内创建新的维护协会端点管理的对象（MEP）。
   输入：
   a）对特定维护协会管理对象的引用（12.14.6）；
   b）创建的MEP的MEPID（默认为1）；
   c）一个值，该值指示MEP在网桥端口或聚合端口上所面对的方向，
   要么：
   1）向下（活动SAP远离帧过滤实体）（默认设置）；
   2）向上（活动SAP更靠近帧过滤实体）；
   d）一个接口，可以是网桥端口，也可以是网桥端口内的聚合IEEE 802.3端口。
   输出：
   1）由于不存在MA而拒绝了操作；
   2）操作被拒绝，因为指定的MEPID已存在于此网桥的此MA中；
   3）操作被拒绝，因为MEPID不在MA的MEPID列表中[项目12.4.1.3中的g）]；
   4）由于存在与该MEP相同的VID，在相同的MD级别上存在相同方向（向上或向下）的MEP，因此拒绝了操作（如果该MEP的MA没有VID，则没有VID） ，在该网桥端口或聚合IEEE 802.3端口上；
   5）操作失败，因为此MA中列出的一个或多个VID已分配给在任何网桥端口上配置了Up MEP的其他MA；
   6）操作被拒绝，因为网桥无法在该网桥端口或聚合的IEEE 802.3端口上实例化MEP；
   7）操作失败，因为不能为没有VID的MA配置Up MEP；
   8）操作被拒绝，因为此MA上存在一个MEP，且其上/下参数的值不同（在12.14.6.3.2中的项目c）]；
   9）接受操作。

   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   

4. 删除MEP管理对象
   输出：
   1）操作拒绝，因为没有这个MEP；
   2）接受操作；

   
   
   
   
   
   

1.4.7 Maintenance association End Point managed object

CFM 操作原理

CFM引入以下概念来支持多个独立运营商，每个概念均支持多个独立客户的服务实例：

a）维护域（18.1）是由单个运营商控制的网络的一部分，用于支持绑定维护域的域服务访问点（DoSAPS，18.1）之间的连接。

b）CFM PDU中包含的维护域级别（MD级别为18.3），允许每个运营商的客户也使用CFM并在需要时充当运营商，在其自身的连接上复用提供的服务实例。

路径发现使用Linktrace协议（20.3）确定通过MA到达目标MAC地址（从MEP到另一个MP）的MIP的路径。此目标MAC地址可以是MIP，MEP或任何其他单个MAC地址的目标MAC地址。 Linktrace消息（LTM，20.3.1）从MEP组播到它的相邻MIP，再从MIP组播到MIP，再到终止路径的MP。路径上的每个MIP以及终止的MP将单播Linktrace答复（LTR，20.3.2）返回到始发MEP。 LTM由管理措施触发。原始MEP对答复进行分类，以供管理员检查。

故障检测使用连续性检查协议（20.1）来检测连接失败和服务实例之间的意外连接。每个MEP可以定期发送多播连接性检查消息（CCM），以宣布MEP及其MA的身份，并跟踪从其他MEP接收到的CCM。所有连接性的故障都可以通过接收的CCM消息与本地MEP配置的期望值之间进行比较后的差异而得之。跟踪的CCM的状态可供管理员检查。

故障验证和故障隔离是通常在故障检测之后执行的管理操作。故障验证还可以确认成功启动或恢复连接。管理员使用环回协议（20.2）进行故障验证。可以命令MEP向MA中的MEP或MIP发送单播回送消息（LBM，20.2.1），可以从CCM（仅MEP）或LTM / LTR（MEP或MIP）中发现其MAC地址。接收方MP通过将LBM转换为发送回原始MEP的单播回送应答（LBR，20.2.2）进行响应。该MEP记录响应以供管理员检查。

MEP提供了故障通知，该MEP在其MA中检测到连接故障，或者是由于未收到预期的CCM，由于收到了意外或无效的CCM，或者是因为CCM携带了其关联的网桥端口故障的通知。

故障恢复由生成树协议（第13条）和网络管理员的活动提供，例如纠正配置错误或替换本标准范围之外的故障组件。

1.5.1 Maintenance Domains and Domain Service Access Points

“域”可以定义为能够向该区域之外的系统提供连接的网络或网络的一部分。 它包含一组DoSAP，域可以在该DoSAP上或打算向域外的系统提供连接。 每个DoSAP都是EISS或ISS的一个实例。 因此，维护域是要管理连接性故障的域或域的一部分。

每个维护域都可以单独管理。每个维护域都分配了一个维护域名。应该在操作员所使用或可用的所有方法中选择唯一的方法，以方便识别维护域的管理责任。

CFM PDU格式支持创建维护域名称，该域在CFM用来防止服务实例的意外连接的域上是唯一的。理想情况下，这些名称在全球范围内是唯一的。

1.5.2 Service instances and Maintenance Associations

注1 —为了适应ITU-T Y.1731（2006）中所表达的服务提供商的要求，可以将维护域名配置为空，在这种情况下，short MA名称需要全局唯一。为了针对服务实例的意外连接提供全面的保护。全局唯一的short MA名称的适当选择在ITU-T Y.1731中定义。

1.5.3 Maintenance Domain Levels

下图18-5说明了维护域，服务实例和MA的嵌套。它说明了嵌套的服务实例，每个实例都在维护域中配置了一个MA。有七个维护域，因此说明了七个服务实例。在（白色）“提供者” MD级别，服务实例被提供给单个“客户” C1。该客户创建了自己的（灰色）服务实例，并配置了一个MA来验证提供商所提供的服务实例的完整性。显示了多个级别的嵌套维护域：

图18-6中的端口g也是以下示例的一个事实：只有MD级别区分端口g的提供商和运营商级别维护域。图18-5和图18-6中所示的示例网络中的单个服务实例是通过右侧操作员的维护域在具有单个VID的单个VLAN上承载的。在该维护域内，无法区分该VID上的数据帧是属于运营商，提供商还是客户维护域。它属于所有人。但是，MD级别允许CFM PDU与不同的维护域相关联，即使它们共享相同的VID。

端口j和端口r已添加到图18-6中。 它们在图18-5中不存在。 两者都表示尚未配置为支持服务实例或MA的DoSAP。 为了通过连接故障管理确保网络的完整性，应将这些DoSAP配置为禁用。

可以将端口k，m，n和s配置为灰色服务实例的ISAP，从而在操作员MD级别提供MIP。 可以使用提供者MD级别的MIP配置端口e，使用客户MD级别的MIP配置端口g。

下图18-7说明了MD级别的使用，以允许用户使用由两个桥接的维护域以及每个维护域的操作员提供的连接性的CFM。 它显示了图18-5的垂直切片，其中包括两个客户的设备以及连接它们的网络路径。 从图18-7可以看出，为什么需要MD级来标识CFM PDU； 否则，例如，桥接端口b将无法判断给定的CFM PDU是sunk（MD级别2或3）还是passed （MD级别5）。

CFM实体操作

注—第18条介绍了CFM操作的原理以及支持它的网络体系结构概念。 第20章规定了每个MP组件所操作的协议，第21章规定了那些协议使用的PDU格式。 第22章进一步描述了系统和网络中CFM的使用。

本节中的操作模型为指定MEP和MIP的外部可观察到的行为提供了基础，并且无意于对实现施加其他约束。 这些可以采用与指定的外部可观察到的行为兼容的任何内部操作模型。 设备符合该标准的纯粹是可观察的协议。

1.6.1 Maintenance Points

1.6.2 Maintenance association End Point

可以在网桥端或局域网的终端创建MEP。

1.6.2.1 MEP定义

配置有相同MAID值的MEP集合定义了一个MA。因此，可以说MA而不是MEP拥有这一参数。但是，MA是一个分散实体，可以在多个地理上分离的网桥之间散布。每个网桥都有一个针对MA的维护协会管理对象，从中可以推导出其MEP的MAID，MD级别和主VID。对于特定的MEP，可以覆盖MA的哪个VID作为主要VID的选择。尽管此信息可能配置不正确（即与某些其他网桥配置不同），但是维护协会管理的对象可确保在单个网桥中对MEP进行统一配置。

每个单独的MEP都配置有在该MA中唯一的MEPID。同样，维护协会管理的对象有助于维护唯一性，因为它将单个网桥和同一MA中的MEP的配置参数联系在一起，并至少在那个网桥中确保MEPID的唯一性。

MAID可以采用多种形式（请参见21.6.5.1），包括基于域名的字符串。为了防止在系统之间意外连接时发生错误操作，MAID在CFM将为其提供这种保护的域上是唯一的。如果MAID是全局唯一的，则该域是全局的。 CFM只能通过MAID唯一的一组MEP来检测连接错误。

MEPID是范围为1–8191的整数。它为每个MEP提供MEP验证MA正确连接所需的唯一身份。

1.6.2.2 MEP功能

下图19-2说明了MEP的组成实体。 仅通过传递，重定向或过滤框架而不改变它们并且没有内部状态的实体以虚线轮廓显示； 那些生成或变换帧或具有内部状态的帧以连续的轮廓显示。 在第20章中指定了描述后一个实体的状态机。图19-2显示了两个封闭的SAP不相等。 图中上方的SAP是被动SAP。 它更靠近受监视服务实例的DoSAP。 图中较低的SAP是活动SAP，它面对受监视的服务实例。 因此，图19-2说明了第208页的图22-1中所示的Down MEP之一。为了说明图22-1的Up MEP之一，必须将图19-2颠倒过来。 还要注意在图中，有两条路径，其中一条仅存在于Up MEP中，而一条仅存在于Down MEP中。

从图中可以看出MP Level Demultiplexer，会根据收到的CFM PDU与本地配置的MEP level进行比较，从而进行不同的操作处理。

MP OpCode Demultiplexer：MEP中有两个MP OpCode解析器，Equal和Low OpCode解析器，而MHF中有一个。 每个MP OpCode解析器将CFM PDU分类，这些CFM PDU在其OpCode字段中携带不同的值（请参见21.4.3），然后将其丢弃或将其传递给适当的状态机。 那些与MP OpCode解析器识别的任何OpCode不匹配或太短而无法包含OpCode的PDU会被MEP的MP
OpCode解析器丢弃， 根据表19-1，那些与已识别的OpCode匹配的PDU将存储在一个变量中，并设置相应的布尔值。 这些变量依次触发状态机动作。 三个MP OpCode解析器将不同的OpCode集分开。 请参见图19-2和图19-3。

• MEP Continuity Check Receiver
  MEP连续性检查接收器接收其MD级别等于或小于MEP的MD级别的CCM。 MEP连续性检查接收器会处理等于或低于其自身MD级别的那些消息，而不考虑destination_address，并更新MEP CCM数据库。 MEP连续性检查接收器为为此MA配置的每个其他MEP维护一个远程MEP状态机实例（20.20）。此外，MEP连续性检查接收器会维护一个单独的实例，每个实例都属于远程MEP错误状态机（Remote MEP Error state machine ）（20.22）和MEP交叉连接状态机（Cross Connect state machine ）（20.24）
  
  

如果MEP的Continuity Check Receiver状态机的allRMEPsDead变量（20.9.4）被设置，并且如果MEP没有与任何VID关联而且是Down MEP（即，在图22-9中的位置5），则无论从Active SAP接收到的MAC_Operational参数的状态如何，MEP呈现给Passive SAP的MAC_Operational参数均为false。 Thus, a completely failed MA causes the attached Bridge Port to appear as a failed link.

可选地，MEP连续性检查接收器可以维护19.3.10中所述的MIP CCM数据库。各种错误条件（包括以比MEP更低的MD级别接收到CCM）导致远程MEP状态机检测到缺陷，进而可以生成故障警报。

• MEP Continuity Check Initiator
  连续性检查发起者仅在MEP的MD级别上发送连续性检查消息（CCM）。 连续性检查启动器的状态机在20.12中描述。
  
  
• MP Loopback Responder
  环回响应器仅在MP的MD级别上接收LBM，根据destination_address（19.4）对其进行验证和过滤，并作为响应发送LBR。 MP环回响应器的状态机在20.27中描述。
  
  
• MEP Loopback Initiator
  环回发起方仅在MEP的MD级别上发送LBM，并根据destination_address（19.4）进行验证和过滤，并对其他MP的环回响应者返回的LBR进行计数。 环回启动器的状态机在20.30中描述。
  
  
• MEP Linktrace Initiator
  Linktrace发起者仅在MEP的MD级别上发送LTM，并根据destination_address（19.4）进行验证，过滤，并对其他网桥的Linktrace响应者返回的LTR进行分类。 Linktrace发起程序的状态机在20.40中描述。 在Up MEP中，Linktrace发起者将其LTM传输到网桥的Linktrace响应器。 在Down MEP中，Linktrace Initiator通过MEP自己的主动多路复用器将其LTM传输到MEP的Active SAP
  
  
• MEP LTI SAP
  向上的MEP（但不向下的MEP）具有MEP LTI SAP，它是ISS或EISS的实例。 该SAP用于：
  a）传输由MEP的Linktrace发起者发起的LTM；
  b）从Linktrace响应器接收LTR。

  
  
  
  
  
  

• MEP Linktrace SAP
  每个MEP都有一个MEP Linktrace SAP，它是ISS或EISS的实例。 该SAP用于将收到的LTM中继到Linktrace响应器。
  注— MEP LTI SAP和MEP Linktrace SAP都是必需的，以便当Linktrace Responder向LTR返回LTR时，MEP知道LTR是否是对MEP生成的LTM的响应，从而将其引导到 MEP Linktrace发起者，或者LTR是否是对MEP先前收到的LTM的响应，因此将其转发到Active SAP。

  
  
  
  

• MEP CCM Database
  MEP CCM数据库由远程MEP状态机（20.20）维护，MA中配置的每个MEP都有一个条目。 除了远程MEP状态机使用的远程MEP变量（20.19），每个条目还包含从远程MEP的CCM获取的信息，如12.14.7.6.3 Read MEP Database中所列。 另见20.1.3。
  
  
• MEP Fault Notification Generator
  故障通知生成器使用MAdefectIndication变量（请参见20.9.3），以向MA所连接的维护域的管理员生成故障警报。 这可以通过发送SNMP通知来完成。 故障通知生成器的状态机在20.35中描述
  
  

1.6.2.3 MIP Half Function

一个MIP由一个桥接端口上的两个MHF组成，一个Up MHF和一个Down MHF。（有关详细说明，请参见J.6。）MHF可以维护一个MIP CCM数据库，与MEPCCM数据库分开。

• MHF identification
  每个MHF都具有一个用于管理目的的配置参数，并且MIP的所有MHF对该配置参数具有相同的值：
  a）MHF被分配到的维护域。出于数据流的目的，MHF具有以下特点：
  b）从其维护域或默认MD级别管理对象继承的维护域级别（MD级别）；
  c）一组主要VID，每个MA与MHF的维护域相关。
  注—当单个服务实例使用多个VID时，MHF会知道每个MA的VID集和主要VID。但是，与MEP不同，MHF没有使用MAID的机会，因此无法通过MAID进行标识。
  MHF与两个桥接端口关联。对于下行MHF，两个关联都具有相同的桥端口；对于Up MHF，这两个关联可以具有相同或不同的桥接端口（请参见
  19.4，J.6）。两个桥接端口是：
  d）配置了MHF的网桥端口；
  e）在其上实现MHF并从其继承其单独MAC地址的网桥端口

  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  

• MHF functions
  a）按照20.1、20.2、20.3和20.46的规定验证收到的LTM；
  b）（可选）验证收到的CCM并建立MIP CCM数据库；
  c）用20.2.2中定义的LBR响应LBM；
  d）通过转发LTM并响应20.3.2中定义的LTR来响应LTM。尽管定义为具有ISS或EISS接口，但MHF在使用EISS方面受到很大限制。特别：
  e）沿任一方向通过MHF的每个帧均以其vlan_identifier，canonical_format_indicator和drop_eligible参数发送出，与接收到的值相同。
  f）MHF转发的所有LBM都携带与接收到的LBM相同的vlan_identifier，canonical_format_indicator和drop_eligible参数。
  g）由MHF生成的所有PDU，即LBR和LTR，都以等于接收到的LBM或LTM的vlan_identifier所属的MA的主要VID的vlan_identifier进行发送。
  h）在任何帧上发出的canonical_format_indicator是与附加到网桥端口的MAC相对应的适当值。
  i）rif_information参数不存在于任何发出的帧上。

  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  

• MHF architecture
  图19-3说明了单个MHF。 仅通过传递，重定向或过滤框架而不改变它们并且没有内部状态的实体以虚线轮廓显示； 那些生成或变换帧或具有内部状态的帧以连续的轮廓显示。 在第20章中指定了描述后一种实体的状态机。图19-3显示了两个封闭的SAP不相等。 图中上方的SAP是被动SAP。 这更接近于受监视服务实例的ISAP。 图中较低的SAP是活动SAP，通过活动SAP主动发送和接收CFM PDU。 因此，图19-3说明了图22-1中所示的Down MHF之一。 为了说明图22-1的Up MHF之一，必须将图19-3反转
  
  
• MHF Level Demultiplexer
  MHF level解析器与上面描述的MP level解析器功能类似。
  
  
• MHF Type Demultiplexer
  MHF类型l解析器与上面中描述的MP类型l解析器功能类似。
  
  
• MHF Continuity Check Receiver
  可选的MHF连续性检查接收器接收CCM，对其进行验证，并按destination_address参数（19.4）对其进行过滤，然后将其提供给MIP CCM数据库。 从图19-3中，我们可以看到与MHF处于相同MD级别的所有CCM均已呈现给MHF Continuity Check Receiver。 在接收的CCM中没有检查其他信息。 特别是，没有将CCM中的MAID与MHF的MAID进行比较。不需要MHF连续性检查接收器及其维护的MIP CCM数据库，即可符合本标准。
  
  
• MIP CCM Database
  MIP CCM数据库可选地由MHF或MEP维护。 这是自上次重置网桥以来，呈现给网桥所有MP连续性检查接收器的所有CCM中每个三联的{FID，source_address，端口号}的列表。 MIP CCM数据库中的条目超时非常缓慢，大约一天，因此在信息不再用于帧转发之后很长时间就可以将其信息用于故障隔离。
  
  
• MHF Linktrace SAP
  每个MHF都有一个MHF Linktrace SAP，它是ISS或EISS的实例。 该SAP用于将收到的LTM中继到Linktrace响应器，并将LTR从Linktrace响应器传递到the MHF’s Active SAP.。
  
  

1.6.2.4 Maintenance Point addressing

MP中的CFM实体识别表8-9和表8-10中列出的CCM和LTM PDU的组播目的mac地址。此外，它们还可以识别正在运行MP的网桥端口的单个MAC地址。如果网桥使用个别MP地址模型（J.6.1）创建MP，则这是在其上配置MP的网桥端口；如果网桥使用共享MP地址模型创建MP，则这是CFM端口。

不能为Down MP分配一个单独的MAC地址[12.14.7.1.3中的项目i]，该地址与为任何其他网桥端口上的MP配置的个人MAC地址相同，因为如果两个网桥端口连接到相同的局域网，但是具有相同的MAC地址，那么两者都会响应发送到该MAC地址的LBM。 CFM协议经过专门设计，允许为Up MP分配一个单独的MAC地址[12.14.7.1.3中的项目i]，该地址与为某些其他网桥端口上的Up MP配置的单独MAC地址相同。从网桥的外部，不可能知道给定的CFM PDU实际上是从哪个Up MP传输的，或者给定的CFM PDU是从哪个物理实体传递的。有关将单个MAC地址分配给MP的讨论，请参见J.6。

注—表19-2和各种CFM接收实体的定义在识别某些个人或组MAC地址方面比CFM发送实体的相应定义更为自由。 例如，即使MEP连续性检查启动器只能发送多播CCM，MEP连续性检查接收器也可以识别单播CCM。 这允许将来增强CFM并改善与ITU-T Y.1731（2006）的兼容性。

1.6.2.5 Linktrace Output Multiplexer

1.6.2.6 Linktrace Responder

单个Linktrace响应器为网桥中的所有MHF和MEP服务。它通过MP和LOM中的Linktrace SAP和LTI SAP连接到网桥中的每个MP和LOM。

注— Linktrace响应程序不是维护点，而是协助维护点（MEP和MHF，19.2和19.3）执行其功能的实体。

为了最小化对LTM产生无限数量的响应的可能性，总是从单个网桥端口（20.3）上的网桥发送LTM。如果使用网桥端口的LLC实体（参见图22-1）在特定网桥端口上传输LTM，则网桥端口连接实体（8.5.1）会将LTM定向到LAN，但它也会通过就像BPDU一样，将其朝向帧过滤实体（8.6.3）。但是，BPDU永远不会传输到其他网桥端口，因为帧过滤实体会根据其目标MAC地址对其进行过滤。 MHF在不同桥接器端口上不同MD级别上的放置（全部用于同一VLAN），因此无法以这种方式过滤LTM。因此，Linktrace Responder通过destination_address参数（19.4）过滤传入的LTM，并且需要一条路径将LTM仅沿网桥端口，LAN而不是帧过滤实体引导。

此路径由MEP（图19-2），MHF（图19-3）和LOM（图19-5）中的Linktrace SAP提供。当LTM首次遇到适当MD级别的MP时，Linktrace SAP也可用于将接收到的LTM定向到Linktrace响应器。

参见图22-1，我们可以看到，由Down MEP Linktrace发起者发起的LTM被引向LAN，并根据需要在单个桥接端口上输出。对于由Up MEP发起的LTM，情况有所不同。实际上，Up MEP所在的网桥是Linktrace协议的第一跳。 MEP LTI SAP是必需的，以便提供一条路径，MEP可以通过该路径将其原始LTM定向到Linktrace响应器。 Linktrace响应器也可以使用此路径将生成的LTR返回给MEP Linktrace发起方。有关这些路径的图解说明，请参见图20-13。

CFM协议以及状态机

1.7.1 Continuity Check protocol

连续性检查协议由 MEP Continuity Check Initiator (19.2.9), the MEP Continuity Check Receiver (19.2.8) 以及可选的在MHF的the MHF Continuity Check Receiver(19.3.9) 中执行。

为了充分利用CFM的优势，运营商将“correct connectivity”定义做为MEP的配置。如果为每个服务实例定义了一个MA，则连续性检查协议可以检测到100％的所有连接故障，交叉连接错误或配置的MA边界内发生的配置错误。

CCM的传输速率是可配置的，以适应错误报告的不同需求以及网络设备的不同功能。只需10.8 ms即可检测到三个CCM的丢失（见表21-16）。交叉连接的CCM的接收是瞬时发生的。

MEP使用自己配置的计时器来检测CCM的丢失，而不是使用发送方的传输速率（在CCM中发出信号），以最大程度地降低跟踪数百个其他MEP的MEP的复杂性。当收到有效的CCM时，计时器将重置，如果计时器到期，则声明缺陷。选择计时器值，以使给定的远程MEP丢失三个连续的CCM会触发该远程MEP的缺陷，并选择计时器精度以确保避免出现过早的缺陷指示。此外，MEP中的状态机会跟踪带有意外信息的远程MEP的CCM，未在接收MEP中配置的远程MEP的CCM，来自较低MD级别的CFM PDU或来自另一个MA的MEP的CCM

比帧计数更重要的事实是，当来自两个不同服务实例的MEP意外连接时，将CCM设置为多播帧可以检测到交叉连接错误。这种类型的错误可能是由于接线错误或两个维护域之间边界处的VID映射参数配置错误而导致的。如果将CCM单播到特定的MAC地址，则将不会检测到两个服务实例的合并，例如两个点对点服务的意外连接到4-SAP LAN服务中;单播CCM仍将正确传递。

此方案还指出了为什么全局唯一的MAID如此重要的原因。对CCM的接收进行编录可以确保MEP（例如MEP 1）知道它是从正确的一组远程MEP接收到的；它不能确保远程MEP接收到由同一MEP传输的CCM。例如，假设在10-MEP MA中，所有MEP 1的CCM都丢失了。 MA中的所有其他MEP都将知道MEP 1的问题，因为它们不会接收1的CCM。但是，MEP 1本身不会意识到这个问题。为了让操作员确定MA是否正常工作，必须检查MA中的每个MEP。

因此，CCM携带一个单一的远程缺陷指示（RDI）。 CCM中没有RDI表示发送方MEP正在从所有已配置的MEP接收CCM。对于MEP 1的单向连接，MEP 1将从每个未接收MEP 1（或任何其他MEP）CCM的远程MEP接收CCM中的RDI。因此，每个MEP（包括仅接收的MEP 1）都知道存在问题。 RDI的存在使系统管理员可以检查属于MA的任何单个MEP，并发现MA中是否有正在检测缺陷的MEP，以及哪些特定的MEP有缺陷。

序列号应在每个CCM中发送。接收器可以使用该序列号来检测和计数CCM损失。通过检测偶尔的CCM丢失，网络管理员可以注意到网络连接不理想等情况，例如过载的链路，并在出现连接故障和随之而来的故障警报之前对其进行纠正。

• MAC status reporting in the CCM
  CCM可以在端口状态TLV（21.5.4）和接口状态TLV（21.5.5）中携带有关在其上配置了发送MEP的网桥端口和/或聚合端口的状态的信息。该信息不严格属于维护协会的范围，该协会不受发送和接收CCM的MEP的限制。但是，通过在Up MEP的CCM中提供网桥端口和聚合的端口状态信息，此TLV可以在维护协会外部立即检测到错误。反过来，这支持故障隔离，在该故障隔离中，在与服务实例的连接点而不是在支持该服务实例的设备内部出现问题。当两个运营商用来支持服务实例的设备之间的边界是可能发生故障的链接或连接时，端口状态TLV和接口状态TLV尤其有用。通过使用端口状态TLV和接口状态TLV，可以从头到尾不间断地进行监视，而无需两个运营商对单个接口设备进行管理访问，也无需依赖用户对级联服务的监视。通过端口状态TLV和接口状态TLV，可以轻松地将维护协会外部的错误与正确归因于维护协会本身的错误区分开。
  
  

• Defects and Fault Alarms
  缺陷与故障警报（19.2.16）分开，这是服务提供商的标准做法。 10 CCM的丢失或交叉连接的CCM的接收都是缺陷。故障警报是管理操作（12.14.7.7），是网桥主动发出的通知。如果实施了CFM MIB模块（17.5），则它是SNMP通知。当MEP故障通知生成器状态机（20.35）检测到已配置的时间段（默认值为2.5 s）已过，并显示一个或多个缺陷，并且启用了故障警报时，将发出此消息。状态机不能再发送任何故障警报，直到通过配置的时间段（默认值为10 s）将其复位（在此期间内不存在任何缺陷指示）为止。收到故障警报后，正常的操作程序是检查报告MEP的管理对象，诊断故障，更正故障，检查MEP的管理对象以查看MEP故障通知生成器状态机是否已重置，并重复这些步骤，直到故障告警已清除。
  
  

故障警报中仅报告优先级最高的缺陷。 表20-1显示了指示缺陷的变量，这些缺陷的优先级以及在“故障警报”中报告的每个缺陷的枚举值之间的关系。

• CCM reception
  每个active MEP都会在其MEP CCM数据库中接收和分类CCM。 必须检查每个CCM，以确保其MAID与接收MP中配置的MAID相匹配。 接收方MEP检查以确保其自身的MEPID与接收到的CCM中的MEPID不匹配。 （这可能表示重复的MEPID或网络转发环路。）CCM中的信息在MEP CCM数据库中分类，并由接收到的MEPID进行索引。 MEP CCM数据库中保存的信息在12.14.7.6.3中列出。
  
  

MIP CCM数据库可以选择由MEP连续性检查接收器或MHF连续性检查接收器（MEP Continuity Check Receiver or an MHF Continuity Check Receiver）维护。 这是自上次重置网桥以来，呈现给网桥的所有下行MHF的MHF连续性检查接收器的所有CCM中每一个三联的{FID，source_address，端口号}的列表。 （有关VID和FID的讨论，请参见8.8.7。）CCM数据库中的条目将在收到最后一个包含其三元组的CCM之后保留至少24小时，并在最多48个之后从MIP CCM数据库中删除。 H。 如果为MIP CCM数据库分配的资源不足以在要求的时间内维护所有条目，则应优先删除最近更新的条目，以便为新条目腾出空间。 有关使用MIP CCM数据库的描述，请参见20.3.2。

1.7.2 Loopback protocol

单播环回消息（LBM）用于故障验证和隔离。 为了验证MEP和MIP之间的连通性，系统管理员可以指示MEP发出一个或多个LBM。 LBM由具有指定destination_address，优先级和drop_eligible参数的MEP发起，destination_address是与发送MEP处于同一维护关联中的另一个MP的单独MAC地址。 接收方MP用单播回送应答（LBR）响应LBM。

环回协议由MEP环回启动器（19.2.11）和MP环回响应器（19.2.10）执行，后者位于MEP或MHF中

• Loopback Message transmission
  LBM由操作员命令按照12.14.7.3中的规定进行传输。 发送的每个LBM都包含一个“回送事务标识符”字段（21.7.3），该字段随每次发送而增加。 这使发送的MEP能够将返回的LBR与发送的LBM相关联。 LBM可以携带任意数量的数据，以帮助诊断对帧中的数据量或模式[12.14.7.3.2中的项目d]敏感的故障。 可以使用任何优先级或drop_eligible参数[12.14.7.3.2中的项目e]进行发送]
  
  

没有提供用于指定发送LBM的速率的装置。 如果没有其他流量插入网桥，网桥不得以导致网桥端口服务的队列溢出和丢弃LBM的速率传输LBM。

• Loopback Message reception and Loopback Reply transmission
  当MP回送响应器（19.2.10）收到LBM时，可以检查其有效性，如果无效则将其丢弃。不管是否检查了LBM的有效性，如果source_address是一个Group而不是单个MAC地址，则应将其丢弃。同样，如果destination_address与接收方MP的MAC地址都不匹配，或者与表8-9中的表MAC的组MAC地址都不匹配，则该MP必须丢弃LBM。如果接收方MP回送响应者驻留在MHF中，并且destination_address是组MAC地址，则MHF将丢弃LBM。如果帧通过了这些测试，则接收方MP会生成LBR，并将其传输到始发MEP。
  
  

LBM的接收方不得解释LBM中的任何其他字段或TLV。不违反20.46验证标准但未在本标准中指定的任何TLV的内容，以及接收方MP未知的任何有效的组织特定TLV，接收方均应予以忽略，并且不对其进行解释，除非将其内容复制到LBR。

注—该标准没有提供使用组MAC地址传输LBM的方法。 MP环回响应器响应发送到CCM组地址的LBM，因为ITU-T Y.1731（2006）规定要发送此类消息。见J.4。

• Loopback Reply reception
  当MHF接收到LBR（异常发生）时，由于MIP没有LBR的接收实体，因此将其忽略。当MEP环回启动器（19.2.11）接收到LBR时，将检查以查看destination_address参数是否与接收到的MEP的MAC地址匹配，如果不匹配则将其丢弃。接下来，检查其“环回事务标识符”字段是否与最近传输的LBM的字段匹配，并且适当的计数器递增，或者是顺序计数器[12.14.7.1.3中的项目y]]还是顺序不正确。计数器[项目12.14.7.1.3中的z]]。
  
  

如果特定的网桥使用了用于实现连接性故障管理的共享MP地址模型，则如20.47中所述，在确定LBR所针对的特定Up MP的标识中存在歧义。因此，使用此模型的网桥使用单个变量来管理共享相同MAC地址，MAID和MD级别的所有MP的环回事务标识符字段。 LBR的接收器可以逐位比较其内容与相应LBM的记忆内容，如果不匹配，则将变量[12.14.7.1.3中的项目aa]递增。

1.7.3 Linktrace protocol

Linktrace协议由与单个MEP关联的MEP Linktrace发起程序（ the MEP Linktrace Initiator ）（19.2.12）和与网桥关联的Linktrace响应程序（ the Linktrace Responder）（19.6）执行。

MTM Linktrace发起方发送LTM以执行路径发现和故障隔离.LTM携带目标MAC地址作为其有效负载的一部分。它在多播帧中承载，其中的destination_address根据发送的MEP的MD级别从表8-10中获取，并通过桥接网络进行中继，直到到达适当MD级别的MP。该MP拦截LTM并将其转移到网桥的Linktrace响应器。 Linktrace Responder确定其网桥的MAC中继实体是将具有指定目标MAC地址的普通数据帧转发到单个出口网桥端口，还是对其进行过滤或泛洪。如果找到了单个出口端口，或者如果接收的MP是终接MP，则Linktrace响应器将单播Linktrace答复（LTR）发送给LTM的始发者，其MAC地址也作为LTM中的有效载荷携带。 LTR在0
<延迟≤1 s范围内的随机延迟后发送，以减轻始发mep的负担。此外，如果通过其接收ltm的mp是mhf，则linktrace响应器会将ltm的更改版本从单个网桥端口中转发到目标mac地址的方向。发起初始ltm的mep="" linktrace发起者收集ltr。这些为构造发送到目标mac地址的数据帧将遍历的mp序列提供了足够的信息。无连接环境中的路径发现比面向连接的环境更具挑战性。在桥接lan中，这尤其具有挑战性，因为ltm目标的mac地址可以在网络拓扑更改后立即由tcn从筛选数据库中删除，并且会过期并被删除几分钟（“最大使用期限”）。在最后一次获悉故障导致目标与发起ltm的mep隔离后进行的最后一次了解。<="" p="">

注—定期LTM允许系统管理员在正常操作期间沿着MEP之间的路径确定MIP，从而为后续的故障隔离建立基线。 但是，以接近CCM传输间隔的速率触发LTM可能会使网桥处理CFM PDU的能力不堪重负。 另见22.5。

• Linktrace Message origination
  LTM由MEP Linktrace发起方响应操作员命令（12.14.7.4）传输。在传输LTM之后，每个传输的LTM的nextLTMtransID [项目b）在12.14.7.4.3，20.36.1中将保留至少5 s。给定MEP传输的LTM事务标识符值在此时间段内是唯一的，以便将慢速MP返回的LTR与触发慢速LTR的LTM相匹配。将nextLTMtransID初始化为随机值11，并在每次传输的LTM处将其递增一次即可满足此条件。对于每个传输的LTM，MEP Linktrace发起者在Linktrace数据库（20.36.2）中创建一个条目。当接收到相应的LTR时，由nextLTMtransID对该条目进行索引以进行检索。
  
  

如果同一服务实例和同一MD级别上的多个MEP具有不同的MAC地址，则发送网桥可以为每个MEP维护一个单独的LTM事务标识符序列，但对于共享这两个特征的MEP使用通用的LTM事务标识符序列。

LTM的destination_address是为LTM保留的组MAC地址，根据表8-10，它适合于始发MEP的MD级别。

LTM中的“目标MAC地址”字段[12.14.7.4.2，21.8.6中的项目c）可以是任何单独的MAC地址。但是，由于要求MEP定期发送CCM，因此MIP沿该路径很可能知道MEP的MAC地址。相反，由于MIP不会启动任何CFM PDU，因此MIP的MAC地址对于中间网桥可能是未知的，除非它最近已回复LBM或LTM。

下行MEP中的MEP Linktrace发起程序通过其活动SAP向连接到其网桥端口的LAN传输LTM。上层MEP中的MEP Linktrace发起方通过其MEP LTI SAP将LTM传输到其自己的网桥的Linktrace响应器。 Linktrace Responder按照20.3.2中的描述处理LTM。 Linktrace响应程序可以通过LOM Linktrace SAP转发LTM，并且可以通过带有LTR的MEP LTI SAP进行响应。因此，当LTM在Up MEP中启动时，最开始的网桥是第一跳（hop）

• Linktrace Message reception, forwarding, and replying
  特定MD级别的LTM作为普通多播数据帧转发，直到遇到相等或更高MD级别的MEP或相等MD级别的MHF。 处于较高MD级别的MEP会丢弃LTM，而无需进一步处理。 处于相等MD级别的MP会将LTM定向到其网桥的Linktrace响应器。 由于对于给定的MD级别，可以使用MHF，MEP（或两者都不配置）为给定网桥上的不同网桥端口进行配置，因此LTM既可以作为普通数据转发，也可以由网桥的Linktrace响应器进行处理。 由上层MEP发起的LTM直接转发到其网桥的Linktrace响应器，而不是通过MEP的Active SAP转发到帧过滤过程
  
  

注1 —当追踪到已知MAC地址的路径时，共享介质上的所有网桥将接收LTM。 在过滤数据库查询中将LTR的传输和LTM的转发作为条件，以确保这些桥中的最多一个将进行答复。 同样，可以通过尚未学习目标MAC地址的网络区域来泛洪LTM，而不会触发LTR。

LTM立即转发，以最大程度地减少完成Linktrace操作所需的时间。 LTR排队等待稍后交付。 如果LTM是由Down MEP或Down MHF接收的，则LTR包含描述该MP的Reply Ingress TLV（21.9.8）。 如果Down MEP未收到该消息，并且如果出口端口为LTM的MA配置了Up MEP或Up MHF，则LTR包括一个Reply Egress TLV（21.9.9）。 这些TLV沿着到目标MAC地址的路径向始发MEP报告MIP和/或MEP。

如果将LTM转发到共享介质LAN，并且连接到该LAN的一个或多个其他网桥只有两个网桥端口转发LTM的vlan_identifier（包括该共享介质）的数据，并且LTM中的MAC地址 在那些网桥的过滤数据库中不存在目标MAC地址字段（21.8.6）（或者如果在多个网桥的MIP CCM数据库中存在目标MAC地址），那么接收网桥的接收网桥中的一个以上可以通过以下方式响应LTM： LTR。 另外，网桥或LAN操作中的异常，例如，筛选数据库记录的信息不正确，可能会导致沿多个路径的LTR响应。

LTR中的Reply TTL字段本身足以使发起MEP Linktrace发起方命令沿着单个路径返回的LTR。 LTM和LTR还包含三个值，即上一个出口标识符（21.9.7.1），下一个出口标识符（21.9.7.2）和LTM出口标识符TLV（21.8.8），这些值使始发MEP能够明确地构造以下树： 如果LTR是沿着多条路径返回的，则LTM所采用的路径。

注2 —如果不能将MA配置为传输CCM的速度快于Max Age导致从网桥的过滤数据库中删除MAC地址的速度，那么对于系统管理员来说，最佳实践是仅在触发几个LBM之后才触发LTM传输。目标MAC地址。这有助于确保目标MAC地址对于中间网桥是已知的，以便LBM将返回结果，并且仅沿单个路径返回LTR。

注3 —如果异常情况促使沿多条路径做出响应，则传输LTR的延迟会降低返回的LTR淹没始发MEP接收能力的可能性。

注4：转发的LTM使用转发LTM所通过的MP的地址作为其源地址，而不是原始LTM的源地址。这意味着网桥的Linktrace响应器不需要与其中继实体完全同步，因为后者可以快速更改活动拓扑，而不会冒着相邻网桥从LTM得知源MAC地址错误方向的风险。 LTM TTL字段可确保在活动拓扑更改时正在处理的LTM不会在持久循环中转发。

MEP Linktrace发起者忽略LTR中收到的任何不违反20.46验证标准但未在此标准中指定的TLV，并且忽略任何未知的有效组织特定TLV。 除非在20.42.3和20.42.4中另有规定，否则所有链接跟踪响应者已知或忽略的TLV都会从接收的LTM复制到转发的LTM，再从接收的LTM复制到LTR。

注5 —在LTM和LTR中转发所有未知的TLV，使该标准的将来修订版以及组织特定TLV的设计者能够添加新功能

• Linktrace Reply reception
  LTR由Linktrace响应器响应收到的LTM进行传输，并以单播帧的形式返回到发起LTM的MEP Linktrace发起方。 MEP Linktrace发起方会验证收到的LTR，如果无效，如果destination_address参数与MEP所在的网桥端口的MAC地址不匹配，或者LTR事务标识符字段与存储在其中的LTR不匹配，则将其丢弃。 MEP的Linktrace数据库（20.36.2），在LTM产生时创建。
  
  

每个经过验证的LTR都会在Linktrace数据库中触发一个新条目的创建，可以通过“读取Linktrace回复”命令（12.14.7.5）作为托管对象进行访问。 如果此MEP的Linktrace数据库中没有与LTR事务标识符字段相对应的条目，则MEP Linktrace发起者将创建一个新条目，其索引值[12.14.7.5.2中的项目c）]为1。 确实存在与该字段匹配的内容，它将创建一个新条目，其索引值比最后一个匹配的LTR大一。 无论哪种情况，MEP Linktrace发起程序都将LTR的内容存储在此新条目中。

1.7.4 Connectivity Fault Management state machines

1.7.4.1 CFM procedures

1.7.4.2 Maintenance Domain variable

1.7.4.3 Maintenance Association variables

以下变量是单个维护协会的本地变量，并且可以由多个状态机访问：a) CCMinterval (20.8.1).CCM传输之间的配置时间。 为此变量配置的值应为表21-16中的非0值之一。 该变量可用作托管对象[项目12.14.6.1.3中的e]]

1.7.4.4 MEP variables

MEP为：

• 在不与VID关联的MA中配置；
• 在运行生成树的多个实例的网桥上；
• 在不属于静态VLAN注册条目的网桥端口上，属于属于多个生成树实例的VID的成员资格；
  可能无法为端口状态TLV生成明确的值，因为不同的MSTI可能位于不同的端口状态中。 对于处于该位置的MEP，enableRmepDefect始终为true。
  
  

1.7.4.5 MEP Continuity Check Initiator variables

1.7.4.6 MEP Continuity Check Initiator procedures

1.7.4.7 MEP Continuity Check Initiator state machine

每个MEP连续性检查启动器（19.2.9）实例化一个MEP连续性检查启动器状态机。 MEP连续性检查启动器状态机实现图20-2中的状态图指定的功能，20.10中的变量声明以及20.11中的过程。

注—图20-2指示MACstatusChanged的设置会导致CCI重置，从而改变CCM传输周期的相位。 状态机的替代形式可以传输额外的CCM，但不能同时重置CCI。 此标准未指定在MEP中设置MACstatusChanged是否导致CCI重置。

1.7.4.8 MHF Continuity Check Receiver variables

1.7.4.9 MHF Continuity Check Receiver procedures

1.7.4.10 MHF Continuity Check Receiver state machine

1.7.4.11 MEP Continuity Check Receiver variables

1.7.4.12 MEP Continuity Check Receiver procedures

1.7.4.13 MEP Continuity Check Receiver state machine

1.7.4.14 Remote MEP variables

1.7.4.15 Remote MEP state machine

1.7.4.16 Remote MEP Error variables

1.7.4.17 Remote MEP Error state machine

)]

1.7.4.18 MEP Cross Connect variables

1.7.4.19 MEP Cross Connect state machine

1.7.4.20 MP Loopback Responder variables

1.7.4.21 MP Loopback Responder procedures

1.7.4.22 MP Loopback Responder state machine

1.7.4.23 MEP Loopback Initiator variables

1.7.4.24 MEP Loopback Initiator transmit procedures

1.7.4.25 MEP Loopback Initiator transmit state machine

1.7.4.26 MEP Loopback Initiator receive procedures

1.7.4.27 MEP Loopback Initiator receive state machine

1.7.4.28 MEP Fault Notification Generator variables

1.7.4.29 MEP Fault Notification Generator procedures

1.7.4.30 MEP Fault Notification Generator state machine

1.7.4.31 MEP Linktrace Initiator variables

1.7.4.32 MEP Linktrace Initiator procedures

1.7.4.33 MEP Linktrace Initiator receive variables

1.7.4.34 MEP Linktrace Initiator receive procedures

1.7.4.35 MEP Linktrace Initiator receive state machine

每个MEP Linktrace发起者实例化MEP Linktrace发起者接收状态机的一个实例。 MEP Linktrace发起方接收状态机实现图20-12中的状态图指定的功能，20.38中的变量以及20.39中的过程

1.7.4.36 Linktrace Responder variables

1.7.4.37 LTM Receiver procedures

• LTM paths through a Bridge
  如果LTM有效，则根据以下子节进行处理。 否则，ProcessLTM（）会丢弃LTM，并且不会进行进一步的处理。
  图20-13说明了LTM通过网桥采取的许多（但不是全部）可能的路径。 灰色圆圈表示LTM的处理以及LTM修改副本的可能转发。 LTR路径未显示。
  

  
  
  
  
  
  

• Ingress Port, vlan_identifier, and Egress Port determination
  在20.3.2和图20-13中，情况a）到情况e）都需要ProcessLTM（）来确定此接收到的LTM的入口和出口。 入口端口是LTM通过MEP，MHF或LOM进入桥接器的桥接器端口。 在情况d）中，当LTM由Up MEP生成并通过MEP LTI SAP传递到Linktrace响应器时，入口端口是始发MEP的桥接端口。
  
  

如果从EISS SAP收到，则接收到的LTM的vlan_identifier将包含在EM_UNITDATA.indication中。 如果从ISS SAP接收到，则接收到的LTM的vlan_identifier是在接收LTM的MEP，MHF或LOM中配置的vlan_identifier，或者如果没有，则是入口端口的PVID（6.7.1）。

这两个步骤都可能无法确定出口端口； 当无法确定唯一的出口端口时，永远不会转发LTM.

• LTM is received by a Down MHF or originated by an Up MEP
  在第20.42.1.1页中的情况b）（如第173页的图20-13中所示）中，LTM由Down MHF接收。 在图20.-13中所示的20.42.1.1中的情况d）中，LTM由Up MEP发起。 无论哪种情况，ProcessLTM（）都会执行以下步骤:
  a）如果LTM是由Up MEP生成的，则将跳过项目b）和项目c），然后继续进行项目d），如下所示。
  b）如果LTM中携带的目标MAC地址是接收MHF的MAC地址，则LTM已达到其目标。 ProcessLTM（）调用enqueLTR（）（20.42.4）来为接收LTM的Linktrace SAP的LTR排队。 LTM被丢弃，并且不再进行任何处理。
  c）否则，如果LTM的网桥端口和vlan_identifier的生成树状态未转发，则LTM将被丢弃，并且不会进行进一步处理。
  注意—此测试可防止在共享介质的备份端口上生成伪造的LTR。
  d）否则，根据20.42.1.2确定入口和出口。如果无法确定唯一的出口端口，则将丢弃LTM，并且不会进行进一步的处理。
  e）在三种情况下，需要进一步处理LTM，这取决于LTM通过出口端口时，带有LTM的vlan_identifier的帧是否会首先遇到Up MEP，Up
  MHF，或两者都不。这些在情况f），情况g），情况h）和情况i）中描述如下。
  f）如果在出口端口上遇到上行MHF，则：
  1）ProcessLTM（）调用enqueLTR（）（20.42.4）为出口端口Up MHF的MHF Linktrace SAP的LTR排队。
  2）如果LTM中携带的目标MAC地址是MHF的出口端口MAC地址，则LTM将被丢弃，并且不会进行进一步处理。
  3）否则，如果LTM TTL字段等于0或1，则将丢弃LTM，并且不会进行进一步处理。
  4）否则，ProcessLTM（）调用ForwardLTM（）（20.42.3），以在标识的出口端口上通过LOM的LOM Linktrace SAP转发LTM的更改副本。
  g）如果在出口端口上遇到LTM的MD级别的Up MEP，则：
  1）ProcessLTM（）调用enqueLTR（）（20.42.4）为入站端口Down MHF的MHF Linktrace SAP或Up MEP的MEP LTI SAP的LTR排队，后者将LTM传递给Linktrace响应器。
  2）LTM被丢弃，并且不再进行任何处理。
  h）否则，如果在出口端口上遇到高于LTM的MD级别的Up MEP，则LTM将被丢弃，并且不会进行进一步的处理。
  i）如果在出口端口上既不会遇到上行MHF，也不会遇到MD级别高于或等于LTM的上行MEP，则：
  1）ProcessLTM（）调用enqueLTR（）（20.42.4）为入站端口Down MHF的MHF Linktrace SAP的LTR排队。
  2）如果LTM TTL字段等于0或1，则将丢弃LTM，并且不会进行进一步处理。
  3）否则，ProcessLTM（）调用ForwardLTM（）（20.42.3），以通过LOM的LOM Linktrace SAP转发LTM的更改副本，该LTM的帧在通过标识的出口通过LTM的vlan_identifier时首先会遇到。

  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  

• LTM is received by an Up MEP
  在图20.-13中所示的20.42.1.1中的情况c）中，LTM在没有MEP或MHF的桥端口上进入一个桥，因此只有一个LOM。因此，LTM可以由上行MEP（例如，图20-13的端口3上的MEP）接收。在Up MEP上收到的LTM的处理过程如下：
  a）如果LTM中携带的目标MAC地址是接收MEP的MAC地址，则LTM已达到其目标。 ProcessLTM（）调用enqueLTR（）（20.42.4）为接收Up MEP的MEP Linktrace SAP的LTR排队。 LTM被丢弃，并且不再进行任何处理。
  b）否则，根据20.42.1.2确定入口和出口。如果无法确定出口端口，或者如果出口端口不是配置接收MEP的网桥端口，则LTM将被丢弃，并且不会进行进一步处理。
  c）否则，（即，出口端口是接收上行MEP的端口）ProcessLTM（）调用enqueLTR（）（20.42.4）来排队接收上行MEP的MEP Linktrace SAP的LTR。然后将LTM丢弃。

  
  
  
  
  
  
  
  

• LTM is received by an Up MHF
  在图20.-13中所示的20.42.1.1中的情况c）中，LTM在没有MEP或MHF的桥端口上进入一个桥，因此只有一个LOM。 因此，LTM可以由上行MHF接收，例如图20-13的端口2和端口6上的MHF。 在Up MHF上收到的LTM的处理过程如下：
  a）如果LTM中携带的目标MAC地址是接收Up MHF的MAC地址（即该MHF所在的网桥端口的MAC地址），则LTM已达到其目标。 ProcessLTM（）调用enqueLTR（）（20.42.4）为接收Up MHF的MHF Linktrace SAP的LTR排队。 LTM被丢弃，并且不再进行任何处理。
  b）否则，根据20.42.1.2确定入口和出口。如果无法确定出口端口，或者如果出口端口不是配置接收MHF的网桥端口，则LTM将被丢弃，并且不会进行进一步处理。
  c）否则：
  1）ProcessLTM（）调用enqueLTR（）（20.42.4）为接收Up MHF的MHF Linktrace SAP的LTR排队。
  2）如果LTM TTL字段等于0或1，则将丢弃LTM，并且不会进行进一步处理。
  3）否则，ProcessLTM（）调用ForwardLTM（）（20.42.3），以在与接收LTM的上行MHF相同的桥端口上，通过LOM的MHF Linktrace SAP转发LTM的更改副本。

  
  
  
  
  
  
  
  
  
  
  
  
  
  

1.7.4.38 LTM Receiver state machine

1.7.4.39 LTR Transmitter procedure

a) xmitOldestLTR() (20.44.1):当且仅当nPendingLTR不为零时，才使单个LTR出队并发送，并将nPendingLTR减1。

1.7.4.40 LTR Transmitter state machine

LTR发送器状态机的一个实例由Bridge的Linktrace Responder实例化。 LTR发送器状态机实现图20-15中的状态图指定的功能，20.41中的变量以及20.42中的过程:

此状态机执行（20.3.2）的要求，即在接收LTM之后等待随机的时间间隔，然后再通过自由运行的1 s计时器发送LTR，该计时器的到期时间将触发所有LTR传输。 此方法避免了为每个收到的LTM创建和管理计时器的需要。 可以使用满足20.3.2要求的任何其他实现方式来代替此状态机。

1.7.4.41 CFM PDU validation and versioning

本小节的目的是陈述CFM关于本标准与本标准未来版本之间的关系要实现的特定目标，并定义实现这些目标所必需的程序。

• Goals of CFM PDU versioning
  CFM关于该版本与本标准未来版本之间的关系的目标是确保：
  a）本标准的实现将与本标准未来版本的实现互操作；
  b）实施者将能够通过增强的功能为该标准提供专有的非标准扩展； 和
  c）符合本标准但扩展的实施方式将不会限制本标准将来版本扩展标准功能的能力。

  
  
  
  
  
  
  
  

• PDU transmission
  为了确保将来的连通性故障管理版本与该标准的实现兼容，对传输的CFM PDU提出了某些要求：
  a）固定报头字段应严格按照本标准的规定进行发送。
  b）在本标准中定义为“保留”的所有比特，例如“标志”字段中未使用的比特，应被发送为0。
  c）不应将附加字段添加到本标准规定的固定报头中。
  d）在本标准或ITU-T Y.1731（2006）中保留的代码点，例如，固定报头中的OpCode字段（表21-4），TLV中的Type字段（表21- 6）或表21-19中维护域名格式的保留值，不得在任何CFM PDU中发送。
  e）不应将附加字段添加到本标准规定的任何TLV中。
  特定于组织的TLV可以由拥有OUI的任何组织定义，并且可以发送
  通过符合本标准的实施方式

  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  

• PDU validation
  未通过某些指定测试的CFM PDU被MP丢弃。 此处将此需求描述为两遍处理算法，首先是验证遍历，然后是执行遍历。 首先执行验证过程。 当且仅当成功时，才执行执行通过。 该描述不排除其他算法。 例如，MP可以一次处理CFM PDU，建立受影响的状态机和数据库的暂定更改列表，并仅在处理成功后才提交更改。 然而，从本节中描述的两次通过算法的外部可观察到的行为（即管理对象和协议数据包）的角度来看，这种实现的行为应是无法区分的。
  
  
• Validation pass
  内容详见文档
  
  
• Execution pass
  内容详见文档
  
  
• Future extensions
  内容详见文档
  
  

1.7.4.42 PDU identification

MAID和/或维护关联端点标识符字段不用于标识接收MP。 因此，如果特定的网桥使用了个别MP地址模型（请参阅J.6），并且每个MP使用其网桥端口的单独MAC地址，则VID，MD级别和流向将唯一地标识接收MEP。 如果网桥使用了共享MP地址模型，以便网桥中的Up MP可以共享MAC地址，则作为LBM目标的特定网桥端口可能确实模棱两可。 这种歧义性使设计人员可以将详细信息的价值与获得该信息的成本进行交易

1.7.4.43 Use of transaction IDs and sequence numbers

每个CCM，LBM和LTM都有一个字段（21.6.3、21.7.3和21.8.3），该字段对于每种类型传输的每个PDU递增，因此连续传输的PDU按数字顺序。 控制这些字段的变量是CCIsentCCM（对于CCM为20.10.2），nextLBMtransID（对于LBM为20.28.2）和nextLTMtransID（对于LTM为20.36.1）。

从理论上讲，网桥中的每个MEP都有一个CCIsentCCMs变量，一个nextLBMtransID变量和一个nextLTMtransID变量，独立于其他所有MEP。 因此，只要它们具有不同的MAC地址，单个网桥中的任意数量的MEP都可以传输独立的LBM和LTM流。 （如果它们具有相同的MAC地址，则无法将彼此的LBR和LTR区分开。）

实际上，这些变量及其对应的状态机的实例可能少于每个MEP实例一个。 第12条中的受管理对象，特别是MEP的LBR计数器的定义[项目y]（12.14.7.1.3）和项目z）[12.14.7.1.3]，以及对“发送回送消息”命令的响应（12.14.7.3） .3），以便可以实现从一台到多台MEP的任何数量的MEP Loopback Initiator发送状态机。 每个状态机都可以增加其自己的nextLBMtransID变量，以确定下一个传输的回送事务标识符字段。 同样，对“发送链接跟踪消息”命令（12.14.7.4.3）允许的响应为实现的nextLTMtransID变量的数量提供了相同的范围。 然后，同一桥中的不同MEP可以连续而不是同时使用用于传输LTM或LBM流的资源。

另一方面，每个正在递增其CCIsentCCMs变量的MEP都有该变量的实例，因此也具有自己的MEP连续性检查启动器状态机，因为接收那些CCM的远程MEP状态机正在独立跟踪每个MEP的CCM序列。 MEP还可以在每个CCM的序列号字段中发送0。

CFM工作机制

CFM基本功能包括连通性检测（CC）、环回功能（LB）和链路跟踪功能（LT）。

连通性检测（CC）

连通性检测功能用来检测维护端点之间的连通状态，由维护端点MEP周期性的发送CCM（Continuity Check Message）组播报文，相同维护联盟的其他维护端点接收该报文。当维护端点在3个超时周期内未收到源端维护端点发送的CCM报文，则认为链路有问题。

具体的实现过程为：

1. CCM的产生

   CCM由MEP产生并发送。如图所示，MEP1、MEP2和MEP3是同一个MA的3个MEP。当使能了CCM发送功能后，MEP1定期以组播方式向MEP2和MEP3发送CCM。同样，MEP2以相同的周期向MEP1和MEP3发送CCM，MEP3也以相同的周期向MEP1和MEP2发送CCM。

   CCM中携带有该CCM的级别信息。CCM的级别等于发送该CCM的MEP的级别。

2. MEP数据库的建立

   每个启动了以太网CFM功能的设备上都有一个MEP数据库。MEP数据库中记录着本设备上的MEP（即本地MEP）和同一MA内的其它设备上的MEP（即远端MEP）。本地MEP和远端MEP均由用户手工配置后由设备自动记入MEP数据库。

3. 故障判定

   如果某个MEP连续3个CCM发送周期没有接收到另一个远端MEP发送的CCM，则认为链路有问题。会输出日志报告，用户可以通过环回功能或链路跟踪功能来进行故障区间的定位。当维护域内的多个MEP在发送CCM报文时，就实现了多点到多点之间的链路检测。

4. CCM终结

   CCM由MEP产生也由MEP终结。当MEP接收到大于自身级别的CCM时，继续转发该CCM；当MEP接收到小于或等于自身级别的CCM时，不再转发该CCM，以确保低级别MD内的CCM不会扩散到高级别MD中。

环回功能（LB）

环回功能即802.1ag MAC Ping功能与IP层的Ping类似，用于验证本地设备与远端设备之间的连接状态。

由MEP发起，目的节点可以是同一MA内的或不同MA内的，与发起节点级别相同的MEP或MIP。指定地址的MP收到LBM（Loopback Message）后，将向源MEP回应LBR（Loopback）。故障位置前的MP能够响应环回消息，而故障位置后的MP不能够响应环回消息，从而实现故障的定位。LBM和LBR均为单播报文。

下面以[图4-1]为例，介绍环回功能实现的具体过程。

PE1和PE4之间建立端到端的CFM，MD的级别为6，PE2和PE3设备上存在两个级别为6的MIP节点。当发现PE1到PE4之间链路故障或者通过CC检测到PE1到PE4之间链路发生故障时，可以采用如[图4-2]所示的方式定位故障点。

另外，发起端MEP1还可以根据802.1ag MAC Ping操作时的回显结果，计算出网络的时延；或者发起端发送多个LBM，观察LBR的返回情况，从而了解网络的丢包情况。

链路跟踪功能（LT）

链路跟踪功能即802.1ag MAC Trace与Traceroute类似，用于确定源端到目的维护端点的路径。

由MEP发起，目的节点可以是同一MA内的或不同MA内的，与发起节点级别相同的MEP或MIP。源端MEP构造LTM消息帧，发送到目的MP。在转发到目的MEP或者MIP的过程中，MIP会回复LTR，同时转发LTM，到达目的MEP则终止LTM的转发同时回复LTR。这样，远端MEP就会得到整个路径的信息。LTM是组播报文，LTR是单播报文。

下面以[图4-3]为例，介绍链路跟踪功能实现的具体过程。

1. MEP1向MEP2发送LTM（Linktrace Message）消息。LTM消息中包含有TTL（Time to Live）和目的节点MEP2的MAC地址。
2. 当LTM到达MIP1时，MIP1将LTM中的TTL字段的值减1，若此值为0不再转发，否则继续转发该LTM。同时向MEP1回复LTR（Linktrace Reply）。LTR中还携带了分析报文路径的转发信息和收到的LTM报文的TTL字段。
3. MIP2和MEP2收到LTM后，会做和MIP1相同的处理。但是，由于根据LTM中携带的目的节点MAC地址MEP2可以判断出自己
   是LTM的目的节点，因此MEP2不会再转发该LTM。
   
   
4. MEP1接收到MIP1、MIP2、MEP2回复的LTR后，根据LTR携带的信息即可得到从MEP1到MEP2的转发路径。

   如果MEP1到MEP2之间的路径有故障，则故障点下游的MEP或MIP将无法收到LTM，也不会回复LTR，可据此判定故障点的位置。例如当MEP1到MIP2之间的路径正常，而MIP2和MEP2之间的路径有故障时，MEP1可以收到MIP1、MIP2回复的LTR，但收不到MEP2回复的LTR，于是可判定MIP2和MEP2之间的链路或设备有故障。

CFM告警

CFM用于端到端链路的连通性检测，当检测到故障时，会触发告警上报网管，便于网络管理员对故障做出及时处理。

告警防抖动

当网络不稳定时，如果以太网CFM已经启动故障连通性检测功能，在较短的时间内将有大量的告警和告警恢复产生。这些告警将会占用大量的系统资源，会影响到系统性能。可以通过调整RMEP激活时间，防止错误告警的产生；通过告警防抖动功能减少告警数量。

表5-1 告警防抖动功能说明

告警抑制

在网络中，多种故障可能同时产生，因此，多种告警也可能同时产生。CFM的告警抑制功能的原理是：当多种告警同时产生时，只上报最高级别的告警。当最高级别的告警恢复后，如果低级别的告警仍然存在，则继续上报当前存在的最高级别的告警。如此反复，直至系统中不再有告警。

告警抑制的作用在于：

• 一般情况下，高级别的告警对应网络中比较严重的问题，需要用户优先解决。
• 同一个问题可能产生多种告警，这些告警的级别可能不相同。当最高级别的告警恢复后，当前系统中由相同问题产生的所有低级别的告警可能都会恢复。

术语与缩略语

术语

缩略语