Cos

NDC Release 3.1 2012 AT&T Knowledge Ventures. All rights reserved. 1 AT&T is a registered trademark of AT&T Knowledge Ventures.

AT&T Network-Based

Class of Service Features

Customer Router Configuration Guide

Release 3.1

July 2012


Technical Assistance

This is an AT&T proprietary document developed for use by AT&T customers. For additional technical assistance contact your AT&T sales team. (This document was prepared by AT&T Solution Center Network Design and Consulting Division.)

Legal Disclaimer

This document does not constitute a contract between AT&T and a customer and may be withdrawn or changed by AT&T at any time without notice. Any contractual relationship between AT&T and a customer is contingent upon AT&T and a customer entering into a written agreement signed by authorized representatives of both parties and which sets forth the applicable prices, terms and conditions relating to specified AT&T products and services, and/or, to the extent required by law, AT&T filing a tariff with federal and/or state regulatory agencies and such tariff becoming effective. Such contract and/or tariff, as applicable, will be the sole agreement between the parties and will supersede all prior agreements, proposals, representations, statements or understandings, whether written or oral, between the parties relating to the subject matter of such contract and/or tariff.


Table of Contents Changes from Release 3.0 to 3.1................................................................................................................... 4 1. Introduction .......................................................................................................................................... 5 2. COS Systems Approach ....................................................................................................................... 7

2.1 Ordering COS in the Service (for the PE) ................................................................................... 7 2.2 CPE Marking and Queuing.......................................................................................................... 8 2.3 Network Based Class of Service ................................................................................................. 9

2.3.1 PE Ingress Treatment .............................................................................................................. 9 2.3.2 Core Treatment ...................................................................................................................... 10 2.3.3 PE Egress Treatment ............................................................................................................. 10

2.4 Network Capacity ...................................................................................................................... 11 3. Configuring Class of Service ............................................................................................................. 12

3.1 Identify Traffic Types ................................................................................................................ 12 3.2 Create a Policy ........................................................................................................................... 14

3.2.1 Priority Command for COS1 Real-Time Class ..................................................................... 15 3.2.2 Setting the DSCP ................................................................................................................... 16

3.3 Configuring the Interface and Appling the Policy ..................................................................... 17 3.4 Verify the Policy ........................................................................................................................ 19

4. Configuring Interfaces with COS ....................................................................................................... 22 4.1 PPP Interfaces ............................................................................................................................ 22

4.1.1 Sub-Rate PPP Interfaces........................................................................................................ 22 4.1.2 MLPPP Interfaces (for Multiple T1s or E1s) ........................................................................ 22

4.2 Frame Encapsulation Interfaces (Unilink) ................................................................................. 23 4.3 Ethernet Interfaces ..................................................................................................................... 24

4.3.1 Target Rate ............................................................................................................................ 25 4.3.2 Committed Burst (Bc) ........................................................................................................... 26 4.3.3 Excess Burst (Be) .................................................................................................................. 26 4.3.4 802.1Q Encapsulation with Multiple VLANs (Unilink): ...................................................... 26

4.4 Frame Relay Interfaces .............................................................................................................. 27 4.4.1 Sub-rate Frame Relay Interfaces ........................................................................................... 27 4.4.2 Frame Relay Interfaces with Multiple Logical Channels (Unilink) .................................. 28

4.5 ATM Interfaces ......................................................................................................................... 29 4.5.1 Sub-rate ATM Interfaces ....................................................................................................... 29 4.5.2 ATM Interfaces with Unilink ................................................................................................ 30 4.5.3 IMA Interfaces ...................................................................................................................... 30

5. Conclusion .......................................................................................................................................... 32 Appendix A - AT&T COS Feature Description ......................................................................................... 33

A.1 Class Markings .......................................................................................................................... 33 A.2 Class Behaviors ......................................................................................................................... 34 A.3 COS Profiles .............................................................................................................................. 35 A.4 COS Packages ........................................................................................................................... 36

Appendix B - Mapping Applications to Classes ......................................................................................... 39 B.1 Application Attributes ............................................................................................................... 39 B.2 Application Mapping Guidelines ............................................................................................... 41

Appendix C - Data Queue Scheduling Mechanisms - Tutorial ................................................................... 43 C.1 First-In-First-Out (FIFO) ........................................................................................................... 43


C.2 Priority Queuing ........................................................................................................................ 43 C.3 Flow-Based Weighted Fair Queuing (WFQ) ............................................................................. 43 C.4 Class-Based Weighted Fair Queuing (CBWFQ) ....................................................................... 44 C.5 Modified Deficit Round-Robin (MDRR) .................................................................................. 47

Appendix D - Case Studies: Fragmentation/Interleaving/Header Compression ........................................ 48 Appendix E COS for Video ..................................................................................................................... 51

E.1 Introduction ............................................................................................................................... 51 E.2 Video Application Behavior ...................................................................................................... 51 E.3 Video Network Behavior ........................................................................................................... 52 E.4 Video COS Methodologies ........................................................................................................ 53

E.4.1 Video in COS1 without VoIP................................................................................................ 53 E.4.2 Video in COS1 with VoIP ..................................................................................................... 54 E.4.3 Video in COS2V ................................................................................................................... 54 E.4.4 Video in COS2 ...................................................................................................................... 54 E.4.5 Video in Other Classes .......................................................................................................... 54

E.5 Call Admission Control ............................................................................................................. 54 References ................................................................................................................................................... 56

Changes from Release 3.0 to 3.1 Below is a list of the more significant changes made since release 3.0.

Section 3.2.1.1 and 3.2.1.2 added to address handling COS with a lost T1 from the MLPPP bundle

Removed references to Blue B profiles as they are no longer supported Updated some of the configuration and show command examples Moved content from some appendices to the main document Moved references to Unilink connections under their respective interface configuration discussion Added Appendix E which addresses COS issues with Video Added references to the 4COS Model


1. Introduction This document has been created to assist AT&T customers in understanding and using the network-based Class of Service (COS) features of AT&T IP transport services (where the customer manages their own CPE). The Class of Service feature allows multi-application enterprise networks to optimize response times for time-critical interactive applications while maintaining high throughput for bulk data applications. In addition, COS provides low latency queuing capabilities to minimize delays and variance for real time applications such as voice and interactive video.

This guide does not reflect in any way what AT&T managed services does or does not support when AT&T manages customer-premises routers. For information on AT&T managed router capabilities see your sales representative.

Network-based COS capabilities have become increasingly important as businesses move to deploy mission critical enterprise applications across public IP infrastructures and IP VPN services. These applications have traditionally been deployed across private, point-to-point networks where application differentiation could be accomplished entirely by premise based edge equipment. With IP architectures, many-to-one flows inside the carrier cloud create network bottlenecks that cannot be easily controlled by edge-based policies alone. In addition, the emergence of Voice over IP and interactive video conferencing are driving a requirement for tight control over queuing delay and variance. This has driven the need for IP network services to participate in the enforcement of customer defined COS policies. AT&T COS features have been designed specifically to meet these needs.

The primary functions of COS features are to differentiate traffic types competing for bandwidth in an enterprise network and place them into different queues to partition bandwidth in a deterministic fashion. COS is a powerful set of network design tools to aid in performance engineering for your network. Used properly, these features often allow you to forgo bandwidth upgrades while maintaining the performance of mission critical applications. However, COS is NOT a substitute for sufficient bandwidth. COS features are intended to provide deterministic behavior during periods of network congestion. This behavior represents a tradeoff, usually favoring time sensitive mission critical applications during congestion over less time sensitive or less critical applications. AT&T supports a common set of COS markings and behaviors across all IP services. This document describes this common feature set and outlines best practices for using these capabilities.

The primary objective of this document is to provide guidance on the basic functions, configuration, and operation of COS features. This document provides an overview of COS from a systems perspective, describes the high level attributes of the network-based features, and provides basic guidance for configuring customer equipment to operate properly as a part of the described system. This information is believed to be applicable and sufficient for most enterprise network environments.

Several appendices are provided for those who want more in-depth information and/or more specialized application of COS features. The following appendices provide more detailed descriptions:

Appendix A: the operation of the network features

Appendix B: mapping applications to classes

Appendix C: the operation of COS queue scheduling mechanisms

Appendix D: fragmentation, interleaving and header compressions

Appendix E: COS for video environments


