Delivering QoS Services in a Cable Environment

This topic describes how SRC policies provide quality of service in the cable network environment.

Service Flow Scheduling Types

The DOCSIS protocol is used to support quality of service for traffic between the cable modem and the CMTS device. To support QoS, the DOCSIS protocol uses the concept of service flows for traffic that is transmitted between cable modems and CMTS devices. A service flow is a unidirectional flow of packets that provides a particular quality of service. Traffic is classified into a service flow, and each service flow has its own set of QoS parameters. Table 8 describes the service flow scheduling types and the QoS parameters that you can set for each type.

The SRC software is compliant with the service flow scheduling types as defined in the PacketCable Multimedia Specification PKT-SP-MM-I03-051221. See the specification for detailed information about each scheduling type.

Table 8: DOCSIS Service Flow Scheduling Types

Client Type 1 Support

The PCMM specification defines three types of clients, and defines a client as a logical entity that can send or receive data. The SRC software supports client type 1, which represents endpoints such as PC applications or gaming consoles that lack specific QoS awareness or signaling capabilities. Client type 1 entities communicate with an application manager to request service, and the CMTS device manages the QoS signaling.

Client type 1 entities support the proxied QoS with policy push scenario of service delivery defined in the PacketCable Multimedia Architecture Framework Technical Report (PKT-TR-MM-ARCH). In this scenario, the application manager requests QoS resources on behalf of the client, and the policy server pushes the request to the CMTS device. The CMTS device sets up and manages the DOCSIS service flow that the application requires.

Proxied QoS with Policy Push

In the proxied QoS with policy push scenario of service delivery, the client requests a service by sending a service request to the application manager. The application manager determines the QoS needs of the request and sends a policy request to the policy server. The policy server validates the policy request and if, the decision is affirmative, sends a policy set message to the CMTS device. The CMTS device performs admission control on the requested QoS envelope, installs the policy decision, and establishes the service flow to the client with the requested QoS levels.

Figure 12: Authorization Framework for Proxied QoS with Policy Push

PCMM Gate

A PCMM gate is a logical representation of a policy decision that has been installed on the CMTS device. The gate performs traffic classification and enforces QoS policies on media streams.

The set of service flow characteristics that provide enhanced QoS is the envelope. A CMTS gate contains up to three envelopes that indicate authorized, reserved, and committed resources for the service flow that corresponds to the gate. A gate defines a resource authorization envelope that consists of IP-level QoS parameters as well as classifiers that define the scope of service flows that can be established against the gate.

Three elements of a gate discussed here are session class ID, classifiers, and traffic profiles.

Session Class ID

The session class ID provides a way for the application manager and the policy server to group gates into classes with different authorization characteristics. A CMTS device can perform authorization based not only on the requested QoS and the gate’s authorized flow specification (FlowSpec), but also on the session class ID specified in the GateSpec. For example, you could use the session class ID to represent a prioritization scheme that allows either the policy server or the CMTS device to preempt a preauthorized gate in favor of allowing a new gate with a higher priority to be authorized.

Use the GateSpec action to specify the session class ID for a gate.

PCMM Classifiers

The classifier identifies the IP flow that will be mapped to the DOCSIS service flow associated with the gate. You define the classifier by using a classify-traffic condition.

PCMM Classifiers and Extended Classifiers

Classify-traffic conditions comply with the classifiers specified in PacketCable Multimedia Specification PKT-SP-MM-I02-040930 (referred to as PCMM I02) as well as the extended classifiers in PacketCable Multimedia Specification PKT-SP-MM-I03-051221 (referred to as PCMM I03).

To specify which version of the PCMM classifiers that you are using, see one of the following:

• Specifying the PCMM Classifier Type .
• Configuring Policy Lists (C-Web Interface)
• Adding a Policy Rule
• Specifying the PCMM Classifier Type (C-Web Interface)

PCMM I02 classifiers do not support IP masks or a range of port numbers. PCMM I03 classifiers do support IP masks and a range of port numbers.

