[发明专利]一种pimdm路由器上的优化方法

说明书

技术领域：

本发明涉及数据通信中的IP组播路由，特别涉及一种pimdm路由器上的优化方法。

背景技术：

Internet路由协议中，对于密集模式的组播路由协议pimdm而言，在实际数据通信中存在以下缺陷：如图1所示，上游两台设备，实际上是由assert winner负责组播报文的转发。如果同一个网段有三台或者三台以上机器，assertwinner的下游端口出现故障，则目前的RFC中的做法，无法让下游邻居快速知道上游assert winner已经失效，势必要等到邻居(assert winner)超时或者上游另外一台机器的assert timer超时后，重新打通组播路由链。极端情况下，这个过程要等105秒，也就是组播业务数据可能在这一段时间内全部丢失。所以，只有通过判断down掉的邻居是否是assert winner，才能加快切换速度。

以往图1扩充前的工作原理过程是：

路由器R133和R134，R135通过hello报文建立邻居关系并进行邻居状态位置，同理，R134，R135，R136也有这一个过程。

当邻居关系建立好以后，如果组播数据源src开始发生主播数据，则会在R133上复制数据分别发给R134和R135，也就是一份数据变为了两份，转发给R136，这样，就会导致业务报文重复。为了解决这个问题，RFC的规定是，当R134和R135，如果有一方下游端口收到组播业务数据，就启动assert竞争机制，发送assert报文，宣布自己是assert winner，通过竞争，最后产生一个winner，由winner负责报文的转发，而竞争后处于loser的机器，比如R134的下游端口则处于prune状态，并启动assert定时器，如果定时器没超时，则一直维持prune和loser状态。

上述过程出现的问题：如果assert winner的下游端口突然出现故障，这个时候，负责报文转发的端口失效，则因为hello维持邻居定时器还没有超时，下游机器R136将不能及时切换到R135上，导致在维持定时器超时以前无法获取组播源的业务数据。

名词解释：

RFC—Request for Comments请求注解；

PIM—协议无关组播；

PIM-DM—协议无关组播，密集模式；

(s，g)—组播路由条目；

Upstream—组播上游端口，PIM-DM协议，是指向数据源的端口；

Downstream—组播下游端口；

GenID—组播路由器端口协议UP/DOWN是带的一个ID，用于判断机器或者端口是否重启；

assert winner—对于同一个网段的PIM-DM端口，需要通过竞选，来设置一个负责数据转发的下游端口，该端口就是对应的winner；

assert—实际是一种断言机制，通过这种机制来决定由胜出的一方进行组播数据的转发。

graft—嫁接，用于通知上游邻居，本地需要组播业务报文。

src—组播数据源。

发明内容：

鉴于上述技术问题，本发明的目的是提供一种pimdm路由器上的优化方法。该方法能够让现有pimdm路由器尽快知道assert winner的变动，以便及时采取相应措施，恢复整个组播通路。

为了实现上述技术效果，本发明所述的方案主要包括两大操作流程：

(1)Assert状态的保存：

每台pimdm路由器都需要保存同一个网段上游的(s，g)assert winner邻居的端口地址，还需要保存本地端口的assert状态。

(2)探寻assert winner的状态：

采用keepalive机制方式以可配置的时间间隔探寻上游assert winner状态的邻居是否正常。

具体步骤如下：

①每台pimdm路由器都需要保存同一个网段上的(s，g)assert winner，如果是(s，g)的下游端口，还需要保存本地的assert状态。