The fundamental concepts contained in this document need to be applied to each customer's specific environment. While basic environments and configurations are addressed, this document is not intended to be exhaustive. If assistance is needed in more complex scenarios contact your AT&T technical resources.


2. COS Systems Approach COS features are used in a Wide Area Network (WAN) to provide deterministic utilization of congested links. For IP networks the congested links are typically at the edges of the network on the link between the Provider Edge (PE) and the Customer Edge (CE) devices. Deterministic utilization is accomplished by providing separate queuing paths for identified application flows along with a scheduling algorithm to service the queues in a defined manner. The queue configuration and scheduling algorithm work together to determine the network performance aspects of a particular application class.

COS features allow multi-application enterprise networks to optimize response times for time-critical interactive applications while maintaining sufficient throughput for bulk data applications. These features are one necessary aspect of an overall systems approach to application performance. Effective use of these features requires looking at every potential bottleneck end-to-end, encompassing the customer equipment (marking and queuing) as well as the network-based COS features. Figure 1 depicts bi-directional traffic flow across an IP network highlighting each of the COS components along their respective paths.

Figure 1 Network Based COS Functions

2.1 Ordering COS in the Service (for the PE) To get the COS treatment that you want from the service, you order COS profiles with your ports. This puts a policy map on your port on the PE in both the ingress and egress directions. Section 2.3and 2.5 address those PE behaviors. The profile choices are discussed in detail in Appendix A - AT&T COS Feature Description.

Note that if you place an order to change COS on an existing port you should assume some packet loss or at worse a hard down for a minute or two.

PE Ingress:Policing

PE

CE

CE

CE: Marking,Queuing

PE Egress: Queuing

PE Egress:Queuing

CE: Marking, Queuing

MPLS Core(LSPs) PE Ingress:

Policing

PE

MPLS Core Multi-Protocol Label Switched CoreCE Customer Edge RouterPE Provider Edge RouterLSP Label Switched Paths


2.2 CPE Marking and Queuing The Customer Premise Equipment (CPE) has two critical functions to perform: (1) identification and marking of application traffic flows, and (2) differential queuing of traffic into the WAN network.

The marking of packets is done by setting specific Differentiated Services Code Point (DSCP) values within the Type of Service (TOS) byte of the IP header. The DSCP field in the IP header consists of 6 bits in the TOS byte, some CPE can only support marking the 3-bit IP precedence (IPP) field of the TOS byte rather than the full 6-bit DSCP field. Note that there are multiple CPE devices that could accomplish the DSCP marking (Originating device, CE router, or some intermediate device1

). Each marking indicates the type of treatment that a packet should receive from the network. The set of flows that share a common marking and resulting treatment are referred to as a class. AT&T supports up to six user markings (or classes) as outlined in Table 1.

Class DSCP and IPP Marking Behavior COS1 EF, CS5, IPP5 Priority

COS2V AF41, CS4, IPP4 Video Conferencing

COS2 AF31, CS3, IPP3 Bursty Data

COS3 AF21, CS2, IPP2 Bursty Data

COS4 Default0, IPP0 Best Effort

COS5 AF11, CS1, IPP1 Scavenger

Table 1 AT&T Class of Service Markings

When COS is ordered for a given site, a COS Bandwidth Allocation Profile is selected for the site from either the 4-COS model or the 6-COS model. Details of the various choices of COS Profiles that can be used per site are provided in Appendix A. The COS Profile identifies which of the class markings are recognized for the site, and how much of the available port bandwidth is guaranteed for the class during congestion. In some cases, bandwidth allocation profiles are selected that do not utilize all six of the available class markings.

If a profile is selected that does not include COS2V or COS5, then traffic that has these markings will be treated as part of the COS4 class.

If a profile is selected that does not have COS1, then traffic with this marking is treated as part of the next lower class.

1 Common practice for packet marking is to administer markings at a single common networking device, typically the CE Router. This prevents a rogue originating system/user from implementing markings that are inappropriate to the overall COS policy and hence cause undesired effect for all users at that site. In some cases, it is desirable to trust the marking from the originating system. In these cases it is preferable if the trusted systems can be isolated on separate/trusted VLANs. Separate VLANs with trusted DSCP markings are a common construct for Voice over IP (VoIP) deployments where DSCP is typically set at the originating device.


If a profile is selected that only recognizes a single class, then all traffic is treated as part of this class, regardless of its marking.

The CPE utilizes queuing and congestion management techniques to provide the desired application differentiation. This type of differentiated treatment is needed anywhere in the network where congestion may occur. The CPE queuing behavior specifically addresses the case where there is contention/congestion for traffic being transmitted from the Local Area Network (LAN) into the WAN. For these cases the CPE needs to make the intelligent decisions regarding allocating the available bandwidth to the various application classes and if necessary discarding excess.

Congestion occurs when the traffic demand on a particular link is greater than the capacity. Congestion events may be sustained or transient. Sustained congestion will typically be observed in the utilization metrics taken by typical network management systems. Transient congestion may last for just a few seconds, or even less, and typically is not displayed in network management reports do to the lack of granularity. COS policies are effective for both sustained and transient congestion.2

2.3 Network Based Class of Service

The AT&T network has three roles in the overall COS systems approach. At ingress to the network a policing function is used to enforce the COS policy provisioned for the site. Across the MPLS core several differentiated Label Switched Path (LSP) markings are used to differentiate traffic in the event of core trunk congestion. And at network egress, the IP header markings are used to provide differentiated egress queuing in the event of egress congestion at the site. Additional detail on these roles is provided below.

2.3.1 PE Ingress Treatment As traffic enters the network, the DSCP markings are inspected at the ingress PE. Priority treatment is given to applications marked for COS1. When ordering COS for a site, the amount of COS1 bandwidth is explicitly specified. if the amount of COS1 traffic exceeds this provisioned amount, the excess is immediately discarded. This prevents excessive COS1 traffic from being carried across the core network with low latency treatment. Likewise with the default behavior of COS2V, any traffic exceeding the bandwidth allocation is discarded. The COS1 ingress bandwidth allocation is defined as a percentage of the access port.

For AT&T MPLS-based services, like AVPN or PNT, the DSCP markings and the PE ingress policing are used to determine the MPLS headers EXP setting for COS treatment across the core.

There are two out-of-contract concepts, for classes that are not strictly policed (e.g. COS2, 3, 5):

1. The first is when a customer marks a packet with a DSCP of AFx2 or AFx3. This will affect both the core treatment (lower WRED threshold; see Section 2.3.2) and how the PE at the far end treats the packets on egress (see section 2.3.3).

2. The second out-of-contract concept is when this ingress policing detects packets that exceed their class bandwidth allocation, it marks the MPLS headers EXP bit with an out-of-contract

2 During sustained congestion, COS can help assure that time sensitive interactive application continue to perform well. However, sustained congestion indicates an ongoing period where all of the available bandwidth is consumed. This indicates that there are one or more applications that are bandwidth constrained. If these bulk data applications are not meeting the required performance levels, COS tools will not be sufficient to provide improvement. In this case, additional WAN bandwidth is warranted to improve the transfer times for bulk data.


value that gets a lower WRED threshold treatment in the core. Note that AT&T does not change a customers DSCP, so this does not affect egress PE queuing (which only looks at DSCP).

2.3.2 Core Treatment The EXP field is used across the core for two fundamental functions. It is used provide differentiation/protection among service offerings sharing the core, and it is used within VPN services to provide protection among CoS classes. The EXP field is a 3-bit field providing 7 potential markings for LSPs. There are 4 queues supported across the core trunks; one dedicated for COS1 traffic (EXP-5), one for VPN data traffic with two separate drop thresholds (WRED) for in and out of contract traffic (EXP-4 and EXP-3), one for Best Effort/Internet traffic with 3 separate drop thresholds (EXP-2, EXP-1, EXP-0), and finally, there is a queue reserved for control plane traffic to operate the network (EXP-6).

2.3.3 PE Egress Treatment As traffic leaves the network the DSCP markings are again inspected at the egress PE. This is the point along the communication path where congestion is most likely to occur. Congestion occurs at network egress when the total amount of traffic transmitted toward a customer site exceeds the bandwidth of the connection to the site. As with all junctions along the communication path, when there is no congestion, packets are simply forwarded toward the site as soon as they are received in a First-In, First-Out (FIFO) manner (not queued). During these periods, COS has no impact at all on the behavior of the connection3

