具体实施方式
本发明的方法是:FC设备利用光纤最短路径优先(FSPF)协议将各自配置的TE链路信息在FC域内泛洪,并接收FC域内其他FC设备发送的自身TE链路信息;
当需要在FC网络中从起点到终点传输数据报文时,该FC设备若为起点,则根据自身和其它FC设备配置的流量工程(TE)链路信息,并利用基于约束的最短路径优先算法(CSPF)确定报文转发路径;若该FC设备为所述转发路径上的FC设备,则利用资源预留协议(RSVP)在转发路径上建立Crlsp隧道;建立Crlsp隧道后,该FC设备通过建立的Crlsp隧道传输数据报文。
如图3所示,本发明在FC网络实现报文转发的方法具体可以包括如下步骤:
步骤301:在光纤通道(FC)网络中的每一个FC设备的E-port接口上配置流量工程(TE)链路信息。
本步骤在E-port接口上配置的TE链路信息可以包括:TE链路的剩余带宽、TE Metric、TE链路的最大可预留带宽、TE链路的最大带宽以及TE链路的亲和属性等其中任意一种或其组合,这些TE链路信息将直接参与后续的路径计算。当然,实际应用中,还可以在E-port接口上配置其它的参数信息,比如:超额分配的带宽资源比例、分配或释放Crlsp隧道所需要的带宽资源等,要配置哪些参数可以参考TE技术,此处不再赘述。
步骤302:每一个FC设备利用FC网络的最短路径优先协议(FSPF)将各自配置的TE链路信息在FC域内泛洪,使得每一个FC设备都获得其它所有FC设备配置的TE链路信息。
这里,“泛洪”的含义是指某个FC设备将自身配置的TE链路信息携带在新增加的链路状态更新(LSU)报文中,将该LSU报文传递给邻居,并逐层传递给FC域内的其它FC设备,使FC域内所有FC设备都获得该FC设备配置的TE链路信息。
现有的FSPF路由协议本身就具有泛洪的功能,只是不用于TE链路信息。因此,为方便起见,本发明可以为FSPF路由协议新增加一种LSU报文,专门用于承载TE链路信息,新增加的LSU的格式请参见后续具体的实施例。
步骤303:当需要将数据报文从作为起点的第一FC设备发送到作为终点的第二FC设备时,第一FC设备根据自身和其它FC设备配置的TE链路信息,并利用基于约束的最短路径优先算法(CSPF)确定报文转发路径。
步骤304:转发路径上的各FC设备利用资源预留协议(RSVP),在沿起点到终点的转发路径上建立Crlsp隧道。
实际应用中,建立隧道的方法具体包括从第一FC设备到第二FC设备的正向过程,以及从第二FC设备到第一FC设备的逆向过程:
正向过程:从第一FC设备开始,转发路径中的上游FC设备向下游FC设备发送路径PATH报文,下游FC设备记录接收到的PATH报文携带的信息,再继续转发给自身的下游FC设备,直到将PATH报文发送给第二FC设备。
逆向过程:从第二FC设备开始,转发路径中的下游FC设备分配Crlsp标签后,向上游FC设备反馈响应(RESV)报文,上游FC设备记录接收到的RESV报文携带的信息并预留带宽资源,直到将RESV报文反馈给第一FC设备。
由于这里是在FC网络中建立Crlsp隧道,PATH报文和RESV报文的格式都与IP网络中不相同,具体参见后续的实施例,此处不再赘述。
步骤305:第一FC设备通过建立的Crlsp隧道将数据报文传输给第二FC设备。
从以上说明可以看出,本发明先后通过信息发布(步骤301~302)、路径计算(步骤303)、路径建立(步骤304)等步骤在FC网络中建立了Crlsp隧道,而信息发布、路径计算、路径建立等正是流量工程(TE)的基础组件。因此,通过上述步骤的实施,本发明可以成功地将TE技术引入了FC网络。
引入TE技术之后,如果需要转发数据报文,本发明就可以不同于现有FC网络采用FSPF路由协议的做法,而直接通过Crlsp隧道转发。由于Crlsp隧道是基于TE链路信息来建立的,已经考虑了链路的带宽等因素,因而可以有效地避免网络拥塞的问题。
为了更好地说明本发明方案,下面用一个具体的较佳的实施例进行详细描述。
图4是本实施例的系统架构图。如图4所示,假设某FC域包括FC1~FC8共8个FC设备,每一个FC设备的地址和接口索引号如图所示。另外,本实施例还假设FC2(第一FC设备)要发送数据报文到FC8(第二FC设备),因此需要建立从FC2到FC8的隧道。
图5是本实施例的流程图。如图5所示,本实施例包括如下步骤:
步骤501:在FC1~FC8的E-port接口上配置TE链路信息,配置的TE链路信息至少包括:TE链路的剩余带宽、TE Metric、TE链路的最大可预留带宽、TE链路的最大带宽以及TE链路的亲和属性。
本领域技术人员知道,E-port接口是物理接口,可以支持多个VSAN,而不同的VSAN可以运行不同的FSPF实例,并且可以配置各自的TE链路信息。因此,步骤501这里配置的其实是某个运行的FSPF实例对应的VSAN的TE链路信息。相应地,步骤502发布的也是该FSPF实例对应的VSAN的TE链路信息。
步骤502:每一个FC设备将自身配置的TE链路信息携带在TE_LSU报文中,并将该TE_LSU报文通过邻居逐层传递,使得每一个FC设备都获得其它所有FC设备配置的TE链路信息。
本步骤是TE链路信息泛洪的具体实现,比如FC2要将自身的TE链路信息进行泛洪,就需要将携带TE链路信息的TE_LSU报文传递给自身的邻居FC3,FC3传递给FC1、FC4和FC5,FC4传递给FC7,FC5传递给FC6,FC7再传递给邻居FC8,从而使得FC域内所有的FC设备都可以获得FC2配置的链路信息。如果其他FC设备要泛洪自身配置的TE链路信息,也可以采用相同的方式,此处不再举例。
另外,本步骤所述的TE_LSU报文就是步骤302所述的链路状态更新(LSU)报文的一种实施例,是FSPF路由协议新增加的报文。为了在FSPF路由协议中增加一种新的报文,可以作如下定义:
首先,在FSPF报文头的Command字段中增加对TE_LSU报文的描述。FSPF报文头如表一所示:
表一
其中,Command字段的格式如表二所示
编码值(Encoded Value(hex)) |
描述(Description) |
缩略(Abbr.) |
14000000 |
Hello |
HLO |
15000000 |
Link State Update |
LSU |
16000000 |
Link State Acknowledgement |
LSA |
… |
… |
… |
××× |
TE Link State Update |
TE_LSU |
表二
最后一行就是新增加的对TE_LSU报文的描述,编码值可以由应用本实施例方案的用户自行确定。
本实施例中,TE_LSU报文的具体格式如表三所示:
表三
其中,“FSPF报文头”为表一所述的内容,占20个字节;“预留”是协议预留的字段,占3个字节;“标志”占1个字节;“链路状态记录个数n”表示TE_LSR携带的LSR的个数;“链路状态记录”是n个LSR的具体内容,其所占空间为m个字节,m=LSR个数n×一个LSR所占字节。具体的,一个LSR的格式如表四所示:
表四
其中,最后一行的“TLVS”表示TE_LSU含多个TLV。一个TLV表示一个包括有类型(T,Type)、长度(L,Length)和值(V,Value)的信息,其格式如图6所示。
在本实施例中,假设一个LSR至少包括8个TLV:
1)Type=1,Length=1个字节,Value为本链路的链路类型。
2)Type=2,Length=4个字节,Value为本链路对端FC设备的地址。
3)Type=3,Length=8个字节,Value为本链路的接口索引号以及链路对端的接口索引号。
4)Type=4,Length=4个字节,Value为TE Metric。
5)Type=5,Length=4个字节,Value为TE链路的最大带宽。
6)Type=6,Length=4个字节,Value为TE链路的最大可预留带宽。
7)Type=7,Length=32个字节,Value为TE链路的剩余带宽。
8)Type=8,Length=4个字节,Value为TE链路的亲和属性。
其中,Type为4~8的TLV是步骤502需要泛洪的TE链路信息,而Type为1~3的TLV是需要泛洪的拓扑信息。当然,如果已经获知FC网络的拓扑信息,本步骤可以仅泛洪TE链路信息即可。
上面仅描述了在配置一个E-port接口后,如何在新增加的TE_LSU报文中携带TE链路信息的问题。但通常情况下,一个FC设备可能有多个E-port接口,这就需要配置多个LSR。那么,该FC设备可以将这多个LSR分别携带在多个不同的PATH报文中,分多次进行泛洪,也可以将多个LSR携带在同一个PATH报文中进行一次泛洪。
不管采用何种方式,当某个FC设备获得其他FC设备的TE链路信息后,该FC设备实际上就获得了整个网络的TE链路状况。实际应用中,FC设备还可以将获得的TE链路信息保存在TEDB数据库中,一旦需要建立路径,该FC设备可以比较方便地从TEDB数据库中获取信息来计算路径。
步骤503:当FC2需要将数据报文发送给FC8,FC2根据自身和其它FC设备配置的TE链路信息,并利用CSPF算法确定报文转发路径。
这里,FC2为第一FC设备,是隧道头所在的FC设备。FC8为第二设备,是隧道尾所在的FC设备。第一FC设备在建立隧道时,通常会考虑以下几个条件来确定转发路径:
1、剩余带宽是否满足将要建立的Crlsp隧道的要求;
2、亲和属性是否满足将要建立的Crlsp隧道的要求;
3、转发路径的TE Metric是否最小;
4、是否可以支持严格显式路径和松散显式路径。
上述几个条件可以参考TEDB数据库中保存的TE链路信息,至于具体如何确定转发路径,可参考CSPF算法,此处不再赘述。
假设本实施例经过CSPF算法计算出路径要经过的FC设备是:FC2->FC3->FC5->FC6->FC7->FC8,其具体转发路径的序列如下表五:
序列号 |
FC设备地址 |
接口索引号 |
1 |
10.1.2 |
1 |
2 |
10.1.3 |
2 |
3 |
10.1.3 |
4 |
4 |
10.1.5 |
1 |
5 |
10.1.5 |
2 |
6 |
10.1.6 |
1 |
7 |
10.1.6 |
2 |
8 |
10.1.7 |
2 |
9 |
10.1.7 |
3 |
10. |
10.1.8 |
1 |
表五
从表五可以看出,本实施例中转发路径的信息是路径上各FC设备地址和接口索引号,其中,FC设备地址是24位,接口索引号可以为32位,这和IP网络是不一样的。
步骤504:FC2向下游设备FC3发送路径(PATH)报文,FC3记录接收到的PATH报文携带的信息,再继续转发给自身的下游设备FC5,并以此类推,直到将PATH报文发送给FC8。
本步骤所述的PATH报文是本发明实施例扩展FC报文得到的,使其能够承载RSVP协议报文,即:RSVP协议报文利用FC的SW_ILS类型的报文来承载。同时,为了进行扩展,还需要增加其SW_ILS Command Codes字段的定义。比如:
表六
其中,编码值为“A00000000”~“A0000000A”是本实施例新增加的各种报文的定义。比如,“A00000000”是对PATH报文的定义,用于步骤504。又比如,“A00000003”一行是对RESV报文的定义,用于本实施例的步骤505。当然,实际应用中还可以增加其他报文的定义,如何使用可以参见RSVP协议,此处不再赘述。
本步骤504是建立隧道的正向过程,其中的PATH报文携带的信息可以包括:
隧道的会话对象(Session Object)、上一跳对象(RSVP_HOP Object)、标签请求对象(RSVP_LABEL_REQUEST Object)、显式路径对象(ExplicitRoute Object)、发送模板对象(SENDER_TEMPLATE Object)以及记录路径对象(Record Route Object)。
上述信息都是以TLV的格式给出,其中:
会话对象(Session Object)的Value包括:隧道尾所在第二FC设备的地址、隧道位于第一FC设备的编号、隧道头所在第一FC设备的地址。其中,“隧道尾所在第二FC设备的地址”就是本实施例FC8的地址“10.1.8”,“隧道头所在第一FC设备的地址”就是FC2的地址“10.1.2”,而“隧道位于第一FC设备的编号”表示将要建立的隧道在FC2中的隧道编号。实际应用中,FC2中可能建立了多条隧道,为了区分,就需要为不同的隧道标识不同的编号。
上一跳对象(RSVP_HOP Object)的Value包括:发送此PATH报文的上游FC设备的地址,以及该上游FC设备发送此PATH报文的接口索引。实际应用中,某个FC设备接到PATH报文后,可以从中获知PATH报文是从上游设备的哪个接口发送的。比如:FC2从接口1发送PATH报文给FC3的接口2,那么PATH报文中上一跳对象(RSVP_HOP Object)的Value就应该填写FC2的地址“10.1.2”以及接口索引“1”。当FC3收到该PATH报文后,就可以获知上游设备是FC2,且PATH报文是从FC2的接口2发送的。
标签请求对象(RSVP_LABEL_REQUEST Object)的Value包括:上层的业务ID,其内容可以填写为FC网络。
显式路径对象(Explicit Route Object)的Value包括:转发路径上每一个FC设备的地址以及接口索引,其内容可以为表五的内容。
发送模板对象(SENDER_TEMPLATE Object)的Value包括:隧道头所在第一FC设备的地址以及标签转发路径编号(LSP ID)。其中,“隧道头所在第一FC设备的地址”为FC2的地址“10.1.2”,“LSP ID”表示隧道内Crlsp的实例号,如“100”。
记录路径对象(Record Route Object)的Value包括:PATH报文当前已经经过的FC设备的地址以及接口索引。
图7a~图7d是FC2发送给FC3的PATH报文,除了包含的上述信息,其余信息的含义可以参见资源预留协议(RSVP),此处不再详细说明。FC3接收到该报文后,可以建立PSB记录来保存PATH报文的信息。之后,FC3将继续将PATH转发给下游设备。从PATH报文中的显式路径对象(ExplicitRoute Object)可知,PATH报文应该从FC3的4号接口转发给FC5的1号接口。
当然,FC3转发PATH报文时,某些信息可能会根据实际情况修改或更新。比如:FC3接收到PATH报文时,上一跳对象(RSVP_HOP Object)的Value包括FC2的地址和索引号为1的信息。但FC3要转发PATH报文时,则需要将上一跳对象(RSVP_HOP Object)的Value更新为FC3的地址和索引号为4的信息。再如:FC3接收到PATH报文后,还需要从显式路径对象(Explicit Route Object)的Value中删除FC3的地址和接口索引号。再如:FC3接收到PATH报文后,还需要在记录路径对象(Record Route Object)的Value中添加FC3的地址和接口索引号。按照这种方式,本实施例的FC3更新后的要转发给FC5的PATH报文可如图8a~图8e所示。当然,实际应用中,上游设备是否需要更新PATH,更新哪些信息,可以由应用本方案的用户自行确定,只要发送给下游设备的PATH报文可以体现隧道建立的信息即可。
步骤505:FC8设备为上游设备FC7分配Crlsp标签后,向上游设备FC7反馈响应(RESV)报文,FC7记录RESV报文携带的信息,并在预留带宽资源以及为自身的上游设备分配Crlsp标签后,再将RESV报文反馈给自身的上游设备FC6,并以此类推,直到将RESV报文反馈给FC2。
此步骤是建立隧道的逆向过程。
实际应用中,RESV报文携带的信息包括:
隧道的会话对象(Session Object)、下一跳对象(RSVP_HOP Object)、过滤规范对象(FILTER_SPECIFICATION Object)、标签对象(LABEL Object)以及记录路径对象(Record Route Object)。这些信息也是以TLV的格式给出,其中:
隧道的会话对象(Session Object)与PATH报文中的相同,其Value也包括:隧道尾所在第二FC设备的地址、隧道位于第一FC设备的编号、隧道头所在第一FC设备的地址。其中,“隧道尾所在第二FC设备的地址”就是本实施例FC8的地址“10.1.8”,“隧道头所在第一FC设备的地址”就是FC2的地址“10.1.2”,而“隧道位于第一FC设备的编号”表示将要建立的隧道在FC2中的隧道编号。
下一跳对象(RSVP_HOP Object)与PATH报文的上一跳对象(RSVP_HOPObject)相似,只是其Value值的内容略有不同,是发送此RESV报文的下游FC设备的地址,以及接收此RESV报文的上游设备在发送PATH报文时的接口索引。比如:从FC6的接口1发送了RESV报文给FC5,且FC5在发送PATH报文时是通过接口2发送给FC6的,那么,RESV报文的下一跳对象(RSVP_HOPObject)的Value就应该填写FC6的地址“10.1.5”,以及FC5的接口索引2。
过滤规范对象(FILTER_SPECIFICATION Object)的Value包括:隧道头所在第一FC设备的地址以及标签转发路径编号LSP ID。其中,“隧道头所在第一FC设备的地址”为FC2的地址“10.1.2”,“LSP ID”表示隧道内Crlsp的实例号,如“100”。
标签对象(LABEL Object)的Value包括:发送此RESV报文的FC设备为上游FC设备分配的标签。
记录路径对象(Record Route Object)的Value包括:RESV报文当前已经经过的FC设备的地址和接口索引。
图9a~9c是FC8反馈给FC7的RESV报文,除了包含的上述信息,其余信息的含义也可以参见资源预留协议(RSVP),此处不再详细说明。FC7接收到该报文后,可以建立RSB记录来保存RESV报文的信息,并根据事先记录的PSB可知,FC7将从2号接口继续向上游设备FC6反馈RESV报文。
FC7反馈RESV报文时,某些信息也可能会根据实际情况修改或更新。比如:FC7接收到RESV报文时,下一跳对象(RSVP_HOP Object)的Value包括FC8的地址以及FC7的索引号为3的信息。但FC7要转发RESV报文时,则需要将下一跳对象(RSVP_HOP Object)的Value更新为FC7的地址以及FC6的索引号为2的信息。再如:FC7接收到FC8反馈的RESV报文时,标签对象(LABEL Object)的Value是FC8分配的标签10。但FC7要反馈RESV报文给FC6时,还需要将标签对象(LABEL Object)的Value修改自身为FC6分配的标签20。再如:FC7反馈RESV报文给FC6时,还需要在记录路径对象(Record Route Object)的Value中添加FC7的地址“10.1.7”和接口索引号“2”。按照这种方式,本实施例的FC7更新后的要反馈给FC6的RESV报文可如图10a~10c所示。当然,实际应用中,上游设备是否需要更新RESV报文,更新哪些信息,可以由应用本方案的用户自行确定,只要反馈给上游设备的RESV报文可以体现隧道建立的信息即可。
需要注意的是,当某个FC设备接收到下游设备反馈的RESV报文后,从RESV报文可以获得下游设备为自身分配Crlsp标签,并作为本节点的出标签;该FC设备在向自身的上游设备分配Crlsp标签后,可将该标签作为本节点的入标签;最后,该FC设备在路径的接口上预留带宽资源后,就可以形成本节点Crlsp。比如:FC8为FC7分配的Crlsp标签为10,FC7为FC6分配的Crlsp标签为20,并且FC7在索引号为3的接口上预留了80兆带宽。此时,FC7在本节点形成了如下的Crlsp:
表七
这样,当转发路径上的每个FC都建立了Crlsp,整个Crlsp隧道也就完成了。
步骤506:FC2通过建立的Crlsp隧道将数据报文传输给FC8。
本步骤中,当FC2传输数据报文时,需要在报文中携带Crlsp标签。至于具体如何利用Crlsp标签在隧道中传输数据报文,可以参见协议,此处不再赘述。
按照上面所述的方法,本发明还提供一种FC设备。如图11所示,该设备包括:信息发布单元1101、路径计算单元1102、路径建立单元1103、报文转发单元1104。其中,
信息发布单元1101,用于在本FC设备的E-port接口上配置流量工程TE链路信息,将配置的TE链路信息在FC域内泛洪,使得FC域内的每一个FC设备都获得其配置的TE链路信息。
路径计算单元1102,路径计算单元,当数据报文需要从作为报文起点的第一FC设备发送到作为终点的第二设备,且本FC设备是第一FC设备时,根据自身和其它FC设备配置的TE链路信息,并利用基于约束的最短路径优先算法CSPF确定报文转发路径。
路径建立单元1103,在本FC设备作为报文转发路径上的FC设备时,利用RSVP协议建立Crlsp隧道。
报文转发单元1104,利用建立的Crlsp隧道将数据报文传输给转发路径上的下游FC设备,直到第二FC设备。
实际应用中,FC域内的每一个FC设备都具备图11所示的结构,但对于某条隧道来说,只有隧道头所在的FC设备才启动路径计算单元1102,只有隧道路径上的各FC设备才启动路径建立单元1103和报文转发单元1104。但FC域内的所有FC设备都将启动信息发布单元1101,将配置的TE链路信息在FC域内泛洪,使得每一个FC设备都获得其他所有FC设备的TE链路信息。
实际应用中,信息发布单元1101可以通过新增加的TE_LSU报文来发布TE链路信息,发布的TE链路信息包括:TE链路的剩余带宽、TE Metric、TE链路的最大可预留带宽、TE链路的最大带宽以及TE链路的亲和属性。所述TE_LSU报文可以是在FSPF路由协议中增加一种新报文,其定义和格式如表一~表四所示,此处不再赘述。
当某个FC设备获得其他所有FC设备,就可以启动路径计算单元1102来计算报文的转发路径。此时,该FC设备是报文的起点,这里称为第一FC设备(隧道头),而报文的终点则称为第二FC设备(隧道尾)。
第一FC设备如何利用路径计算单元1102来计算转发路径,则可以参见方法部分的步骤503,此处不再赘述。
另外,转发路径上的各FC设备如何利用路径建立单元1103来建立隧道的,可参见方法部分的步骤504和505。
即:在正向过程中,第一FC设备向下游设备发送路径(PATH)报文,下游设备记录接收到的PATH报文携带的信息,再继续转发给自身的下游设备,并以此类推,直到将PATH报文发送给第二FC。这里的PATH报文的格式可以参见步骤504的描述以及图7、图8。
在逆向过程中,第二FC设备为上游设备分配Crlsp标签后,向上游设备反馈响应(RESV)报文,上游设备记录RESV报文携带的信息,并在预留带宽资源以及为自身的上游设备分配Crlsp标签后,再将RESV报文反馈给自身的上游设备,并以此类推,直到将RESV报文反馈给第一FC设备。这里的RESV报文的格式可以参见步骤505的描述以及图9、图10。
总之,利用本发明方案,可以将TE技术引入FC网络。由于TE技术本身可以根据网络带宽的利用率均衡不同的业务流量,因此可以很好地解决FC网络中网络拥塞的问题。
以上所述仅为本发明的较佳实施例而已,并不用以限制本发明,凡在本发明的精神和原则之内,所做的任何修改、等同替换、改进等,均应包含在本发明保护的范围之内。