CN101087257B - 基于以太接口针对虚拟专用网流量实现服务质量的方法 - Google Patents

Abstract

本发明公开了一种基于以太接口针对虚拟专用网VPN流量实现服务质量QoS的方法，包括：在PE设备上针对需要做QoS处理的VPN，提取对端PE通告的内层标签值、下游设备通告的外层标签值、以及对端PE的媒体访问控制MAC地址，组成VPN-QoS表；当有数据包从所述PE设备的以太接口发出时，跟所述VPN-QoS表进行比较，如果符合表中的VPN特征，即作QoS处理。本发明采用完全由本地设备处理的方式实现了针对VPN流量的QoS处理，使转发层面只需要按照预先制定好的转发表对数据包进行相应的匹配操作，转发表形成所依据的特征也很简单；另外，由于没有设备之间的信令交互，不会对控制层面添加过多的负担。

Description

基于以太接口针对虚拟专用网流量实现服务质量的方法

技术领域

本发明涉及通信领域，尤其涉及一种基于以太接口针对VPN(VirtualPrivate Networks，虚拟专用网)流量实现QoS(Quality of Service，服务质量)的方法。

背景技术

互联网经过这些年的发展，已经走进了千家万户，推动网络迅猛发展的，就是熟知的TCP/IP(Transmission Control Protocol/Internetworking Protocol，传输控制协议/互联网协议)。该协议的出现解决了很多网络互联的问题，规定了所有网络设备执行的标准。其核心内容就是互联网协议(Internetworking Protocol)，即IP。

通过路由器这样的三层设备根据IP头转发数据包存在很多缺陷，包括转发效率低下、无法有效的提供QoS保证等，这些问题，加上ATM(Asynchronous Transfer Mode，异步传输模式)技术积累的经验，诞生了MPLS(Multiprotocol Label Switching，多协议标签交换)技术。

目前，MPLS技术的主要应用方向是VPN，通行的几种MPLS VPN(基于MPLS的VPN)技术包括：VPLS(Virtual Private LAN Services，虚拟专用LAN业务)、VPWS(Virtual Private Wire Service，虚拟专用线路业务)、L3 VPN(三层VPN)。不论是哪一种VPN，基本的网络结构都是一样的，都是按照CE-PE-P-PE-CE的结构组建网络(如图1所示)，除了P设备以外，其余设备都是必须存在的。其中CE(customer Edge，用户边缘设备)设备就是客户边缘设备，用来连接运营商网络的路由器或者交换机，负责将用户的数据包转发至PE设备上；PE(Provider Edge，运营商边缘设备)设备就是运营商边缘路由器，由运营商负责维护，连接客户站点中的CE设备，主要功能是维护VPN信息，以及对报文插入MPLS标签头的操作；P(Provider，供应商设备)设备就是运营商路由器，处于运营商网络核心位置，不和任何客户站点中的设备(CE)连接，不需要维护任何VPN信息，只需要进行MPLS标签转发即可。不论P还是PE，都需要在本地为相应的路由生成FEC(Forwarding Equivalence Class，转发等价类)，然后为每一个FEC分配本地标签，再通过LDP(Label Distribution Protocol标签分发协议)将标签值通告给自己的上游设备。

需要说明一下MPLS数据包在上述网络中转发的过程，报文从CE设备发出到达PE设备之后，由PE为该报文插入两层MPLS标签头，内层标签是已经为VPN实例分配好的VPN标签，由对端PE设备通告到本地，处于标签堆栈的栈底位置，其S位置1，S是MPLS标签头中标识标签堆栈栈底位的一个比特(bit)；外层标签是MPLS转发表中对应该VPN的出口标签，由下游P(或者PE)设备通告到本地，其S位置0，即使一个数据包被插入了不止两层MPLS标签，除了栈底的标签以外，其它标签的S为都被置0。标签栈封装好以后，走MPLS转发流程将报文从上联公网的接口发送出去。报文到达对端PE以后做相反的操作，即剥离MPLS标签，然后查找相应的VPN转发表，将报文转发给CE设备。