When congestion occurs at an egress port, the PE begins to queue traffic into one of six class queues; COS1, COS2V, COS2, COS3, COS4, or COS5 when the 6COS model is used and one of four class queues; COS1, COS2, COS3, or COS4 when the 4COS model is used. Each time the transmitter is ready to forward a subsequent packet, a packet is taken from one of the queues and transmitted out of the interface. If there is no traffic arriving with that particular class marking, then that class queue will be empty.

. As the rate of traffic increases beyond the port speed, the PE cannot forward all packets immediately so congestion develops. The egress PE has two primary tools for managing congestion; queuing and discards. Queuing is simply holding the traffic in a buffer, delaying the packet delivery, until it can be sent. If the congestion condition persists, the amount of queued traffic and resulting queuing delay will continue to increase. At some point further delay of packets is no longer reasonable, and the PE discards packets.

The delay for each traffic class will be different. The delay will be a function of how much traffic is arriving in a given class and how often that class queue is chosen for transmission out of the interface (i.e. how full the queue is, which is a function of Class Arrival Rate and Class Service Rate).

On egress, the class bandwidth allocations control the relative servicing rate out of the queue and on to the egress port toward the customer site. But this allocation is only in effect when the port is congested (the total data arrival rate is greater than the port capacity). Traffic in a class will get the full port rate if the port is not congested. Each COS allocation profile defines the percentage of available bandwidth during congestion for each COS class (see Appendix A for details about allocation profile choices). For any class that is not consuming its full allocation, the excess bandwidth for the class becomes available for the remaining queues in a ratio proportional to their allocation. Note that the COS1 and COS2V classes are an exception. COS1 is policed to its bandwidth allocation and is always first to go. COS2V is serviced next and traffic exceeding the allocation is discarded. COS2V can be ordered without the

3 At network egress, COS1 traffic is always limited to its bandwidth allocation, even when congestion is not present. Other traffic classes may consume any available bandwidth as long as the connection is not congested.


policing behavior while COS1 is always policed. Unused COS1 and COS2V bandwidth is still available for consumption by the remaining data classes.

Packets marked with one of the out-of-contract DSCP settings (e.g. AFx2 or AFx3) will be subject to a lower WRED threshold and thus a higher drop probability than in-contract marked traffic (AFx1). These out-of-contract markings came from the ingress CE, AT&T does not change a customers DSCP settings (i.e. short pipe mode).

2.4 Network Capacity Network capacity planning is the process of determining the appropriate link capacity to meet the application needs of a specific enterprise. Proper capacity planning by the customer is necessary in assuring that a WAN deployment can provide acceptable application performance. Once the customer provisions appropriate link capacity, the COS tools provide a means to use and share the available capacity in a deterministic fashion.

This document does not specifically address network capacity planningwhere the customer chooses the best link bandwidth. AT&T has Data Network Analysts (DNAs) available to assist in this step. DNAs have extensive experience in network performance and application characteristics, as well as sophisticated modeling and planning tools to aid in this process. Contact your AT&T account team to engage a DNA.


3. Configuring Class of Service4

The sections that follow detail how to deploy COS features in the CE. The steps are as follows:

1. Identify traffic types using class-maps and ACLs (Access Control Lists).

2. Create a policy for queuing and marking traffic.5

3. Apply the policy to the WAN interface.

4. Verify the policy is behaving as intended.

Examples provided in this guide are using IOS 12.4(24)T2. The available features and command set for IOS based COS features are constantly evolving and expanding. For example more recent Cisco IOS images are phasing in Hierarchical Queueing Framework(HQF) to replace the Modular Quality of Service Command Line Interface (MQC). Users of this guide are strongly encouraged to refer to their CPE vendor documentation for more detailed configuration guidance. Please note that these examples are for illustrative purposes only. The precise examples shown may not be appropriate for your business needs. Moreover, readers should not infer that AT&T will or will not follow these examples when AT&T manages customer premises routers.

AT&Ts COS features recognize up to six separate classes for differentiating application types. You do not need to use all six classes; many enterprise networks operate sufficiently with only 2 levels of differentiation to support their application requirements. When developing a COS policy for the enterprise, we recommend using the minimum number of classes that meet the identified need. Refer to Appendix B for guidelines on mapping applications to the various classes. The network links can be ordered with a full complement of COS classes on the PE even if there is no intent or need to use all of the available markings. There is no loss of performance or throughput if a particular class marking in the network is not used.

3.1 Identify Traffic Types The first step in router configuration is to uniquely identify each traffic type in the CE. This is done using class-maps and ACLs.

Some traffic you will identify via an ACL that looks for specific server IP addresses or TCP/IP port numbers. Other traffic may already be marked with a trusted DSCP, so you simply match on the existing DSCP.

Class-Map Examples:

4 This section provides instructions for configuring the Customer Edge Router (CER) for COS. The configuration illustrations displayed throughout this section are focused on Cisco IOS implementations. AT&T does not require the use of Cisco equipment but recognizes that the majority of current customer implementations are with Cisco equipment. The Quality of Service feature set is constantly evolving and expanding. The guidelines outlined here contain a subset of available features that have been proven to work well with AT&T Network-based COS features. To gather the most recent information for the latest Cisco IOS releases please consult the Cisco documentation. This is not intended to be an IOS primer but rather a starting point for what needs to be done to get COS implemented in the CER. 5 Please refer to the Appendix B Mapping Applications to Classes - for addition guidelines and best practices for mapping applications into the various queues.


Class-map match-any COS5 !Non-business or scavenger traffic match access-group name COS5-Traffic !See ACL examples below ! class-map match-any COS3 !Multi-second response time apps match access-group name COS3-Traffic !See ACL examples below ! class-map match-any COS2V !Video conferencing app match access-group name COS2V-Traffic !See ACL examples below ! class-map match-any COS2 !Sub-second response time apps match access-group name COS2-Traffic !See ACL examples below match ip dscp af31 !Traffic pre-marked with DSCP AF31 ! class-map match-any COS1 !VoIP match ip dscp ef !COS 1 for pre-marked real time traffic ! class-map match-any COS5-Traffic !Video streaming match ip dscp af11 !COS 5 for pre-marked real time traffic

Class-maps are very flexible and can be much more comprehensive than depicted here. The examples show two different flavors of the match sub-command for class-maps. Match can be used to recognize a number of protocols directly; or match can refer to an ACL that defines the traffic to be recognized. It can also be used to identify traffic based on packet size, existing DSCP marking, input interface, etc. NOTE: Your platform/release may not support all of the protocol types shown in the examples. If a protocol is not directly supported, then it can usually be matched using an ACL instead. IMPORTANT

The name assigned to each of the class maps (COS5, COS3, COS2, COS2V, COS1) is used within a queuing policy to determine the treatment for traffic types matching the class. When using these class-maps in a queuing policy, there is one additional pre-defined class-map available named class-default. This class matches all traffic that is not matched elsewhere in the queuing policy. This default class must appear last in the list.

: When using multiple match commands, be sure to set up the class using match-all or match-any depending on whether you wish to recognize traffic based on all of the specified conditions, or any one of the specified conditions.

The COS2 and COS3 class-maps in the previous example each reference an ACL. Below are some simple ACL examples to match the class-map definitions above.

ACL Examples:

ip access-list extended COS2V-Traffic !Defined video conference traffic permit tcp any any range 3230 3231 !Range of TCP ports used by video6 permit udp any any range 3230 3235 !Range of UDP ports used by video

! ip access-list extended COS2-Traffic !Time critical applications permit tcp host 10.55.64.95 any !Anything from the PBX (call signaling) permit tcp any eq bgp any !BGP traffic

6 These port ranges are for example purposes. Video conferencing applications have a wide range of ports. You must work with your vendor to isolate the specific ports used in your environment.


permit tcp any any eq bgp ! ip access-list extended COS3-Traffic !Time sensitive applications permit tcp host 10.55.64.20 eq www any !Web enabled enterprise application (server

source) permit tcp any host 10.55.64.20 eq www !Web enabled enterprise application (server

dest) ! ip access-list extended COS5-Traffic !Time sensitive applications permit tcp any any eq 554 !TCP port used for streaming video NOTE: These access lists are intended as examples. Customers should tailor them to meet the application mix and performance requirements of your specific enterprise network. Notice that the COS3 example includes two statements, to recognize traffic based on either source or destination criteria. For some application types (e.g. telnet), this may be desirable since there is a good chance that the client server relationship could be set up in either direction across the link. For other traffic types, even though traffic will normally match in one direction only, you may find it helpful to define traffic in both directions. Doing so allows you to use the same ACL on all routers in your network, and also reduces the chance of error in defining the traffic in the wrong direction.

