链路管理LMP协议文档翻译

本文为LMP协议文档RFC4204的个人翻译,文档结构按照原文布置,水平有限,部分内容可能不准确或者表达错误,欢迎大家指正。RFC文档的翻译RFC1~RFC3039在10年前有China-pub.com组织过,不过后来都停止了。RFC4204目前还搜不到中文翻译,中国协议分析网论坛的“RFC中文文档翻译及嵌入式系统协议实现 ”板块后来有人继续零零散散翻译过后面的文档,不过最近的也是4年前的帖子了。

转载请注明来源:https://www.tanxiaoyao.com

1.简介

网络设备由路由器、交换机、密波分系统、加掉波设备等组成。GMPLS协议通过动态分配资源 的方式来为网络生存性提供恢复和保护措施。一对节点之间可能存在上千条互联,这些二层或者一 层的互联可能由数条数据链路组成,所以为了可扩展性起见,多条数据链路必须抽象成一条TE链路 管理。

为了在路由、信号传输、链路管理的时候实现两个节点间的通信,他们之间必须要有一对互相 可达的IP端口。我们把这样的一对接口叫做控制通道。需要注意的是,这里的互相可达不是指他们 之间必须是物理直连的,它们之间甚至可能穿通第三方网络。而且控制报文传输的通道并不一定和 业务报文传输的通道是一样的。本文档就运行在两个节点间控制通道上用于链路管理和校验的协议 (LMP)进行阐述,在本文中,这样的一对节点我们简称为“LMP邻居”或者“邻居节点”。

在GMPLS协议中,两个节点间的控制通道不再强制要求和数据链路使用同样的物理通道(背 景: 在PTN中,数据链路和控制链路是合一的,在传送设备上使用GMPLS协议就不再有这样的要 求)。比 如控制通道可以传输在虚链路、特定波长、光线、网线甚至另一个网络提供的IP隧道上。 因为控制通道和数据链路使用的物理通道是不一定一样的,因此控制通道的连通状态和数据链路没 有必然关系,反之亦然。因此,数据链路和控制通道之间的必须要做状态隔离,并且必须要提供一 个新的机制来进行链路校验和管理。

LMP需要完成的任务是校验TE链路下属的这些数据链路,并比对这些链路的属性一致性,链路 两端 的节点都会做这样的校验,这被称为“链路属性一致性校验”。LMP还同时可以通告这些链路 的属 性到IGP模块,IGP可以将这些链路信息洪范至网络的其他节点。LMP还可以通告信令模块TE链 路和 控制链路之间的绑定关系。因此,LMP可以说是控制平面的粘结剂。

需要注意的是,虽然一个控制平面的网络是实现网元间通信必须的,但是这还远远不够。举个 例子,一方面两个节点间可能穿通了第三方网络,第三方网络中的故障可能导致连个节点间没有可 达的路径并造成中断。而另一方面,第三方网络也不是每种错误都会导致特定的控制通道故障,所 以,我们需要自己建立控制通道的管理和维护机制。

在本文中,数据链路必须要考虑它是一个端口抽象的链路还是一个器件抽象的链路,这主要取 决于链路抽象点的复用调度能力。器件抽象的链路具有调度能力而端口抽象的没有。这个区别很重 要,因为这两种链路的资源管理、标签分配、物理连通校验都是不一样的。举个例子(后面的领域 不熟悉不翻译了,具体参见原文,意思就是有复用能力的链路可能数据链路分不同的粒度好几层, 资源分配可能按最底层的粒度管理,但是物理属性校验可能需要在顶层校验)。

为了保证具有复用能力的链路两端节点间的正常协作,支持LMP的设备必须要能将这些底层链路 抽象为单独的数据链路。举个例子,一个路由器能够将四个OC-48链路通过复用器组合成OC-192链 路,我们必须要能够独立抽象最小的OC-48的链路,LMP才能实现对每个子链路的协商管理。

LMP设计上支持将多个数据链路归并到一条TE链路管理。这样做的目的是将一组互相有关系的 链路抽象成一条TE方便CSPF和GMPLS信令模块使用。

1.1.术语

本文默认读者已经提前了解并熟悉了[RFC3471], [RFC4202], [RFC4201]这几大协议。 (即GMPLS协议、GMPLS中的路由协议、TE链路抽象协议)

  • 捆绑链路:
    主要在RFC4201中详细描述,不翻译了.
  • 控制通道:
    控制通道是两个网元间可达的用于路由、信令、链路管理的通信通道。
  • 成员链路:
    主要在RFC4201中详细描述,不翻译了.
  • 数据链路:
    两网元间用于业务报文传输的链路。GMPLS中,数据链路和控制通道不一定是同一个物理通 道。
  • 链路属性校验:
    校验本地和远端链路属性一致性的行为。
  • 复用能力:
    网元将小粒度信号汇聚成大粒度信号的能力。
  • Node Id:
    网元节点ID,在运行OSPF协议的节点上,LMP NODE ID和OSPF IP地址相同。
  • 端口:
    可以抽象链路的接口。
  • TE链路:
    主要在RFC4202中详细描述,不翻译了.
  • 透传:
    透传设备指信号从输入到输出,不会在信号描述信息上进行任何修改的设备。

2.LMP简介

LMP的两个核心流程是控制通道管理和链路属性一致性校验。控制通道管理是用于在相邻节点 间创建和管理控制通道,通过两个网元间利用CONFIG消息和快速保护机制实现。如果控制通道底没 有层故障检测能力,那么快速保活则是必要的。链路一致性校验这是为了同步两个TE链路的属性并 校验两条TE链路的配置正确与否。

LMP协议要求两个网元间至少有一条激活的双向控制通道,每个方向的控制通道通过一个CC ID 来识别,两个方向的控制通道通过交换LMP CONFIG消息关联在一起。除了TEST消息可能受到带内传 输消息机制的限制以外,其他LMP消息包都在LMP开辟的UDP端口上传输。关于LMP消息具体的打包格 式,不在本文的描述范围内。

两个邻居间至少有一个双向控制接口时,LMP邻居就会建立起来。多条控制通道可能同时建立 起来,但是每条控制通道的参数协商必须独立进行。如果LMP使能了控制通道的快速保活功能,这 个控制通道必须要协商HELLO消息。两个网元间的其他类型LMP消息可以通过任意一个UP的控制通道 传输,一个逻辑的控制通道必须至少对应一个物理上的控制通道。

LMP的链路属性校验功能是为了将多条数据链路映射到一条TE链路上并在网元间进行洪 范。LinkSummary作为链路属性校验过程的重要部分,它的消息格式包含了本地和远端的链路索 引、TE链路和下属数据链路的映射链表、各条数据链路的属性参数等。协商过程中,对端必须 回inkSummaryAck或者LinkSummaryNack表示接受或者拒绝该协商消息。

LMP协议设计了Message_Id和重传机制来确保传输的可靠性。Message_Id在协议 的MESSAGE_ID对象中携带,一条LMP消息中有且只有一个MESSAGE_ID对象。对于控制通道上传 输的消息,Message_Id在该控制通道上确保唯一。对于在TE链路上传输的消息,Message_Id确 保在两个邻居间确保唯一(语义可能翻的不准,参照原文)。Message_Id的值在取值范围内单调 递增,达到最大值后会发生翻转。

本文中除了控制通道管理和链路属性一致性校验两个核心流程外,还介绍了链路连通性校验和 故障管理两个附加特性。这两个功能在控制通道和数据链路物理分离的场景下特别有用。链路连通 性校验用于业务平面远端发现、链路索引交换(GMPLS信令会使用链路索引,用于标识端口或者成 员链路,取决与用户的配置)、物理连通性校验。校验的过程在数据链路上交换Test消息和控制 通道上交换TestStatus消息完成。这里可以留意一下,Test消息是LMP协议中唯一一个必须要在 数据链路上传送的消息。ChannelStatus消息则用于在相邻节点间抑制下游告警以及定位故障点 以便进行业务恢复和保护。

前面说过,LMP通过在数据链路上收发Test消息实现链路连通性校验。对于穿通设备来说,我们需要把对应开销设置成为穿通。LMP链路连通性校验通过在控制通道上传输BeginVerify消息来协商。为了支持不同层面的传输,在BeginVerify和BeginVerifyAck消息之间设置了一个Verify状态机来管理。需要注意的是,我们并没有要求所有的数据链路必须同时终结(提取开销信息),但是同一时刻必须至少能终结一个(个人理解即串行校验)。LMP也没有要求所有的TE链路必须和对应的控制通道必须使用同样的物理通道,但是无论在设置进入或者退出穿通模式的时候,控制通道必须和TE链路的两端在一个地方终结,因为LMP BeginVerify消息会交换Test消息来校验数据链路连通性(终结点不一致将无法实现校验)。

故障管理特性则是依赖与于交换ChannelStatus消息,ChannelStatus消息包含ChannelStatus、ChannelStatusAck、ChannelStatusRequest和ChannelStatusResponse四个子消息。ChannelStatus消息会主动发送来通知邻居TE链路下数据链路的状态,ChannelStatusAck、ChannelStatusRequest和ChannelStatusResponse则分别是响应,请求和响应请求ChannelStatus消息。

3.控制通道管理

要初始化两个节点间的LMP邻居,至少一个控制通道必须是UP的。控制通道可以用来传输控制平面信息例如链路配置、故障管理信息、通道管理和标签分配信息、信令报文和网络拓扑信息洪范等。

对于LMP协议来说,控制通道的具体实现方式不受限制。例如,控制通道可以承载在光纤的某一个特定波长上,以太网线上、IP隧道上或者数据链路的报文头上。每个节点将分配一个节点级不重复的32位非0的CC_ID。LMP报文通过LMP对应端口号的UDP协议发送,所以链路级如何实现控制通道通信的部分不在LMP协议本身的范围内。

要建立一个控制通道,我们必须知道CC的远端,这个远端可以是用户手工配置的或者是自动发现的。对于带内来说,数据链路可以明确对应一个特定的控制通道,这种情况下Config消息可以动态的获取到远端地址。这是通过在单播源地址上发送Config消息到组播目的地址(224.0.0.1或者ff02::1)上实现的。接受端收到后必须向报文头中解析出的源IP回ConfigAck或者ConfigNack消息。

控制通道是独立于TE链路存在的,两个节点间的多个控制通道可以同时UP起来,每个控制通达可以有不同的物理实现方式,比如一个可能是带内的而另外一个是带外的。因此,控制通道参数必须每个控制通道单独协商,并且Hello报文必须每个控制通道都进行发送保活,以防其他机制失效。因为CC在每个节点会电终结,所有当使用低阶信道例如SONET或SDH时,可能会检测到CC错误。

LMP协议中有四个报文来管理每个独立的CC,包括Config\ConfigAck\ConfigNack\Hello。这些报文必须在CC自己对应的物理通道上进行传输,除了这些报文,其他所有LMP的报文则可以在任意一个CC上传输即可。

为了管理LMP邻居,两个邻居间必须至少有一个UP的CC(这里重申一下,两个节点间的CC,是可以在同一个时刻UP起来的)。当一个CC发生故障时,备用UP的控制通道可以被用来激活其他的控制通道。

3.1.控制通道参数协商

控制通道的激活从网元间交换Config\ConfigAck\ConfigNack消息来进行参数协商开始。消息的内容是LMP协议打包的相关LMP对象信息,这些信息可以是可协商的或者非可协商的(主要由对象头的N比特决定)。可协商的对象可以让两个邻居来协商出一个具体的取值,而非可协商的这是一个协议特性的取值,这个值不需要或者不能由两个节点协商改变。

