案进行清楚地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
[0057]RSVP是针对IP设计的，只在IP网络上工作。为了能沿业务路径进行资源预留，RSVP路径(PATH)消息的目的地址需要跟业务流的目的地址一致，将RSVP报文通过每跳上送路由器控制平面完成资源预留。这种设计虽然能够满足基于IP流定义的粒度，但无法在MPLS网络中逐跳预留资源。由于MPLS网络中的路由器基于MPLS标签进行转发，MPLS虚拟专用网络(Virtual Private Network, VPN)的场景也不具备用户的路由表信息，因此无法做到利用RSVP报文的目的地址逐跳穿越网络进行资源预留。
[0058]另外，RSVP中将流定义为IP地址、协议标识(Identity，ID)和端口号的组合。这样的定义有局限性，而且RSVP不能对流定义进行管理和控制。
[0059]再者，RSVP是一个相当复杂的协议，它定义了协议软状态，这个软状态通过定时刷新维持。当为大量业务流进行资源预留时，RSVP控制平面需要维护大量信息，定时在网络中双向地通过PATH、预留(RESerVat1n，RESV)消息刷新预留资源，对于超时的资源预留还要端到端地通过信令来清除之前的资源预留。这样复杂的操作消耗大量中央处理单元(Central Processing Unit, CPU)资源,进而使得RSVP的规格受到很大限制。
[0060]而且，RSVP需要判断对资源预留是否成功，也就是说，RSVP需要预留和确认的双方向的RSVP报文传递，这样会造成很大的开销，消耗大量CPU资源。
[0061]并且，RSVP进行的资源预留只考虑了带宽资源，而没有考虑诸如承诺接入速率(Committed Access Rate, CAR)等资源。
[0062]另一方面，资源预留协议流量工程(ResourceReservat1n Protocol-TrafficEngineering, RSVP-TE)可以为MPLS网络建立资源预留，但是RSVP-TE不能为MPLS网络中之外的其他的网络类型建立资源预留，并且RSVP-TE建立资源预留的过程与建立业务流转发路径的过程是耦合的。这样，不仅导致了 RSVP-TE建立资源预留和部署业务流转发路径的时间顺序不灵活，同时也增大了对业务流转发路径建立的需求，导致了不同的业务流需要有不同的转发标签才能基于流进行资源预留。
[0063]图1是本发明一个实施例的建立服务质量预留的方法的流程图。图1所示的方法是在业务流转发路径建立之后执行的，该方法包括:
[0064]101,第一节点获取第一协议报文，该第一协议报文包括第一流定义域、第一 QoS需求域和第一转发头信息域，该第一协议报文用于为业务流建立QoS预留，该第一转发头信息域用于指示业务流转发路径。
[0065]102，第一节点根据该第一流定义域确定流以及流分类规则，该流分类规则用于后续业务报文进行流分类以确定该后续业务报文属于该流。
[0066]103,第一节点提取该第一 QoS需求域中的第一 QoS需求信息。
[0067]104，第一节点生成绑定关系，该绑定关系为该流与该第一 QoS需求信息之间的绑定关系。
[0068]本发明实施例通过协议报文确定流以及QoS需求信息，进一步生成流与QoS需求信息之间的绑定关系，能够为业务流建立QoS预留，该协议报文的逐跳转发能够为业务流逐跳地建立QoS预留，进而能够保障业务流的QoS，并且该预留能够适应各种网络类型。
[0069]应注意，本发明实施例中，建立QoS预留不仅是建立了带宽资源的资源预留，并且同时还建立了诸如CAR等资源的预留。本发明实施例中将带宽资源和CAR等资源的预留统称为QoS预留。
[0070]本发明实施例中，建立服务质量预留的过程是在业务流转发路径建立之后才执行的，这样就实现了业务流的服务质量预留建立与业务流转发路径建立之间的完全解耦。也就是说，在业务流转发路径建立的过程中没有同时进行服务质量资源建立的过程。那么，在业务流转发路径建立之后已经可以进行正常的业务流的转发，只是，由于没有建立服务质量预留，已经建立好的业务流转发路径不一定能够保证业务流的服务质量。
[0071 ] 本发明实施例中，为了保障业务流的服务质量，在业务流转发路径建立之后，再逐跳地建立QoS预留。其中，业务流转发路径的每一跳均可称之为节点。
[0072]本发明实施例中，节点可以是转发设备，例如可以是交换机，或者也可以是路由器，或者具有交换功能的设备，或者是具有路由功能的设备。另外，节点可以是网络中的运营商边缘(Provider Edge,PE)设备,或者也可以是运营商(Provider,P)设备,或者也可以是用户边缘(Customer Edge, CE)设备,本发明实施例对此不作限定。
[0073]本发明实施例中，图1中的第一节点可以是业务流转发路径中的中间节点，也可以是业务流转发路径的最后一个节点。
[0074]可选地，作为一个实施例，第一节点可以是从第三节点接收该第一协议报文，其中，该第三节点可以是业务流转发路径中该第一节点的上一跳节点。
[0075]可选地，本发明实施例中，第一协议报文可以是由该第三节点根据业务需求生成的，再由该第一节点从该第三节点获取该第一协议报文。该第三节点可以是发起业务流服务质量申请的主机，或者也可以是发起业务流服务质量申请的PE设备。此时，可理解为，该第三节点为该业务流转发路径的首节点，该第一节点为第三节点的下一跳节点。也就是说，第一节点为该业务流转发路径的首节点的下一跳节点。
[0076]可选地，作为一个实施例，第一协议报文的形式可以是服务质量预留(QoS RESV)消息。即，该第一节点可以接收QoS RESV消息，该QoS RESV消息包括第一流定义域、第一QoS需求域和第一转发头信息域。可选地，第一协议报文的形式也可以是其他类型的消息，本发明实施例对此不作限定。
[0077]可选地，该QoS RESV消息中还可携带信息域。该信息域包括第一协议报文在建立QoS预留时的监控信息。该监控信息可以包括带宽预留是否完成、是否有队列拥塞丢包发生、建立QoS预留的路径信息、业务流报文统计信息中的一个或多个。并且，可选地，该QoSRESV消息还可包括多个可选域，该多个可选域可用于与该第一协议报文相关的指示信息。本发明对此不作限定。
[0078]这样，可使QoS RESV消息中的必选域的数量比较少，便于对该QoSRESV消息的处理。例如可以在硬件层面处理该QoS RESV消息，比如直接在转发平面处理该QoS RESV消息而不上送到控制平面。而且，可以降低该QoS RESV消息的发送频率，由控制层面的控制实体进行处理，从而能够节省资源。
[0079]可选地，作为另一个实施例，本发明实施例中，信息域可以承载在服务质量信息(QoS INFO)消息中。该第一节点可在获取QoS RESV消息的同时获取该QoS INFO消息，或者该QoS INFO消息可以与QoS RESV消息的周期不同。该信息域可包括第一协议报文在建立QoS预留的监控信息。该监控信息可以包括带宽预留是否完成、是否有队列拥塞丢包发生、建立QoS预留的路径信息、业务流报文统计信息中的一个或多个。
[0080]也就是说，第一协议报文以QoS RESV消息的形式存在可以是以下的任意一种情形:
[0081](I)QoS RESV消息中可以仅包括第一流定义域、第一 QoS需求域和第一转发头信息域，其中第一流定义域、第一 QoS需求域和第一转发头信息域可称为3个必选域；或者，
[0082](2)QoS RESV消息中可以包括第一流定义域、第一 QoS需求域、第一转发头信息域和息域，其中所述息域是可选域；或者，
[0083](3 )QoS RESV消息和QoS INFO消息同时用于建立QoS预留。且QoS RESV消息中包括第一流定义域、第一 QoS需求域和第一转发头信息域，QoS INFO消息中包括信息域。本发明对此不作限定。
[0084]本发明实施例中，第一流定义域可包括第一部分第一流定义域，其中第一部分第一流定义域可包括以下至少一种:源IP地址的范围、目的IP地址的范围、协议ID、端口号的范围、源MAC地址的范围和目的MAC地址的范围。并且，第一部分第一流定义域可以是业务流转发路径的首节点生成的。其中，首节点可以是发起业务流服务质量申请的主机，或者也可以是发起业务流服务质量申请的PE设备。
[0085]具体地，地址的范围可以是地址的前缀。例如，源IP地址的范围可以是源IP地址的前缀，目的IP地址的范围可以是目的IP地址的前缀，源MAC地址的范围可以是源MAC地址的前缀，目的MAC地址的范围可以是目的MAC地址的前缀。
[0086]可选地，第一流定义域还可以包括第二部分第一流定义域，其中第二部分第一流定义域可包括以下中的一个或多个=MPLS标签、GRE IP头、MAC in MAC头和虚拟可扩展局域网(Virtual Extensible Local Area Network, VXLAN)头,本发明实施例对此不作限定。例如，若第一节点从第三节点接收该第一协议报文，并且该第三节点处于MPLS网络，那么该第二部分第一流定义域可包括由该第三节点生成的MPLS标签。应注意，MPLS标签可以是单层或多层的。例如，若第一节点从第三节点接收该第一协议报文，并且该第三节点通过GRE隧道转发第一协议报文，那么该第二部分第一流定义域可包括GRE IP头。例如，若第一节点从第三节点接收该第一协议报文，并且该第三节点通过MAC隧道转发第一协议报文，那么该第二部分第一流定义域可包括MAC in MAC头。例如，若第一节点从第三节点接收该第一协议报文，并且该第三节点通过VXLAN隧道转发第一协议报文，那么该第二部分第一流定义域可包括VXLAN头。
[0087]可以理解为，该第二部分第一流定义域是在建立QoS预留的过程中，由节点动态增加或修改的。这样，本发明实施例扩充了流定义的范围，提高了对流定义的分类能力，能够支持更多的流分类的字段。并且，可以对流定义进行管理和控制。
[0088]本发明实施例中，第一 QoS需求域包括第一 QoS需求信息,用于表不业务流对QoS的需求，该第一 QoS需求信息可以在该第一协议报文中以一定的格式编排携带。例如，该第一 QoS需求信息可包括QoS队列，QoS队列可以是如下参数中的一个或多个:队列调度方式、队列优先级和队列的带宽。该第一 QoS需求信息也可包括其他QoS参数，例如CAR、染色和setting等,本发明对此不作限定。
[0089]其中，该第一 QoS需求域可以是首节点根据业务流对QoS的需求信息经过计算确定的，也可以是预配置在该首节点中的，本发明对此不作限定。首节点可以是发起业务流服务质量申请的主机，或者也可以是发起业务流服务质量申请的PE设备。
[0090]本发明实施例中，第一转发头信息域包括第一部分第一转发头信息域。其中，第一部分第一转发头信息域可包括目的IP地址；或者，第一部分第一转发头信息域可包括源IP地址、目的IP地址和协议ID ;或者，第一部分第一转发头信息域可包括源IP地址、目的IP地址、源端口、目的端口和协议ID ;或者，第一部分第一转发头信息域可包括目的MAC地址；或者，第一部分第一转发头信息域可包括源IP地址、目的IP地址，源MAC地址和目的MAC地址。并且，第一部分第一转发头信息域可以是由首节点生成的。首节点可以是发起业务流服务质量申请的主机，或者也可以是发起业务流服务质量申请的PE设备。其中，源IP地址可以为业务流的源IP地址，目的IP地址可以为业务流的目的IP地址，源MAC地址可以为业务流的源MAC地址，目的MAC地址可以为业务流的目的MAC地址。
[0091]可以理解为，该第一部分第一转发头信息域是属于第一部分第一流定义域的范畴的。具体地，第一部分第一转发头信息域中的源IP地址是属于第一部分第一流定义域中的源IP地址的范围中的一个。第一部分第一转发头信息域中的目的IP地址是属于第一部分第一流定义域中的目的IP地址的范围中的一个。第一部分第一转发头信息域中的源MAC地址是属于第一部分第一流定义域中的源MAC地址的范围中的一个。第一部分第一转发头信息域中的目的MAC地址是属于第一部分第一流定义域中的目的MAC地址的范围中的一个。
[0092]可选地，第一转发头信息域还可包括第二部分第一转发头信息域。其中第二部分第一转发头信息域可包括以下中的一个或多个:MPLS标签、GRE IP头、MAC in MAC头和VXLAN头，本发明实施例对此不作限定。例如，若第一节点从第三节点接收该第一协议报文，且该第三节点处于MPLS网络，该第二部分第一转发头信息域可包括由该第三节点生成的MPLS标签。应注意，MPLS标签可以是单层或多层的。例如，若第一节点从第三节点接收该第一协议报文，并且该第三节点通过GRE隧道转发第一协议报文，那么该第二部分第一转发头信息域可包括GRE IP头。例如，若第一节点从第三节点接收该第一协议报文，并且该第三节点通过MAC隧道转发第一协议报文，那么该第二部分第一转发头信息域可包括MACin MAC头。例如，若第一节点从第三节点接收该第一协议报文，并且该第三节点通过VXLAN隧道转发第一协议报文，那么该第二部分第一转发头信息域可包括VXLAN头。
[0093]可以理解为，该第二部分第一转发头信息域是在建立QoS预留的过程中，由节点动态增加或修改的。这样，本发明实施例中定义的第一协议报文可以应用于各种网络类型，例如IP网络，MPLS网络，或者IP和MPLS的混合网络，或者也可应用于跨域的网络等。
[0094]这样，本发明实施例中，第一转发头信息域用于引导第一协议报文沿着业务流转发路径进行转发。该第一转发头信息域包含了与业务流的转发路径一致的业务流转发路径信息，能够保证第一协议报文沿着业务流转发路径进行转发，可使业务流转发路径的每一个节点根据第一协议报文为业务流建立QoS预留。并且，每一个节点可更新第二部分第一转发头信息域，并将更新之后的协议报文转发至业务流转发路径中的下一跳节点。
[0095]本发明实施例中，步骤102中的流是根据第一流定义域进行定义的。并且可确定流分类规则，该流分类规则可用于后续业务报文进行流分类以确定后续业务报文属于该流。相同的流具有相同的QoS处理过程。
[0096]具体地，流分类规则是第一节点根据第一流定义域生成的。在本发明实施例为业务流建立QoS预留之后，当后续业务报文经过该第一节点时，第一节点可根据流分类规则，对该后续业务报文进行流分类，判断该后续业务报文是否属于该流。当第一节点可确定该后续业务报文属于该流时，可执行与该流对应的相同的QoS处理过程。
[0097]本发明实施例中，第一节点可以根据第一部分第一流定义域确定流，也可以结合第二部分第一流定义域和第一部分第一流定义域一起来确定流,本发明对此不作限定。
[0098]可选地，第一节点可以根据第一流定义域中的IP地址的范围和/或MAC地址的范围确定流。可选地，第一节点也可以结合第一流定义域中的IP地址的范围和MPLS标签等一起确定流。本发明实施例对此不作限定。
[0099]具体地，在同一网络的不同VPN中，可能会有相同的IP地址,这时只根据IP地址的范围不能唯一地确定流。因此，需要结合其他信息与IP地址的范围一起来确定流。这里所说的其他信息可以是MPLS标签，或者可以是GRE IP头，或者也可以是MAC in MAC头，或者也可以是VXLAN头等，或者也可以是其他用于区别不同网络类型的标识，本发明对此不作限定。
[0100]可选地，本发明实施例中，在步骤103中提取的第一 QoS需求信息可以是QoS队列。
[0101]本发明实施例中，在步骤104建立绑定关系，即可认为该第一节点为该业务流建立了 QoS预留。可选地，该绑定关系可以是流与QoS队列的绑定关系。
[0102]可选地，作为一个实施例，当第一节点为业务流转发路径的中间节点时，在建立绑定关系之后，第一节点根据第一协议报文生成第二协议报文，该第二协议报文包括第二流定义域、第一 QoS需求域和第二转发头信息域。进一步地，第一节点根据第二转发头信息域，将第二协议报文发送至第二节点，该第二节点为根据第一转发头信息域进行查表所确定的下一跳节点。其中，第二流定义域是基于第一流定义域或者是基于第一流定义域和第一转发头信息域生成的。第二转发头信息域是基于述第一转发头信息域生成的。该第二协议报文用于由第二节点根据该第二协议报文为业务流建立QoS预留。
[0103]具体地，第二流定义域可包括第一部分第二流定义域和第二部分第二流定义域。并且第一部分第二流定义域与第一部分第一流定义域相同，第二部分第二流定义域与第二部分第一流定义域不同。
[0104]可理解为，若第一流定义域不包括第二部分第一流定义域，第二流定义域可以是第一节点在第一流定义域的基础上增加第二部分第二流定义域之后所生成的。若第一流定义域包括第二部分第一流定义域，第二流定义域可以是第一节点将第一流定义域中的第二部分第一流定义域进行替换为第二部分第二流定义域后所生成的。
[0105]这里，第二部分第二流定义域可包括以下至少一种:MPLS标签、GRE IP头、MAC inMAC头和VXLAN头。
[0106]例如，当第一节点处于MPLS网络时，第二部分第二流定义域可包括MPLS标签，该MPLS标签是该第一节点根据第一转发头信息域查找标签转发表所确定的。应注意，MPLS标签可以是单层或多层的。例如，当第一节点通过GRE隧道转发第一协议报文时，那么该第二部分第二流定义域可包括GRE IP头，该GRE IP头是该第一节点根据第一转发头信息域查找路由表所确定的。当第一节点通过MAC隧道转发第一协议报文时，那么该第二部分第二流定义域可包括MAC in MAC头，该MAC in MAC头是该第一节点根据第一转发头信息域查找第一 MAC转发表所确定的。例如，当第一节点通过VXLAN隧道转发第一协议报文时，那么该第二部分第二流定义域可包括VXLAN头，该VXLAN头是该第一节点根据第一转发头信息域查找第二 MAC转发表所确定的。
[0107]可选地，所述第二转发头信息域包括目的IP地址；或者，所述第二转发头信息域包括源IP地址、目的IP地址和协议ID ;或者，所述第二转发头信息域包括源IP地址、目的IP地址、源端口、目的端口和协议