3.2 Create a Policy There are multiple queuing disciplines available in IOS, some of which are described in Appendix C. In this guide, we show the use of service policies implementing Class-Based Weighted Fair Queuing (CBWFQ). The service policy will be used to perform the DSCP marking, and to provide advanced queuing within the CE. More recent router IOSs support different, but similar, queue scheduling mechanism so read your vendors documentation.

The queuing policy is configured using a policy-map. Within the policy map, there are several commands associated with each traffic class recognized by the policy. The class command identifies a traffic type that was previously defined in a class-map. Beneath each class command are instructions for allocating bandwidth and setting the DSCP marking for traffic in the class. Note that there are actions supported within the policy beyond the basics covered here.

The sample policy below illustrates a policy supporting 256 kbps of COS1 traffic for RT applications such as bearer voice traffic and a bandwidth allocation across the data queues of 30%, 50%, 15%, 5%, 0% for classes 2, 2V, 3, 4, and 5 respectively.

The policy also marks the appropriate DSCPs so that the PE within AT&Ts network will recognize and carry the COS policy across the network end-to-end.

The queue-limit command is used in this sample policy to increase the queue-limit for the classes specified from the default of 64 packets to 600. Increasing the queue limit allows more packets to be buffered rather than discarded. However, larger queues use more memory and result in greater packet delay, therefore one should consider the tradeoff between packet loss and packet delay and memory usage when configuring a queue-limit per class.

Sample Policy:

policy-map COS class COS1 priority 256 !Allocate 256K for real time traffic- provides LLQ set ip dscp ef


class COS2 bandwidth remaining percent 30 set ip dscp af31 queue-limit 600 packets ! see paragraph above class COS2V bandwidth remaining percent 50 set ip dscp af41 queue-limit 600 packets class COS3 bandwidth remaining percent 15 set ip dscp af21 queue-limit 600 packets class COS5 bandwidth remaining percent 1 set ip dscp af11 queue-limit 600 packets class class-default !Class-default is pre-defined in IOS; it matches any bandwidth remaining percent 4 !remaining traffic set ip dscp default queue-limit 600 packets

3.2.1 Priority Command for COS1 Real-Time Class In the example above, the COS1 bandwidth is expressed directly in kbps, while the remaining classes are specified using bandwidth remaining percent (alternative syntaxes are available). It is usually a good idea to directly configure the amount of COS1 bandwidth, as this is an important consideration for planning voice call volumes and/or similar metrics typical of COS1 applications. Conversely, using the percentage notation for the remaining classes provides a policy that matches the network based policies, and does not need to be changed even if the port speed is upgraded.

For multilink interfaces, the available bandwidth is dynamically calculated based on the number of active T1s in the bundle. Therefore AT&T does not recommend customers to configure a 'bandwidth' statement on multilink interfaces because it will override the dynamic calculation. The COS1 real-time class is of most concern since it is most affected (packets are dropped) by reduced bandwidth.

With the understanding that any traffic beyond the COS1 bandwidth allocation will be discarded we need to examine how COS1 behaves as the aggregate bandwidth is reduced due to lost T1s. The behavior is different based on which priority statement you use in the policy-map: priority or priority percent. The next two sub-sections describe the different behavior.

3.2.1.1 Priority kbps command The COS1 behavior when the policy uses a priority 'kbps' command and no bandwidth statement on the interface is as follows:

Functioning BW: the bandwidth remaining after the T1 is lost (e.g. 3xT1 connection is ~4.5Mbps, the functioning bandwidth when a single T1 is lost is ~3.0Mbps)

If the COS1 BW < Functioning BW, then the router will service all of the COS1 traffic presented, however the data traffic may suffer during times of peak COS1 load where there's a chance the lower priority data queues get starved. (The extent of the starvation is dependent upon the difference between the COS1 BW allocation and the functioning BW)


If the COS1 BW > Functioning BW, then the router will service all traffic for all classes in a FIFO fashion just as if there is no COS policy applied at all. Furthermore, any DSCP markings that are manipulated by the service policy on the MLPPP interface will NOT occur during this scenario.

When using this type of configuration for an MLPPP environment, the marking policy should be done separately on the ingress LAN interface(s) so that it continues to operate regardless of queuing behavior.

3.2.1.2 Priority percent command The COS1 behavior when the policy uses a priority percent command and no bandwidth statement on the interface is as follows:

When a T1 fails, the COS1 traffic serviced is reduced based on the percent of the functioning link bandwidth. For example, if a 4.5Mbps connection is used with a 3.6Mbps COS1 allocation (80% of 4.5M) and when the connection loses a T1, then the COS1 allocation is reduced to 2.4Mbps (80% of 3.0M). So any COS1 traffic coming into that connection, during the time of the outage that exceeds 2.4M will be dropped.

Note: The behavior exists in the PE to CE direction as well when the PE is a Cisco GSR. When the PE is a Juniper then the COS1 bandwidth allocation is "hard configured" as a fixed "kbps" of the total bundle.

3.2.2 Setting the DSCP There are several syntactical methods of setting DSCP using IOS commands. Table 3 shows the most common set for using AT&T COS features.


IOS COMMAND Class Codepoint Set ip dscp ef COS1 101 110 Set ip dscp 46 COS1 101 110 Set ip prec 5, Set ip dscp cs5 COS1 101 000 Set ip prec critical COS1 101 000 Set ip dscp af41 COS2V 100 010 Set ip dscp 35 COS2V 100 001 Set ip prec 4, Set ip dscp cs4 COS2V 100 000 Set ip prec flash override COS2V 100 000 Set ip dscp af31 COS2 011 010 Set ip dscp 26 COS2 011 010 Set ip prec 3, Set ip dscp cs3 COS2 011 000 Set ip prec flash COS2 011 100 Set ip dscp af21 COS3 010 010 Set ip dscp 18 COS3 010 010 Set ip prec 2, Set ip dscp cs2 COS3 010 000 Set ip prec immediate COS3 010 000 Set ip dscp default COS4 000 000 Set ip dscp 0 COS4 000 000 Set ip prec 0 COS4 000 000 Set ip prec routine COS4 000 000 Set ip dscp af11 COS5 001101 Set ip dscp 10 COS5 001 101 Set ip prec 1, Set ip dscp cs1 COS5 001 000 Set ip prec priority COS5 001 000

Set ip dscp af42 COS2V out of contract 100 100 Set ip dscp 36 COS2V out of contract 100 100 Set ip dscp af32 COS2 out of contract 011 100 Set ip dscp 28 COS2 out of contract 011 100 Set ip dscp af22 COS3 out of contract 010 100 Set ip dscp 20 COS3 out of contract 010 100 Set ip dscp af12 COS5 out of contract 001 100 Set ip dscp 12 COS5 out of contract 001 100

Table 3 Syntax for Setting Codepoints

(Preferred syntax in bold)

3.3 Configuring the Interface and Appling the Policy The next step is to apply the policy to the WAN interface. But before applying a service policy, there are some other configurations required that are explained below. (1) Ensure ip cef is enabled on the router. Some situations require cef be enabled for proper operation

of the policy. Then under the interface: (2) Turn off Cisco Discovery Protocol cdp on the interface/sub-interface with the no cdp enable

command.. The network PEs will not respond to CDP. This should be turned off on the interface to


eliminate unnecessary packets. For configurations that use sub-interfaces, CDP for each sub-interface should be explicitly disabled.

(3) Ensure the proper bandwidth value is specified for the interface using the bandwidth statement.

This will influence the allocations defined in the service policy. The bandwidth statement is sometimes used to manipulate routing metrics in the IGP. In these cases, care should be taken to achieve both the desired COS behavior and the desired routing behavior. When warranted, consider alternate means of influencing routing decisions, such as cost.

(4) The max-reserved-bandwidth 100 statement should be present in the interface configuration.

Without this statement, policies which allocate more than 75% of the interface bandwidth may not be accepted.

(5) The tx-ring-limit command is used to specify the size of the buffer on the transmit interface. The