要使CC UP,Config消息必须要能发送到对端,对端必须回一个ConfigAck消息。Config消息包含本地的CC_ID,发送端NODEID,为了确保可靠性的Message_id以及一个CONFIG对象结构。两个LMP节点有可能同时初始化,为了避免两个节点同时发送报文产生的冲突,NODEID大的节点会赢得竞争,NODEID小的网元必须停止发送Config消息并响应收到的大端的Config报文。如果发现本端和对端的NODEID相同,则说明两个节点中有一个配置错误,两个节点都可以继续发送Config消息以便当NODEID被修正后继续正常运行,这种情况通过修改一个或者两个网元的NODEID可以解决。

ConfigAck消息则是用来回收到的Config消息的,它表示本端接受了所有对端参数的校验,包括所有可协商或者非可协商的参数。

ConfigNack则是回应表示不可协商的参数校验不过,或者为可协商的参数返回一个推荐值给对端。

如果一个节点收到了ConfigNack消息并解析出可协商参数的建议值,那它必须使用这个建议值再发送一次Config消息进行协商。

如果一个节点收到了ConfigNack消息并解析出可协商参数的建议值,但这个建议值本端不能接受,那节点可以继续坚持发送Config消息,因为如果本端或者对端的配置被修改正确,协商就可以通过。

在多个CC对应同一个物理通道的情况下,参数协商会在每个CC上均进行。网元间这同一个物理通道上传输的协商消息则通过他们具体的CC_ID找到对应的控制通道处理。

3.2.Hello报文

一旦CC激活以后,LMP就可以发送Hello报文来对控制通道进行保活和故障监测。LMP Hello报文是一个轻量级的保活报文,以便能够在控制通道失效的时候快速反应,避免IGP协议的Hello消息丢失或者对应链路的邻居状态被不必要地删除。

3.2.1.Hello参数协商

在发送Hello报文之前,HelloInterval和HelloDeadInterval参数必须在本端和对端网元间匹配,这些参数会在Config消息中传送。HelloInterval消息决定了Hello报文以多快的频率进行发送,单位是ms。举个例子,如果间隔值为150,那么没150ms将会至少发送一个Hello报文。HelloDeadInterval则决定了控制通道需要等多长时间收不到Hello消息才上报CC失效,单位也是ms。

HelloDeadInterval必须大于HelloInterval的值,建议至少是HelloInterval的三倍。如果不想使用快速保活机制,HelloInterval和HelloDeadInterval必须设置为0。

HelloInterval和HelloDeadInterval的值需要合理设置,既要保证能够迅速响应控制通道中断又不至于发生报文拥塞。因此,不同开销类型的控制通道可能又不同的设定值。当控制通道的底层实现是直连的链路的时候,这两个值的推荐大小是150ms和500ms。

当一个节点发送过或者收到过ConfigAck消息后,它将开始发送Hello消息(快速保活使能的话)。当网元发送一个Hello消息并收到对端的Hello消息,CC就进入UP状态(也有可能没发送过Hello消息就能进入UP态,只要能够从其他方法获取到链路的连通状态,比如通过传送平面学习到链路状态OK)。然而,当网元收到ConfigNack而不是ConfigAck消息时,它不能再发送Hello消息,CC状态也不能是UP。具体流程可以参照11.1的CC状态机介绍。

3.2.2.快速保活

每条Hello报文包含两个序列号:一个是发送序列号(TxSeqNum)用来继续发送的Hello消息计数,另一个是接收序列号(RcvSeqNum)用来记录从控制通道收到的对端Hello报文计数。

对这两个序列号来说,TxSeqNum不能为0。TxSeqNum=1表示发送端刚开始发送或者重置发送状态。因此,发送的第一个Hello消息的TxSeqNum为1,RcvSeqNum为0。当TxSeqNum达到(2^32)-1时,下一个发送序号是2而不是0或1。

在正常情况下,收到的RcvSeqNum和本地生产的TxSeqNum差异不超过1,超过1则一般是CC的序列号产生了翻转。

因为32位的序列号可能产生翻转,下列的公式可以用来检测收到的TxSeqNum是否小于前一个收到的值:

1
2
3
If ((int) old_id - (int) new_id > 0) {
New value is less than old value;
}

Hello消息中的序列号使得每个节点可以校验是否收到了属于自己的Hello消息,Hello消息中拥有RcvSeqNum,本地节点就能知道对端收到了哪个Hello报文。

下列的例子说明了序列号怎样在交互中发挥作用。注意,这里只展示一个节点的操作,对端节点类似:

  1. Config消息过程完成后,节点A向节点B发送Hello消息, {TxSeqNum=1;RcvSeqNum=0}。

  2. 节点A收到节点B回的Hello消息,{TxSeqNum=1;RcvSeqNum=1}。当节点A的HelloInterval消息超时后,将再次发送Hello消息,{TxSeqNum=2;RcvSeqNum=1}。

  3. 节点A收到节点B回的Hello消息,{TxSeqNum=2;RcvSeqNum=2}。当节点A的HelloInterval消息超时后,将再次发送Hello消息,{TxSeqNum=3;RcvSeqNum=2}。

3.2.3.CC状态DOWN

为了方便管理员能够人为地去使能CC功能,LMP报文头中有一个ControlChannelDown标记。当两个节点间的数据链路仍被使用且有其他CC可用时,CC只能由管理员人为地置DOWN。

当管理员人为地置CC DOWN后,节点必须在该CC上发送的所有LMP报文中置ControlChannelDown标记。节点控制CC DOWN的机制会在HelloDeadInterval超时后停止发送Hello 消息,或者收到该CC上带有ControlChannelDown标记的LMP报文,也会停止发送。

当对端节点收到带有ControlChannelDown标记的LMP报文时,它应该发送带有ControlChannelDown标记的Hello消息并把自己的CC也置为DOWN状态。

3.2.4.链路状态降级

使能CC的结果可能是数据链路均被业务使用但没有一个UP的CC。在许多的应用中,就因为CC不可用就将承载着客户业务的数据链路置DOWN是不能接受的。然而,业务使用这样的链路不能再保证同样保护级别,所以TE链路需要置降级状态。

当TE链路处于降级状态时,需要通知路由和信令该链路不能在建立新的业务。

4.链路参数校验

链路参数校验作为LMP协议的一部分,由 LinkSummary, LinkSummaryAck, 和LinkSummaryNack消息组成。消息的内容包括可协商或者不可协商的LMP对象(由N标记决定)。可协商的参数用来使两端协商对应链路参数值,不可协商的参数用来通告那些不需要或者不允许协商的链路属性。

每条TE链路都有一个索引值(link_id),链路两端的属性必须保持一致,比如都是IPV4或者IPV6,如果收到一个LinkSummary消息发现本端和对端链路的类型都不一样,那必须要发送一个LinkSummaryNack消息并携带”Bad TE Link Object”的错误码给对方。

同样的,每个数据链路也有一个链路索引(Interface_Id),它两端的链路类型也必须保持一致。如果LinkSummary发现数据链路两端的链路类型不一致,处理方法和上面一致。

链路参数校验应该在链路UP之前完成,如果链路处于正常UP状态并且不在校验过程中,也有可能触发完成一次参数校验过程。

LinkSummary是用来校验链路两端参数的一致性的,LinkSummary消息也还有下面几种作用:

  1. 将多条数据链路合并到一条TE链路中。
  2. 交换并确定或者修改两端TE链路的参数
  3. 交换或确定或修改两端数据链路的ID或端口号等数据链路属性。

LinkSummary消息中包含一个TE_LINK对象,后面追加一个或多个DATA_LINK对象。TE_LINK对象包含TE链路的本端和对端远端、是否支持故障管理和链路校验机制等。DATA_LINK则是用来描述TE线路下属的数据链路的,这些数据链路对象包含了本端和对端链路索引以及其他详细信息描述结构体等。

如果网元收到了远端的LinkSummary消息,消息中链路索引的对应关系符合本地的索引值,那么两端就在链路参数和配置校验这个流程上协商通过。如果链路参数校验流程用不到,那么LinkSummary消息可以被用来校验链路两端的手工配置信息。

LinkSummaryAck消息用来响应链路索引匹配关系正确和链路属性校验通过给对端网元。与之相反,在链路索引匹配失败或者参数属性校验不通过时,必须回LinkSummaryNack给对端。如果LinkSummaryNack消息表明链路索引匹配失败并且链路校验机制是使能的,那么校验流程应该一致循环在所有不匹配以及空闲的链路上进行,对于有业务的链路如果匹配失败了,应该暂时给这种链路做个标记,一旦这条链路重新变成空闲的了,就会进行重新校验。如果LinkSummaryNack包含可协商的消息对象,那么消息里面还必须要填写可以接受的建议值。如果收端收到了包含可协商参数的LinkSummaryNack消息,那么状态机应该重新发送一个新的LinkSummary协商,新的消息应该包含一个新的可协商参数的取值,这个取值应当考虑对端带过来的建议取法。

当数据链路比较多的时候,单个LinkSummary消息报文的大小可能增长的很大,所以LMP协议在具体编码实现的时候,应该具有分包发送的能力,收端网元,则必须具有拼接LMP消息IP帧的能力。

5.链路连通性校验

在本章中,将介绍LMP协议的一个可选特性,用来校验链路的物理连通性和动态的学习TE链路以及TE链路对应关系。该机制应当在建立TE链路之前完成,并定期的对空闲的链路进行校验。

在LinkSummary消息中的TE_LINK对象中置位Link
Verification Supported标记就可以使能链路连通性校验功能。

如果网元收到BeginVerify消息但本端不支持该功能,那它必须发送一个BeginVerifyNack消息响应给对端,消息中携带“Link Verification Procedure
not supported for this TE Link”对应的错误码。

透传设备有一个特点是正常情况下它不会修改数据流或者提取开销,但是这种特性反而给链路连通性校验和标签匹配带来了挑战。因此,为了保证连通性校验的正常进行,当链路没哟被业务使用的时候,它能够被设置为终结状态。为了支持不同层面的终结(例如报文头、IP帧等)以及不同的Test消息传输机制,BeginVerify和BeginVerifyAck消息里面,设计了一个Verify传输机制。

LMP没有要求所有的数据链路必须在同一时刻终结,只要一次能够操作一个终结即可。而且对于链路校验机制来说,架构上设计的就是任何一条数据链路都可以收发消息的。需要说明的是,上述的限制对正常终结的设备来说是无所谓的,因为链路本来就会在传输到下一个维度之前在电层终结,所以这仅仅是对透传设备的一种额外要求。

为了在两个网元间建联,它们之间抽象了一条TE链路,网元间必须至少有一条可用的CC。为了链路校验正常使用,TE链路必须对应至少一条数据链路。

一旦网元间的CC建立起来之后,数据链路连通性校验就可以通过收发TEST报文在每条数据链路上进行了。需要留意的是,在联通性校验的过程中,所有的LMP消息除了Test消息都会在控制通道上传输,Hello消息也会持续在控制通道上发送,Test消息则会在要校验的数据链路上进行发送。Test消息会沿着信号流传输的方向校验数据链路,因为它是一个单向的校验过程,因此,链路两端的网元可能同时进行Test消息校验。

本端网元节点要初始化一个链路联通性校验过程就必须在CC上先发送一个BeginVerify消息,为了限制链路连通性校验的范围,本端网元的Link_Id必须是非0的指定值。如果这个字段填0,那么多条数据链路可能合并到同一条TE链路上校验(is yet to be语法不是特别熟悉,此句可能翻译有误)。在这种情况下,BEGIN_VERIFY消息中会使用”Verify all Links”标记来区分多条TE链路下的数据链路以及那些还没有绑定到TE的数据链路。也就是说,要检验所有TE链路下对应的数据链路,就设置 “Verify all Links”标记。要只校验那些没有TE的数据链路,就把Link_Id置0并清除”Verify all Links”标记。

