只有当节点发送或接收到ConfigAck消息，控制通道才进入激活（UP）状态，此时通过周期性发送HELLO消息来实时维护通道的连通性；其中，HELLO消息的间隔时间（HelloInterval）和死亡间隔时间（HelloDeadInterval）在进行初始化的Config消息中配置。HELLO消息包括两个重要的序列号：发送序列号（TxSeqNum）其初始值为1，随后每发送一个HELLO消息加1；接收序列号（RcvSeqNum）启动或重启动时其值为0；（值得注意的是当一端节点HELLO消息重新启动时，其发送序列号回到初始值1，接收序列号回到初始值0，而另一端节点在收到此消息时，会继续累加记数，这时发送序列号和接收序列号将不是相差1；）HELLO消息的处理流程如图1所示。
图1 Hello消息的处理流程
另外，为了在管理需要的时候关闭控制通道，在LMP包的通用头部（Common Header）中设置了一个ControlChannelDown标志。控制通道关闭的过程可能在超过 HelloDeadInterval时间之后停止发送Hello消息，当节点接收到一个设置了ControlChannelDown 标志LMP包时，它应该发送一个Hello消息（其中携带已经置位的ControlChannelDown标志），并且使控制通道切换至Down 状态。
3） 故障管理
由于控制通道和相关联的数据链路在物理上存在相互分离的可能，当出现故障，没有可利用的控制通道时，数据链路仍在使用。若因此而关闭一条正在使用的数据通道显然是不可被接受的。故此时应将数据链路置为降级（Degraded）状态，并应通知路由管理，使其不再接收新的连接。
3.2 链路属性关联
链路属性关联可以将多条数据链路汇聚成一条TE链路，并同步链路属性，这将大大减少网络中链路状态广播（LSA）消息的发送。在链路属性关联过程中可进行链路绑定，可以修改、关联和交换链路的流量工程参数，最终确保相邻节点之间TE链路属性的一致，使相邻节点就数据链路的性质和容量等参数达成共识。LMP链路属性关联消息有：LinkSummary,LinkSummaryAck和LinkSummaryNack。其处理流程与控制通道管理初始化相似：链路进入UP状态，周期性发送LinkSummary消息，如对方节点同意LinkSummary消息中所有属性和端口映射关系则返回LinkSummaryAck 消息，否则返回LinkSummaryNack消息并指明不同意的属性和端口映射。
3.3 链路连通性验证
链路连通性验证用来验证数据链路的物理连通性，以及本地ID到远端ID的映射；其最大的好处是通过验证可以得到一张标有确定链路状态的本地——远端ID映射表。
LMP链路连通性验证过程通过控制通道上的BeginVerify 消息来协调，并且需要控制通道和数据通道协同进行。这是一个可选的过程，由参数协商过程配置可协商的验证标志（VerificationFlag）决定。具体过程如下：
源端向远程节点发送BeginVerify消息（携带认证间隔、数据链路数目、编码类型、认证传输机制、传输速率、波长等信息），如果远程节点回应BeginVerifyAck消息，其必须携带32bit的Verify ID（用于唯一标志特定的链路连通性验证实例），并且被其他所有在源和目的之间验证关联消息拷贝共享；如果远程节点回应BeginVerifyNack消息即表示远程节点不能或者不愿意进行链路连通性验证。
在源端收到BeginVerifyAck消息后，表明协商成功，验证开始。源端节点将会在指定数据链路上发送Test消息（携带了该数据链路编号和源端节点端口/接口编号），远程节点用Verify ID来加速特定的验证过程，并且映射远程接口ID给相应的本地值。接着通过控制通道传送TestStatusSuccess消息（携带远程节点接口ID）返回源端节点（如果远程节点不能在认证间隔内收到Test消息，则通过控制通道发送TestStatusFailure消息给源端节点报告错误）。
此时源端节点将通过控制通道返回TestStatusAck消息进行确认，当所有数据链路验证结束，源端节点将通过控制通道发送EndVerify消息，远程节点收到EndVerify消息后返回EndVerifyAck消息结束整个验证过程，其验证过程如图2。
图2 链路连通性认证过程
需要指出的是在验证过程中只有Test消息是在数据链路上传递的，其他消息是在相应的控制通道上传递的。另外，在认证初始状态中BeginVerify消息中链路区域的本地链路ID（LOCAL_LINK_ID）一般情况下应为非0值，其目的是为了限制链路认证程序通过特殊TE链路，例如一条正在使用的链路；如果此区域为0值，则代表验证所有链路。
3.4 链路故障管理
LMP提出的故障定位的机制是由下游检测到数据链路故障的节点发起，通过通道故障消息以及回复消息的交互，沿着LSP向上游逐跳检测链路状态，直到定位到发生故障的链路。这种方式的好处是可对故障作出快速反应并可精确定位故障是否发生在本地节点。
LMP故障管理过程基于通道状态（ChannelStatus） 交换，其使用的消息有：通道状态（ChannelStatus）, 通道状态应答（ChannelStatusAck）,通道状态请求（ ChannelStatusRequest） 和通道状态响应（ChannelStatusResponse）。
1）故障定位的判决
故障探测是在物理层完成。连接两个节点的TE链路可能包括多个数据链路。如果两个节点间一个或更多的数据链路发生故障，必须有一个用于快速故障通知的机制，以产生适当的保护/再生机制。如果故障随后就被清除，则必须有一个机制用来通知故障以被清除，链路状态OK。对于全光交换设备其故障探测仅限于光信号本身，目前比较常见的一种方式是探测光衰耗（LOL），而故障定位依据探测结果进行判决，但其本身是独立于探测机制的。
2）故障定位过程
如果光交叉连接设备（OXCs）之间的数据链路发生故障，所有下游接点的监控系统将探测到LOL并且显示故障发生。为避免同一故障的多重报警， ChannelStatus消息可提供某单个数据通道失效，多个数据通道失效或者整个TE链路失效三种显示方式；基于接收到故障通知，在每个节点实现了故障关联。为把故障定位在两个相临的OXCs之间的特殊链路，探测到故障的下游节点将发送一个ChannelStatus 消息到它的上游相邻节点，显示故障已经发生（所有故障数据链路的通知都绑定在一起）。接收到ChannelStatus 消息的上游节点应返回一个ChannelStatusAck 消息到下游节点，显示它已经接收到ChannelStatus消息。上游节点应该关联故障，看看故障是否也在相应LSP的本地被探测到。如果说，故障在上游节点的入口或内部被标注并上报网管，那么上游节点便定位好了故障。一旦故障被关联，上游节点应该发送一个ChannelStatus消息到下游节点显示通道失效。如果ChannelStatus消息没有被下游节点接受到，它应该发送一个ChannelStatusRequest 消息，若此时下游节点收到ChannelStatusRequest 消息它将返回一个ChannelStatusResponse消息并显示被询问的数据链路的状态。
可见，通过上述4个功能，已经初步形成一个对数据通道和控制信道管理的闭环系统，基本满足了人们在最初设计时的初衷。当然，在具体应该过程中，各个厂商会根据自己的设备、网络的结构以及业务运营商的需求对各个功能进行细化和取舍。
四、总结
LMP协议作为一个相对完整链路资源管理协议，在传送平面上已经可以完成对数据链路的分类、绑定、标识、可用性以及故障定位的管理，在控制平面上也可以完成对控制通道自身的维护，初步实现了智能化。然而，传送光网络的
智能化是期望人为的干预尽量减少，网络的自我调节能力，合理分配链路资源的能力不断增强。这不仅需要链路资源管理协议的进一步细化、完善，更需要相关的机制配合发展，如自动发现机制、光链路性能的监测技术以及与管理平面数据交换能力的提高，它们是相辅相成、相互制约的有机整体。值得注意的是，并不是功能越多，甄测的性能数据越多，鉴别的带宽资源越细化，网络的利用率越高，网络的服务质量越好，网络越健壮。这犹如一柄双刃剑，当一个过于复杂的管理协议出现在网络中时，必然增加各个节点
信息处理负担，阻碍网络资源的有效传送。所以把握尺度，整合各功能模块协调运作是发展的关键。