queue scheduling algorithms (e.g. CBWFQ) forwards packets to this interface buffer before finally going out the interface. For packet interfaces (Frame Relay, PPP, PoS), the tx-ring-limit specifies the number of frames in the buffer. For ATM interfaces, the tx-ring limit may specify packets, or it may specify a number of 576 byte particles (refer to the Cisco documentation for you hardware interface). This buffer should be kept to the smallest practical value.7

The transmit buffer assures that a packet is ready for the transmitter once the transmitter completes sending the previous packet out the interface. If set too small, it is possible that the transmitter will be starved and need to wait for the next packet to arrive from the queue scheduler before . This is generally not an issue for interfaces at or below T1 speed. For these interfaces, use the minimum configurable value (1 for Packet Interfaces, 2 or 3 for ATM Interfaces). For higher speed interfaces, a good rule of thumb is to size the tx-ring for ~ 5ms of data at the interface speed. The 5ms threshold is estimated by dividing the maximum amount of data in the transmit ring by the speed of the interface. For packet-based transmit rings it is usually reasonable to assume 1,500-byte packets. For particle-based transmit rings use 576 bytes per particle. Note that for some interfaces, the default value may already represent less than 5ms. For these cases, the default value should be kept. Example calculations for 5ms transmit buffers: tx-ring-limit = INT( link speed * 5 ms) / RING-UNIT For packet interfaces, use 1,500 bytes for the RING UNIT For particles interfaces, use 576 bytes for the RING UNIT Example 1: T1 Frame Relay interface tx-ring-limit = INT(1,536,000 * .005 / (1,500*8 bits/byte)) = INT (.64) = 1

7 The guidance provided here provides a conservative tx-ring-limit setting that provides reasonable performance. Some more recent IOS/interface configurations now have default values that are actually smaller than these recommendations and may provide better performance than these recommendations. Consult your Cisco documentation for the most up to date information on your hardware/software combination.


Example 2: 4 x T1 IMA interface (using particles) tx-ring-limit = INT(4* 1,536,000 * .005 / (576*8 bits/byte)) = INT (6.67) = 6

(6) Apply the policy to the interface. The commands to do this vary by interface type so reference Section 4, Configuring Interfaces with COS, for the specific configuration examples for each interface type. Those examples also include the commands described above (2 through 5).

3.4 Verify the Policy It is very important to verify that the service policy has been applied to the interface as expected and is properly marking packets. We have seen configurations that look correct only to discover that the router was not applying them as they appeared. Use the show policy-map command to verify the policy. Verify that the policy is applied to the interface and is marking traffic as expected. To truly verify the policy is correctly applied you will want to do this show policy-map command and note the packet and byte counters, send specific traffic that should be marked into the particular queue, then do the show policy-map command again. Check the packet and byte counters again to determine whether the traffic was marked and sent within the appropriate queue.

Router# show policy-map interface Multilink3000 Multilink3000 Service-policy output: COS queue stats for all priority classes: (queue depth/total drops/no-buffer drops) 0/0/0 (pkts output/bytes output) 0/0 Class-map: COS1 (match-any) 0 packets, 0 bytes 30 second offered rate 0 bps, drop rate 0 bps Match: ip dscp ef (46) 0 packets, 0 bytes 30 second rate 0 bps Match: ip dscp cs5 (40) 0 packets, 0 bytes 30 second rate 0 bps Priority: 256 kbps, burst bytes 6400, b/w exceed drops: 0 QoS Set dscp ef Packets marked 0 Class-map: COS2 (match-any) 128 packets, 6400 bytes 30 second offered rate 0 bps, drop rate 0 bps Match: access-group name COS2-Traffic 0 packets, 0 bytes 30 second rate 0 bps Match: ip dscp af31 (26) 128 packets, 6400 bytes


30 second rate 0 bps Queueing queue limit 600 packets (queue depth/total drops/no-buffer drops) 0/0/0 (pkts output/bytes output) 128/6656 bandwidth remaining 30% (1305 kbps) QoS Set dscp af31 Packets marked 128 Class-map: COS2V (match-all) 1262 packets, 64400 bytes 30 second offered rate 0 bps, drop rate 0 bps Match: ip dscp af41 (34) Queueing queue limit 600 packets (queue depth/total drops/no-buffer drops) 0/0/0 (pkts output/bytes output) 1262/66924 bandwidth remaining 50% (2176 kbps) QoS Set dscp af41 Packets marked 1262 Class-map: COS3 (match-any) 0 packets, 0 bytes 30 second offered rate 0 bps, drop rate 0 bps Match: access-group name COS3-Traffic 0 packets, 0 bytes 30 second rate 0 bps Match: ip dscp af21 (18) 0 packets, 0 bytes 30 second rate 0 bps Queueing queue limit 600 packets (queue depth/total drops/no-buffer drops) 0/0/0 (pkts output/bytes output) 0/0 bandwidth remaining 15% (652 kbps) QoS Set dscp af21 Packets marked 0 Class-map: COS5 (match-any) 98 packets, 4900 bytes 30 second offered rate 2000 bps, drop rate 0 bps Match: ip dscp af11 (10) 98 packets, 4900 bytes 30 second rate 2000 bps Queueing queue limit 600 packets (queue depth/total drops/no-buffer drops) 0/0/0 (pkts output/bytes output) 98/5096 bandwidth remaining 1% (43 kbps) QoS Set dscp af11 Packets marked 98


Class-map: class-default (match-any) 86 packets, 12522 bytes 30 second offered rate 0 bps, drop rate 0 bps Match: any Queueing queue limit 600 packets (queue depth/total drops/no-buffer drops) 0/0/0 (pkts output/bytes output) 86/5439 bandwidth remaining 4% (174 kbps) QoS Set dscp default Packets marked 86


4. Configuring Interfaces with COS This section shows how to apply the service policy to the different interface types:

1. PPP and MLPPP

2. Frame Encapsulation, Dedicated Access

3. Ethernet

4. Frame Relay

5. ATM, including IMA

4.1 PPP Interfaces The COS policy for PPP interfaces are applied at the interface level. The configuration example below is based on a T1 private line access into the MPLS service.

interface Serial0/1 bandwidth 1536 ip address 10.155.60.2 255.255.255.252 max-reserved-bandwidth 100 service-policy output COS !Service-policy is configured on the main interface encapsulation ppp tx-ring-limit 1 no cdp enable

4.1.1 Sub-Rate PPP Interfaces To accommodate sub-rate port speeds with PPP, the aggregate traffic rate is shaped to the port speed. This is done with a traffic shaping command in the service policy. The structure of the interface configuration remains the same except the new policy-map is referenced in the service-policy.

policy-map shape-25M-Port class class-default shape average 25000000 !Shape to the sub-rate speed service-policy COS !Service-policy referencing COS policy

interface Serial0/ !25M DS3 sub-rate port bandwidth 25000 ip address 10.155.60.2 255.255.255.252 max-reserved-bandwidth 100 service-policy output shape-25M-Port !Referencing the appropriate shaping policy encapsulation ppp tx-ring-limit 10 no cdp enable

4.1.2 MLPPP Interfaces (for Multiple T1s or E1s) Multilink PPP provides link aggregation for multiple T1s (between 2 and 8). MLPPP connections are unique in that the connection bundles together between 2 and 8 T1s to create a larger bandwidth connection. These connections will still be operational even if one or more T1 in bundle fails (unless of


course it is the last one in the bundle that fails). Therefore it is prudent to plan how the COS policy behaves when this scenario occurs. Section 3.2.1 addresses such a scenario and provides contingency recommendations with regard to how the COS policy behaves.

Note there is another AT&T feature called MLPPP LFI (link fragmentation and interleaving) which is used with a single fractional T1 interface (768 kbps and less) to break each packet into smaller fragments to improve latency for real-time (e.g., voice over IP) applications. This capability is described in Appendix D.

The following is an example of a 2xT1 MLPPP configuration illustrating the service-policy applied to the multilink interface. Refer to the AT&T VPN Service Customer Router Configuration Guide for additional details about multilink interface configurations.

