分组格式与分组转发

  • OLSR协议对跟其有关的所有数据采用统一的分组格式进行通信
  • 其目的是为了便于OLSR协议的功能扩充和强化，以及版本升级，而又不会影响OLSR协议的向后兼容性
  • 同时提供一种简易方法将不同“类型”的信息组合在一起进行一次传输， 因而有利于采用网络提供的最大分组。

  • 这些分组可以嵌入在UDP数据报中在网络中传输。本版本采用IPv4地址。

  • 每个分组封装一条或者多条消息

  • 各条消息共享一个公共分组头格式，使得各个节点能够正确接收和转发未知类型的消息(假如适当的话)

  • 消息可以泛洪到整个网络中，或者泛洪到某一直径(离本消息源节点的跳数距离)的有限范围内

  • 因此，将一条消息发送给一个节点的相邻区域正好是泛洪的一种特殊情形

  • 当泛洪任一控制消息时，就地排除该消息拷贝的重传(即每个节点维护一个拷贝集，用于防止对同一条OLSR控制消息发送两次或者两次以上)，采用随后描述的MPR将控制消息在整个网络中的重传次数降低到最低程度

  • 此外，一个节点可以检查消息的头部，获取有关到达该消息源节点的跳数距离

  • 这种特征在有些场合可能非常有用

  • 例如，存储在节点中的、来自所接收控制消息的时间信息取决于到达本消息源节点的距离

    OLSR协议和端口号

  • OLSR协议中的分组采用UDP进行通信

  • IANA已经将端口698分配给OLSR协议专门使用

    主地址

  • 对于只包含单个接口的-一个节点，根据“OLSR协议术语”，该节点的主地址必须设为该接口地址

    分组格式

    image.png

  • 分组头

    • 分组头包含分组长度、分组序列号两个组成部分，详细说明如下:
    • ①分组长度(Packet Length)。本域表示本分组的字节长度。
    • ②分组序列号(Packet Sequence Number, PSN)。 每当发送一个新的OLSR分组的时候，必须将分组序列号PSN加1。按照方法（https://www.yuque.com/wangxi_chn/iku3gm/iaiicw）处理序列号的返转(Wrap-Around) 问题。为每个接口单独维护一个分组序列号，这样在一个接口上发送的分组被连续添加序列号编号。
    • 从分组的IP头中获取发送本分组的接口的地址。假如一个分组没有任何消息(即分组长度小于或者等于分组头的长度)，则必须丢掉该分组。对于IPv4 地址，这就意味着分组长度小于16个字节的分组被丢掉。

image.png

  • 消息头
    • 消息头由消息类型、接收信息有效时间、消息长度、消息源节点地址、消息发送有效时间、跳数、消息序列号组成，详细说明如下。
    • ①消息类型(Message Type)。本域说明随后的“消息”的类型。本文的消息类型编码为0~127， 今后有可能进一步扩充。
    • ②接收信息有效时间(Vtime)。 本域说明一个节点必须考虑本消息中包含的信息在被接收之后的有效时间长度，除非接收到本信息的一个最近更新。有效时间用本域高部4比特表示的尾数和本域低部4比特表示的指数来共同表示，即:

【自组织网络】OLSR分组转发 - 图3

  • 其中: a表示本域高部4比特表示的整数，b表示本域低部4比特表示的整数。比例因子C的建议值见（https://www.yuque.com/wangxi_chn/iku3gm/gb60gu）
  • ③消息长度(Message Size)。本域给出本条消息的长度，以字节为单位，从“消息类型”开始计算到下一条“消息”开始的位置为止(假如后面没有其他消息，则到本分组最后字节为止)。
  • ④消息源节点地址(Originator Address)。本域包含产生本条消息的源节点的主地址。不应该混淆本域与IP头中的源地址，后者随着每当到达一个转发本条消息的中间接口地址而变化。本域在本分组的整个传输过程中必须保持不变。