伴随着网络的发展，各种基于Internet网络的应用业务也应运而生，包括VoIP(Voice Over Internet Protocol，互联网电话)、IPTV(Internet ProtocolTelevision，互联网协议电视)等等。为了安全或者其它原因，这些业务往往需要基于VPN隧道开设，相应的，需要为这些对转发时延要求比较高的业务提供QoS保障，包括带宽保障，低时延，CPU(Central Processing Unit，中央处理器)优先调度等等。各种不同的转发方式都能够不同程度的实现QoS保障。报文基于IP转发时，可以通过ToS(Type of Service，服务类型)字段的值区分不同的业务流量，进而采取不同的QoS策略；报文基于MPLS标签转发时，可以通过MPLS标签头中的EXP(experiment，实验)位定义不同的值，用来区分各个业务流量，即通常所说的E-LSP(EXP-LSP，通过EXP字段在LSP上实现差分服务的方法)，或者采用L-LSP(Label-LSP，通过Label+EXP字段在LSP上实现差分服务的方法)的方式，即使用EXP加上标签值的方式区分业务流。那么对于一条VPN流量如何作QoS处理呢？

由于MPLS报文在网络中转发时，完全依据外层MPLS标签的label值判断流量方向(此处“label”指外层MPLS标签的前20个bit，也就是标签转发过程中真正被使用并替换的部分，外层MPLS标签一共32个bit)，所以只能针对最外层MPLS标签的EXP字段的值定义QoS策略。由于外层MPLS标签值和内层VPN标签值并没有直接的一对一关系，往往多个VPN会绑定同一个LSP(Label Switch Path，标签交换路径)，导致外层的出标签值一样，所以仅仅依靠这样的方式不能够针对VPN流量做出合适的QoS行为。如果采用直接到栈底找到VPN标签的EXP值的方式也不可行，原因是，可能不同的VPN流量定义了相同的EXP值，无法加以区分。如果采用直接到栈底找到VPN标签的label值的方式也不可行，原因是对于P或者PE设备来说，发送出去的数据包所插入的标签是对端通告的，很有可能出现对端PE设备不止一台，同时又通告了相同VPN标签值的情况，因为标签的分配是本地行为。

目前针对VPN流量的QoS方式还比较少，一般现有技术不能够很好的识别VPN流量，大多只是能够识别普通MPLS流量，然后通过E-LSP或者L-LSP的方式对流量实行分类、制定优先级、限速等操作，无法很好的针对单个VPN流量实现QoS。另外，也有一些通过信令交互、协商对VPN流量进行控制的方式，例如通过RSVP(Resource ReSerVation Protocol，资源预留协议)作外层标签的方法。这类方法相对较为繁琐，对设备的控制层面要求也比较高。

发明内容

本发明要解决的技术问题就是提供一种基于以太接口针对VPN流量实现QoS的方法，能够在PE设备连接公网的接口上实现针对VPN流量的QoS，在本地实现对向公网转发的VPN流量的控制。

为了解决上述技术问题，本发明提供一种基于以太接口针对虚拟专用网VPN流量实现服务质量QoS的方法，包括如下步骤：

(1)在运营商边缘设备，即PE设备上针对需要做QoS处理的VPN，提取对端PE通告的内层标签值、下游设备通告的外层标签值、以及对端PE的媒体访问控制MAC地址，组成VPN-QoS表；

(2)在所述PE设备的接口上绑定VPN-QoS表，当有数据包从所述PE设备的以太接口发出时，跟所述VPN-QoS表进行比较，如果符合表中的VPN特征，即作QoS处理。

进一步地，所述步骤(1)执行之前，需要在PE设备上创建VPN实例，并与对端PE设备建立信令交互机制。

进一步地，与对端PE设备建立信令交互机制后，三层VPN使用多协议边界网关协议MPBGP向对端PE通告VPN标签，二层VPN按照Martini或Kompella草案的要求使用标签分发协议LDP或边界网关协议BGP向对端PE通告VPN标签。

进一步地，所述步骤(1)包括如下步骤：

(1.1)在PE设备上针对需要做QoS处理的VPN，提取对端PE通告的内层标签值、下游设备通告的外层标签值；

(1.2)记录学习到标签交换路径LSP下游设备与本地PE设备连接的接口MAC；

(1.3)将对端PE设备通告过来的VPN标签值、下游设备通告的外层标签值，以及LSP下游设备与本地PE设备连接的接口MAC一同组成VPN-QoS表；所述VPN-QoS表中，每个VPN实例对应一个序号；

(1.4)若需要对该VPN流量作QoS处理，将生成的VPN-QoS表通告给VPN绑定的LSP的出接口。

进一步地，所述步骤(1.2)包括如下步骤：

(1.2.1)找到VPN绑定的LSP的出接口，称为接口O；

