专利名称：在以太网应用中使用虚拟媒体访问控制地址的方法和系统的制作方法
技术领域：
本发明涉及网络通讯领域，尤其涉及一种在以太网应用中使用虚拟MAC(媒体访问控制)地址的方法和系统。
背景技术：
Mac-in-Mac是IEEE(电子电气工程师协会)802.1ah草案给出的PBB(Provider Backbone Bridges，运营商骨干网桥)的关键技术。Mac-in-Mac是一种以太网应用方案，通过在客户以太网帧外层添加外层MAC(媒体访问控制)头和业务实例ID的方式，将客户以太网络和运营商以太网络隔离开来，从而可以解决以往由于以太网应用没有层次导致的一系列问题。
IEEE 802.1ag提出了PBT(Provider Backbone Transport，运营商骨干网传输)方案。PBT方案通过配置方式建立隧道，关闭MAC学习和组播功能，简化组网，满足点到点应用。
在传统的IP网络中，为了提高上行链路/节点的可靠性，有时会用VRRP(虚拟路由冗余协议)协议来组网。VRRP将局域网的一组路由器组织成一个虚拟路由器。该虚拟路由器也称之为一个备份组，包括一个MASTER(主用)路由器和若干个BACKUP(备份)路由器，拥有自己的IP地址和虚拟MAC地址。网络内的主机就通过该虚拟路由器来与其它网络进行通信。如果备份组内的MASTER路由器坏掉时，备份组内的其它BACKUP路由器将会接替成为新的MASTER，继续向网络内的主机提供路由服务。在VRRP协议中，虚拟MAC地址的应用避免了网络倒换时下行设备重新学习ARP(地址解析协议)。
现有技术中一种在以太网中进行报文传递的方法为在本端PE(Provider Edge Device，运营商边缘设备)和对端PE之间的以太网隧道上逐跳配置MAC+VLAN(虚拟局域网)，通过不同的VLAN或者MAC来区分不同的隧道，通过802.1ag来触发隧道的倒换，但倒换的过程还没有文本描述。
在图1所示的应用了Mac-in-Mac的隧道的PBT组网示意图中，客户的报文经过Metro Ethernet与对端客户互通。客户发出的二层以太网报文到达PE1后，PE1对该报文进行Mac-in-Mac封装，在该报文中添加二层MAC头和业务实例后，将该报文输入主用PBT隧道，中间P设备(比如交换机)查询二层MAC转发表后，将该报文逐跳转发到对端设备PE2，PE2终结PBT隧道，将该报文剥去外层MAC封装和业务实例后，重新转发给对端客户。
上述在以太网中进行报文传递的方法的缺点为在本端PE和对端PE之间的隧道都是静态配置的。比如，如图2所示的应用了Mac-in-Mac的隧道的PBT典型应用组网示意图中，PE1和PE2之间的隧道都是静态配置的。在交换机A(见图2中的标注)上，主用隧道A配置为目的MACPE2/入接口1的物理MAC地址，VLANVLAN1，出接口出接口A；备用隧道B配置为目的MACPE2/入接口2的物理MAC地址，VLANVLAN2，出接口出接口B。当PE2的接口1由于某些原因出现故障时时，PE1通过802.1ag OAM(操作、管理和维护)感知到主用隧道A的状态出现故障，于是，将到PE2之间的业务流量切换到备用隧道B(见图2中的标注)。对于中间的P设备来说，由于隧道是事先配置好的，流量的切换只是从命中一个转发表项切换到命中另一个转发表项而已，即中间交换机设备上的表项不需要修改，隧道的倒换对中间设备是透明的。
但当PE1到PE2的隧道对应的PE2上的物理接口(比如接口1和接口2)需要变化时，则需要重新配置PE1及所有中间的P设备上的转发表项，工作量很大。
一般在如下几种情况下，PE1到PE2的隧道对应的物理入接口及入接口MAC可能会发生变化1、物理损坏，比如单板坏需要更换，这时MAC地址肯定变化；2、端口冗余时，比如Trunk端口下有端口状态变化；3、PE2设备更换。
在上述几种情况下，因为PE1到PE2的隧道对应的物理入接口MAC地址发生了变化，需要更新两端PE设备和所有中间的P设备上的转发表项，工作量极大，导致以太网缺乏可维护性。
发明内容
本发明的目的是提供一种在以太网应用中使用虚拟媒体访问控制地址的方法和系统。从而可以实现当PBT隧道的PE设备的端口数据发生变化时，不需要对PBT隧道的交换机及其它运营商设备上的转发表项进行重新配置。
本发明的目的是通过以下技术方案实现的一种在以太网应用中使用虚拟媒体访问控制地址的方法，包括使用虚拟媒体访问控制MAC地址对MAC-in-Mac组网中的业务隧道进行配置。
包括步骤A、在MAC-in-Mac组网中的业务隧道的运营商边缘PE设备和运营商核心设备上配置虚拟MAC地址；B、当所述业务隧道的PE设备的端口信息发生变化时，在所述业务隧道的PE设备上重新配置所述虚拟MAC地址。
所述的步骤A具体包括
A1、在MAC-in-Mac组网中的业务隧道的目的端PE设备上配置虚拟MAC地址；A2、在所述业务隧道的运营商核心设备上使用所述虚拟MAC地址来配置该业务隧道的目的地址。
所述的步骤A1还包括在MAC-in-Mac组网中的两端PE设备上配置多个虚拟MAC地址，该多个虚拟MAC地址和所述两端PE设备之间的多组业务隧道相对应，根据该多个虚拟MAC地址对所述两端PE设备之间的多组业务隧道进行区分。
所述的虚拟MAC地址为单播MAC地址，在网络中互不冲突。
所述的业务隧道包括运营商骨干网传输PBT隧道。
所述的运营商核心设备包括交换机和其它运营商设备。
所述的步骤B具体包括当所述MAC-in-Mac组网中的业务隧道的PE设备出现故障时，使用新的PE设备来替换所述出现故障的PE设备，并在该新的PE设备上重新配置所述虚拟MAC地址。
一种在以太网应用中使用虚拟媒体访问控制地址的系统，包括PE设备配置有一个或多个虚拟MAC地址，用于标识PE设备之间的MAC-in-Mac组网中的一个或多个业务隧道；运营商核心设备使用所述PE设备上配置的一个或多个虚拟MAC地址来配置所述MAC-in-Mac组网中的相应的业务隧道的目的地址。
所述的运营商核心设备包括交换机和其它运营商设备。
所述的业务隧道包括PBT隧道。
由上述本发明提供的技术方案可以看出，本发明通过定义一个或多个虚拟MAC，使用定义的虚拟MAC地址来配置PBT应用组网中交换机及其它P设备的PBT隧道的地址。从而可以实现当PBT隧道的两端PE设备的端口数据发生变化时，不需要对PBT隧道的交换机及其它运营商设备上的转发表项进行重新配置。避免了需要刷新隧道配置的麻烦，减少了控制平面的复杂度，降低了运营开销，提高了网络的可扩展能力。
图1为应用了Mac-in-Mac的隧道的PBT组网示意图；其中CE给以太网帧或带C-Tag的以太网帧增加业务tag(S-Tag)，并将之转发到PE；从PE接收客户以太网帧并转发给CE设备；PE将S-Tag映射到I-Tag并封装客户以太网帧到MinM帧中转发MinM帧到PBT工作隧道；接收MinM帧，并将客户以太网帧发送给CE设备；当802.1ag通过单播CCM检测到隧道失效时切换工作隧道；映射S-Tag的802.1p优先级到I-Tag的优先级，或者通过配置对I-Tag/S-Tag的优先级进行remark；为PBT隧道预留带宽并对不同优先级的流量进行调度；交换机基于外层目的MAC和B-Tag转发MinM帧；过滤未知/广播/多播帧；图2为应用了Mac-in-Mac的隧道的PBT典型应用组网示意图中；图3为本发明所述方法的实施例的处理流程图；图4为本发明所述使用虚拟MAC地址的实施例的组网示意图；图5为本发明所述使用多虚拟MAC地址的实施例的组网示意图。
具体实施例方式
本发明提供了一种在以太网应用中使用虚拟MAC地址的方法和系统，本发明的核心为在配置PBT隧道时不使用物理MAC地址，而使用虚拟MAC地址。
下面结合附图来详细描述本发明，以应用了Mac-in-Mac的隧道的PBT应用为例，本发明所述方法的实施例的处理流程图如图3所示，包括如下步骤
步骤3-1使用虚拟MAC地址来配置PBT应用组网中PE设备、运营商核心设备的PBT隧道的地址。
在对PBT应用组网中的运营商核心设备，比如交换机及其它运营商设备进行PBT隧道(包括主用隧道和备用隧道)地址配置时，使用虚拟MAC地址而不是物理端口MAC地址作为该PBT隧道的目的地址。该虚拟MAC地址通过PBT隧道的目的端PE设备来确定，即首先在目的端PE设备配置该虚拟MAC地址，通过该目的端PE设备来配置所述运营商核心设备上的相应PBT隧道的目的地址。
上述虚拟MAC地址的格式与物理MAC地址的格式相同，都是采用IEEE的标准格式。但该虚拟MAC地址要求是非保留或者组播MAC地址，即应该采用单播MAC。同时，该虚拟MAC地址要求保证在网络中不冲突。
比如，在图4所示的使用虚拟MAC地址的实施例的组网示意图中，交换机A上的PE1到PE2方向的主用隧道A配置为目的MACPE2/虚拟MAC地址，VLANVLAN1，出接口出接口A；备用隧道B配置为目的MACPE2/虚拟MAC地址，VLANVLAN2，出接口出接口B。上述虚拟MAC地址由PE2上通过配置来确定。交换机A上的PE2到PE1方向的备用隧道的虚拟MAC地址在PE1上通过配置来确定。
步骤3-2当PBT隧道的PE设备的端口数据发生变化时，在PBT隧道的PE设备上重新配置所述虚拟MAC地址，不用修改PBT应用组网中交换机及其它运营商设备上的转发表项。
在使用虚拟MAC地址对PBT应用组网中PE设备、交换机及其它运营商设备的PBT隧道的地址进行配置后，当PBT隧道的PE设备的端口数据发生变化时，比如，PE设备发生物理损坏，需要更换新的PE设备，此时，新的PE设备和以前的PE设备的物理MAC地址会发生变化。此时，在该PBT隧道的PE设备上重新配置所述虚拟MAC地址，不需要修改PBT应用组网中交换机及其它运营商设备上的转发表项。
比如，在图4所示的使用虚拟MAC地址的实施例的组网示意图中，当PE2的物理端口数据发生变化，需要更换新的PE设备时，直接在更换后的PE2上对重新配置上述虚拟MAC地址，不需要修改交换机A及其它运营商设备上的转发表项。从而大大地减轻了网络管理的工作量。减少了配置工作量。另外以后如果进行协议扩展，引入控制平面，也能大大降低对控制平面的要求。
在PBT隧道的两端PE设备上，可以只配置一个虚拟MAC地址，也可以配置多个虚拟MAC地址，用于在两端PE设备之间配置多组PBT隧道。
在典型PBT应用组网中，在两端PE设备之间只需要配置一组隧道(包括主用隧道和备用隧道)，用于承载客户业务。当需要对客户的不同业务给予不同的SLA(服务等级协议)或者对客户的不同业务进行隔离时，就可以在两端PE设备之间配置多组隧道，并且为每组隧道配置不同的虚拟MAC地址。
比如，在图5所示的使用多虚拟MAC地址的实施例的组网示意图中，当PE1和PE2之间通过多组业务隧道来承载不同的业务，比如承载语音、视频和数据应用等业务时，可以通过给不同的业务隧道配置不同的VLAN来区分多组业务隧道，但VLAN地址空间只有4K，规划起来就很麻烦。另外一种选择就是为多组业务隧道配置多个虚拟MAC地址，每个虚拟MAC地址和一组业务隧道相对应，每个虚拟MAC地址唯一地标识一组业务隧道。即利用配置的虚拟MAC地址对每组业务隧道进行区分。从而达到不用配置不同VLAN而仅由不同的虚拟MAC地址来区分不同的业务隧道。
以上所述，仅为本发明较佳的具体实施方式
，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到的变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应该以权利要求的保护范围为准。
权利要求
1.一种在以太网应用中使用虚拟媒体访问控制地址的方法，其特征在于，包括使用虚拟媒体访问控制MAC地址对MAC-in-Mac组网中的业务隧道进行配置。
2.根据权利要求1所述的方法，其特征在于，包括步骤A、在MAC-in-Mac组网中的业务隧道的运营商边缘PE设备和运营商核心设备上配置虚拟MAC地址；B、当所述业务隧道的PE设备的端口信息发生变化时，在所述业务隧道的PE设备上重新配置所述虚拟MAC地址。
3.根据权利要求2所述的方法，其特征在于，所述的步骤A具体包括A1、在MAC-in-Mac组网中的业务隧道的目的端PE设备上配置虚拟MAC地址；A2、在所述业务隧道的运营商核心设备上使用所述虚拟MAC地址来配置该业务隧道的目的地址。
4.根据权利要求3所述的方法，其特征在于，所述的步骤A1还包括在MAC-in-Mac组网中的两端PE设备上配置多个虚拟MAC地址，该多个虚拟MAC地址和所述两端PE设备之间的多组业务隧道相对应，根据该多个虚拟MAC地址对所述两端PE设备之间的多组业务隧道进行区分。
5.根据权利要求2所述的方法，其特征在于，所述的虚拟MAC地址为单播MAC地址，在网络中互不冲突。
6.根据权利要求2所述的方法，其特征在于，所述的业务隧道包括运营商骨干网传输PBT隧道。
7.根据权利要求3所述的方法，其特征在于，所述的运营商核心设备包括交换机和其它运营商设备。
8.根据权利要求2、3、4、5、6或7所述的方法，其特征在于，所述的步骤B具体包括当所述MAC-in-Mac组网中的业务隧道的PE设备出现故障时，使用新的PE设备来替换所述出现故障的PE设备，并在该新的PE设备上重新配置所述虚拟MAC地址。
9.一种在以太网应用中使用虚拟媒体访问控制地址的系统，其特征在于，包括PE设备配置有一个或多个虚拟MAC地址，用于标识PE设备之间的MAC-in-Mac组网中的一个或多个业务隧道；运营商核心设备使用所述PE设备上配置的一个或多个虚拟MAC地址来配置所述MAC-in-Mac组网中的相应的业务隧道的目的地址。
10.根据权利要求9所述的系统，其特征在于，所述的运营商核心设备包括交换机和其它运营商设备。
11.根据权利要求9所述的系统，其特征在于，所述的业务隧道包括PBT隧道。
全文摘要
本发明提供了一种在以太网应用中使用虚拟媒体访问控制地址的方法和系统，该方法主要包括使用虚拟MAC(媒体访问控制)地址对MAC－in－Mac组网中的业务隧道进行配置。利用本发明所述方法，可以实现当PBT(运营商骨干网传输)隧道的PE(运营商边缘设备)设备的端口数据发生变化时，不需要对PBT隧道的交换机及其它运营商设备上的转发表项进行重新配置。
文档编号H04L12/56GK1897596SQ200610057410
公开日2007年1月17日 申请日期2006年3月13日 优先权日2006年3月13日
发明者王建兵, 侯超, 郭俊, 沈文良, 徐靖, 徐岗, 张 浩, 卢希飞 申请人:华为技术有限公司