interface Multilink3000 !The multilink group number for this example is 3000 ip address 10.70.254.217 255.255.255.252 encapsulation ppp no peer neighbor-route no cdp enable ppp multilink ppp chap hostname 10.70.254.217ATT !Create a unique hostname ppp multilink group 3000 ppp multilink fragment disable service-policy output COS !Apply the policy to the interface ! interface Serial0/0/0 !First T1 in the multilink bundle no ip address encapsulation ppp ppp chap hostname 10.70.254.217ATT !Create a unique hostname ppp multilink ppp multilink group 3000 keepalive interface Serial0/1/0 !Second T1 in the multilink bundle no ip address encapsulation ppp ppp chap hostname 10.70.254.217ATT !Create a unique hostname ppp multilink ppp multilink group 3000 keepalive

4.2 Frame Encapsulation Interfaces (Unilink) This method is used for a feature called Unilink which allows the customer to connect to multiple VPNs with one physical port. Each virtual circuit is bound to a different VPN. Up to twelve logical channels are allowed as standard. Note that a virtual circuit cannot be used for AT&T Managed Internet service.

Multiple VPN connections over private line access are typically provided using Frame Relay encapsulation on the access link to provide L2 differentiation of the connections. The COS for Frame Encapsulated ports is at the port level, a single COS policy is applied to all connections sharing the port.

COS Frame Encapsulation Example


interface Serial0/0 bandwidth 44000 max-reserved-bandwidth 100 no ip address service-policy output COS !Apply policy to interface encapsulation frame-relay IETF tx-ring-limit 10 frame-relay lmi-type cisco ! interface Serial0/0.777 point-to-point !Connection for VPN1 ip address 10.55.254.125 255.255.255.252 no cdp enable frame-relay interface-dlci 777 ! interface Serial0/0.888 point-to-point !Connection for VPN2 ip address 10.56.254.125 255.255.255.252 no cdp enable frame-relay interface-dlci 888

4.3 Ethernet Interfaces There are three speeds that can be associated with Ethernet access:

1. Physical interface speed (10baseT, 100baseT, etc.)

2. Port speed that is purchased. This can be the same as physical interface speed or less. If less then this is a logical sub-rate speed

3. VLAN sub-interface speed.

Ethernet access is typically delivered using an 802.1q VLAN interface over 10M, 100M, or 1000M physical access lines. Then, one can purchase a main Ethernet port speed at a committed rate or sub-rate of something less than the speed of the physical line8

The Ethernet Service Provider (ESP), who provide the Ethernet access to MPLS rate-limits and strictly polices the port speed at the VLAN sub-interface speeds. Conforming to this committed rate requires the CE to have a service-policy on the VLAN

. Then, the port can have one or more VLAN sub-interfaces (one per VPN) each having a committed rate.

sub-interface

Each VLAN must be strictly shaped to a maximum rate. The shaping is accomplished within the service policy using a shape command. A class within the policy matches all traffic for the interface. The actions for the class are to shape the traffic to the speed which was ordered for the connection. Then a nested COS service policy is used to provide COS differentiation for the various traffic classes.

to limit the maximum traffic rate to what was purchased (otherwise the ESP will drop packets that exceed that rate). If there is no VLAN and the port speed purchased is less than the physical interface speed, then the main Ethernet interface needs the service policy to shape the traffic to the purchased speed (limit the rate with queuing as opposed to dropping).

8 In the special cases where the committed rate is the same as the speed of the physical access line, a shaping policy is not required. Since the physical and committed rates are equal the potential to violate the access network commitment is absent, removing the potential for access network drops. In these cases a COS policy may be attached directly to the main Ethernet interface.


The service policy is a nested construct as follows:

policy-map ETHERNETSHAPING class class-default shape average !See details below queue-limit 2048 !See paragraph below service-policy COS !Nested COS service-policy interface FastEthernet0/0 description ** 10M AVPN Ethernet ** no ip address duplex full speed 100 max-reserved-bandwidth 100 interface FastEthernet0/0.1139 encapsulation dot1Q 1139 ip address 10.64.42.253 255.255.255.252 no cdp enable service-policy output ETHERNETSHAPING !Shaping policy applied to the sub-interface

The top level policy has a single class, the class-default, and contains the shaping parameters for the connection. The queue-limit is added in this example to increase the queue-limit from the default (which varies depending on the platform used consult the equipment vendors documentation). Remember that larger queue sizes will generally reduce the number of packet discards, however, at the same time, increase packet delay and increase memory usage in the router. The designer will need to take this into account when configuring. This policy also calls out a nested policy which provides Class of Service (COS) differentiation within the shaped interface.

4.3.1 Target Rate The target rate represents the speed that was purchased for the access circuit. The shaper implementation in IOS does count all of the bits transmitted on the interface9

9 In most Cisco IOS platforms, only a portion of the total bits is actually counted by the shaper. The target shaping rate must be adjusted to account for the difference between the actual forwarded bits on the line and the portion counted by the shaper. For each frame, there is a total of 42 bytes of protocol overhead. In IOS, the shaper counts only 18 of the overhead bytes. This means that for every frame, an additional 24 bytes are being transmitted that are not being counted as part of the target rate. Hence the actual transmit rate is greater than the rate specified by the shaper. This is particularly significant when the predominant payloads are small, such as in a heavy Voice over IP (VoIP) environment. In order to match the shaped rate more closely to the desired/contracted forwarding rate, the shaper rate should be reduced. Since the payload in any environment is variable, there is no absolutely correct amount of target rate reduction needed. Refer to the AT&T VPN Service Ethernet Access Customer Router Configuration Guide for additional details.

, however the shaping function counts the IP payload and only a portion of the packet overhead, but not all. The Ethernet Service Providers counts all the bits. Therefore, to accommodate this difference, the customer must configure the target rate in the CE less than the purchased rate.


This parameter is configured in bits per second.

For most environments:

Target Rate = 0.95 * Contracted Rate

For environments where VoIP represents more than 50% of overall traffic:

Target Rate = 0.80 * Contracted Rate

NOTE: The 95% and 80% target rate thresholds are rule of thumb levels. As average packet size decreases, which is typical of high percentage VoIP environments, the target rate should be further decreased to account for the larger amount of uncounted per packet overhead traffic.

4.3.2 Committed Burst (Bc) Bc represents the granularity at which the shaped rate is maintained. This parameter is configured in bits. Use the minimum configurable value

Typically: 0.004 * Shaped Rate. (i.e. 4ms of data at the shaped rate)

for this parameter:

This minimizes the size of transmit bursts and provides the best COS differentiation.

4.3.3 Excess Burst (Be) Be provides an initial burst after an idle period and is configured in bits. Use the minimum configurable value for this parameter, typically 0. This minimizes the size of transmit bursts and provides the best COS differentiation.

Important note: The maximum burst achieved with this configuration has been observed to be approximately 2x Bc. After an idle period, a traffic burst can immediately consume a full Bc size burst. A subsequent allocation of Bc is then allocated anywhere from 0 to Tc (4ms in this recommendation) later. If this allocation is near 0, then the initial burst approaches 2x Bc. This initial burst of 2xBc was only observed at the minimum shaping interval of 4ms. Testing at longer shaping intervals was not tested, and may or may not exhibit similar behavior.

4.3.4 802.1Q Encapsulation with Multiple VLANs (Unilink)10

This method is used for a feature called Unilink which allows the customer to connect to multiple VPNs with one physical port. Each logical channel (VLAN) is bound to a different VPN. Up to twelve logical channels are allowed as standard.

:

When using Ethernet connecting to multiple VPNs, 802.1q encapsulation is required. The customer purchases a speed for each VLAN. That speed is a maximumthere is no bursting above that speed. The PE and the Ethernet access service strictly shapes each VLAN to the purchased rate, and the sum of the VLAN speeds must be less than the physical Ethernet access speed. Each VLAN gets a portion of the port bandwidth and no VLAN can burst to above its logical channel speed. Furthermore, each VLAN port on the PE is configured with its own COS policy. So, the customer should use this same design on the CE outbound to the service. The CE needs a separate COS policy for each VLAN as defined by the policy-map. The traffic on one VLAN cannot use the bandwidth of the other VLAN(s).

10 Unilink examples in this document are intended to address methods for applying COS policies in environments with multiple WAN connections on a port. The examples are not addressing the mechanisms for keeping the traffic in separate routing domains such as VRF Lite.