(1.2.2)判断接口O是否为以太接口；如果是，执行下一步；

(1.2.3)记录接口O学习到该LSP下游设备与本地PE设备连接的接口MAC。

进一步地，所述步骤(2)包括如下步骤：

(2.1)PE设备的接口上绑定VPN-QoS表；

(2.2)查找所转发报文的2层链路报头的目的MAC，若该MAC地址与需要作QoS的VPN在VPN-QoS表中的MAC地址一致，则执行下一步；

(2.3)若所述转发报文包是只有一层VPN标签的包，则直接执行下一步；否则，查找报文包外层标签的label值，如与需要作QoS的VPN在VPN-QoS表中的下游设备通告的外层标签值一致，则执行下一步；

(2.4)查找报文包的VPN标签的label值，并判断该VPN标签是否与需要作QoS的VPN在VPN-QoS表中的对端PE通告的内层标签值一致，若一致，则对该报文做QoS处理。

进一步地，所述步骤(2.1)绑定VPN-QoS表后，还需要找到需要作QoS处理的VPN在VPN-QoS表中的序号。

进一步地，所述步骤(2.1)执行之后，还需要判断所述PE设备的接口是否是以太接口，如果是，才执行步骤(2.2)。

进一步地，所述步骤(2.2)执行之后，还需要查找该以太报文头的协议号，判断该报文是否是多协议标签交换MPLS报文，如果是MPLS报文，才执行步骤(2.3)。

进一步地，所述步骤(2.3)包括如下步骤：

查找处于标签堆栈最外层的MPLS标签的S位数值，判断S的值是多少，如果是1的话说明该标签包已经是栈底标签，直接执行步骤(2.4)；否则，查找报文包外层标签的label值，如与需要作QoS的VPN在VPN-QoS表中的下游设备通告的外层标签值一致，则执行步骤(2.4)。

进一步地，所述步骤(2.4)包括如下步骤：

(2.4.1)查找所述报文下一层标签的S值，若是1，则执行下一步，若否，继续执行步骤(2.4.1)；

(2.4.2)检查该VPN标签的label值，判断该VPN标签是否与需要作QoS的VPN在VPN-QoS表中的对端PE通告的内层标签值一致，若一致，则对该报文做QoS处理。

本发明采用完全由本地设备处理的方式实现了针对VPN流量的QoS处理，使转发层面只需要按照预先制定好的转发表对数据包进行相应的匹配操作，转发表形成所依据的特征也很简单；另外，由于没有设备之间的信令交互，不会对控制层面添加过多的负担。

附图说明

图1是现有技术中一个MPLS网络的示意图；

图2是现有技术中一个VPN实例绑定内、外层标签的流程；

图3是本发明实施例根据VPN的特征生成VPN-QoS表，并且告知接口的过程；

图4是本发明实施例VPN-QoS模块绑定到流量的出接口上以后，转发模块的处理流程；

图5是本发明实施例针对VPN-QoS表中的特征参数2的存在原因说明示例；

图6是本发明实施例针对VPN-QoS表中的特征参数3的存在原因说明示例。

具体实施方式

通过分析不难看出，许多针对VPN的QoS需求只要在PE设备的出口处理就能够得到很好的效果，也不会增加P设备的负担，因为P设备要处理的数据包数量往往远大于PE设备，相应的，对于P设备的定位也是更加注重包处理能力。

本发明中，为了能够对VPN流量进行控制，关键处在于如何识别VPN流量，只要能够通过某种特征识别出特定的VPN数据包，就可以继续采取下一步动作，进行QoS处理。该过程包括对VPN流量的特征定义，以及建立转发表，最后在流量流经的接口上应用相关策略。在这里把特征参数组成的集合定义成一个表格的形式，称为VPN-QoS表。

本发明所述的方法包括以下步骤：

步骤1，在PE设备上创建VPN实例，并与对端PE设备建立信令交互机制，相应的，三层(L3)VPN使用MPBGP(Multiprotocol BGP，多协议边界网关协议)向对端PE通告VPN标签，二层(L2)VPN按照Martini或Kompella草案的要求使用LDP或BGP(Border Gateway Protocol，边界网关协议)向对端PE通告VPN标签；

步骤2，针对需要做QoS处理的VPN，提取相应的参数，包括接口学习到的对端PE的MAC(Media Access Control，媒体访问控制)地址，对端PE通告的内层标签值，下游设备通告的外层标签值，组成VPN-QoS表；