You define classifiers for PCMM irrespective of whether the policy is meant for I02 or I03. At service activation time, depending on whether the SAE is configured to use I02 or I03 policies, the policy engine does the appropriate translations. For example, if I02 policies are to be used, source and destination IP masks and ranges of port numbers are ignored.

You can configure all fields for extended PCMM classifiers (PCMM I03), except for classifierID, activation state, and action. At service activation, the policy engine sets these fields as follows:

• ClassifierID=A system-generated number
• Activation state=Active
• Action=Add

Guidelines for Configuring Classifiers

When you configure classify-traffic conditions for PCMM policies, keep in mind the following:

• Do not leave the IP address field empty.
• For PCMM classify-traffic conditions, there are two special protocol values:
  • 256 matches traffic that has any IP protocol value
  • 257 matches both TCP and UDP traffic
• PCMM I02 classifiers do not support IP masks or a range of port numbers.
• PCMM I03 classifiers to support IP masks and a range of port numbers.

Traffic Profiles

There are three ways to express the traffic profile for a gate:

• DOCSIS parameters—Specifies the traffic profile through DOCSIS-specific parameters.
• Service class name—Name of a service class that is configured on the CMTS device.
• FlowSpec—Defines the traffic profile through an RSVP-like parameterization scheme.

You can also mark the ToS byte of a packet as it gets to the gate.

DOCSIS Parameters

You use DOCSIS parameters in a network that uses version 1.1 of the DOCSIS protocol. To define DOCSIS parameters for a traffic profile, use the DOCSIS action. This action supports service flow scheduling types and QoS parameters described in Delivering QoS Services in a Cable Environment. See one of the following:

• Configuring DOCSIS Actions .
• Configuring DOCSIS Actions (C-Web Interface)

Service Class Name

To use a service class name for a traffic profile, use the service class name action. Instead of setting QoS parameters, you specify the name of a service class that is configured on the CMTS device. See one of the following:

• Configuring Service Class Name Actions
• Configuring Service Class Name Actions (C-Web Interface)

FlowSpec Parameters

You can use an RSVP-style FlowSpec to specify a traffic profile. A FlowSpec is made up of two parts, a traffic specification (TSpec) and a service request specification (RSpec). The TSpec describes the traffic requirements for the flow, and the RSpec specifies resource requirements for the desired service.

TSpec parameters defined in the FlowSpec are:

• Bucket rate
• Bucket depth
• Peak rate
• Minimum policed unit
• Maximum packet size

RSpec parameters defined in the FlowSpec are:

• Reserved rate
• Slack term

Types of FlowSpec Services

FlowSpecs support two types of services—controlled load and guaranteed.

• Controlled-load service can be used to provide minimum bandwidth guarantees, and is suitable for applications that are not latency sensitive. Controlled-load service allows applications to have low delay and high throughput even during times of congestion. Controlled-load service can be closely approximated to the best-effort service flow scheduling type. Controlled-load services support TSpec parameters only.
• Guaranteed service allows applications to reserve bandwidth, and is suitable for latency and jitter-sensitive applications such as voice, MPEG video, or gaming. The CMTS device uses the traffic profile parameters specified in the FlowSpec to select one of the two types of DOCSIS scheduling types that can provide guaranteed services—RTPS and UGS. Guaranteed services support both TSpec and RSpec parameters.

Table 9 shows how the FlowSpec service types map to the DOCSIS service scheduling types.

Table 9: Mapping FlowSpec Types

FlowSpec Parameters

Table 10 shows the parameters that you can set for each service type.

Table 10: Parameters Available for Each Type of Service

Marking Packets

You can also mark packets and then install policies on the router that handle the marked packets in a certain way. The mark action causes the ToS byte to be set in the IP header of IPv4 traffic or the traffic-class field to be set in the IP header of IPv6 traffic. For example, to offer videoconferencing, you could:

1. Create a classify-traffic condition that causes the CMTS device to classify the traffic.
2. Create a mark action that causes the CMTS device to mark the ToS byte or traffic-class field in the classified traffic.
3. Create a policy on the router that classifies the traffic according to the marked ToS byte.

Copyright © 2008, Juniper Networks, Inc. All Rights Reserved. Trademark Notice.