BeginVerify消息还包含了将要检验的链路条数,也包含Test消息发送的时间间隔(VerifyInterval),包含消息支持的编码方式和传输机制,也包括Test消息的发送速率。当数据链路对应的是光纤的时候,Test消息中的波长描述字段也会包含其中。

如果对端网元接受到BeginVerify消息并且可以处理,那么它必须回一个BeginVerifyAck消息给本端并告诉本端想要的Test消息传输机制。对端网元回的BeginVerifyAck消息中有一个网元级的Verify_Id,这个Verify_Id有可能是随机生成的,但是它不能和网元中其他当前正在使用的Verify_Id消息冲突。Verify_Id会用在所有相应的验证消息中,用来区分从不同LMP邻居传来的消息并可以做到并行校验。当节点收到远端的BeginVerifyAck消息时,它将开始在每条数据链路上发送周期性的Test消息来校验链路。Test消息包含对应数据链路的Verify_Id和Interface_Id。此时,远端节点对每条数据链路必须发送TestStatusSuccess或者TestStatusFailure消息响应,本端节点必须发送TestStatusAck以确认收到了这两个消息。未收到响应的TestStatusSuccess和TestStatusFailure消息应该重发知道消息得到响应或者重试次数达到上限。(具体参见第十章)

对于发端节点,在发送BeginVerify消息之后可以随时结束校验过程,只要发送EndVerify消息即可。

LMP消息通过消息标识和Verify_Id识别,通过它们,不同的TE链路或者LMP邻居下的数据链路可以实现并行处理。

当Test消息收到时,收到的Interface_Id会被记录下来并与本地对应的数据链路索引关联起来,此时必须发送TestStatusSuccess响应。TestStatusSuccess消息中包含本段链路的Interface_Id,后面跟收到的Test消息的里的Interface_Id和Verify_Id。收到TestStatusSuccess消息则表明Test被远端收到并且数据链路的物理连通性也校验通过。当TestStatusSuccess收到后,本端节点应该标记数据链路为UP并发送TestStatusAck消息给远端。然而,当在给定的VerifyDeadInterval期限内,远端没有在对应端口探测到Test消息,那么远端必须在CC上发送一个TestStatusFailure消息表明物理层连通性校验失败。当本端收到TestStatusFailure消息后,应该将数据链路标记为FAILED并向远端发送一个TestStatusAck消息。当列表内所有的数据链路都校验完成后,本端节点应该发送一个EndVerify消息表明本链路的检验已经完成。

当本端和对端数据链路关系已知后,链路校验流程可以优化成按两个节点都已知的顺序来校验。推荐的标准时通过递增远端Interface_Id的方式实现。

为了关联性,本段和对端节点都应该维护完整的Interface_Id对应表。

5.1.链路连通性校验例子

图1展示了节点A和B添加后,链路连通性校验的流程。本例中,TE链路由三个空闲的端口组成,每个端口对应一条光纤并关联一个双向的CC(图中C所示)。校验的流程如下:

lmp_doc_fig1

  • A在CC上发送BeginVerify消息给B,表明他将要开始校验本TE链路下的端口。BeginVerify消息中的LOCAL_LINK_ID携带了本端分配给这条TE链路的索引。

  • B一旦收到BeginVerify消息,将会创建一个Verify_Id病绑定到A对应的TE链路Test上。当后面B收到A的Test消息时会用到这个绑定关系。B通过解析收到的BeginVerify消息里的LOCAL_LINK_ID对象将会得知A分配给TE链路的索引(如果数据链路此时还没有映射到TE链路,则绑定信息只会填写A的Node_Id),B发送BeginVerifyAck响应A的BeginVerify消息。BeginVerifyAck消息携带LOCAL_LINK_ID对象携带B的TE链路的索引,REMOTE_LINK_ID对象则用来绑定A和B分配的Link_Id。BeginVerifyAck消息会通过控制通道返回Verify_Id给A。

  • 当A收到BeginVerifyAck消息,它将会通过第一个端口(Interface Id=1)周期性地发送Test消息。Test消息包含端口的Interface_Id以及B通告的Verify_Id。

  • 当B收到Test消息,它将映射收到的Interface_Id到本端的Interface_Id = 10,然后在CC上发送一个TestStatusSuccess消息给A。TestStatusSuccess消息包含本端和收到的Interface_Id以及Verify_Id。Verify_Id用来本端/对端的数据链路属于哪个TE链路。

  • A将会在CC上响应TestStatusAck消息给B,表示它已经收到了TestStatusSuccess消息。

  • 上述过程会一直重复,直到所有的端口校验完毕。

  • 此时,A将会在CC上发送EndVerify消息给B,表明test完成。

  • B会在CC上回EndVerifyAck消息给A。

提示:这个流程可以用来发现数据端口的连接关系。

6.故障管理

本章中将会描述LMP中用来管理故障并快速通告TE链路下属数据链路状态的一个可选功能。本功能以TE链路为单位,并属于LinkSummary协商的一部分。本功能可以用来快速隔离故障的数据链路和TE链路,设计上支持单向和双向LSP。

使用透传设备意味着传统监测数据链路状态的方法可能不再适用,与在2层或者3层进行故障监测相比,它将在物理层进行监测(例如:光层检测是否能收到光)。

再次重申一下,两个节点间的TE链路可能包含多条数据链路。如果一个或多个数据链路失效,必须要有一个机制来快速通告触发保护和恢复动作。如果部分链路的故障消失,也必须要有一个机制来通告故障已经解除,通道状态恢复正常。

6.1.故障检测

故障检测应该在最接近故障的地方进行,对于光层的网络来说,会在物理层进行。一个检测方法是检测是否收到光。其他检测光层信号技术仍然在不断发展,本文也无法做到预知。但是,需要澄清的是LMP的故障检测不应该依赖于故障检测的具体手段,只需要能够感知到故障即可。

6.2.故障定位

在某些情况下,两个节点间的数据链路失效会向下游传递,不做故障定位时下游所有的节点都会检测到告警。为了避免同一个故障导致多个告警,LMP通过ChannelStatus提供了故障通告功能。ChannelStatus消息可以用来指示单个数据通道存在故障,多个数据通道存在故障或者整个TE链路都故障了,本地节点在收到故障通告后就会完成告警关联。

要定位两个邻居节点间具体某一条链路的故障,下游节点(沿着信号流方向的下游)在检测到数据链路故障后会发送ChannelStatus消息给上游邻居节点表明检测到了一个故障(所有故障信息可以批量发送)。上游节点收到ChannelStatus后必须发送一个ChannelStatusAck消息给下游节点表明已经收到了ChannelStatus。上游节点应该解析故障信息并检测本段是否也在对应的LSP上检测到了相同的故障信息。举个例子,如果上游节点检测到本节点的入口或者中间没有故障,那么它就可以确定故障发生在本网元。一旦故障定位消息跟本网元有关系,上游节点应该发送一个ChannelStatus消息给下游节点通知通道是故障还是正常的。如果下游节点收不到ChannelStatus消息,它应该发送ChannelStatusRequest消息请求通道状态。一旦故障被具体定位,信令协议可以实行跨段或者重路由恢复保护。

如果TE下所有的数据链路故障,上游节点可能只收到TE链路故障,不包含具体每条故障的数据链路。这是通过在ChannelStatus消息的CHANNEL_STATUS对象中不填Interface_Id实现的。

6.3.故障定位示例

如图2展示了一个四节点的链状网络,图中的C表示双向的控制通道。所有的LSP也是双向的。

lmp_doc_fig2

在第一个例子中(如图2.a),双向LSP的有一个方向发生故障。节点4将会检测到故障,然后给上游节点3发送ChannelStatus通告消息(例如光信号丢失)。当节点3收到节点4的ChannelStatus消息,会返回一个ChannelStatusAck消息给节点4并在本地关联该告警。当节点3找到告警关联LSP并确认告警在本站终结,那么它可以定位到告警位于节点3和节点4之间的数据链路上。此时,节点3应该发送一个ChannelStatus给节点4表明故障已被定位。

在第二个例子中(如图2.b),某个告警(例如断纤)影响到双向的LSP。节点2将会检测到上游故障,同时节点3将会检测到下游故障,节点会沿着信号流的上游发送一个ChannelStatus消息通告故障。同时,节点1和节点4将分别检测到上游和下游的故障,也会发送故障定位ChannelStatus消息,节点2和节点3将会把告警定位出来。

6.4.通道激活态通告

ChannelStatus消息也可以用来通告LMP邻居数据链路需要进入激活监控状态,也就是激活态。这个功能在透传设备的数据链路状态需要由LMP才能检测到的时候有用。举个例子,如果某条预先配置好的数据链路在校验完成之后用户业务上来之前发生了物理层故障,必须有一个机制来通告数据链路应该处于激活态,否则故障可能检测不到。

ChannelStatus消息可以用来通告通道或者通道组当前是激活态,收到对应ChannelStatus消息后必须回ChannelStatusAck消息。当ChannelStatus收到后,相应的数据链路必须进入Active态。进入激活态后,如果检测到故障,需要按照6.2章的介绍发送ChannelStatus消息定位。

6.5.通道去激活通告

ChannelStatus可以用来通告LMP邻居数据链路不再需要激活监控,这个和上文的激活态是对应配套的。

当收到通告通道去激活的ChannelStatus消息,对应的数据链路必须退出Active态。

7.Message_Id使用

LMP中的MESSAGE_ID和MESSAGE_ID_ACK对象被用来确保传输的可靠性,本章将会介绍这些对象的使用方法。MESSAGE_ID和MESSAGE_ID_ACK对象均包含Message_Id字段。

在所有的LMP消息中,MESSAGE_ID/MESSAGE_ID_ACK是都可以有的。

对于CC级别的消息,Message_Id字段填写的是CC_Id,对于在TE链路级别的消息,Message_Id字段填写的是LMP邻居NODE ID。

MESSAGE_ID对象的Message_Id字段是一个发端选定的值,这个值必须是单调递增的。当消息在CC或者邻居间发送出去后,该值即是被被使用了。MESSAGE_ID_ACK消息的Message_Id则是对应响应的消息的Message_Id值。

带有MESSAGE_ID的消息如果没有得到响应应该重传,直到得到响应或者达到重传次数上限。

需要注意的是32位的Message_Id可能翻转,下列公式可以用来检测是否发生翻转:

1
2
3
If ((int) old_id - (int) new_id > 0) {
New value is less than old value;
}

节点在处理接收到的消息的时候应该检查新收到的消息是否是错乱的,错乱的消息可以被丢掉。判断错乱可以通过检测消息中的Message_Id字段。如果一个消息被判定为错误的消息,那么它可以被丢掉。

如果消息是一个Config消息,Message_Id小于之前从这个CC上接受到的历史消息的最大值,那么这个消息应该被视为错乱的消息。

如果消息是一个LinkSummary消息,Message_Id小于之前从这个TE链路上接受到的历史消息的最大值,那么这个消息应该被视为错乱的消息。

如果消息是一个ChannelStatus消息,Message_Id小于之前从这个TE链路上接受到的历史消息的最大值,那么收端应当检测该ChannelStatus消息中的通道在之前收到的状态。如果Message_Id大于最近一次收到的包含有至少一个当前消息里通道的历史消息的值,那么这个消息就不能认为是错乱的,否则则是错乱的。然而,如果Message_Id小于最近收到的对应通道的消息的值,那这一个通道的状态则一定不能更新,只更新部分通道。

其他类型的所有消息则无论什么场景都不算错乱的。

8.软重启