步骤3，在所述PE设备以太接口上启用针对该VPN流量的QoS，当有数据包从该接口发出时，跟所述VPN-QoS表进行比较，如果符合表中定义的VPN流量特征，即作QoS处理。

下面结合附图及具体实施例对本发明进行详细说明。

图1是一个简单的示意图，指出了在当前的网络中，PE和CE设备所处的位置和相互之间连接的方式。在“MPLS网络”中，所包含的主要是P设备，数量视网络需要而定，承担标签转发的任务。

图2示出了当VPN实例被创建以后，VPN标签的通告和绑定过程，以及与外层标签匹配的过程。由于该技术是已经广泛应用，并且已经有相关标准，所以只作简单说明，处理步骤如下：

步骤201，在PE设备上创建VPN实例，该步骤纯粹是本地行为，没有和对端产生任何的信息交互；

步骤202，VPN实例被创建以后，PE设备需要为该实例分配一个本地标签，该标签即所说的本地内层标签，和外层标签没有任何联系，完全单独存在；当相应的信令交互机制被建立以后，该标签会被通告给对端PE设备；

步骤203，为了向对端PE设备通告本地内层标签值，以及接收对端通告过来的标签值，本地PE需要和对端建立一定的信令交互机制；在L3VPN中，现在主要采用MPBGP的方式；在L2VPN中，目前有两种信令机制：Martini和Kompella，本发明主要针对Martini方式；

步骤204，信令交互机制建立之后，本地PE设备会收到对端PE通告过来的VPN标签；本地PE将收到的标签和本地分配的标签对应，建立内层标签的转发表；

步骤205，上述所有的工作都完成之后，VPN在控制层面的工作已经完成，需要和转发层面建立联系，就需要令VPN能够匹配上一条LSP；这条被匹配的LSP必须是已经建立好的，即使用通常意义上说的MPLS转发表进行匹配。

这样，当数据包被PE设备从上连MPLS网络的接口发送出去的时候，就会带有两层MPLS标签：内层是对端PE通告过来的VPN标签，外层是下游P或者PE设备通告的LDP或者RSVP标签。

图3是紧接着图2的处理过程，示出了VPN-QoS表的生成过程，主要内容是提取VPN流量特征参数，利用这些特征参数识别一个VPN流量，然后把生成的VPN-QoS表通告给接口；这样，接口可以按照这张表描述的特征在转发流量的过程中找到属于该VPN流量的数据包，再做出进一步QoS操作。

步骤301，指出需要生成VPN-QoS表的VPN流量，便于PE设备对该VPN流量进一步提取特征参数；此处假设该VPN为X，针对X绑定QoS策略；

步骤302，在图2描述的流程中，PE设备之间的信令交互机制已经建立，并且已经针对VPN实例分配了本地标签，同时也已经将标签通告到了对端PE。另外，外层LSP已经建立，所以此处只需要将对端PE设备通告过来的VPN标签值和下游设备通告的外层标签值记录下来即可；这两个参数作为VPN-QoS表的参数被记录；

步骤303，由于LSP已经生成，并且已经和X绑定，所以可以很容易地找到X绑定的LSP的出接口，给该接口取名叫作O(即out)，找到以后进入步骤304；

步骤304，由于本发明实现的针对VPN流量的QoS是基于以太接口的，所以需要判断X绑定的LSP的出接口是否为以太接口；如果是，进入步骤305，如果不是，直接进入步骤309，进入其它流程处理；

步骤305，由于X绑定的LSP的出接口，即接口O，是以太接口，所以通过ARP(Address Resolution Protocol，地址解析协议)解析，在这个接口上必然会学习到该LSP下游设备与本地PE设备连接的接口MAC，即接口发出的以太报文二层帧头里面的目的MAC；记录下这个MAC地址，作为另外一个VPN-QoS表的特征参数；

步骤306，将步骤302记录的两个特征参数：对端PE设备通告过来的VPN标签值(特征参数1)和下游设备通告的外层标签值(特征参数2)，以及步骤305记录的特征参数：LSP下游设备与本地PE设备连接的接口MAC(特征参数3)一同组成VPN-QoS表。事实上，这三个参数就是一个数据包被从接口发送出去的时候，在以太帧头和MPLS标签头里面携带的目的MAC以及两层标签值；