Refer to the AT&T VPN Service Ethernet Access Customer Router Configuration Guide for additional details about Ethernet interface configurations. interface GigabitEthernet0/0 !See Ethernet Access Configuration Guide for details Interface GigabitEthernet0/0.101 !VLAN for VPN1 description **VPN1** encapsulation dot1Q 101 ip address 192.168.1.1 255.255.255.252 no cdp enable service-policy output COS-VPN1 !COS policy for VLAN1 ! Interface GigabitEthernet0/0.102 !VLAN for VPN2 description **VPN2** encapsulation dot1Q 102 ip address 192.168.2.1 255.255.255.252 no cdp enable service-policy output COS-VPN2 !COS policy for VLAN2

4.4 Frame Relay Interfaces For Frame Relay interfaces, the customer applies the policy to the main interface if only one logical channel (sub-interface).

Frame Relay Example:

interface Serial0/0 bandwidth 1536 max-reserved-bandwidth 100 no ip address service-policy output COS !Apply policy to interface encapsulation frame-relay IETF tx-ring-limit 1 frame-relay lmi-type cisco ! interface Serial0/0.777 point-to-point ip address 10.55.254.125 255.255.255.252 no cdp enable frame-relay interface-dlci 777

4.4.1 Sub-rate Frame Relay Interfaces The customer can purchase a port speed at a rate less than the DS3 physical interface speed. This is referred to a sub-rate port.

For sub-rate ports with a single logical channel (single VPN), the rate is controlled within the service policy on the main interface.


Sub-Rate Port Frame Relay Example:

policy-map shape-20M-Port class class-default shape average 20000000 !Shape connection to 20Mbps service-policy COS !Nested COS service-policy

interface Serial0/0 !20M subrate DS3 Port bandwidth 20000 max-reserved-bandwidth 100 no ip address service-policy output shape-20M-Port !Apply policy to interface encapsulation frame-relay IETF tx-ring-limit 10 frame-relay lmi-type cisco ! interface Serial0/0.777 point-to-point ip address 10.55.254.125 255.255.255.252 no cdp enable frame-relay interface-dlci 777

For sub-rate ports with Unilink (i.e. multiple logical channels), the rate is controlled using frame relay traffic shaping on the individual PVCs. The sum of the shaped rates should not exceed the sub-rate port speed. This configuration is shown in the next in section 4.4.2.

4.4.2 Frame Relay Interfaces with Multiple Logical Channels (Unilink) Unilink is the case where there are multiple PVCs sharing the port. Unilink configurations may be used for connections to multiple VPNs, or for a mix of VPN connections and Point to Point Layer 2 PVCs. When using Unilink with Frame Relay interfaces, each PVC is traffic shaped so the sum of the PVC speeds is less than the port speed.

With traffic shaping, the queuing occurs on the sub-interface rather than the main interface. In these cases, the policy is included in the traffic shaping parameters applied to the sub-interface. Note that the actual shaping rate (cir) used in the configuration of traffic shaping should be slightly below (2%-3%) the actual desired rate; this assures that queuing remains at the sub-interface rather than the physical interface. Note Bc and Be have the same behavior as the Ethernet shaping parameter given in sections 4.3.2 and 4.3.3 follow the same guidelines.

Frame Relay Unilink Example11

interface Serial0/0 :

bandwidth 1536 max-reserved-bandwidth 100 no ip address encapsulation frame-relay IETF tx-ring-limit 1 frame-relay lmi-type Cisco

11 Unilink examples in this document are intended to address methods for applying COS policies in environments with multiple WAN connections on a port. The examples are not addressing the mechanisms for keeping the traffic in separate routing domains such as VRF Lite (Contact the AT&T account team for information about VRF Lite).


interface Serial0/0.777 point-to-point ip address 10.55.254.125 255.255.255.252 bandwidth 768 no cdp enable frame-relay class shape768Unilink !Shape to half the T1 bandwidth which includes the

COS policy frame-relay interface-dlci 777 ! interface Serial0/0.890 point-to-point ip address 10.55.254.129 255.255.255.252 bandwidth 768 no cdp enable frame-relay class shape768Unilink !Shape to half the T1 bandwidth which includes the

COS policy frame-relay interface-dlci 890 map-class frame-relay shape768Unilink frame-relay cir 750000 !Shape to 2-3% less than port frame-relay bc 7500 frame-relay be 0 service-policy output COS !Apply policy to shaped sub-interface in this nested

arrangement

Note that separate map-class sections could be used for each sub-interface to provide different shaping rates or different COS policies for each PVC. This example uses the same shaping rate for both PVCs.

4.5 ATM Interfaces ATM policies are applied at the virtual connection (VC) or sub-interface level. In order to provide appropriate queuing at the VC level, use VBR-NRT VCs. The rate of the VC should normally be the same as the port speed (except for Unilink environments).

4.5.1 Sub-rate ATM Interfaces The configuration example below is based on an 20M sub-rate bandwidth on a DS3 ATM port. The COS policy is applied to the sub-interface. Notice that the vbr-nrt command is used to shape the connection to the sub-rate bandwidth, in this example it is 20M. This configuration is identical to the full-rate interface except the vbr is set lower. Refer to the Customer Router Configuration Guide for more details about sub-rate interface configurations.

interface ATM1/0 description ** AT&T DS3 ATM port: DNEC.xxxxxx ** no ip address atm scrambling cell-payload no atm ilmi-keepalive ! interface ATM0/1 point-to-point description ** To AT&T PE VPI/VCI 1/777 ** ip address 192.168.10.1 255.255.255.252 oam-pvc manage 0 encapsulation aal5snap


pvc att-per 1/777 vbr-nrt 20000 20000 1 !Shape the sub-interface to the sub-rate BW = 20M service-policy output COS !Apply the COS policy

4.5.2 ATM Interfaces with Unilink For Unilink ATM interfaces, simply configure the additional PVCs, each with an appropriate VBR-NRT rate and COS service policy applied.

interface ATM1/0 description ** AT&T DS3 ATM port: DNEC.xxxxxx ** no ip address atm scrambling cell-payload no atm ilmi-keepalive ! interface ATM0/1 point-to-point description ** To AT&T PE VPI/VCI 1/777 ** ip address 192.168.10.1 255.255.255.252 oam-pvc manage 0 encapsulation aal5snap pvc att-per 1/777 vbr-nrt 20000 20000 1 !Shape the sub-interface to the sub-rate BW = 20M service-policy output COS !Apply the COS policy ! interface ATM0/1 point-to-point description ** To AT&T PE VPI/VCI 1/888 ** ip address 192.168.10.5 255.255.255.252 oam-pvc manage 0 encapsulation aal5snap pvc att-per 1/888 vbr-nrt 20000 20000 1 !Shape the sub-interface to the sub-rate BW = 20M service-policy output COS !Apply the COS policy

Note that each PVC can have unique COS policies applied. This example uses the same COS policy for both PVCs.

4.5.3 IMA Interfaces Inverse Multiplexing for ATM (IMA) is the concept of bonding multiple T1/E1 circuits together to provide an aggregated larger circuit. The configuration example below is based on an IMA port with a 2xT1 implementation that provides an aggregate connection bandwidth of 3072 kbps into the MPLS core. The COS policy is applied to the IMA sub-interface. Refer to the Customer Router Configuration Guide for more details about IMA interface configurations.

interface ATM2/0 description ** AT&T T1, DHEC.xxxxxx ** !1st T1 in IMA-group 3 no ip address ima-group 3 interface ATM2/1 description ** AT&T T1, DHEC.xxxxxx ** !2nd T1 in IMA-group 3


no ip address ima-group 3 interface ATM2/IMA3 no ip address no atm ilmi-keepalive ima active-links-minimum 2 ! interface ATM2/IMA3.800 point-to-point description ** ePVC to ATT PE ** bandwidth 3072 ip address 10.51.254.125 255.255.255.252 no cdp enable pvc 1/800 vbr-nrt 3072 3072 1 !Shape to 3072kbps tx-ring-limit 3 max-reserved-bandwidth 100 oam-pvc manage 0 service-policy output COS !Policy applied to the sub-interface


5. Conclusion The Class of Service feature set is a powerful tool for assuring application performance and making the most efficient use of available bandwidth. This guide has covered the basic capabilities and application of these features. Refer to the Appendices for configuration examples. For more information and assistance in deploying Class of Service, contact your AT&T account team to engage the support of an AT&T Data Network Analyst (DNA).