image.png

  • ⑤消息发送有效时间(Time To Live, TTL)。本域说明本条消息将被发送传输的最大跳数。在发送本条消息前，必须将本域的值减一。当-一个节点接收到一条消息发送有效时间等于0或者1的消息后，在任何条件下都不必转发该消息。一般情况下，节点不会接收到TTL等于0的消息。
  • 因此，消息的源节点通过设置TTL的值就能够限制消息的泛洪范围。
  • ⑥跳数(Hop Count)。本域说明本条消息已经传输通过的转发跳数。在一条消息被转发之前，必须将其跳数加1。开始的时候，消息的源节点将本域设为0。
  • ⑦消息序列号(Message Sequence Number)。当产生消息的时候，消息的源节点给其产生的每条消息分配一个唯一的识别码号码。 将这个号码插入到本条消息的序列号组成域。一个节点每产生一条消息,就将消息序列号加一。按照描述的方法（https://www.yuque.com/wangxi_chn/iku3gm/iaiicw）处理消息序列号的返转问题。消息序列号用来确保一条消息不会被任何一个节点转发两次或者两次以上。

    分组处理和消息泛洪

  • 一个节点接收到一个基本分组后，检查其中包含的每个“消息头”
  • 根据“消息类型”的取值，该节点就能够决定该消息的最终结果
  • 一个节点可能对同一条消息接收到多次
  • 因此,为了避免重复处理某些已经被接收过和处理过的消息，每个节点维护一个拷贝集合
  • 节点将有关最近所接收到的消息的信息记录在拷贝集合中，从而避免一条消息的重复处理
  • 对于一条消息,每个节点在拷贝集合中记录一个“拷贝数组”
  • 【自组织网络】OLSR分组转发 - 图5
  • D_addr表示本条消息的源节点地址
  • D_seq_num表示本条消息的消息序列号
  • D_retransmitted表示本条消息是否已经被转发过的布尔指示标志
  • D_iface_list表示依次接收到本条消息时的各个接口的地址的列表
  • D_time表示本数组的有效期满时间，在期满时间结束时必须删除本数组

  • 一个节点的拷贝数组集合就是该节点的“拷贝集合”

  • 在本小节，将“消息源节点地址”用作发送本条消息的节点的主地址

  • 将“发送节点接口地址”用作发送本条消息的接口的发送节点地址(假定在包含本条消息的本分组的IP 头中),
  • 将“接收接口地址”用作接收本条消息的节点的接口地址

处**理流程**

  • 一个节点接收到一个基本分组后，必须对其中封装的每条消息执行以下操作:
  • 第一步，假如该分组没有包含任何消息(即：分组长度小于或者等于分组头的长度)，则必须丢掉该分组。对于IPv4地址，这就意味着分组长度小于16字节的分组必须丢掉。
  • 第二步，假如本条消息的TTL小于或者等于0，或者假如本条消息是该节点发送的(即本条消息的消息源节点地址等于本节点的主地址)，则必须丢掉该分组。
  • 第三步，处理条件如下:

(1) 假如本拷贝集合中存在一个数组，使得同时满足
D addr = Originator Address(本条消息的消息源节点地址);
D seq _num = Message Sequence Number (本条消息的消息序列号)。
则本条消息已经被完全处理过，不必再处理。
(2) 否则，假如该节点认可本条消息的消息类型，则必须按照本条消息所属类型的规范进行处理。

  • 第四步，转发条件如下:

(1) 假如本拷贝集合中存在一个数组，使得同时满足
D addr = Originator Address(本条消息的消息源节点地址);
D seq_num = Message Sequence Number (本条消息的消息序列号):
接收接口地址在 D_iface_list 列表中
则本条消息已经被考虑转发过，不必再转发。
(2) 否则:
假如该节点认可本条消息的消息类型，则必须按照本条消息所属类型的规范考虑转发该条消息。
否则(即该节点不认可本条消息的消息类型)，则应该按照下面描述的默认转发算法处理该条消息。

默认转发算法

  • 第一步，假如在该节点的对称一跳相邻区域内没有检测到本条消息的发送节点接口地址，则必须就此停止执行本转发算法，也不必转发本条消息。
  • 第二步
    • 假如本拷贝集合中存在一个数组，使得同时满足

D_addr = Originator Address(本条消息的消息源节点地址);
D_seq_num = Message Sequence Number (本条消息的消息序列号)。
那么当且仅当同时满足下列条件时应该进一步考虑本条消息的转发:
标志D_retransmitted设为false (假);
接收本条消息的接口(地址)不在D_iface_list列表中

  • 第三步，否则，假如本拷贝集合中不存在这样的条目，则进一步考虑本条消息的转发
  • 假如经过上述三步的处理后不再考虑本条消息的转发，则本节点的处理就此完毕(即随后的第四步到第八步的处理被忽略)；否则，假如仍然继续考虑本条消息的转发,则采用以下算法:
  • 第四步，假如发送节点接口地址等于本节点一个MPR选择器的地址，并且本条消息的TTL大于1，则必须转发本条消息(见随后的第六步到第八步)
  • 第五步，假如本拷贝集合中存在一个条目，具有相同的消息源节点地址、相同的消息序列号，那么本条目更新