步骤307，判断目前是否需要对VPN流量作QoS处理，因为在某些情况下，比如接口带宽很充足，可以暂时不作QoS处理；如果需要，则进入步骤308，如果不需要，则进入步骤309，进入其它流程处理；

步骤308，目前需要对该VPN流量作QoS处理，将已经生成的VPN-QoS表通告给接口O；这样，当有数据包从接口O转发出去的时候，转发层面就可以根据VPN-QoS表中记录的三个特征参数去判断该数据包是否需要作QoS处理；结束流程；

步骤309，如果不需要作QoS处理，或者作QoS处理的条件不具备，那么就进入其它流程处理。

以此类推，如果需要做QoS处理的VPN流量不止一个也没有关系，只需要将每个VPN流量的三个特征参数分别对应记录在表中，让转发层面在数据包转发的过程中查找就可以了。

接下来需要说明VPN-QoS表的结构，这样便于理解转发层面如何匹配特征参数，如下表所示，是示意性的VPN-QoS表结构。

具体说明如下：

表中的序号Index n是针对不同的VPN实例而言的，每一个VPN实例对应一个Index；

表中的特征参数1是对端PE设备通告过来的VPN标签值，即通常所说的内层出方向上的label值；

表中的特征参数2是下游设备通告的外层标签值，即通常所说的外层出方向上的label值；

表中的特征参数3是LSP下游设备与本地PE设备连接的接口MAC，即接口上学习到的下一跳接口MAC。

当接口上需要针对VPN流量作QoS处理的时候，首先找到该VPN对应的Index，然后按照后面的参数一个个匹配，全部匹配上了就作相应的QoS处理。

目前已经清楚了VPN-QoS表的生成条件需要那些特征参数，以及表的结构，那么接下来就需要说明当接口向外转发数据包的时候以什么样的步骤一一匹配上这三个特征参数，从而识别出一条VPN流量。

图4说明了如何在接口上通过匹配特征参数识别出VPN流量并进行QoS处理的过程，需要说明的是，该过程针对从此接口往外转发的报文生效，不会影响接收的报文的正常转发。

步骤401，首先在接口上绑定VPN-QoS转发表，找到需要作QoS处理的VPN的Index，以便接下来针对该Index对应的特征参数识别VPN数据包；

步骤402，由于本技术针对的是以太接口，所以需要提前判断接口是否是以太接口，如果是，则继续匹配，如果不是，则直接到步骤416，进入其它流程处理；

步骤403，查找所转发报文的2层链路报头的目的MAC，即为VPN-QoS表中的特征参数3，即LSP下游设备与本地PE设备连接的接口MAC；

步骤404，如果查找到的MAC地址确实在VPN-QoS表中，也确实是对应了需要作QoS的Index后面的特征参数3，则进入步骤405，否则直接到步骤416，进入其它流程处理；

步骤405，查找以太报文头的协议号；

步骤406，判断该报文是否是MPLS报文，例如MPLS单播报文协议号一般为8847；如果是MPLS报文，则进入步骤407，否则直接到步骤416，进入其它流程处理；

步骤407，查找处于标签堆栈最外层的MPLS标签的S位数值，之所以需要提前作该操作，是考虑到可能启用本技术的设备已经是次末节点，即可能存在PE设备之间背靠背直连，不经过P设备的情况。这种情况下，如果末节点使用了隐式空标签机制，那么从接口发出的包就是一个只有一层VPN标签的包，也就不存在对特征参数2的匹配操作；

步骤408，判断S的值是多少，如果是1的话说明该标签包已经是栈底标签，可以直接转到步骤413，否则需要进入步骤409，匹配特征参数2；

步骤409，检查外层标签的label值；

步骤410，如果查找到的label值确实在VPN-QoS表中，也确实是对应了需要作QoS的Index后面的特征参数2，则进入步骤411，否则直接到步骤416，进入其它流程处理；

步骤411，如果特征参数3和特征参数2都已经先后匹配上了，就可以继续向下查找下一层标签的S值；这里所说的向下的意思是向栈底的方向，即从最外层标签向栈底标签的方向；由于每一层标签的结构都是一样的，所以这样的查找非常简单，只需要在转发时向后偏移一定的bit就可以；

步骤411的过程需要从最外层标签的label位向后偏移36个bit，即最外层标签的EXP(3个bit)+S(1个bit)+TTL(8个bit)，以及下一层标签的label(20个bit)+EXP(3个bit)+S(1个bit)的总和；如果还需要往后查找，只要每次偏移32个bit(MPLS标签长度)即可；