本章描述了控制平面重启后重启LMP的机制。控制平面可能在控制通信不通后UP第一个控制通道的时候发生重启。控制通信中断可能由LMP邻居中断或者节点故障导致LMP状态丢失引起,但是不影响数据平面。后者可以通过在LMP消息的通用报文头中置位LMP Restart位实现。当控制平面因为控制通道状态丢失重启时,LMP链路的信息需要被保留。节点故障的时候,节点有可能还能够保存LMP链路的信息,但是无论怎样,数据链路通道的信息必须要重新同步。

这里有一个假定就是Node_Id和本地的链路索引Interface_Id在控制平面重启的过程中是不变的。

当节点的控制平面重启后,CC必须要使用3.1章的流程重新建立。在CC重建的过程中,Config应该走单播IP地址。

如果控制平面是因为节点故障导致LMP控制状态丢失引起的,LMP消息中的LMP Restart必须置位直到Hello消息收到并且RcvSeqNum等于本地的TxSeqNum,这表明CC已经UP并且对端检测到了本次重启。

下面假设LMP重启只发生在TE链路的一端,如果TE两端同时发生了重启,需要按照第4章的描述重新执行LinkSummary过程。

一旦控制通道CC UP起来,LMP必须给邻居间的每条TE链路发送LinkSummary消息。所有LinkSummary消息的对象的N标记必须设置为0,表示这些参数是不可协商的。这些参数提供了本地/远端的Link_Id和Interface_Id映射关系,关联的数据链路参数、被业务使用的数据链路等。当节点收到LinkSummary消息,它会校验本地的配置,如果节点在重启时可以保存住LMP信息,它也必须按照章节4处理LinkSummary消息,不同的是数据链路占用状态标记必须以收到的LinkSummary消息里的为准。如果节点重启时保存不了LMP信息,那么它必须接受来自对端的LinkSummary消息然后回一个LinkSummaryAck。

一旦LinkSummary交换完成,软重启的节点应该发送相应链路的ChannelStatusRequest消息,并且也需要重新校验所有空闲链路的连通性。

9.目的地址

LMP消息都是通过UDP上对应LMP的端口号发送的(Test消息必须在带内传输除外)。IP报文的目的地址可能是从对端Config消息头中获取的IP地址,也有可能是手工配置的远端IP或者是NODEID。不过Config消息有点特别,如下文描述:

Config消息的目的地址有可能受信流号传输方式的影响,当信号流是点到点传输的时候,Config消息应该发送至广播地址(224.0.0.1 或者 ff02::1),否则,Config消息必须发送到对端对应IP。是点到点还是广播,可以是手工配置在CC两端的或者是自动发现的。

10.快速退避机制

本章基于RFC2961,并提供一个消息的快速退避机制。具体的代码实现必须遵循文中描述的机制或者它们的等价实现。

10.1.实现方式

下面是对没得到响应LMP消息的快速退避重传算法的一种可能实现。发送端重传消息直到得到响应或者达到重传上限次数。当发送端收到响应,重传即停止。快速重传的间隔会逐渐递增,定时器从一个较小的间隔值开始,然后指数递增直至间隔的上限值。

下面描述具体的时间算法:

快速重传间隔Ri

Ri是未响应消息重传间隔的初始值,第一个消息发出后,发端将会在Ri毫秒后重发消息。

快速重传次数限制Rl:

Rl是消息重传次数的上限值。

递增系数Delta:

Delta是发端重传时间间隔的增长系数,重传时间增长速度为(1+Delta)。

建议默认的重传间隔初始值(Ri)是500ms,此时增长系数(Delta = 1),重传次数限制为3。

10.2.重传算法

当节点发送一个需要重传保障的消息时,它应该在Ri之后开始重传计时。如果响应消息在Ri之内收到了,重传被取消。否则,它将会在(1+Delta)*Ri后重传。重传会一直持续直到收到响应或者达到重传上限。

发端可以使用下述重传算法:

1
2
3
4
5
6
7
8
9
// 初始时 Rk = Ri , Rn = 0
while (Rn++ < Rl) {
// 重传消息;
// 任务休眠Rk毫秒;
Rk = Rk * (1 + Delta);
}
// 消息一直未响应或者Rl次数达到
// 现场清理;
exit;

如果发端收到了响应消息,Rn会被修改为Rl。

注意节点不会在Config消息或者LinkSummary消息中协商是否使用快速重传算法。

11.LMP状态机

11.1.CC状态机

CC状态机描述了CC的状态以及对应的跳转逻辑处理。

11.1.1.CC状态

CC的状态可以是下文描述中的一种,每种状态对应一种确定的场景,通常每种状态对应收到了远端发来的一种LMP消息类型。

  • DOWN:CC的初始状态,此状态下,不会做任何动作,也不会发送任何消息。CC上的参数,应当被设置为初始值。

  • ConfSnd:CC处于参数协商状态,此状态下,节点周期性的发送Config消息,等待对端节点返回ConfigAck或者ConfigNack消息。此时状态机不会进入Active状态直到对端通过了参数协商。

  • ConfRcv:CC处于参数协商状态,此状态下,等待对端响应一个可接受的参数,一旦参数协商通过,状态机可以进入
    Active状态。

  • Active:此状态下节点周期性的发送Hello消息并等待接受Hello消息,一旦收到一个有效的Hello消息,状态机进入Up状态。

  • Up:CC进入UP状态,节点接收有效Hello消息并发送Hello消息。

  • GoingDown:CC在管理状态变更时可能进入此状态,当CC处于此状态时,节点在所有发送的消息中,将ControlChannelDown位置为1。

11.1.2.CC事件

CC变化由状态和事件描述,CC事件由底层协议和软件模块,或者消息处理和TE链路关联动作产生。每种状态都有它对应的序号和名称:

  • 1:evBringUp:这是一个外部触发的事件,表示CC开始进行参数协商。举个例子,该事件可能被管理命令使能LMP协议触发。根据协议,下面两个动作也将被触发:
    1a) 发送Config消息
    1b) 等待接收对端的Config消息

  • 2:evCCDn:该事件表明CC不再可用。

  • 3:evConfDone:该事件表明收到ConfigAck消息,正在检查参数。

  • 4:evConfErr:该事件表明收到了ConfigNack,参数协商失败。

  • 5:evNewConfOK:该事件表明收到一个新的Config消息并协商通过。

  • 6:evNewConfErr:该事件表明收到一个新的Config消息但协商失败,发出ConfigNack响应。

  • 7:evContenWin:本端发送Config消息的同时收到了一个对端新的Config消息,本端赢得了竞争。此时收到的Config消息将被丢弃。

  • 8:evContenLost:本端发送Config消息的同时收到了一个对端新的Config消息,本端竞争失败。此时收到的Config消息将被丢弃。响应结果有:
    8a) Config消息协商通过
    8b) Config消息协商失败

  • 9:evAdminDown:管理员禁用了本CC。

  • 10:evNbrGoesDn:本端收到了对端带有ControlChannelDown标记的报文。

  • 11:evHelloRcvd:带有预期SeqNum的Hell消息被本端收到。

  • 12:evHoldTimer:HelloDeadInterval定时器超时都没有Hello报文收到,这将会使CC重新返回参数协商状态。根据本端的配置,可能会触发下面两个动作:
    12a) 周期性地发送Config消息
    12b) 等到对端发送Config消息

  • 13:evSeqNumErr:本端收到了带有非期望的SeqNum的Hello消息。

  • 14:evReconfig:CC参数被修改,需要重新协商。

  • 15:evConfRet:重传定时器超时,重传Config消息。

  • 16:evHelloRet:重传定时器超时,重传Hello消息。

  • 17:evDownTimer:定时器超时,期间没有收到任何带有ControlChannelDown标记的消息。

11.1.3.CC状态机描述

图3描述了CC状态机流转的状态表。

lmp_doc_fig3

evCCDn事件总是强制状态机迁移到down状态。evHoldTimer和evReconfig事件总是强制状态机迁移到参数协商(ConfSnd 或 ConfRcv)状态。

11.2.TE链路状态机

TE状态机描述了LMP TE链路的状态以及对应的跳转逻辑处理。

11.2.1.TE链路状态

TE链路状态可能为下面描述中的一种,每种状态对应TE的一种场景,一般对应一种远端周期性在CC上或者带内发送的LMP消息类型。

  • Down:没有数据链路绑定到本TE链路上

  • Init:有数据链路被绑定到TE上,但是还没有和对端进行一致性校验。LinkSummary会周期性地发送到对端。

  • Up:TE链路处于正常状态,节点间该TE链路下至少有一个CC是up的。最为常规动作的一部分,LinkSummary可能会周期性的发送到对端或者由外部触发发送。

  • Degraded:该状态下,所有的CC down,但是TE仍然绑定着一些承载着用户业务的数据链路。

11.2.2.TE链路事件

LMP TE链路变化由状态和事件描述,LMP TE链路事件由底层协议和软件模块,或者消息处理和CC、数据链路关联动作产生。每种状态都有它对应的序号和名称,下面描述了可能的事件类型:

  • 1:evDCUp:一个或多个数据链路被使能并绑定到该TE链路。

  • 2:evSumAck:收到LinkSummary消息并校验通过。

  • 3:evSumNack:收到LinkSummary消息但检验失败。

  • 4:evRcvAck:收到LinkSummaryAck消息。

  • 5:evRcvNack:收到LinkSummaryNack消息。

  • 6:evSumRet:重传定时器超时,LinkSummary重传。

  • 7:evCCUp:第一个激活的CC UP。

  • 8:evCCDown:最后一个激活的CC DOWN。

  • 9:evDCDown:TE链路的数据链路被解绑定。

11.2.3.TE链路状态机描述

图4描述了LMP TE链路状态机流转的状态表。

lmp_doc_fig4

上面的状态机中,当使用的链路校验机制被裁剪后,可能会出现子状态。

11.3.数据链路状态机

数据链路状态机定义了LMP TE链路下数据链路的状态和流转逻辑。数据链路的操作变化由状态和事件共同定义。数据链路可能处于主动模式,Test消息主动发出;也可能处于被动模式,收到Test消息。为了逻辑清晰,主动模式和被动模式设计了不同的状态机,但它们共用同一套事件和状态定义。

11.3.1.数据链路状态

数据链路的状态如下文所述,每种定义对应数据链路的一种状态。

  • Down:数据链路尚未被放到资源池中,数据链路还不可用。

  • Test:数据链路正处于校验状态,Test消息正周期性的在数据链路上传递。

  • PasvTest:数据链路正在接收并校验Test消息。

  • Up/Free:数据链路校验成功并被放入资源池中,数据链路当前还未被业务使用。

  • Up/Alloc:数据链路UP并被业务使用。

11.3.2.数据链路事件

数据链路变化由状态和事件描述,事件由底层协议和软件模块,或者消息处理和CC、TE链路关联动作产生。每种状态都有它对应的序号和名称,下面描述了可能的事件类型:

  • 1:evCCUp:第一个激活的CC UP。

  • 2:evCCDown:LMP邻居连接中断。说明两个节点间的CC失效。

  • 3:evStartTst:这是一个外部触发Test消息开始发送的事件。

  • 4:evStartPsv:这是一个外部触发数据链路开始监测Test消息的事件。

  • 5:evTestOK:链路校验完成并可以被用来建业务。
    (a) 该事件表示数据链路校验成功(详见章节5),并且从CC上收到了TestStatusSuccess消息。
    (b) 该事件表示数据链路可以建业务,但是链路校验机制并没有使用。对于带内CC来说,CC能够建立起来就足够说明数据链路连通性OK。

  • 6:evTestRcv:Test消息从数据链路收到,并且TestStatusSuccess消息已在CC上发送出去。

  • 7:evTestFail:链路校验返回失败。可能因为:
    (a) 收到了一个TestStatusFailure消息。
    (b) 校验流程异常退出并且没有收到该数据链路上的TestStatusSuccess或者TestStatusFailure消息。

  • 8:evPsvTestFail:链路校验返回失败。说明没有收到Test消息,可能因为:
    (a) VerifyDeadInterval定时器超时。
    (b) 校验流程异常退出但VerifyDeadInterval还没有超时。

  • 9:evLnkAlloc:数据链路被业务使用。

  • 10:evLnkDealloc:数据链路被业务释放。

  • 11:evTestRet:重传定时器超时,Test消息重发。

  • 12:evSummaryFail:LinkSummary消息和当前数据链路匹配失败。

  • 13:evLocalizeFail:故障定位流程定位故障位于该数据链路。

  • 14:evdcDown:数据链路不再可用。