D time = current time + DUP HOLD TIME
将该接收接口(地址)添加到D_iface_list 列表中
将标志D retransmitted设为true (真)
否则，在本拷贝集合中记录一个条目如下
D addr = Originator Address(本条消息的消息源节点地址)
D seq num = Message Sequence Number (本条消息的消息序列号)
D_time = current time + DUP HOLD TIME
D iface list包含该接收接口地址
当且仅当按照第四步转发本条消息，则将标志D retransmitted 设为真
假如当且仅当按照第四步必须转发本条消息，则执行下一步操作:

  • 第六步，将本条消息的TTL减1。
  • 第七步，将本条消息的跳数加1。

  • 第八步，将本条消息广播到所有的接口上(注意：本条消息的其余组成域保持不变)

  • 应该注意

  • 消息的处理和转发是两种不同的操作，取决于不同规则
  • 消息的处理涉及消息内容的利用

  • 消息的转发则涉及将同一条消息转发给网络中的其他节点

  • 本规范包含每种已知消息类型的转发和处理

  • 使用OLSR默认转发算法时不必盲目地转发类型己知的消息
  • 转发以及正确设置被转发已知消息的消息头是OLSR默认转发算法完成的任务，即详细说明如何处理该消息
  • 假如必要的话还要详细说明如何转发该消息
  • 这就能够为消息指定消息类型，使得消息在传输过程中能够被修改(例如反映该消息已经通过的路由信息)
  • 假如由于某种原因而需要经典泛洪一条消息，则可以将MPR泛洪机制关闭

  • 经典泛洪法详细说明了如何处理消息：对消息采取简单地重复广播，而与MPR无关

  • 通过定义一个消息类型集合，就可能给OLSR协议引入其他的消息类型，而同时仍然能够保持兼容以前的版本

  • 定义的消息类型集合必须被所有的OLSR协议实现所认识

  • OLSR协议内核功能要求的消息类型如下:

    • HELLO消息：用于完成链路探测、相邻节点探测、以及MPR信令任务
    • TC消息：用于完成拓扑声明任务(广播链路状态)
    • MID消息：用于完成声明一个节点存在多个接口的任务

以及今后可能增加诸如使能节能/休眠方式、多目标路由、单向链路支持、自动配置/地址分配等消息类型

消息发送与抖动时间

  • 作为一个基本的实现要求，应该避免控制消息的同步
  • 因此，OLSR控制消息的发送应该避免同步
  • 由于各种原因(主要是分组处理的定时器相互作用的缘故)，将所接收到的相邻节点的控制消息重新发送出去可能需要同步，以便若千个相邻节点同时尝试发送控制消息

  • 根据链路层的特点，这可能会引起碰撞，以及由此产生的分组丢失，可能丢失随后同一类型的数条消息

  • 采用如下消息发送控制策略避免这种发送同步问题

  • 一个节点应该给消息的产生间隔时间添加一定的抖动时间(Jitter)
  • 对于每条产生的消息，其抖动时间必须是一个随机数值
  • 因此，对于使用抖动时间的一个节点，则有:

消息的实际间隔时间= MESSAGE INTERVAL (消息间隔时间) - 抖动时间
抖动时间是一个从[0, MAXJITTER]范围内随机选出的数值，MAXJITTER 表示最大抖动时间
MESSAGEINTERVAL(消息间隔时间)是为发送本条消息而指定的消息间隔时间
例如HELLO INTERVAL (HELLO消息发送间隔时间)、TC_ INTERVAL (TC消息发送间隔时间)，等等

  • 转发消息的时候也应该引入抖动时间
  • 可以采用下列简单策略
  • 当一条消息被一个节点转发的时候，该条消息应该在该节点中保存如下长度的一段时间:

消息保存时间=抖动时间(Jitter)
抖动时间是一个从[0, MAXJITTER]范围内随机选出的数值
一个节点发送一条控制消息时，可以顺便携带其他消息(在其保存时间结束之前)，以便减少分组传输数量

  • 注意:采用最小控制消息发送速率
  • 假如有利于特定的应用，那么节点可以采用较高速率发送控制消息