步骤412，判断当前查找的这一层标签的S值是否为1，如果是，即说明已经是栈底标签，进入步骤413处理，否则继续按照前面说的bit偏移的方法回到步骤411查找一次，直到查找到S为1的标签；

步骤413，既然该标签已经是栈底标签，那么必定是一个VPN标签，即用来识别VPN的标签，所以该标签的label值即对应VPN-QoS表中的特征参数1；检查该标签的前20bit标签值；

步骤414，如果该label值是对应了需要作QoS的Index后面的特征参数1，则进入步骤415，否则转到步骤416，进入其它流程处理；

步骤415，到此为止，VPN-QoS表中的三个特征参数都已经成功匹配上这个被转发的报文，可以认为这是需要作QoS处理的VPN数据包，按照需求作相应的QoS处理后，结束流程；做什么样的QoS处理已经不是本发明需要描述的内容，所以不再详细说明；

步骤416，不论在哪个步骤判断出该数据包不是需要作QoS的VPN数据包，都进入本步骤处理，即直接进入其它流程，不在本文的讨论范围之内。

说明了PE连接公网的出口处理流程之后，为了进一步解释为什么要引入VPN-QoS表中的这三个特征参数，而不引入其它的参数来定义VPN流量，需要通过图示和文字结合的方式加以说明。

首先，特征参数1对应的“对端PE设备通告过来的VPN标签值”应该没有异议，这是必须要使用的参数，因为报文到了对端PE设备以后，就是通过该参数识别不同的VPN；

其次，通过图5讨论一下特征参数2---“下游设备通告的外层标签值”的必要性，即证明仅仅通过特征参数1无法识别一条VPN流量。

如图5所示的组网方式，三台PE设备以线形组网方式直连，PE1分别和PE2、PE3都建立VPN的对接关系，那么PE2和PE3都会向PE1通告VPN标签，即内层标签。此处PE2既作为PE设备也同时作为P设备使用。由于标签是本地有效的，很有可能出现PE2和PE3通告到PE1的VPN标签值相同的情况，所以单独通过VPN标签值在出口上识别VPN流量不可行。但是如果加上外层标签值就可以规避一部分问题，因为从图上可以看出，PE2和PE3用来建立连接的地址肯定不是一个地址，所以PE2上学习到的路由也不一样，即在PE2上创建的FEC一定不会相同，自然会分配不同的标签通告到PE1。即PE1收到下游PE2设备通告过来的外层标签是不一样的。

接下来需要通过图6讨论一下特征参数3---“LSP下游设备与本地PE设备连接的接口MAC”的必要性，即证明仅仅通过特征参数1和特征参数2无法识别一条VPN流量。

如图6所示，三台PE设备通过一台二层交换机连接在一起，并且建立了标签分发机制以及VPN对接关系。那么PE2和PE3都会向PE1通告VPN标签，即内层标签，以及外层LDP标签。同样，由于标签是本地有效的，很有可能出现PE2和PE3通告到PE1的VPN标签值相同的情况。同理通告的LDP标签值也有可能相同。也就是说，有可能PE1收到的来自PE2和PE3的内外层标签都有可能相同，所以不能够仅仅通过VPN标签值+外层标签值的方式在出口上识别VPN流量。不过由于三台PE连接在交换机上的接口同处于一个局域网中，所以接口的MAC地址是不可能相同的。所以PE1分别向PE2和PE3发出的报文的目的MAC也不可能相同。

现在我们可以说明，当PE1连接交换机的接口发出两条VPN流量，其内、外层标签值都相同的情况下，此时如果想区分它们，只要加上“目的MAC”这个参数就可以做到了。

综上所述，本发明采用完全由本地PE设备处理的方式使用以太网接口实现了针对VPN流量的QoS处理，使转发层面只需要按照预先制定好的转发表对数据包进行相应的匹配操作，转发表形成所依据的特征也很简单；另外，由于没有设备之间的信令交互，不会对控制层面添加过多的负担。

尽管已经说明和描述了本发明的优选实施例，本领域的一般技术人员应该理解可以在不超出本发明范围的情况下，实施各种改变、变型和部件的同体替换。因此本发明不受限于所公开的实现本发明的具体实施例，本发明包括落在所附权利要求之内的所有实施例。

Claims (11)