11.3.3.主动模式数据链路状态机

图5描述了主动数据链路状态机流转的状态表。

lmp_doc_fig5

11.3.4.被动模式数据链路状态机

图6描述了被动数据链路状态机流转的状态表。

lmp_doc_fig6

12.LMP消息格式

所有的LMP消息(除了Test消息在某些场景下必须走在带内)都运行在LMP端口(701)的UDP协议上。

12.1.Common Header

除了UDP的头和IP头外,所有的LMP消息都有下面的公共头:

lmp_doc_common_header

图中Reserved的字段应该默认置0,且收端需要忽略该字段。

所有的值都使用网络序定义(大端序)。

  • Vers: 4 bits
    协议版本号,初始版本号1.

  • Flags: 8 bits
    当前有下列位被定义使用,其他的均应默认至0并在收端忽略。
    0x01: ControlChannelDown
    0x02: LMP Restart
    该位为1表示节点故障并且LMP状态丢失。当收到RcvSeqNum和本地TxSeqNum相同的Hello消息时,该位会被重置为0。

  • Msg Type: 8 bits
    当前有下列位被定义使用,其他位保留。
    1 = Config
    2 = ConfigAck
    3 = ConfigNack
    4 = Hello
    5 = BeginVerify
    6 = BeginVerifyAck
    7 = BeginVerifyNack
    8 = EndVerify
    9 = EndVerifyAck
    10 = Test
    11 = TestStatusSuccess
    12 = TestStatusFailure
    13 = TestStatusAck
    14 = LinkSummary
    15 = LinkSummaryAck
    16 = LinkSummaryNack
    17 = ChannelStatus
    18 = ChannelStatusAck
    19 = ChannelStatusRequest
    20 = ChannelStatusResponse
    所有上述消息都可以在任意一个CC上发送,除了Test消息必须在对应的数据链路上传送。

  • LMP Length: 16 bits
    LMP消息总长度,包括common header和其后所有变长对象长度。

12.2.LMP Object格式

LMP消息由对象object构成,每个object由 Object Class和Class-type组成。每个object有自己的名字,本文将以大写字母标出。LMP object可以是可协商或者不可协商的(由消息object头中的N位决定)。可协商object可由两端设备协商一个确定值,不可协商object用来通告不可变的参数。

所有的值都使用网络序定义(大端序)。

LMP objec格式如下:

lmp_doc_lmp_object

  • N: 1 bit
    N标记表示参数是可协商(1)或者不可协商(0)的。

  • C-Type: 7 bits
    Class-type,唯一对应一个Object Class,取值详见章节13。

  • Class: 8 bits
    Class表示object的类型。每个object有自己的名字,本文大写字母标出。

  • Length: 16 bits
    object的字节数,包括N位,C-Type,Class,Length等。

12.3.参数协商消息

12.3.1.Config消息(Msg Type = 1)

Config在LMP中用来进行CC协商,Config消息的内同由LMP object组成。格式如下:

<Config Message> ::= <Common Header> <LOCAL_CCID> <MESSAGE_ID> <LOCAL_NODE_ID> <CONFIG>

具体实现需要遵循上述顺序。

MESSAGE_ID object在LOCAL_CCID object范围内(原文:The MESSAGE_ID object is within the scope of the LOCAL_CCID object。翻译的不太懂)。

Config消息必须周期性的发送直到:
(1)收到ConfigAck或ConfigNack消息
(2)达到重传次数上限
(3)收到远端的Config消息并且竞争失败(例如对端的NODEID比本端大)
上述的重传间隔和重传次数都是指本站单站配置的值。

12.3.2.ConfigAck消息(Msg Type = 2)

ConfigAck消息用来响应收到Config消息并表示所有的参数协商通过。

<ConfigAck Message> ::= <Common Header> <LOCAL_CCID> <LOCAL_NODE_ID> <REMOTE_CCID> <MESSAGE_ID_ACK> <REMOTE_NODE_ID>

具体实现需要遵循上述顺序。

REMOTE_CCID, MESSAGE_ID_ACK, 和 REMOTE_NODE_ID的内容必须是从响应的Config消息中获得的。

12.3.3.ConfigNack消息(Msg Type = 3)

ConfigNack消息用来响应收到Config消息并表示由不可协商的参数校验失败或者对可协商参数返回一个建议值。协商过的部分参数一定不能包含在ConfigNack消息中。ConfigNack消息格式如下:

<ConfigNack Message> ::= <Common Header> <LOCAL_CCID> <LOCAL_NODE_ID> <REMOTE_CCID> <MESSAGE_ID_ACK> <REMOTE_NODE_ID> <CONFIG>

具体实现需要遵循上述顺序。

REMOTE_CCID, MESSAGE_ID_ACK, 和 REMOTE_NODE_ID的内容必须是从响应的Config消息中获得的。

Config消息中,会有可能多个参数是无效的。

如果ConfigNack消息中包含可协商的CONFIG对象,那么必须也包含该参数的建议值。

如果ConfigNack消息中包含不可协商的CONFIG对象,那么CONFIG对象必须从要响应的Config消息中原样复制。

如果发端收到了对端的ConfigNack消息且只包含可协商的CONFIG对象,那应该再重新发送一个新的Config消息。新的Config消息中的参数值应该考虑对端ConfigNack消息中带过来的建议值。

如果一个节点收到一个Config消息并识别了CONFIG对象,但是不识别C-Type(类型),那么需要发送ConfigNack消息,并包含这些不识别的CONFIG对象。

12.4.Hello消息(Msg Type = 4)

Hello消息格式如下:

<Hello Message> ::= <Common Header> <LOCAL_CCID> <HELLO>

具体实现需要遵循上述顺序。

Hello消息必须周期性的发送,至少每个HelloInterval周期一次。如果在HelloDeadInterval周期内没有收到Hello消息,CC将失效。

12.5.链路校验消息

12.5.1.BeginVerify消息(Msg Type = 5)

LMP在CC上发送BeginVerify消息来启动链路校验流程。格式如下:

<BeginVerify Message> ::= <Common Header> <LOCAL_LINK_ID> <MESSAGE_ID> [<REMOTE_LINK_ID>] <BEGIN_VERIFY>

具体实现需要遵循上述顺序。

为了将链路校验的范围具体限制到一条具体的TE链路,LOCAL_LINK_ID中的Link_Id字段必须是非0值。如果这个字段填0,那么数据链路可以选择多个TE链路使用或者选择还没有配置好的TE链路使用。在这种特定场景下,Link_Id是0,BEGIN_VERIFY对象里的”Verify all Links”标记用来区分那些是选择其他TE链路还是选择未配置数据链路的数据链路。(见章节5)

REMOTE_LINK_ID在本端和对端链路对应关系已知的时候包含。

REMOTE_LINK_ID中的Link_Id字段必须是非0的。

BeginVerify消息必须周期性的发送直到:
(1)收到BeginVerifyAck或BeginVerifyNack消息
(2)达到重传次数上限
上述的重传间隔和重传次数都是指本站单站配置的值。