Appendix A - AT&T COS Feature Description This section describes the operation of the COS features within AT&Ts IP networks. It provides the appropriate DSCP markings for each class, and describes the treatment of these classes across the service. It also describes the available profiles for allocating bandwidth across the classes on a specific port.

A customer can order either the 4COS model or the 6COS model. The 4COS model has COS1, 2, 3 and 4. COS2V and COS5 are only part of the 6COS model.

A.1 Class Markings Customers may mark traffic for any of six specific behaviors in the network. These behaviors are referred to as classes. We will describe the class markings using DSCP nomenclature. The markings below are for all 6 classes. The 4COS model is just a subset of these.

COS1 This class is indicated with DSCP Expedited Forwarding (EF) and is intended for real time applications such as interactive voice or interactive video.

COS2V This class is indicated with DSCP Assured Forwarding 41 (AF41) and is intended for delay sensitive applications that exhibit known or desired bandwidth restrictions.

COS2 This class is indicated with DSCP Assured Forwarding 31 (AF31) and is intended for time sensitive, mission critical, low bandwidth, bursty data applications.

COS3 This class is indicated with DSCP Assured Forwarding 21 (AF21) and is intended for time sensitive, mission critical, bursty data applications.

COS4 This class is indicated with DSCP default (default). It is also referred to as the best effort class and is intended for all bulk data applications and non-time critical applications.

COS5 This class is indicated with DSCP Assured Forwarding 11 (AF11). It is also referred to as the scavenger class and is intended for applications that do not support the business.

The Diff-Serv field in the IP header consists of 6 bits in the IP Type of Service (ToS) byte. Table A-1 shows how each possible marking is mapped into one of the AT&T defined classes. Some CPE can only support marking the 3-bit precedence field of the Type of Service byte rather than the full 6-bit DSCP field.

Class Marking Behavior COS1 EF, CS5, IPP5 Priority

COS2V AF41, CS4, IPP4 Policed Data COS2 AF31, CS3, IPP3 Bursty Data COS3 AF21, CS2, IPP2 Bursty Data COS4 Default 0, IPP0 Best Effort COS5 AF11, CS1, IPP1 Scavenger

Table A-1. AT&T Class of Service Markings


A.2 Class Behaviors The class markings tell the network how to differentiate customer traffic flows. This has an impact at network egress, network ingress, and across the core of the network.

COS1 is reserved for real time applications that require low delay and low delay variance. Applications mapped to COS1 can tolerate very little queuing delay. The queuing algorithm always checks the COS1 queue when it is time to transmit a packet. If traffic exists in this queue, it is forwarded before all other traffic. This assures that the delay for COS1 is kept to an absolute minimum. There is a danger associated with this sort of queuing behavior. If too much COS1 traffic arrives at a site, it would always be served above all other traffic and result in the starving of the other classes. To avoid this undesirable behavior, strict policing is implemented for COS1 traffic. When ordering COS for a site, the amount of bandwidth allocated to the COS1 queue is specified. If the amount of COS1 traffic exceeds this provisioned amount, the excess is immediately dropped. The amount of bandwidth allocated to the COS1 queue is calculated by multiplying the profiles percentage by the port speed. For example if the port is a 10M Ethernet and the COS1 percentage of the profile is 40% then the bandwidth allocated to COS1 is 4M. Unused COS1 bandwidth is available to the other classes that are configured.12

The default behavior for COS2V is to specify the queues bandwidth allocation and discard traffic exceeding this allocation. The queuing algorithm is different than COS1 where the scheduler is always checking the queue when its time to transmit, instead the traffic transmitted is determined by the bandwidth allocation. A policing function is implemented for COS2V to restrict bursting above the bandwidth allocation. This policing function differentiates this queue from the other data classes, COS2, COS3, COS4, and COS5. In the case of the other data classes, they are allowed to use the available bandwidth when not used by the other queues. Note that COS2V can be configured to behave like the data classes, this arrangement would be customized, for more information and assistance in deploying this arrangement, contact your AT&T account team to engage the support of an AT&T Data Network Analyst (DNA). When using the default behavior for COS2V the amount of bandwidth allocated to the COS2V queue is calculated similar to the COS1 allocation. With a 10M Ethernet port and the COS2V profile percentage of 50%, then you can expect to transmit up to 5Mbps of traffic within this class before you reach the policing function. Unused COS2V bandwidth is available to the other classes that are configured.

For the data classes, COS2 and COS3, the queuing algorithm allocates packets based on an allocation profile, which is ordered and provisioned for the port. The allocation determines how quickly and how often a particular class queue gets the opportunity to transmit on the egress line. If the service rate for a particular class is more frequent than the arrival rate of packets in that class, then there will be no congestion at all for that class. Conversely for a class where the service rate is slower than the arrival rate of traffic, then a queue will build. The intent is that customers will allocate applications to COS2 and COS3 such that they are never congested. This means that the amount of application traffic mapped to these classes is never more than the service rate of the class during congestion. If too much traffic is mapped to these classes, then the goal of maintaining consistent, low delay for these application types is not realized

12 When a port is combined with a CIR as would be the case with the IP Frame Relay or ATM service then the CIR is used instead of the port speed for the calculation of the COS1 bandwidth allocation. For example if the port speed was 1.536Mbps and the CIR for this particular connection was 768kbps and the percentage of COS1 in the profile was 50% then the bandwidth allocated to COS1 would be 384kbps.


The goal is that any traffic that will generate congestion is mapped to COS4, and that this traffic is bulk data oriented or does not have critical response time requirements. There may be a number of application types mapped to COS4.

COS4 is used for any traffic that will generate congestion and is bulk data oriented or does not have critical response time requirements.13

The default behavior for COS5 is that this class receives a very small amount of bandwidth allocation. This queue is intended to transmit only when the other classes have nothing to transmit. Applications that are not business related should be mapped into this class. If there is no other traffic on the line then traffic is this queue will be serviced.

There may be a number of application types mapped to COS4.

A.3 COS Profiles For each IP service connection, customers order a pair of COS profiles, one to control ingress policing and one to control egress queuing (as referenced to WAN). The profile specifies the amount of bandwidth reserved for each COS class. When ordering COS, the COS profile can be specified as simple or complex. The simple COS profiles provide a set of the most common COS profiles via a simple drop-down menu selection. Use of these profiles is suitable for the vast majority of enterprise needs and is highly recommended.

COS2 COS3 COS4 80% 10% 10% 40% 30% 30% 60% 30% 10%

Simple COS Profiles for the 4COS model*

COS2V COS2 COS3 COS4 COS5 20% 20% 20% 20% 20% 50% 30% 15% 5% 0% 25% 50% 15% 5% 5% Simple COS Profiles for the 6COS model*

* The simple profile selection menu provides these allocation percentages for the data classes, coupled with any of the available COS1 allocation values. In addition to these profiles, there are a small set of profiles that map all traffic to a single class, resulting in no differentiation of traffic types.

In some cases, bandwidth COS profiles are selected that do not utilize all six of the available class markings.

If a profile is selected that does not include COS2V or COS5, then traffic that has these markings will be treated as part of the COS4 class.

If a profile is selected that does not have COS1, then traffic with this marking is treated as part of the next lower class.

If a profile is selected that only recognizes a single class, then all traffic is treated as part of this class, regardless of its marking.

13 If there are applications that require controlled response time (i.e. COS2 or COS3 treatment) that also generate sufficient traffic to congest the port, then this suggests a capacity issue for the port.


If a complex COS profile is needed, it can be chosen by assigning specific bandwidth values to each class. Table A-2 outlines all of the possible bandwidth allocation combinations for the classes using the 6COS Model. There are approximately 23,500 combinations. Table A-3 provides all 25 possible combinations of profiles when using the 4COS Model.

A.4 COS Packages For each IP Service connection customers can order a COS Package. The Packages are divided up based on the amount of COS1 bandwidth allocated, see the left column of Tables A-2 and A-3 for the Package delineation. For example 6COS Profiles that have >50% COS1 bandwidth allocation will be consider in the MultiMedia-High Package. For the 6COS model you cannot order a Profile that is outside of the chosen Package. Furthermore if there is a Unilink connection using Ethernet, Frame Relay, or ATM access where each logical channel can have its own unique COS Profile, all COS Profiles of the LCs in the Unilink must be fro

Date post:	26-Sep-2015
Category:	Documents
Upload:	mentoria
View:	217 times
Download:	0 times

Cos

Documents