1.一种基于以太接口针对虚拟专用网VPN流量实现服务质量QoS的方法，包括如下步骤：

(1)在运营商边缘设备，即PE设备上针对需要做QoS处理的VPN，提取对端PE通告的内层标签值、下游设备通告的外层标签值、以及对端PE的媒体访问控制MAC地址，组成VPN-QoS表；

(2)在所述PE设备的接口上绑定VPN-QoS表，当有数据包从所述PE设备的以太接口发出时，跟所述VPN-QoS表进行比较，如果符合表中的VPN特征，即作QoS处理。

2.根据权利要求1所述的方法，其特征在于，所述步骤(1)执行之前，需要在PE设备上创建VPN实例，并与对端PE设备建立信令交互机制。

3.根据权利要求2所述的方法，其特征在于，与对端PE设备建立信令交互机制后，三层VPN使用多协议边界网关协议MPBGP向对端PE通告VPN标签，二层VPN按照Martini或Kompella草案的要求使用标签分发协议LDP或边界网关协议BGP向对端PE通告VPN标签。

4.根据权利要求1所述的方法，其特征在于，所述步骤(1)包括如下步骤：

(1.1)在PE设备上针对需要做QoS处理的VPN，提取对端PE通告的内层标签值、下游设备通告的外层标签值；

(1.2)记录学习到标签交换路径LSP下游设备与本地PE设备连接的接口MAC；

(1.3)将对端PE设备通告过来的VPN标签值、下游设备通告的外层标签值，以及LSP下游设备与本地PE设备连接的接口MAC一同组成VPN-QoS表；所述VPN-QoS表中，每个VPN实例对应一个序号；

(1.4)若需要对该VPN流量作QoS处理，将生成的VPN-QoS表通告给VPN绑定的LSP的出接口。

5.根据权利要求4所述的方法，其特征在于，所述步骤(1.2)包括如下步骤：

(1.2.1)找到VPN绑定的LSP的出接口，称为接口O；

(1.2.2)判断接口O是否为以太接口；如果是，执行下一步；

(1.2.3)记录接口O学习到该LSP下游设备与本地PE设备连接的接口MAC。

6.根据权利要求1所述的方法，其特征在于，所述步骤(2)包括如下步骤：

(2.1)PE设备的接口上绑定VPN-QoS表；

(2.2)查找所转发报文的2层链路报头的目的MAC，若该MAC地址与需要作QoS的VPN在VPN-QoS表中的MAC地址一致，则执行下一步；

(2.3)若所述转发报文包是只有一层VPN标签的包，则直接执行下一步；否则，查找报文包外层标签的label值，如与需要作QoS的VPN在VPN-QoS表中的下游设备通告的外层标签值一致，则执行下一步；

(2.4)查找报文包的VPN标签的label值，并判断该VPN标签是否与需要作QoS的VPN在VPN-QoS表中的对端PE通告的内层标签值一致，若一致，则对该报文做QoS处理。

7.根据权利要求6所述的方法，其特征在于，所述步骤(2.1)绑定VPN-QoS表后，还需要找到需要作QoS处理的VPN在VPN-QoS表中的序号。

8.根据权利要求6所述的方法，其特征在于，所述步骤(2.1)执行之后，还需要判断所述PE设备的接口是否是以太接口，如果是，才执行步骤(2.2)。

9.根据权利要求6所述的方法，其特征在于，所述步骤(2.2)执行之后，还需要查找该以太报文头的协议号，判断该报文是否是多协议标签交换MPLS报文，如果是MPLS报文，才执行步骤(2.3)。

10.根据权利要求6所述的方法，其特征在于，所述步骤(2.3)包括如下步骤：

查找处于标签堆栈最外层的MPLS标签的S位数值，判断S的值是多少，如果是1的话说明该标签包已经是栈底标签，直接执行步骤(2.4)；否则，查找报文包外层标签的label值，如与需要作QoS的VPN在VPN-QoS表中的下游设备通告的外层标签值一致，则执行步骤(2.4)。

11.根据权利要求10所述的方法，其特征在于，所述步骤(2.4)包括如下步骤：

(2.4.1)查找所述报文下一层标签的S值，若是1，则执行下一步，若否，继续执行步骤(2.4.1)；

(2.4.2)检查该VPN标签的label值，判断该VPN标签是否与需要作QoS的VPN在VPN-QoS表中的对端PE通告的内层标签值一致，若一致则对该报文做QoS处理。

Images