12.5.2.BeginVerifyAck消息((Msg Type = 6)

当收到BeginVerify消息并准备好接收Test消息时,必须给对端响应BeginVerifyAck消息。

<BeginVerifyAck Message> ::= <Common Header> [<LOCAL_LINK_ID>] <MESSAGE_ID_ACK> <BEGIN_VERIFY_ACK> <VERIFY_ID>

具体实现需要遵循上述顺序。

当本端和对端的Link_Id对应关系已知或者可以从BeginVerify消息中获取时即可包含LOCAL_LINK_ID对象。

LOCAL_LINK_ID中的Link_Id字段必须为非0值。

MESSAGE_ID_ACK对象中的内容必须是从要响应的BeginVerify消息中原样复制的。

VERIFY_ID对象包含一个BeginVerifyAck消息发端分配的节点级唯一的序号,该序号用来区分多个邻居的消息或者两个LMP邻居间多个并行进行的校验流程所发送的Verify消息。

12.5.3.BeginVerifyNack消息(Msg Type = 7)

如果收到了BeginVerify消息并且节点不期望或者不能开始校验流程,那么必须要响应一个BeginVerifyNack消息。

<BeginVerifyNack Message> ::= <Common Header> [<LOCAL_LINK_ID>] <MESSAGE_ID_ACK> <ERROR_CODE>

具体实现需要遵循上述顺序。

MESSAGE_ID_ACK对象中的内容必须是从要响应的BeginVerify消息中原样复制的。

如果不支持校验流程,那么ERROR_CODE必须能表明”Link Verification Procedure not supported”信息。

如果支持校验流程,但是节点还无法开始校验流程,那么ERROR_CODE必须指示”Unwilling to verify”。如果节点收到一个有该错误码的BeginVerifyNack消息,那BeginVerify的发端应该安排BeginVerif Rf秒之后重传,Rf是本端定义的重传间隔值。

如果校验消息的传输机制不支持,那么错误码也必须指出”Unsupported verification transport
mechanism”。

如果远端不支持Link_Id索引分配,BeginVerify消息中的REMOTE_LINK_ID无法和本地任何一个索引匹配,那么ERROR_CODE必须指出”Link_Id configuration error”。

如果节点收到BeginVerify消息并解析出BEGIN_VERIFY对象,但是C-Type不识别,ERROR_CODE必须表明”Unknown object C-Type”。

12.5.4.EndVerify消息(Msg Type = 8)

通过在CC上发送EndVerify消息,我们来终止链路校验流程。EndVerify消息可以在任何节点想终止检验的时候发送。格式如下:

<EndVerify Message> ::=<Common Header> <MESSAGE_ID> <VERIFY_ID>

具体实现需要遵循上述顺序。

EndVerify消息将会周期性的发送,直到:
(1)收到EndVerifyAck消息
(2)达到重传次数上限
上述的重传间隔和重传次数都是指本站单站配置的值。

12.5.5.EndVerifyAck消息(Msg Type =9)

EndVerifyAck消息用来响应CC上对端的EndVerify消息。格式如下:

<EndVerifyAck Message> ::= <Common Header> <MESSAGE_ID_ACK> <VERIFY_ID>

具体实现需要遵循上述顺序。

MESSAGE_ID_ACK对象中的内容必须是从要响应的EndVerify消息中原样复制的。

12.5.6.Test消息(Msg Type = 10)

Test消息在数据链路上传输,用来校验它的物理联通性。除非特殊指定,Test消息必须和其他消息一样使用UDP进行传输。Test消息格式如下:

<Test Message> ::= <Common Header> <LOCAL_INTERFACE_ID> <VERIFY_ID>

具体实现需要遵循上述顺序。

注意,这个消息在数据链路上传输而非CC上传输。Test消息的传输机制是使用BEGIN_VERIFY对象的校验传输机制字段和BEGIN_VERIFY_ACK对象的检验传输响应字段协商实现的(详见13.8和13.9章)。

发端在相应的数据链路上周期性的发送Test消息(至少每个VerifyInterval周期一次),直到:
(1)收到远端对应链路CC上发来的TestStatusSuccess或者TestStatusFailure消息。
(2)两个节点间所有的CC失效。
远端节点将会在CC上周期性的发送TestStatus消息直到它收到对应的TestStatusAck消息或者EndVerify消息。

12.5.7.TestStatusSuccess消息(Msg Type = 11)

TestStatusSuccess消息在CC上传输,用来传输收到的Test消息中的本端和对端Interface_Id的对应关系。

<TestStatusSuccess Message> ::= <Common Header> <LOCAL_LINK_ID> <MESSAGE_ID> <LOCAL_INTERFACE_ID> <REMOTE_INTERFACE_ID> <VERIFY_ID>

具体实现需要遵循上述顺序。

REMOTE_INTERFACE_ID对象中的内容必须是从要响应的Test消息中原样复制的。

12.5.8.TestStatusFailure消息(Msg Type = 12)

TestStatusFailure消息在CC上传输,用来表明没有收到Test消息。

<TestStatusFailure Message> ::= <Common Header> <MESSAGE_ID> <VERIFY_ID>

具体实现需要遵循上述顺序。

12.5.9.TestStatusAck消息(Msg Type = 13)

TestStatusAck消息用来响应收到TestStatusSuccess消息或者TestStatusFailure消息。

<TestStatusAck Message> ::= <Common Header> <MESSAGE_ID_ACK> <VERIFY_ID>

具体实现需要遵循上述顺序。

MESSAGE_ID_ACK对象中的内容必须是从要响应的TestStatusSuccess或者TestStatusFailure消息中原样复制的。

12.6.1.LinkSummary消息(Msg Type = 14)

LinkSummary消息用来同步两个节点间TE链路下对应的数据链路Interface_Ids。格式如下:

<LinkSummary Message> ::= <Common Header> <MESSAGE_ID> <TE_LINK> <DATA_LINK> [<DATA_LINK>...]

具体实现需要遵循上述顺序。

LinkSummary消息可以在链路不再检验流程时的任何时间点进行交换。LinkSummary消息必须周期性的发送,直到:
(1)收到LinkSummaryAck消息或LinkSummaryNack消息
(2)达到重传次数上限
上述的重传间隔和重传次数都是指本站单站配置的值。

12.6.2.LinkSummaryAck消息(Msg Type = 15)

LinkSummaryAck消息用来表明Interface_Id同步和所有的链路参数协商通过。本端节点Link_Id关联需要依赖与该消息的响应。

<LinkSummaryAck Message> ::= <Common Header> <MESSAGE_ID_ACK>

具体实现需要遵循上述顺序。

12.6.3.LinkSummaryNack消息(Msg Type = 16)

LinkSummaryNack消息用来表示不可协商参数协商失败或者返回可协商参数的建议值。已经协商过的部分参数禁止放在LinkSummaryNack消息中。

<LinkSummaryNack Message> ::= <Common Header> <MESSAGE_ID_ACK> <ERROR_CODE> [<DATA_LINK>...]

具体实现需要遵循上述顺序。

DATA_LINK对象必须包含所有可协商参数的可接受值。如果LinkSummaryNack包含带有不可协商参数的DATA_LINK对象,那他们的内容必须原样从收到的LinkSummary消息中复制。

如果收到的LinkSummaryNack消息包含的都是可协商参数,需要重新发送一个新的LinkSummary消息。新的LinkSummary消息参数取值需要考虑LinkSummaryNack消息中的建议值。

如果收到的LinkSummary消息带有不可协商且不可接受的值,ERROR_CODE必须指明”Unacceptable
non-negotiable LINK_SUMMARY parameters.”的错误信息。

如果收到的LinkSummary消息带有不可接受但可协商的消息,ERROR_CODE必须指明”Renegotiate LINK_SUMMARY
parameters.”信息。

如果收到的LinkSummary消息带有无效的TE_LINK对象,ERROR_CODE必须指明”Invalid TE_LINK object.”信息。

如果收到的LinkSummary消息带有无效的DATA_LINK对象,ERROR_CODE必须指明”Invalid DATA_LINK object.”信息。

如果收到的LinkSummary消息中TE_LINK对象的C-Type不识别,ERROR_CODE必须指明”Unknown TE_LINK
object C-Type.”信息。

如果收到的LinkSummary消息中DATA_LINK对象的C-Type不识别,ERROR_CODE必须指明”Unknown
DATA_LINK object C-Type.”信息。

12.7.故障管理消息

12.7.1.ChannelStatus消息(Msg Type = 17)

ChannelStatus在CC上发送,用来通知LMP邻居数据链路的状态。收到ChannelStatus消息的节点必须响应一个ChannelStatusAck消息。格式如下:

<ChannelStatus Message> ::= <Common Header> <LOCAL_LINK_ID> <MESSAGE_ID> <CHANNEL_STATUS>

具体实现需要遵循上述顺序。

如果CHANNEL_STATUS对象不包含任何Interface_Id,那就说明整个TE链路发生了故障。

12.7.2.ChannelStatusAck消息(Msg Type = 18)

ChannelStatusAck消息用来响应接收到了ChannelStatus消息。格式如下:

<ChannelStatusAck Message> ::= <Common Header> <MESSAGE_ID_ACK>

具体实现需要遵循上述顺序。

MESSAGE_ID_ACK对象中的内容必须是从要响应的ChannelStatus消息中原样复制的。

12.7.3.ChannelStatusRequest消息(Msg Type = 19)

ChannelStatus在CC上发送,用来请求一个或多个数据链路的状态。收到ChannelStatusRequest消息的节点必须响应一个ChannelStatusResponse消息。ChannelStatusRequest消息格式如下:

<ChannelStatusRequest Message> ::= <Common Header> <LOCAL_LINK_ID> <MESSAGE_ID> [<CHANNEL_STATUS_REQUEST>]

具体实现需要遵循上述顺序。

如果消息中没有CHANNEL_STATUS_REQUEST对象,那说明ChannelStatusRequest是要请求TE链路下所有数据链路的状态。

12.7.4.ChannelStatusResponse消息(Msg Type = 20)

ChannelStatusResponse消息用来响应接收到了ChannelStatusRequest消息,并通知LMP邻居数据链路的状态。格式如下:

<ChannelStatusResponse Message> ::= <Common Header> <MESSAGE_ID_ACK> <CHANNEL_STATUS>

具体实现需要遵循上述顺序。

MESSAGE_ID_ACK对象中的内容必须是从要响应的ChannelStatusRequest消息中原样复制的。

13.LMP Object 定义

13.1.CCID Class

Class = 1

  • C-Type = 1, LOCAL_CCID

lmp_doc_cc_id

CC_Id: 32 bits

该值必须是节点级唯一的非0值。CC_Id用来区分发端不同CC发送的消息。

该对象是不可协商的。

  • C-Type = 2, REMOTE_CCID

lmp_doc_rmt_cc_id

CC_Id: 32 bits

该值表示对端节点的CC ID并且也是非0的。

该对象是不可协商的。

13.2.NODE_ID Class

Class = 2

  • C-Type = 1, LOCAL_NODE_ID

lmp_doc_node_id

Node_Id:

该值表示LMP报文属于哪个节点。

该对象是不可协商的。

  • C-Type = 2, REMOTE_NODE_ID

lmp_doc_rmt_node_id

Node_Id:

该值表示远端的节点ID。

该对象是不可协商的。

Class = 3

  • C-Type = 1, IPv4 LOCAL_LINK_ID
  • C-Type = 2, IPv4 REMOTE_LINK_ID

lmp_doc_link_id

  • C-Type = 3, IPv6 LOCAL_LINK_ID
  • C-Type = 4, IPv6 REMOTE_LINK_ID

lmp_doc_link_id_ipv6

  • C-Type = 5, Unnumbered LOCAL_LINK_ID
  • C-Type = 6, Unnumbered REMOTE_LINK_ID

lmp_doc_link_id_unnum

Link_Id:

LOCAL_LINK_ID表示消息对应的链路索引。该值必须是非0值。

REMOTE_LINK_ID表示对端节点的链路索引,也必须是非0值。

该对象是不可协商的。

13.4.INTERFACE_ID Class

Class = 4

  • C-Type = 1, IPv4 LOCAL_INTERFACE_ID
  • C-Type = 2, IPv4 REMOTE_INTERFACE_ID

lmp_doc_interface_id

  • C-Type = 3, IPv6 LOCAL_INTERFACE_ID
  • C-Type = 4, IPv6 REMOTE_INTERFACE_ID

lmp_doc_interface_id_ipv6

  • C-Type = 5, Unnumbered LOCAL_INTERFACE_ID
  • C-Type = 6, Unnumbered REMOTE_INTERFACE_ID

lmp_doc_interface_id_unnum

Interface_Id:

LOCAL_INTERFACE_ID表示消息对应的接口索引。该值必须是非0值。

REMOTE_INTERFACE_ID表示对端节点的接口索引,也必须是非0值。

该对象是不可协商的。

13.5.MESSAGE_ID Class

Class = 5

  • C-Type=1, MessageId

lmp_doc_msg_id

Message_Id:

Message_Id字段用来区分消息ID,该值是递增的且可能翻转。它被广泛用在消息交换中。

该对象是不可协商的。

  • C-Type = 2, MessageIdAck

lmp_doc_msg_id

Message_Id:

Message_Id字段用来区分响应消息的ID,该值从收到的message消息的MESSAGE_ID对象中获得。

该对象是不可协商的。

13.6.CONFIG Class

Class = 6

  • C-Type = 1, HelloConfig

lmp_doc_config_class

HelloInterval: 16 bits

表示Hello报文发送的间隔,单位(ms)。

HelloDeadInterval: 16 bits

如果HelloDeadInterval周期内收不到Hello报文,CC将失效,周期的单位是(ms)。HelloDeadInterval必须比HelloInterval大,一般建议是HelloInterval的3倍。

如果快速保活机制并没有启用,HelloInterval和HelloDeadInterval的值必须置0。

13.7.HELLO Class

Class = 7

  • C-Type = 1, Hello

lmp_doc_hello_class

TxSeqNum: 32 bits

表示当前Hello消息的序列号,该序列号时递增的,同理收到Hello消息,RcvSeqNum也是递增的。

TxSeqNum=0是不允许的。TxSeqNum=1表示这是第一个CC上发送的Hello消息。

RcvSeqNum: 32 bits

表示CC上收到的最后一个Hello消息的序列号。RcvSeqNum=0用来表示当前还没有收到Hello消息。

该对象是不可协商的。

13.8.BEGIN_VERIFY Class

Class = 8

  • C-Type = 1

lmp_doc_beginverify_class

保留字段应该默认置0并在收端忽略。

Flags: 16 bits

标记定义如下:

0x0001 Verify all Links

如果该位为1,将会校验所有空闲的链路,否则仅校验新增端口或者将要绑定到该TE的端口。

0x0002 Data Link Type

如果该位为1,表示将检验的是端口,否则是成员链路。

VerifyInterval: 16 bits

Test消息间隔,单位(ms)。

Number of Data Links: 32 bits

将要检验的数据链路数量

EncType: 8 bits

数据链路编码方式,EncType取值参考文档RFC3471中LSP编码方式的取值。

Verify Transport Mechanism: 16 bits

本字段定义了Test消息的验证传输机制,每个比特位对应一种编码方式。本地节点会在LMP消息中置位它支持的所有编码方式,接收方从收到的BeginVerifyAck中选择一种双方都支持的方式。

下面的标记在每种编码方式里面都有,所有其他标记均以编码方式标记为基址。

0x8000 Payload:Test消息在payload中传输。
Test消息可以在payload中以IP包的方式传输。

TransmissionRate: 32 bits

Test消息在数据链路上的传输速率,单位是Bytes/s,遵循IEEE浮点数单位标准。

Wavelength: 32 bits

当数据链路映射到一个可以传输多个波长的物理端口或者成员链路(比如光纤或者波分端口)时,我们必须要知道Test消息在哪个波长上传输。该值就用来描述Test消息在哪个波长上传输。如果不知道在哪个波长上传输,本值应该置为0。

13.9.BEGIN_VERIFY_ACK Class

Class = 9

  • C-Type = 1

lmp_doc_beginverify_ack_class

VerifyDeadInterval: 16 bits

如果Test消息没有检测到VerifyDeadInterval,节点会发送给一个该数据链路的TestStatusFailure消息。

Verify_Transport_Response: 16 bits

BeginVerify消息和后面TEST消息的接收方会从对端Test消息中选取一种检验编码方式,在相应消息Verify_Transport_Response中必须置且只置一个位返回给发送方。

该对象是不可协商的。

13.10.VERIFY_ID Class

Class = 10

  • C-Type = 1

lmp_doc_verifyid_class

Verify_Id: 32 bits

该值用来区分不同TE或者LMP邻居的Test消息,该值是节点级唯一的,由BeginVerify消息的接收方指定。

该对象是不可协商的。

Class = 11

  • C-Type = 1, IPv4 TE_LINK

lmp_doc_telink_class

  • C-Type = 2, IPv6 TE_LINK

lmp_doc_telink_class

  • C-Type = 3, Unnumbered TE_LINK

lmp_doc_telink_class_unnum

预留字段应该置0并在收端被忽略。

Flags: 8 bits

定义如下,其他预留的位应该置0并在收端被忽略。

0x01 支持故障管理。

0x02 支持链路校验。

Local_Link_Id:

本节点的链路索引,必须是非0值。

Remote_Link_Id:

对端链路的索引,必须是非0值。

Class = 12

  • C-Type = 1, IPv4 DATA_LINK

lmp_doc_datalink_class

  • C-Type = 2, IPv6 DATA_LINK

lmp_doc_datalink_class_ipv6

  • C-Type = 3, Unnumbered DATA_LINK

lmp_doc_datalink_class_unnum

预留字段应该置0并在收端被忽略。

Flags: 8 bits

定义如下,其他预留的位应该置0并在收端被忽略。

0x01 Interface Type:为1表示数据链路对应一个物理端口,否则是一个成员链路。

0x02 Allocated Link:为1表示数据链路当前被用户业务使用。如果Interface_Id同时对应数据链路的发方向和收方向,该字段只标在发方向上。

0x04 Failed Link:为1表示数据链路失效,不适合新建业务。

Local_Interface_Id:

本端数据链路索引,必须是节点级唯一的非0值。

Remote_Interface_Id:

对端数据链路索引,必须是节点级唯一的非0值。

Subobjects:

DATA_LINK对象包含的内容由一系列变长的数据组成,称为Subobjects。Subobjects在下面13.12.1章定义。

一个DATA_LINK对象可能包含超过一个subobject。如果链路支持的话,同一个类型的对象也可能出现多次。

DATA_LINK对象包含的内容由一系列变长的数据组成。每个subobject都有如下的形式:

lmp_doc_datalink_subobject

Type: 8 bits

Type指定了subobject的类型,当前定义的有:

Type = 1, 链路调度类型

Type = 2, 波长

Length: 8 bits

长度包含subobject的总长度(字节),包含Type和Length字段的长度。所以长度至少大于等于4,必须是4的倍数。

13.12.1.1.Subobject Type 1: 链路调度类型

lmp_doc_datalink_subobject_type1

Switching Type: 8 bits

该字段用来标识链路的调度类型,具体参见GMPLS协议文档RFC3471

EncType: 8 bits

定义数据链路的编码方式,该编码方式和RFC3471协议中LSP编码方式一直。

Minimum Reservable Bandwidth: 32 bits

单位为B/s,遵循IEEE浮点格式定义。

Maximum Reservable Bandwidth: 32 bits

同上

如果链路只支持固定速率,最大带宽和最小带宽值填为一样。

13.12.1.1.Subobject Type 2: 波长

lmp_doc_datalink_subobject_type2

预留的位应该置0并在收端被忽略。

Wavelength: 32 bits

该值表示端口上承载的的波长,只在两个节点间的端口上有效。

13.13 CHANNEL_STATUS Class

Class = 13

  • C-Type = 1, IPv4 INTERFACE_ID

lmp_doc_channelstatus_class_ipv4

  • C-Type = 2, IPv6 INTERFACE_ID

lmp_doc_channelstatus_class_ipv6

  • C-Type = 3, Unnumbered INTERFACE_ID

lmp_doc_channelstatus_class_unnum

Active bit: 1 bit

表示通道是否被业务使用,如果使用数据链路应该处于激活监视状态。

Direction bit: 1 bit

表示CHANNEL_STATUS对象对应的通道的传输方向,为1表示发送方向。

Channel_Status: 30 bits

标识通道的状态,下列值被定义,其他值预留:

1 Signal Okay (OK): 通道正常
2 Signal Degrade (SD): 轻度故障导致光纤BER越限。
3 Signal Fail (SF): 发生了严重故障包括但不限于光信号丢失(LOS)、帧丢失(LOF)、或者光纤AIS

该对象包含一个或多个Interface_Id,后跟Channel_Status字段。

如果要指示整条TE链路的状态,那只能有一个Interface_Id且值为0。

该对象是不可协商的。

13.14.CHANNEL_STATUS_REQUEST Class

Class = 14

  • C-Type = 1, IPv4 INTERFACE_ID

lmp_doc_channelstatusrequest_class

该对象包含一个或多个Interface_Id。

长度为4+4N,N为Interface_Id的数量。

  • C-Type = 2, IPv6 INTERFACE_ID

lmp_doc_channelstatusrequest_class_ipv6

该对象包含一个或多个Interface_Id。

长度为4+16N,N为Interface_Id的数量。

  • C-Type = 3, Unnumbered INTERFACE_ID

lmp_doc_channelstatusrequest_class_unnum

该对象包含一个或多个Interface_Id。

长度为4+4N,N为Interface_Id的数量。

13.15.ERROR_CODE Class

Class = 20

  • C-Type = 1, BEGIN_VERIFY_ERROR

lmp_doc_errcode_class

下列比特位被定义使用,字节序为网络序(大端序)。

0x01 = 不支持链路校验机制。
0x02 = 无法开始校验。
0x04 = 不支持校验传输机制。
0x08 = Link_Id配置错误。
0x10 = 对象C-Type类型不识别。

其他预留的位应该置0并在收端被忽略。

可以同时有多个错误码被置位表示同时有多个错误。

该对象是不可协商的。

例如:如果收到BeginVerifyNack消息携带错误码2,那么发端应该在Rf后重传,Rf为本站定义的重传时间间隔。

  • C-Type = 2, LINK_SUMMARY_ERROR

lmp_doc_errcode_class_linksummary

下列比特位被定义使用,字节序为网络序(大端序)。

0x01 = 无法接受的LINK_SUMMARY不可协商参数。
0x02 = 重新协商LINK_SUMMARY参数。
0x04 = 无效TE_LINK对象。
0x08 = 无效DATA_LINK对象。
0x10 = 不识别C-Type的TE_LINK对象。
0x10 = 不识别C-Type的DATA_LINK对象。

其他预留的位应该置0并在收端被忽略。

可以同时有多个错误码被置位表示同时有多个错误。

该对象是不可协商的。

14.参考文献

14.1.规范性参考文献

[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, March 1997.

[RFC4201] Kompella, K., Rekhter, Y., and L. Berger, “Link Bundling in MPLS Traffic Engineering (TE)”, RFC 4201, October 2005.

[RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., “Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)”, RFC 4202, October 2005.

[RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., and S. Molendini, “RSVP Refresh Overhead Reduction Extensions”, RFC 2961, April 2001.

[RFC2402] Kent, S. and R. Atkinson, “IP Authentication Header”, RFC2402, November 1998.

[RFC2406] Kent, S. and R. Atkinson, “IP Encapsulating Security Payload (ESP)”, RFC 2406, November 1998.

[RFC2407] Piper, D., “The Internet IP Security Domain of Interpretation for ISAKMP”, RFC 2407, November 1998.

[RFC2409] Harkins, D. and D. Carrel, “The Internet Key Exchange (IKE)”, RFC 2409, November 1998.

[RFC3471] Berger, L., Ed., “Generalized MPLS - Signaling Functional Description”, RFC 3471, January 2003.

14.2.信息参考

[RFC3630] Katz, D., Kompella, K., and D. Yeung, “Traffic Engineering (TE) Extensions to OSPF Version 2”, RFC 3630, September 2003.

[RFC3784] Smit, H. and T. Li, “Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE)”, RFC 3784, June 2004.

[RFC2401] Kent, S. and R. Atkinson, “Security Architecture for the Internet Protocol”, RFC 2401, November 1998.

[RFC2434] Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs”, BCP 26, RFC 2434, October 1998.

[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, “RSVP-TE: Extensions to RSVP for LSP Tunnels”, RFC 3209, December 2001.

15.安全性考虑

LMP协议可能遭到不同的网络攻击,比如:

  • 攻击者发送欺骗控制报文
  • 攻击者拦截并修改报文
  • 攻击者发送复制报文攻击
  • 攻击者可能抓取部分报文并使用解密工具破解密钥,如果加密算法存在已知漏洞,则很容易被攻击者利用并破解出密钥。

本章则描述了LMP基于IPsec的安全机制。

15.1.安全要求

本章在下面描述了LMP的安全要求。

  • LMP必须能够提供认证、完整性校验和复制报文攻击保护。
  • LMP传输的报文不需要加密,只需要提供认证机制确保控制报文是正确的远端传送过来的并且没有被篡改。数据链路上的LMP的Test消息不需要保护。
  • 对于LMP报文,LMP节点的身份保护通常不需要。
  • 安全机制应当提供良好设计的密钥管理机制。密钥应当在业界是安全成熟的,可扩展的甚至是自动的。
  • 用于认证的算法必须是密码学成熟的,同时认证协议也必须允许两边协商选择,以便可以使用不同的认证算法。

15.2.安全机制

IPsec是一个用来在网络层节点间安全通信的协议工具包。该协议由IP安全架构文档RFC2401,IKERFC2409,IPsec AHRFC2402和IPsec ESPRFC2406。IKE是IP网络的关键管理协议,AH和ESP用来保护IP网络流量。IKE是专门于IP的网络密钥交换协议。

考虑到15.1章中描述的要求,我们推荐当LMP需要考虑安全的时候,使用如下的IPsec来实现功能:

  1. 基于IPsec协议实现LMP需要支持手动控制模式。
    手动控制模式提供了方便的设置和调试IPsec功能的手段。
    然而,手动控制模式不能支持类似报文重复攻击保护或者自动密钥分配。实现者应当了解手动模式的这些限制。
    所以我们推荐实现者仅在调试的时候使用手工模式,为了使用上面的两个功能,请使用自动模式。

  2. 在隧道模式下,带有负载验证的IPsec ESP必须支持。

  3. 实现的时候,LMP必须支持认证密钥交换协议。如果邻居间动态协商密钥,必须使用IKERFC2409协议。

  4. 具体实现必须使用IPsec DOIRFC2409

  5. IKE协议中,在快速协商模式中有SA标记代表着两端节点同意保护的流量由地址空间、协议类型和端口信息组成。
    在IPsec协议上实现的LMP协议,推荐在快速模式的身份识别字段中包含以下信息:
    身份识别ID必须是IP地址格式,取值是两端节点的IP地址。
    协议类型字段必须是UDP,端口字段必须置0表示该字段需要被忽略。这意味着所有节点间的UDP流量必须在IPSec隧道中传送。如果实现上支持基于端口进行选择,那可以通过在端口字段上指定具体端口来实现更精细的传送流量控制。反之则必须将该字段置0。

  6. 必须支持IKE协议的主动模式
    当节点间使用IPSec协议时,所有的LMP协议应当在IPSec隧道(加密隧道)中传输。类似的,LMP接收方也应当拒绝所有不在IPSec隧道上收到的消息。
    加密隧道可以是LMP里邻居节点提前设置好的,也可以是从发送的LMP消息中解析出的具体指定通道。
    多个控制通道可以共享一个加密通信隧道,当LMP的Hello消息在监控控制通道状态的时候,我们需要始终记得此时CC的失效有可能是加密隧道失效造成的。下面的手段可以用来确认两个节点间的LMP通信是否正常:

  • 如果LMP Hello检测到CC失效,可以切换到另外的控制通道并试着重新建立一个新的CC连接。

  • 使用LMP Hello机制来确认CC的通信状态,如果所有的CC显示故障,新增的通道也建立不起来,检查所有存在的CC,并同时检查IPSec和IP SA加密隧道。

  • 重建加密隧道,建立失败则意味着LMP通信存在致命故障。

  • 尝试UP CC,建立失败同样意味着LMP通信存在致命故障。

当LMP邻居是动态发现的时候,下面这些点需要注意:

在身份模式识别中使用预先设置好的密码时,需要计算一个密码的SKEYID(对应通信中加密的KEY值)。在IKE主模式中,预设密码需要在收到对端身份识别豹纹之前设置好,这个密码会用来计算SKEYID。此时,我们唯一知道的是对端的IP地址,如果不知道ID地址是不可能获取到预设密码的,因为IP地址是动态生成的,根本无法提前预测。

因为身份识别报文是发动的第一个报文,所以我们可以使用主动密钥交换模式。

需要注意,主动模式很容易被DDOS攻击。推荐使用共享密钥技术,因为它有助于避免中间者攻击。

数字签名验证不容易面临上面所述的问题,可以的话建议使用数字签名验证。

如果需要使用预设密码,应该使用主动模式。IKE预设密码应该使用和用户账户密码同等的保护方式保护。

16.IANA考虑

INNA分配给LMP的端口号是701。

下面给出了INNA给每个LMP变量命名空间的取值指导,每个取值空间有其特定含义并经过专家评审,符合RFC2434的标准要求。

LMP协议留给私有数据的编号空间不在文档的标准定义中,不同的LMP实现代码可能不能互相识别这些私有的报文定义,所以在多厂商的混合组网中,一定要注意这些私有报文。

IESG指定专家会审查LMP编号区间,本章描述了一些实验性扩展的参数取值,这些取值必须便随着实验性标签,如果实际部署建议这些扩展确实有用,那他们必须打上标准标签,新增的编码及对应的处理流程也必须同时指定清楚。

标准定义的的编码必须和RFC标签一起在文档中定义清楚,并且通常需要提交给IETF组织,但一般情况下不管怎样都需要遵循标准IETF的制定流程。

LMP Common报文头中的预留字节需要按照标准流程申请使用,一般按照RFC2434文档中概述的流程操作。

LMP定义了下列需要统一管理的命名空间:

  • LMP 消息类型
  • LMP 对象类
  • LMP 对象类类型(C-Type),每种类里各有一套编码。
  • LMP 子对象类类型(Type),每种类里各有一套编码。

LMP消息类型编码空间应该按照下述流程申请使用:
按照RFC2434中概述的流程,0-127的编码被标准流程使用,128-240由组委会专家评审通过后使用,241-255留有私有定义使用。

LMP对象类编码空间应该按照下述流程申请使用:
按照RFC2434中概述的流程,0-127的编码被标准流程使用,128-247由组委会专家评审通过后使用,248-255留有私有定义使用。

定义LMP对象类编码的策略是类定义的一部分,当定义一个类的时候,它的定义中必须包含对应编码的分配策略。

LMP子对象也同上。

下列命令空间是INNA规定的:


LMP消息类型

  • Config message (Message type = 1)
  • ConfigAck message (Message type = 2)
  • ConfigNack message (Message type = 3)
  • Hello message (Message type = 4)
  • BeginVerify message (Message type = 5)
  • BeginVerifyAck message (Message type = 6)
  • BeginVerifyNack message (Message type = 7)
  • EndVerify message (Message type = 8)
  • EndVerifyAck message (Message type = 9)
  • Test message (Message type = 10)
  • TestStatusSuccess message (Message type = 11)
  • TestStatusFailure message (Message type = 12)
  • TestStatusAck message (Message type = 13)
  • LinkSummary message (Message type = 14)
  • LinkSummaryAck message (Message type = 15)
  • LinkSummaryNack message (Message type = 16)
  • ChannelStatus message (Message type = 17)
  • ChannelStatusAck message (Message type = 18)
  • ChannelStatusRequest message (Message type = 19)
  • ChannelStatusResponse message (Message type = 20)

LMP 对象类取值空间和对象类型(C-Type)

  • CCID Class name (1)

CCID对象类型取值空间按照下述规则分配:
按照RFC2434中概述的流程,0-111标准定义使用,112-119组委会评审使用,120-127留给私有定义使用。

  1. LOCAL_CCID (C-Type = 1)
  2. REMOTE_CCID (C-Type = 2)
  • NODE_ID Class name (2)
    0-111标准定义使用,112-119组委会评审使用,120-127私有定义使用。
  1. LOCAL_NODE_ID (C-Type = 1)
  2. REMOTE_NODE_ID (C-Type = 2)
  • LINK_ID Class name (3)
    0-111标准定义使用,112-119组委会评审使用,120-127私有定义使用。
  1. IPv4 LOCAL_LINK_ID (C-Type = 1)
  2. IPv4 REMOTE_LINK_ID (C-Type = 2)
  3. IPv6 LOCAL_LINK_ID (C-Type = 3)
  4. IPv6 REMOTE_LINK_ID (C-Type = 4)
  5. Unnumbered LOCAL_LINK_ID (C-Type = 5)
  6. Unnumbered REMOTE_LINK_ID (C-Type = 6)
  • INTERFACE_ID Class name (4)
    0-111标准定义使用,112-119组委会评审使用,120-127私有定义使用。
  1. IPv4 LOCAL_INTERFACE_ID (C-Type = 1)
  2. IPv4 REMOTE_INTERFACE_ID (C-Type = 2)
  3. IPv6 LOCAL_INTERFACE_ID (C-Type = 3)
  4. IPv6 REMOTE_INTERFACE_ID (C-Type = 4)
  5. Unnumbered LOCAL_INTERFACE_ID (C-Type = 5)
  6. Unnumbered REMOTE_INTERFACE_ID (C-Type = 6)
  • MESSAGE_ID Class name (5)
    0-111标准定义使用,112-119组委会评审使用,120-127私有定义使用。
  1. MESSAGE_ID (C-Type = 1)
  2. MESSAGE_ID_ACK (C-Type = 2)
  • CONFIG Class name (6)
    0-111标准定义使用,112-119组委会评审使用,120-127私有定义使用。
  1. HELLO_CONFIG (C-Type = 1)
  • HELLO Class name (7)
    0-111标准定义使用,112-119组委会评审使用,120-127私有定义使用。
  1. HELLO (C-Type = 1)
  • BEGIN_VERIFY Class name (8)
    0-111标准定义使用,112-119组委会评审使用,120-127私有定义使用。
  1. Type 1 (C-Type = 1)
  • BEGIN_VERIFY_ACK Class name (9)
    0-111标准定义使用,112-119组委会评审使用,120-127私有定义使用。
  1. Type 1 (C-Type = 1)
  • VERIFY_ID Class name (10)
    0-111标准定义使用,112-119组委会评审使用,120-127私有定义使用。
  1. Type 1 (C-Type = 1)
  • TE_LINK Class name (11)
    0-111标准定义使用,112-119组委会评审使用,120-127私有定义使用。
  1. IPv4 TE_LINK (C-Type = 1)
  2. IPv6 TE_LINK (C-Type = 2)
  3. Unnumbered TE_LINK (C-Type = 3)
  • DATA_LINK Class name (12)
    0-111标准定义使用,112-119组委会评审使用,120-127私有定义使用。
  1. IPv4 DATA_LINK (C-Type = 1)
  2. IPv6 DATA_LINK (C-Type = 2)
  3. Unnumbered DATA_LINK (C-Type = 3)

DATA_LINK Sub-object,0-111标准定义使用,112-119组委会评审使用,120-127私有定义使用。

  1. Interface Switching Type (sub-object Type = 1)
  2. Wavelength (sub-object Type = 2)
  • CHANNEL_STATUS Class name (13)
    0-111标准定义使用,112-119组委会评审使用,120-127私有定义使用。
  1. IPv4 INTERFACE_ID (C-Type = 1)
  2. IPv6 INTERFACE_ID (C-Type = 2)
  3. Unnumbered INTERFACE_ID (C-Type = 3)
  • CHANNEL_STATUS_REQUESTClass name (14)
    0-111标准定义使用,112-119组委会评审使用,120-127私有定义使用。
  1. IPv4 INTERFACE_ID (C-Type = 1)
  2. IPv6 INTERFACE_ID (C-Type = 2)
  3. Unnumbered INTERFACE_ID (C-Type = 3)
  • ERROR_CODE Class name (20)
    0-111标准定义使用,112-119组委会评审使用,120-127私有定义使用。
  1. BEGIN_VERIFY_ERROR (C-Type = 1)
  2. LINK_SUMMARY_ERROR (C-Type = 2)

17.致谢

The authors would like to thank Andre Fredette for his many contributions to this document. We would also like to thank Ayan Banerjee, George Swallow, Adrian Farrel, Dimitri Papadimitriou, Vinay Ravuri, and David Drysdale for their insightful comments and suggestions. We would also like to thank John Yu, Suresh Katukam, and Greg Bernstein for their helpful suggestions for the in-band control channel applicability.

18.贡献者

Jonathan P. Lang
Sonos, Inc.
223 E. De La Guerra St.
Santa Barbara, CA 93101

EMail: jplang@ieee.org

Krishna Mitra
Independent Consultant

EMail: kmitra@earthlink.net

John Drake
Calient Networks
5853 Rue Ferrari
San Jose, CA 95138

EMail: jdrake@calient.net

Kireeti Kompella
Juniper Networks, Inc.
1194 North Mathilda Avenue
Sunnyvale, CA 94089

EMail: kireeti@juniper.net

Yakov Rekhter
Juniper Networks, Inc.
1194 North Mathilda Avenue
Sunnyvale, CA 94089

EMail: yakov@juniper.net

Lou Berger
Movaz Networks

EMail: lberger@movaz.com

Debanjan Saha
IBM Watson Research Center

EMail: dsaha@us.ibm.com

Debashis Basak
Accelight Networks
70 Abele Road, Suite 1201
Bridgeville, PA 15017-3470

EMail: dbasak@accelight.com

Hal Sandick
Shepard M.S.
2401 Dakota Street
Durham, NC 27705

EMail: sandick@nc.rr.com

Alex Zinin
Alcatel

EMail: alex.zinin@alcatel.com

Bala Rajagopalan
Intel Corp.
2111 NE 25th Ave
Hillsboro, OR 97123

EMail: bala.rajagopalan@intel.com

Sankar Ramamoorthi
Juniper Networks, Inc.
1194 North Mathilda Avenue
Sunnyvale, CA 94089

EMail: sankarr@juniper.net

联系方式

Jonathan P. Lang
Sonos, Inc.
829 De La Vina, Suite 220
Santa Barbara, CA 93101

EMail: jplang@ieee.org

版权声明

Copyright (C) The Internet Society (2005).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

知识产权

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Informationon the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.

致谢

Funding for the RFC Editor function is currently provided by the Internet Society.