QPPB

Background

The following example uses the network shown in Figure 1 to illustrate how QPPB is introduced. In this networking, the AS 400 is a high priority network. All packets transmitted across AS 400 must be re-marked with an IP precedence for preferential transmission. To meet such requirements, edge nodes (Node-A, Node-B, and Node-C) in AS 100 must be configured to re-mark the IP precedence of packets destined for or sent from AS 400. The edge interface connecting to AS 400 on Node-C must be configured to re-mark packets. Node-A or Node-B must be configured to perform traffic classification for packets destined for an IP address in AS 400. If a large number of IP addresses or address segments are configured in AS 400, Node-A and Node-B encounter excess traffic classification operations. In addition, if the network topology is prone to changes, a large number of configuration modifications are required.

Figure 1 Inter-AS network

To simplify configuration on Node-A and Node-B, QPPB is introduced. QPPB allows packets to be classified based on AS information or community attributes.

QPPB, as the name implies, applies QoS policies using Border Gateway Protocol (BGP). The primary advantage of QPPB is that BGP route attributes can be set for traffic classification by the route sender and the route receiver must only configure an appropriate policy for receiving routes. The route receiver sets QoS parameters for packets matching the BGP route attributes and then implements corresponding traffic behaviors before data forwarding. When the network topology changes, the BGP route receiver does not modify local configurations if the route attributes of the advertised BGP routes do not change.

Implementation

As shown in Figure 2, Node-A and Node-C are IBGP peers in AS 100. Node-A is configured to re-mark IP precedence for packets destined for or sent from AS 400. The QPPB implementation is as follows:

Figure 2 QPPB Implementation

1. The BGP route sender (Node-C) sets specific attributes for BGP routes (such as the AS_Path, community attributes, and extended community attributes).
2. Node-C advertises these BGP routes.
3. The BGP route receiver (Node-A) presets attribute entries. After receiving BGP routes matching the attribute entries, the BGP route receiver sets a behavior ID identifying a traffic behavior in the forwarding information base (FIB) table.
4. Before transmitting packets, Node-A obtains the behavior IDs of the routes from the FIB for these packets and performs the corresponding traffic behaviors for these packets.

The preceding process demonstrates that QPPB does not transmit the QoS policy along with the BGP route information. The route sender sets route attributes for routes to be advertised, and the route receiver sets the QoS policy based on the route attributes of the destination network segment.

Typical Application 1: Inter-AS Traffic Classification

Figure 3 Inter-AS Traffic Classification

As shown in Figure 3, QPPB allows the edge devices in AS 100 to classify inter-AS packets. For example, to configure rate limit on Node-C for packets transmitted between AS 200 and AS 400, perform the following operations:

• For packets from AS 200 to AS 400, apply source address-based QPPB on all Node-C's interfaces that belong to AS 100.
• For packets from AS 400 to AS 200, apply destination address-based QPPB on the Node-C's interface connecting to AS 400.

FIB-based packet forwarding applies to upstream traffic but not downstream traffic. Therefore, QPPB is enabled on the upstream interface of traffic.

Typical Application 2: L3VPN Traffic Classification

Figure 4 QPPB application to L3VPN traffic

As shown in Figure 4, PEs connect to multiple VPNs. A PE can set route attributes, such as community, for a specified VPN instance before advertising any route. After receiving the routing information, the remote peer imports the route and the associated QoS parameters to the FIB table. This enables the traffic from CEs to be forwarded based on the corresponding traffic behaviors. In this manner, different VPNs can be provided with different QoS guarantees.

Typical Application 3: User-to-ISP Traffic Accounting

Figure 5 QPPB application for user-to-ISP traffic accounting

As shown in Figure 5, QPPB is implemented as follows for user-to-ISP traffic accounting:

• BGP routes are advertised with community attributes.
• BGP routes are imported and the community attributes of the BGP routes are matched against attribute entries. Behavior IDs are set in the FIB table for the routes matching the attribute entries.
• A QPPB policy is configured. A corresponding traffic behavior (such as statistics collection, CAR, and re-marking) is configured for the qos-local-id (Behavior ID).
• Destination address-based QPPB is enabled for incoming traffic.
• The QPPB policy is applied to incoming traffic on the user-side interface.
• During packet forwarding, the Behavior ID (qos-local-id) is obtained for packets based on the destination IP address, and the corresponding traffic behavior is performed.

Typical Application 4: ISP-to-User Traffic Accounting

Figure 6 Application for ISP-to-user traffic accounting

As shown in Figure 6, QPPB is implemented as follows for ISP-to-user traffic accounting:

• BGP routes are advertised with community attributes.
• BGP routes are imported and the community attributes of the BGP routes are matched against attribute entries. Behavior IDs are set in the FIB table for the routes matching the attribute entries.
• A QPPB policy is configured. A corresponding traffic behavior (such as statistics collecting, CAR, and re-marking) is configured for the qos-local-id (Behavior ID).
• Source address-based QPPB is enabled for incoming traffic.
• The QPPB policy is applied to outgoing traffic on the user-side interface.
• During packet forwarding, the Behavior ID (qos-local-id) is obtained for packets based on the source IP address, and the corresponding traffic behavior is performed.