student guide alcatel lucent qos

Alcatel-Lucent C

onfidential for internal use only -- Do N

ot Distribute

2

Alcatel-Lucent Quality of Service (QoS)

This course is part of the Alcatel-Lucent Service Routing Certification (SRC) Program. For more information on the

SRC program, see www.alcatel-lucent.com/src

To locate additional information relating to the topics presented in this manual, refer to the following:

Technical Practices for the specific product

Internet Standards documentation such as protocol standards bodies, RFCs, and IETF drafts

Technical support pages of the Alcatel-Lucent website located at: http://www.alcatel-lucent.com/support

Alcatel-Lucent C


ot Distribute

3

Alcatel-Lucent C


ot Distribute

4

Alcatel-Lucent C


ot Distribute

5

Alcatel-Lucent C


ot Distribute

6

Alcatel-Lucent C


ot Distribute

7

Alcatel-Lucent C


ot Distribute

8

Alcatel-Lucent C


ot Distribute

9

Alcatel-Lucent C


ot Distribute

3FL-30639-AAAA-ZZZZA Edition 01

Alcatel-Lucent C


ot Distribute

Alcatel-Lucent C


ot Distribute

2








Alcatel-Lucent C


ot Distribute

Alcatel-Lucent C


ot Distribute

4

The core of the Internet and the Enterprise WAN is evolving. It is a place where customers‘ traffic must compete for

the bandwidth needed to properly complete network transactions. In many cases, several customers‘ flows will be

moved through the same device. The purpose of QoS is to take the guesswork out of the equation since ―best efforts‖

is often not good enough. Telecommunications carriers differentiate themselves from one another by their ability to

make a profit while providing a superior standard of service for their customers. For a networking equipment

manufacturer to compete successfully in this space, they must engineer a service-centered product that correctly

classifies customer traffic. Then, based on this classification, the equipment must deliver the Quality of Service (QoS)

indicated in the Service Level Agreement (SLA) between the carrier and their customers as traffic transits the WAN

Adding to the debate and according to research conducted by Forrester Research‘s Robert Whitely, December 16,

2005 entitled “The Three Myths Of Network QoS”

(http://www.forrester.com/Research/Document/Excerpt/0,7211,38075,00.html)

―After a decade of avoiding complex quality of service (QoS) attributes in an IP network, Forrester's clients are

showing renewed interest. Why? Because shifting to IP-based apps and converged multimedia networks can be

easily foiled by IP's best effort nature. But QoS is not that simple. Forrester has found that firms shouldn't

believe vendor hype and must avoid three pitfalls — that QoS is standard, easy to set up, and part of a static

configuration. To combat the problem, limit QoS to only where it's needed — like in the wide-area network

(WAN) — and use optimization appliances like those from [listed vendors] to avoid unnecessary QoS

requirements.‖

The conclusions are debatable since many vendors attest that QoS is never a PnP (Plug and Play) solution. Careful

network planning and a detailed SLA with rigorous QoS will future-proof the customer‘s traffic in a heterogeneous

WAN. In this course we will prove this point.

Alcatel-Lucent C


ot Distribute

5

With no QoS, it is possible that customers‘ traffic, beyond best path selection by routers, could be introduced to all

parts of the network without control. Clearly this is not optimal since not all customer traffic makes the same

demands of the network with what constitutes acceptable QoS. Anarchy may result as the network becomes

basically a path control network….first in, first out (FIFO) queuing of customer traffic.

Alcatel-Lucent C


ot Distribute

6

Alcatel-Lucent C


ot Distribute

7

Alcatel-Lucent C


ot Distribute

8

The first step to a QoS solution is to examine and define the natural demarcations in a network. The terminology can

be confusing because it is often vendor-specific or (worse) mixed and/or misused. Alcatel-Lucent simplifies the

terminology by defining Provide Edge (PE) and Customer Edge (CE) devices but even so, in order to achieve

consistency some definitions are proposed.

The edge of the network (whether provider edge or customer edge) is an area of the network that carries

traffic in a relatively high-bandwidth, congestion free and low latency, low Bit Error Rate (BER) part of the

network where no specific control for QoS is required. A collapsed or hierarchical Ethernet LAN or

Metropolitan Ethernet network would be a good example.

The core of the network will be defined as the high-speed, redundant transit area that carries aggregate

traffic that has been distributed in from a number of devices at the edge.

CE devices define points of aggregation of a single customers traffic before it is distributed into the core of

the network.

PE devices are more often than not in the core of the service provider‘s network. A PE is a device that

carries traffic, in the aggregate, often from several different customers CE devices. A PE device will peer on

other devices in the core of the network.

Note: Bit Error Rate (also called Bit Error Ratio) is the number of erroneous bits received divided by the total number

of bits transmitted.

Alcatel-Lucent C


ot Distribute

9

At this point we have established that there is a fair degree of sophisticated interplay between different ideas for an

effective QoS solution.

An effective QoS solution starts with methods of classifying customer traffic. There is usually enough information in

protocol data units to (at some layer) differentiate between different types of customer traffic.

Once the customer‘s traffic is classified, it must be marked for differentiated services using a protocol such as

802.1p, IP Precedence or IP DiffServ. This does not of itself give preferential treatment to customer‘s traffic, but it

allows QoS-aware devices to apply differentiated services to the customer traffic.

Alcatel-Lucent C


ot Distribute

10

An access interface is a natural demarcation on the router which defines an interface which ―sees‖ customer

traffic which may require classification and marking. On a CE, an access interface would typically see a

single customer‘s traffic. On a PE, the access interfaces would collectively see the traffic from several

different customers. Some of this traffic may already have been marked for QoS at the CE.

A network interface is an interface that faces the core. Marked up customer traffic will have services

applied to it in order to provide for QoS as needed.

The use of the terminology access and network for the ports on the routers is consistent. Whether a port is an access

port or a network port is reflective of its role in classifying/marking traffic (access port) and applying services

(network port).

P devices have network ports while PE devices can both have network ports and access ports.

As traffic flows through the network it is aggregated into ―flows‖. Flows in turn are aggregated into other flows.

The traffic may be re-marked several times at routers and layer 3 switches as it flows through the network. As the

customer‘s traffic might be encapsulated / tunnelled in other packets, this re-marking might not re-mark the original

user packets. In some cases this might not be desirable because the customer‘s QoS markings might be required for

some type of end-to-end flow from the customer‘s viewpoint.

Upstream refers to the direction of flow to the core of the network.

Downstream refers to the direction of flow towards the customer side of the network.

Alcatel-Lucent C


ot Distribute

11

Putting it all together, there are natural demarcations in the network where QoS can be assured by proper marking.

The locations where marking is applied is dependent on the characteristics of the traffic

Typically, at the access point, traffic is classified based on information contained within the protocol header. But it

can also be classified based on incoming port or circuit id. At the network point traffic is classified based on markings

in the protocol header.

Access port has a lot more parameters to mark the customer traffic and provide isolation by customer/SAP

Alcatel-Lucent C


ot Distribute

12

QoS is, of itself, a fairly straightforward idea. QoS issues can quite literally hit us close to home.

Here is a simple Case Study of QoS which illustrates some basic principles.

QoS issues can affect even small office home office (SOHO) networks. A SOHO router-firewall with integrated VoIP

phone adapter and wireless access point is pictured. This integrated device gives preference to the VoIP traffic when

there is congestion on the WAN (Internet) link. Thus, if a user on the LAN side of the router uses a potentially

bandwidth-consuming application like FTP, the QoS for the VoIP application is maintained. This is typical of many

commercial infrastructure VoIP solutions which are now becoming available to the home and office user. The

integrated router-firewall-VoIP adapter allows the user to connect existing analogue phone equipment to an IP

network. The VoIP call progresses between the phone adapter and a SIP (Session Initiation Protocol) server on the

Internet which works as a gateway to the PSTN (public switched telecommunications network) as well as a peer in a

pure VoIP network. The attraction for the VoIP provider is that they do not need to educate the users about how to

implement QoS for VoIP as it is the default logic for the device. The attraction for the user, of course, is superior

VoIP service.

The disadvantage is that there is no way to exert QoS on an existing legacy IP network such as the Internet. While

the integrated device does actually mark the IP packet for QoS, the markings will most probably be ignored by

devices in the Internet. This can be improved upon by having at least part of the TCP/IP network under the control of

the VoIP provider. This is examined on the next page.

Clearly the only way to assure end-to-end QoS is on a private network where all the devices along the path

understand the QoS markings.

Alcatel-Lucent C


ot Distribute

13

The MAC address and IP address of the customer premises equipment can be used as differentiators for QoS in the

service provider‘s network.

Another difference with this service is since the Internet Service Provider and the VoIP Service Provider are the same

company; QoS can be maintained, with VoIP calls getting preference over other calls at least within the ISP‘s

network. Unlike the previous example, the markings for QoS when the customer‘s traffic hits the Internet are

actually read and result in differentiated QoS. This has a lateral benefit to security of the VoIP network because QoS

is the weak point of any VoIP network. Interestingly some traditional phone companies are beginning to offer VoIP

services as a replacement to PSTN. No doubt they too are implementing QoS for their subscribers as part of their

solution.

Alcatel-Lucent C


ot Distribute

14

Alcatel-Lucent C


ot Distribute

Alcatel-Lucent C


ot Distribute

16

Quality of Service is, by its very nature, hard to quantify. It is the responsibility of the service provider to find some

way to assure QoS for the customer within the context of the SLA. Normal network conditions such as congestion, a

non-zero Bit Error Rate (BER) and sub-optimal, higher latency path selections as a result of alternate path selection

around network outages, may result in unacceptable QoS for the customer.

The provider will often rely on simple metrics such as bandwidth and packet loss for performance measurements.

While these are easy to quantify, they are not necessarily reflective of whether the performance of the network can

be tolerated by the customer‘s equipment. Understanding the customer‘s requirements is one thing. Finding some

way to transpose the customer‘s requirements onto the network is another.

Alcatel-Lucent C


ot Distribute

17

Using VoIP as an example:

Delay is caused by latency in the network, which is the time that it takes for a VoIP packet to be stored then

forwarded by an intermediate device. The effect is cumulative meaning that the cumulative effects of latency on

intermediate systems will eventually create unacceptable delay. A certain amount of delay is tolerable for a

telephone conversation. The accepted industry standard is 150 milliseconds (0.150 seconds).

Jitter is a measure of variable delay. Consistent delay is fairly easy for the human ear to adjust to, but if the delay

itself varies constantly and is not somehow compensated for in the phone network, the phone conversation will

quickly become intolerable. Most vendor equipment employ some type of anti-jitter buffer. When jitter becomes an

issue, they will implement an artificial delay of no more than 150 milliseconds (the acceptable delay threshold) while

it waits for packets to reassemble.

Packet Loss. A third accepted metric is packet loss. Some packet loss is acceptable and VoIP equipment will wait

only a finite period of time to assemble a packet into a phone conversation before it assumes the packet is lost.

Excessive packet loss will result in large empty spots in a conversation.

Alcatel-Lucent C


ot Distribute

18

Serialization /transmission delay is the time it takes to ―place the bits making up a packet on the wire‖ for

transmission out the router. It is calculated using the reference packet size and the transmission speed of the

physical media. Therefore, serialization delay depends on the clocking speed of the interface – a 1Gpbs link will have

lower serialization delay than a 100Mbps link. Serialization delay is a fixed form of delay in networks

Queuing delay is the time a packet spends at a queuing point before being processed or forwarded. Queuing occurs

when the router experiences congestion. Packets may be queued both at the ingress and egress of a router. Queue

delay is proportional to the size of the buffer and hence is variable.

Processing delay is the amount of time taken by the router to perform forwarding table lookups, encapsulation and

any other packet manipulation required before sending the packet to the egress port.

Propagation delay is the time it takes for a packet (signal) to travel across a link (wire) from one router to another.

It is dependent on the characteristics of the transmission media (different media have different propagation speeds)

and the distance between the routers.

Alcatel-Lucent C


ot Distribute

19

This diagram demonstrates the concept of jitter. Packets are arriving at the router at fixed intervals. If the

processing and queuing delay in the router was fixed, then packets would exit the router with the same interval and

hence, there would be no jitter. However, if the processing and queuing delay was variable then packets would exit

the router with varying interval and hence there would be jitter.

Thus, jitter is the variation in delay.

Negative jitter signifies that there is a period of time when packets are not transmitted out the router at the

expected interval. This may occur if there is significant queuing taking place.

Positive jitter signifies that packets are transmitted ―clumped‖ together, with a smaller than expected interval

between them. This may occur when packets that have been queued are subsequently transmitted together.

Jitter (sometimes even low levels) can affect the perceptual quality of video and voice applications. Jitter is often

measured peak-to-peak.

Alcatel-Lucent C


ot Distribute

20

Packet loss occurs when a router along the path discards a packet as a result of congestion (queue depth exceeded)

or packet corruption (unknown packets are often dropped). Packet loss can also result from faulty equipment or

signal degradation on the network media.

Alcatel-Lucent C


ot Distribute

21

Different applications have different bandwidth requirements to function properly – some being bandwidth intensive

others not, some having variable bandwidth needs, others requiring constant (fixed) bandwidth.

Alcatel-Lucent C


ot Distribute

Alcatel-Lucent C


ot Distribute

23

Alcatel-Lucent C


ot Distribute

24

For a QoS solution to work, the devices in the service provider‘s network must understand the markings that have

been applied to the customer‘s traffic in order to separate them into different flows. They need to be ―QoS Aware‖

What is the point of differentiating customer‘s traffic if the markings are ignored in the provider‘s network?

Traffic assigned to forwarding classes is placed into queues and the contents of the queues are output in a controlled

manner using schedulers.

The packet‘s forwarding class—along with whether it conforms to a policy or doesn‘t, determines how the packet is

queued and handled as it passes through the router.

Alcatel-Lucent C


ot Distribute

25

QoS involves mapping the appropriate bits in a protocol data unit header at OSI layer 2 or layer 3 to indicate

differentiating levels of service. This will involve a protocol, recognizing that the word ―protocol‖ means ―rules for

communication‖, it is important that devices in a QoS-aware network understand the same mappings of QoS

information in the customer traffic. While the QoS bits may be remapped at several natural demarcation points in

the network, QoS peer devices need to adhere to the same protocol in order to maintain a coherent QoS policy

throughout the network.

There are several competing mechanisms for differentiating customer traffic.

Alcatel-Lucent C


ot Distribute

26

Alcatel-Lucent C


ot Distribute

27

Alcatel-Lucent C


ot Distribute

28

If a network were to never experience congestion then a simple FIFO queue could be sufficient, and the network

could continue to function in a best effort manner. However, in reality, congestion is likely to occur at varying times

and at different points in the network, given that it would not be economical for the service provider to deploy much

more capacity than required under normal circumstances. The better solution is to make efficient use of the

available resources, and to ensure that the higher priority traffic get privileged access to these resources during

moments of transient congestion.

Hence, once traffic has been classified into different categories based on their requirements and characteristics, it

must be placed in different queues in order to give it differential treatment.

Alcatel-Lucent C


ot Distribute

29

Alcatel-Lucent C


ot Distribute

30

Congestion avoidance mechanisms serve to prevent or reduce the likelihood of congestion so as to minimize the

potential impact on traffic, and usually, to minimize the impact on the higher priority traffic.

One such mechanism is Explicit Congestion Notification in which a router marks packets when the buffer usage/depth

has reached a certain threshold. The intent is to notify the application (or higher level protocol, typically TCP) that

congestion is eminent in the network, and that it should (if possible) throttle back the transmission rate. ECN is

described in RFC 2481.

Another mechanism for implementing congestion avoidance is Random Early Detection (RED) and Weighted Random

Early Detection (WRED). Using RED a router will drop incoming packets with an increasing probability, as the average

utilization of the buffer increases. The router keeps track of the average buffer utilization. Each time a packet

arrives at the queue, the router determines the utilization at that time, and associated with the buffer utilization is

a probability value. This value determines the probability that the incoming packet will be dropped by the router. As

the current average buffer utilization increases, so does the probability that the incoming packet will be dropped.

WRED operates in the same manner as RED, however it enables the distinction of packets with different markings –

i.e. ‗in-profile‘ and ‗out-of-profile‘ packets. Therefore, with WRED, a router can start to discard ‗out-of-profile‘

packets with greater probability than ‗in-profile‘ packets for a given average buffer utilization.

Benefits of (W)RED

With (W)RED the more aggressive flows will be ―penalized‖ more often than the rest, as most of the queue occupancy

will be with packets from those flows. Thus, a level of fairness is maintained even when flows with different

characteristics share the same queue.

Also by randomly discarding packets, not all flows experience packet drops simultaneously. Given that many flows

are TCP based, this means that the simultaneous throttling back of transmission rates from different TCP flows is

reduced, thereby ensuring that the network remains adequately utilized.

Alcatel-Lucent C


ot Distribute

31

Strict Priority and Round Robin are example of simple schedulers, which service queues in order, without regard to

the amount of traffic transmitted from them.

Fair Queuing is an example a adaptive schedulers, which dynamically adapt the allocation of servicing time to each

queue based on the amount of traffic (e.g. number of bits) recently transmitted from that queue.

Schedulers can specify the minimum rate at which a queue can be serviced. They can also dictate the maximum rate

at which a queue is serviced thereby providing rate shaping. Different restrictions can be imposed on different

queues depending on the scheduler‘s algorithm.

Alcatel-Lucent C


ot Distribute

32

All queues have a relative priority. Packets in the Priority 1 queue are always serviced before packets in the Priority

2 queue, which are always serviced before packets in the Priority 3 queue, etc….. When the scheduler services a

queue, it does so at the rate of the underlying link‘s capabilities.

Thus the scheduler may be servicing queue 5 (which means that queues 1 to 4 are empty), but as soon as a packet

arrives at queue 2, the scheduler will stop servicing queue 5 and will service queue 2. It will only revert to servicing

queue 5 once it has emptied queue 2. If, while the scheduler is servicing queue 2, packets arrive at queue 1, it will

stop servicing queue 2 and will start to service queue 1. As is becoming evident, with a Strict Priority scheme it is

possible to starve traffic in lower priority queues, should there be a continuous amount of higher priority traffic using

100% of the links bandwidth.

To ensure that higher priority traffic does not starve lower priority traffic, careful policing and/or shaping must be

performed upstream to ensure that the incoming rate of the higher priority traffic never consumes the link‘s entire

capacity.

Alcatel-Lucent C


ot Distribute

33

With Round Robin schedulers there is no distinction between the queues. The scheduler services each queue, one at a

time, for the same amount of time. For example, if the scheduler is set to process one packet per ―queue visit‖, then

it will first forward one packet from queue 1, then one packet from queue 2, then one packet from queue 3, etc….,

going back to queue 1 after it has serviced queue 6. If a queue is empty when the scheduler ―visits‖ it, then it simply

skips that queue.

With a Round Robin scheduler each queue gets an equal amount of servicing time (though empty queues are skipped),

thus the overall servicing rate obtained by any one queue greatly depends on the number of other queues containing

packets to transmit, making it difficult enforce delay bounds for particular queues.

A Weighted Round Robin scheduler can be used to help provide certain queues with a higher servicing rate (and thus

lower delay), by allowing a queue to receive more frequent ―visits‘ from the scheduler. For example, queue 1 may be

given a greater weight and be serviced at every other scheduler visit. That is the servicing sequence would be: 1, 2,

1, 3, 1, 4, 1, 5, 1, 6, etc… The result is that queue 1 receives half of the servicing rate. However, even with Weighted

Round Robin, the randomness in packet size distribution can still lead to problems with jitter and long-term

bandwidth control.

Alcatel-Lucent C


ot Distribute

34

With WFQ, queues are serviced at the bit level, thus providing fairness in sharing the servicing rate between the

queues, as well as fairness between different flows within the same queue. The WFQ scheduler determines the

sequence in which to service the queues, so that they each meet their long-term average bandwidth targets. This

means that the queues are not necessarily serviced in the same order

The WFQ scheduler allocates a fraction of its servicing rate (i.e. usually the underlying link‘s rate) to each queue,

according to the weight factor associated with each queue. Thus, queues can be differentiated by assigning them

different weights, with higher priority queues (e.g. for traffic with stricter latency requirements) given a greater

weight, for example. The weight assigned to a queue could be based on the queue‘s parameters, such as its size.

When queues are empty the servicing rate which they would have used, can be redistributed amongst the active

queues, according to their relative weights.

Alcatel-Lucent C


ot Distribute

35

Policing and shaping use a metering function to determine whether incoming packets are to be considered ‗in profile‘

or ‗out of profile‘.

For example the measure of how ―assured‖ an Assured Forwarding Class is, is the efficacy of the policing mechanisms

in place to ensure that excess (ie: non-conforming) traffic does not congest the network.

This does not mean that non-conforming traffic is always discarded. ―Shaping‖ tries to find gaps in the traffic flow

of conforming traffic and plugs these gaps with non-conforming traffic that would otherwise be dropped.

Alcatel-Lucent C


ot Distribute

36

Policing and marking are used to prevent transient burst of traffic of a given class from causing congestion and

affecting other traffic further on in the network, downstream from the router where policing and marking occurs.

They are used to ensure that a ‗mis-behaving‘ traffic class does not adversely affect other ‗behaving‘ traffic, by only

penalizing the ‗mis-behaving‘ traffic.

The single bucket , single policer mechanism allows traffic some degree of burst, but will discard packets as soon as

that burst tolerance is exceeded.

The single rate, 3 colors, and two rate, 3 colors mechanisms allows traffic to burst. If the burst tolerance is

exceeded, the packets are marked or colored instead of being dropped. The change in coloring signifies that the

packet is to be considered of lower priority.

Alcatel-Lucent C


ot Distribute

37

With the single bucket metering function, traffic is allowed some degree of burstiness, but its transmission rate is

restricted to a lower long term average. That is, the traffic rate of incoming traffic can peak to a rate higher than

the servicing rate for a limited time, dictated by the size of the bucket (i.e. a maximum burst size). While traffic is

bursting at a higher rate than the servicing rate the bucket fills up. If the incoming traffic rate drops back down to a

lower level before the bucket overflows, the bucket will start to empty, and no packets will be dropped. However, if

the traffic bursts for a long enough time, the bucket will overflow, and packets will be dropped.

Thus, traffic is policed (rate limited) at the servicing traffic rate, and has a burst tolerance equal to the maximum

bucket size.

Alcatel-Lucent C


ot Distribute

38

With the Single Rate Three Color Marker (srTCM) mechanism packets are marked as either green, orange or red depending on whether their burst has exceeded certain parameters or not. The parameters associated with the srTCM mechanism are:

Committed Information Rate (CIR): The rate at which the traffic in the ‗buckets‘ is serviced.

Committed Burst Size (CBS): The maximum amount of buffering allowed in the ‗first bucket‘. (i.e. the depth of the bucket)

Excess Burst Size (EBS): The maximum amount of buffering allowed in the ‗second bucket‘. (i.e. the depth of the bucket)

A packet is marked green if it doesn't exceed the CBS, orange if it does exceed the CBS, but not the EBS, and red otherwise.

Thus, if the incoming traffic rate is less than the CIR, packets will always be marked green. If the incoming traffic exceeds CIR, the first few packets will be marked green, but if this rate is sustained, such that the depth of the first bucket is exceeded (CBS is exceeded) then the ―overflowing‖ packets will be marked orange. If the incoming traffic rate continues to exceed the CIR for a prolonged time, eventually the second bucket may become fill (EBS exceeded) and the ―overflowing‖ packets will be marked red.

The way in which routers treat packets of different colors depends on the implementation on each router. For example, orange packets may be treated as ‗best effort‘ while red packets may be discarded.

The srTCM is useful, for example, for ingress policing of a service, where only the length, not the peak rate, of the burst determines service eligibility.

There are two modes of operation for the srTCM metering function – Color-blind and Color-aware. In the Color-Blind mode, the meter assumes that the packet stream is uncolored. In the Color-Aware mode the meter assumes that some preceding entity has pre-colored the incoming packet stream so that each packet is either green, orange, or red.

Alcatel-Lucent C


ot Distribute

39

Alcatel-Lucent C


ot Distribute

40

With the Two Rate Three Color Marker (trTCM) mechanism packets are marked as either green, orange or red depending on whether their burst has exceeded certain parameters or not. The parameters associated with the trTCMmechanism are:

Committed Information Rate (CIR): The rate at which the traffic in the ‗first buckets‘ is serviced.

Committed Burst Size (CBS): The maximum amount of buffering allowed in the ‗first bucket‘. (i.e. the depth of the bucket)

Peak Information Rate (PIR): The rate at which the traffic in the ‗second bucket‘ is serviced.

Peak Burst Size (PBS): The maximum amount of buffering allowed in the ‗second bucket‘. (i.e. the depth of the bucket)

The PIR must be equal to or greater than the CIR. The PBS and the CBS and are measured in bytes and both of them must be configured to be greater than 0.

A packet is marked red if it exceeds the Peak Information Rate (PIR). Otherwise it is marked either orange or green depending on whether it exceeds or doesn't exceed the Committed Information Rate (CIR).

Thus, if the incoming traffic rate is less than the CIR, packets will always be marked green. If the incoming traffic exceeds CIR but is within PIR, the first few packets will be marked green, but if this rate is sustained, such that the depth of the first bucket is exceeded (CBS is exceeded) then the ―overflowing‖ packets will be marked orange. If the incoming traffic rate exceeds the PIR the packets will be marked orange and if the rate continues to exceed PIR, such that the depth of the second bucket is exceeded (PBS exceeded), the ―overflowing‖ packets will be marked red.

The way in which routers treat packets of different colors depends on the implementation on each router. For example, orange packets may be treated as ‗best effort‘ while red packets may be discarded.

The trTCM is useful, for example, for ingress policing of a service, where a peak rate needs to be enforced separately from a committed rate.

There are two modes of operation for the trTCM metering function – Color-blind and Color-aware. In the Color-Blind mode, the meter assumes that the packet stream is uncolored. In the Color-Aware mode the meter assumes that some preceding entity has pre-colored the incoming packet stream so that each packet is either green, orange, or red.

Alcatel-Lucent C


ot Distribute

41

Alcatel-Lucent C


ot Distribute

42

Alcatel-Lucent C


ot Distribute

43

Standard IP routing is based on shortest path selection algorithm. Thus depending on the network topology and

costing strategy, it is very likely that certain paths or links will be used to route most of the network‘s traffic. In

order to achieve load balancing or obtain some control over the path chosen to route traffic, traffic engineering is

needed.

Path selection can be modified by using QoS-based routing in which the path selection algorithm considers metrics

other than only link costs. For example, the amount of bandwidth available on links could be used to determine the

best path through the network. Thus when a particular link becomes saturated, a path excluding that link will be

used. Implementing QoS-based routing would require that the routing protocol used, include the advertisement of

―resource‖ metrics such as bandwidth, and that the routers run modified version of the shortest path first algorithm

to take into account the additional information.

Traffic Engineering can also be achieved using MPLS with RSVP-TE which gives network operators the option to

explicitly dictate the path taken to route certain traffic. This topic is addressed in the course ―Alcatel-Lucent MPLS‖.

Alcatel-Lucent C


ot Distribute

44

Link Fragmentation and Interleaving (LFI) provides the ability to interleave high priority traffic within a stream of

fragmented lower priority traffic. This feature helps avoid excessive serialization delays to high priority, delay-

sensitive traffic over a low-speed link. This can occur if traffic type shares a link with lower priority traffic that

utilizes much larger frames. Without this ability, higher priority traffic must wait for the entire packet to be

transmitted before being transmitted, which could result in a delay that is too large for the application to function

properly.

For example, if VoIP traffic is being sent over a DS1 or fractional DS1 which is also used for Best Effort Internet

traffic, LFI could be used so the small (usually 64-128 Byte) VoIP packets can be transmitted between the

transmission of fragments from the lower priority traffic. Without LFI, if the Best Effort packet was 1500 bytes, on a

DS1 link (64kbps), the VoIP packet could be delayed up to 187.5ms.

Looking at the diagram above:

1. A low priority frame arrives in the low priority queue. At this particular instant, there are no packets in the high

priority queue so low priority frame is de-queued and passed to the fragmentation mechanism.

2. The original packet is divided into ‗n‘ fragments based on the size of the packet and the fragment threshold

configuration.

3. The fragments are then transmitted out the egress port.

4. After the transmission of the fragments has begun, high priority frames arrive in the high priority queue.

5. The transmission of the remaining fragments stops and the high priority packets are transmitted out the egress

interface. Note that high priority packets are not fragmented.

6. When the high priority traffic is transmitted, the remaining lower priority fragments are then transmitted.

The 7750 SR supports LFI on Multi-link Point-to-Point bundles. The 7450 ESS does not support LFI.

Alcatel-Lucent C


ot Distribute

45

Alcatel-Lucent C


ot Distribute

46

Alcatel-Lucent C


ot Distribute

josemac

PRINT

Alcatel-Lucent C


ot Distribute

josemac

Revised

48

With the Integrated Service model QoS guarantees are provided on a per flow basis. While this model enables every

flow to be treated individually and receive the exact treatment it needs, it results in the need for routers to

maintain, manage and allocate resources for thousands of individual flows, thereby adding much complexity in

implementation.

Alcatel-Lucent C


ot Distribute

49

Alcatel-Lucent C


ot Distribute

50

The packets from individual microflows are classified at the edge routers into a set of Behavior Aggregates. Thus,

routers in the core of the network only need to understand a handful of Behavior Aggregates, or macroflows.

Resource allocation, such as queuing and scheduling of packets only need to be done per Behavior Aggregate, or class

of packets.

Microflow: A single instance of an application-to-application flow of packets which is identified by source address,

source port, destination address, destination port and protocol ID.

Macroflow: Collection of packets with the same classification (i.e. same DSCP value). Also known as Behavior

Aggregate.

Alcatel-Lucent C


ot Distribute

51

Expedited Forwarding

According to RFC 2598:

―The EF PHB can be used to build a low loss, low latency, low jitter, assured bandwidth, end-to-end service through

DS domains. Such a service appears to the endpoints like a point-to- point connection or a "virtual leased line".

―The EF PHB is defined as a forwarding treatment for a particular diffserv aggregate where the departure rate of the

aggregate's packets from any diffserv node must equal or exceed a configurable rate.‖

Therefore the queue corresponding to EF packets should be kept small, and at a low occupancy.

Assured Forwarding

According to RFC 2597:

―The AF PHB group provides delivery of IP packets in four independently forwarded AF classes. Within each AF class,

an IP packet can be assigned one of three different levels of drop precedence.‖

―Within each AF class IP packets are marked (again by the customer or the provider DS domain) with one of three

possible drop precedence values. In case of congestion, the drop precedence of a packet determines the relative

importance of the packet within the AF class. A congested DS node tries to protect packets with a lower drop

precedence value from being lost by preferably discarding packets with a higher drop precedence value.‖

Alcatel-Lucent C


ot Distribute

52

Alcatel-Lucent C


ot Distribute

53

The diagram represents a summary of the terminology found in the RFC 2475

Alcatel-Lucent C


ot Distribute

54

Alcatel-Lucent C


ot Distribute

55

Alcatel-Lucent C


ot Distribute

56

Multi-Field Classifiers are used to map traffic to forwarding classes. We will configure these in a later Section but

here are some examples of service ingress classifiers:

IP or application information (OSI Layers 3 – 7)

Source IP address/prefix

Destination IP address/prefix

Source port/range

Destination port/range

Protocol type (TCP, UDP, etc.)

DSCP value

IP fragment

Source MAC, Destination MAC or other OSI Layer 2 criteria:

IEEE 802.1p value/mask

Source MAC address/mask

Destination MAC address/mask

EtherType type

IEEE 802.2 LLC SSAP value/mask

IEEE 802.2 LLC DSAP value/mask

IEEE 802.3 LLC SNAP PID value

IEEE 802.3 LLC SNAP OUI zero or non-zero value

Alcatel-Lucent C


ot Distribute

57

Alcatel-Lucent C


ot Distribute

58

Alcatel-Lucent C


ot Distribute

59

Alcatel-Lucent C


ot Distribute

60

Alcatel-Lucent C


ot Distribute

61

Alcatel-Lucent C


ot Distribute

62

In summary, remember that DiffServ marking is not a traffic conditioning measure in and of itself, but indicates a

discrimination mechanism that may be used to alter the per-hop behaviours (PHBs) of the traffic at network ingress

and egress points as it moves through macroflows called Forwarding Classes.

Alcatel-Lucent C


ot Distribute

63

All routers pictured are DiffServ-capable.

At Router A

Router A is a marker. It can mark traffic using a variety of classifiers. Recognizing that SNA uses specific SAPs, the

mainframe traffic‘s DSCP is marked using its SAP as a classifier. The FTP traffic is marked using TCP port numbers as

a classifier.

At Router B

Router B is a marker. It can mark the DSCP for the site-to-site VPN traffic using protocol number as a classifier since

the IPSec VPN uses protocol number 50. SIP signaling determines RTCP and RTP port numbers dynamically.

Alcatel-Lucent C


ot Distribute

64

Router B and C are two routers within a DS Domain. The connection between these two routers carries several

microflows. Each microflow carries a single instance of an application-to-application flow of packets which is

identified by source address, source port, destination address, destination port and protocol ID. As has been seen,

the traffic which constitutes these microflows can clearly benefit from differentiated services since their demands

for QoS are completely different.

Although specific mechanisms of achieving the goal of differing QoS for these microflows will be discussed in a later

module, some general points can be made:

Routers B and C, either on separate instance of customer traffic, or an aggregate (BA) will apply differing forwarding

behaviours known as ―Per Hop Behaviours‖ (PHBs) to the traffic. In order that the traffic properly conform to the

policy expressed by the TCA and (by extension) the SLA (see definitions), some policing is expected whereby DS-

capable systems known as droppers will discard packets within the data stream. Similarly, some packets may be

delayed by a shaper. Shaping is the process of delaying packets within a traffic stream to cause it to conform to

some defined traffic profile.

For example, mission-critical packets could be encoded with a DSCP that indicated a high bandwidth, 0-frame-loss

routing path. Interactive video conferencing data and all data from the CEO's computer may carry the same

requirement and be aggregated with mission-critical packets. E-mail and web browsing data could be coded with a

DSCP indicating routine traffic handling with minimal packet drops. The DS-compliant boundary router would then

make route selections and forward the packets accordingly as defined by network policy and the PHBs the network

supports. The highest class traffic would get preferential treatment in queuing and bandwidth while the lower class

packets would be relegated to less preferential service.

Differentiated Services Implementation

While the information in the slide might seem self-evident it is worth emphasizing that a successful DSCP

implementation entails end-to-end involvement across the whole network. It might mean a significant upgrade in

equipment both by the customer and the service provider.

Each natural network demarcation point may determine DSCP marking to each packet.

Alcatel-Lucent C


ot Distribute

65

With DSCP, every router or layer 3 switch is part of an end-to-end solution.

Routing is no longer a best path decision made solely on routing metrics and administrative distances of interior gateway protocols, forwarding follows DSCP prioritization rules. DS-compliant routers and layer 3 switches may make delay/drop decisions on lower class packets in order to assure delivery of higher-class packets. If available, higher quality, faster and alternate routes may be chosen for packets with higher classifications.

Marking entities can change the DSCP marking both on network egress and service ingress based on upstream and downstream marking rules contained in the SLA and TCA ensuring a coherence of packet-marking integrity within the network.

Additionally, Differentiated Services may trigger accounting mechanisms at network boundaries to track service usage for quality level monitoring, auditing, content filtering, billing purposes and other value-added services.

Referring to the diagram, the competing needs of these users are best served by effective classification followed by marking at the CE. Only then will the PE be able to properly answer these questions.

Q: Do the SIP Server, Softphone, VoIP phones, PC and terminal all require the same QoS?

A: Unlikely, but can QoS issues such as jitter, packet loss, delay and bandwidth be answered with differentiated services at the PE? Does the device have the granularity and range of options required for adequate QoS? These are questions that have no easy answer and must be part of a carefully designed, end-to-end QoS solution.

Alcatel-Lucent C


ot Distribute

66

The reason we classify traffic is in order to ascribe it to the correct forwarding class. Our definition of forwarding

classes has been a bit nebulous and simple up to now. While we have agreed that forwarding classes effectively

categorize traffic in the core of the network we haven‘t touched on an important point.

First, though, let‘s recall the definition of a microflow:

“A single instance of an application-to-application flow of packets which is identified by source address,

source port, destination address, destination port and protocol ID.”

Note:

It’s interesting that the RFC that defines DiffServ (RFC 2475) doesn’t even define a forwarding class. We’re

left to intuit that it would be difficult or impossible for a DiffServ network to distinguish between large

numbers of individual microflows such as the VoIP microflow we used as an example in our walk-through.

In this case, our intuition would be correct. Forwarding classes exist as a practical alternative. It is much

easier for the core of a DiffServ network to distinguish between a small number of forwarding classes (8 on

the SR/ESS) rather than individual microflows.

Forwarding classes are essentially macroflows.

Alcatel-Lucent C


ot Distribute

67

References

―An Architecture for Differentiated Services‖ – RFC 2475

―Assured Forwarding PHB Group‖ – RFC 2597

―An Expedited Forwarding PHB‖ – RFC 2598

―A Framework for Integrated Services Operation over Diffserv Networks‖ – RFC 2998

―Random Early Detection Gateways for Congestion Avoidance‖ – IEEE/ACM Trans. On Networking vol. 1, No-4, August

1993

―Explicit Allocation of Best-Effort Packet Delivery Service‖ – IEEE/ACM Trans. On Networking, vol. 6, no-4, August

1998. (RIO)

Alcatel-Lucent C


ot Distribute

Alcatel-Lucent C


ot Distribute

69

Alcatel-Lucent C


ot Distribute

70

There are three customers: Purple, Orange, and Blue. Each customer has two sites (A and B). Each customer

subscribe to VLL services from the network service provider to communicate between their sites.

Service Ingress on Router N1

At N1, purple and orange traffic arrive through two different service interfaces of an MDA. As the traffic enters the

ingress forwarding complex, incoming packets of purple and orange traffic are classified into one or more forwarding

classes, as determined by SAP-ingress QoS policies for

purple and orange traffic. The mapping of traffic to forwarding classes is based on multi-field classification rules in

the SAP-ingress QoS policy.

The classified packets are then queued according to the SAP that they ingress and their forwarding classes.

Therefore, the purple traffic is queued separately from the orange traffic on the ingress IOM. Within purple or

orange traffic packets can be queued according to their forwarding classes. Queue allocations for the forwarding

classes are determined by the SAP ingress QoS policy.

Network Egress on Router N1

Because purple and orange packets belong to the VLL service and come from the service ingress, their forwarding

classes and profile status (in/out) are translated into QoS markings (EXP, DSCP, or dot1p bits) in their tunnel headers.

The mapping of forwarding classes into QoS markings in tunnel header is determined by the associated network QoS

policy. Because both purple and orange traffic from N1 and flow towards N2 all the packets (regardless of whether

they are purple or orange) that belong to the same forwarding class are queued together at the N1

network egress.

Alcatel-Lucent C


ot Distribute

71

Network Ingress on Router N2 (similar on Router N3)

At N2, purple and orange packets arrive through the network interface. Based on tunnel headers, the packets are

classified according to their forwarding classes. The mapping of the tunnel header to forwarding class is specified by

the associated network QoS policy at N2. Because the same MDA level buffer pool is used to queue all the network

ingress traffic of an MDA in a node, purple and orange packets are queued together according to their forwarding

classes. Because blue packets arrive at N2 through the service ingress, they are queued in isolation from purple and

orange packets. The queued packets are serviced by VoQ scheduler and sent towards the fabric core.

Network Egress on Router N2 (Similar on router N3)

Because purple packets come from the network ingress, their tunnel headers are remarked only if the remark flag in

the associated network QoS policy is enabled.

Service Egress

The SAP-egress QoS policy defines queuing and packet marking based on the forwarding classes. Packets are queued

according to their SAP and forwarding class. The queued packets are serviced by the egress VoQ scheduler and sent

towards the egress port for delivery to the customers.

Alcatel-Lucent C


ot Distribute

72

Classification and queuing of packets (based on Forwarding Class) occur at the ingress SAPs, where up to 32 queues

can be defined per SAP. The queues are scheduled to the Switch Fabric using either Default (single-tier) mode or

hierarchical (multi-tier) mode scheduling.

The same queuing and scheduling process occurs at the ingress of a network port.

Alcatel-Lucent C


ot Distribute

73

Alcatel-Lucent C


ot Distribute

74

Traffic Classification

Ingress traffic can be classified into one of eight internal forwarding classes. Each forwarding class can have one or

more queues associated with it. Each queue has user configurable parameters that allow traffic within the queue to

be treated differently.

Buffer Management

Buffer space can be configured and assigned to each queue.

Scheduling

A scheduling mechanism controls how traffic is dequeued.

Rate limiting

Rate limiting is performed as part of the queuing mechanism and works within the context of buffer management.

Alcatel-Lucent C


ot Distribute

75

The three major system components of the 7x50 are:

Media Dependant Adapter (MDA)

Input/Output Module (IOM)

Switch Fabric/Central Processor Module (SF/CPM)

All traffic management tasks (queuing, buffer management, scheduling shaping and policing) are performed on the

IOM. Not having these functions performed on the SF/CPM, enables the 7x50 to scale. Furthermore, as the traffic

management functions are performed on the IOM, this allows for consistency in configuring the TM features

regardless of the type of MDA.

Alcatel-Lucent C


ot Distribute

76

QoS policies can be applied on service ingress and egress as well as on network ingress and egress. What type of QoS

policies are applied to the traffic as it is moved across the router in order to avoid or manage congestion and to

schedule traffic flow through the device? These, too, are QoS policies and there are some standard, well known

mechanisms used to deal with these issues.

We have defined the service and network ingress and egress. In defining these, we have implied that QoS policies

will be needed to manage traffic at these parts of the network.

QoS Service Ingress Policy

The QoS Service ingress policy defines how traffic arriving at a SAP is classified and queued before being forwarded

to the fabric.

QoS Service Egress Policy

The QoS Service Egress Policy defines how traffic is to be serviced as it exits a service and before being forwarded to

a SAP

Network Policy

The Network policy defines how traffic arriving at a port is classified, based on its marking, and defines how traffic is

to be marked before exiting a port.

Network Queue Policy

The Network queue policy defines the queue and their associated parameters at network ports, and defines the

mapping of traffic ingressing and egressing network ports to specific queues.

Slope policy

The slope policy defines default buffer allocations and WRED slope definitions

Scheduler policy

The scheduler policy used to configure hierarchical virtual schedulers (H-QoS)

Alcatel-Lucent C


ot Distribute

77

The entities to which the various QoS policies are applied, and the function of these policies is summarized in the

following slides.

Alcatel-Lucent C


ot Distribute

78

Alcatel-Lucent C


ot Distribute

79

Alcatel-Lucent C


ot Distribute

80

We have completed a broad introduction on the principles of QoS.

Methods of classifying, marking and allocating resources through traffic shaping, queuing algorithms, scheduling, and

bandwidth reservation were discussed in a standards-based approach and will be expanded on in the remaining

modules.

Alcatel-Lucent C


ot Distribute

81

Alcatel-Lucent C


ot Distribute

82

Alcatel-Lucent C


ot Distribute

83

Learning Assessment Answers:

1. As a first step, traffic must be classified so that routers can allocate the resources necessary to give the traffic

proper treatment (i.e. queuing, scheduling and bandwidth allocation).

2. A, B and C

3. Delay, Jitter and Packet Loss

4. A, B, C

5. Policing discards non-conforming packets (i.e. that exceed their contracted Committed rates), while shaping

buffers traffic and schedules them out at the contracted rate.

Alcatel-Lucent C


ot Distribute


Alcatel-Lucent C


ot Distribute

2








This module will be an in-depth examination of the principles of the different input classification options that must

be implemented in order to properly differentiate customer traffic at the access interface.

Furthermore, methods to properly mark services for correct differentiation in Forwarding Classes between peers in

the core of the carrier‘s network will be discussed.

Alcatel-Lucent C


ot Distribute

3

.

Alcatel-Lucent C


ot Distribute

Alcatel-Lucent C


ot Distribute

5

The customer‘s traffic needs are as varied as the types of application are diverse.

Imagine that routers C and D represent respectively a PE and CE which connect a branch office in the customer‘s

network and that router A and B represent respectively a CE and a PE at the Headquarters network. There are many

services hosted on this network.

For example:

A user with a VoIP softphone makes calls to other VoIP handsets in the customer‘s network as well as to

outside phones. Because this is a softphone, the user also has other applications on the PC which need to

compete for bandwidth on the local LAN connection.

Regular VoIP handsets make calls to other VoIP handsets in the customer‘s network as well as to outside

phones.

A dumb terminal (or a PC running a terminal emulation) is used for data entry to the mainframe in the HQ

network.

At the branch and in the HQ network VoIP SIP servers signal each other for call setup information as well as

handle call progression between the two sites.

A user on a PC in the branch office downloads a file from a file server in the HQ network.

A site-to-site IPSec VPN is established between router D in the branch and router A at the HQ network. The

VPN is used to encrypt all traffic between sites except that which is noted above.

Alcatel-Lucent C


ot Distribute

6

In the initial estimate, it would seem that the QoS issues are trivially simple. They can be encapsulated in the simple

question, ―What is critical?‖ The answer being that the so-called ―critical‖ traffic should be given the first priority.

The logical extension to this is that we only need to establish different levels of importance to the data traffic and

this will determine its priority. Simply put (and from the service provider‘s perspective) ―critical‖ traffic is the

traffic from which revenue is generated!

In reality, when the customer traffic arrives at the access ports on the CE device, it may already have been marked

with DSCP by customer premises equipment and in some cases also with 802.1p. Also, not all the traffic can be

properly classified at the CE. For example, the site-to-site VPN is established from the customer router, too late for

classification on the access ports at the CE. In the diagram above, the CE will only see VoIP, mainframe and file

transfer traffic initiated from the ―inside‖.

At the PE, what traffic has already been classified and marked by the CE? Ideally, the only traffic that the PE will be

responsible for classifying and marking is the Site-to-Site VPN traffic since the VoIP, file transfer and mainframe

traffic will already be marked. The PE may need to re-mark the code points on the traffic from the CE depending on

the SLA and TCA in the DS domain with DS-capable peers.

It is clear at this point that the PE will not have:

the infinite bandwidth,

infinitesimally small delay, and

zero packet loss

that would be necessary to avoid the decision as to prioritizing and predictive bandwidth utilization with its

peers.

Alcatel-Lucent C


ot Distribute

7

1. The softphone application‘s marker on the user‘s workstation engineers an IP packet with the ToS bits set to

indicate high priority. The NIC on the workstation has a QoS driver installed.

Recap:

Alcatel-Lucent C


ot Distribute

8

Alcatel-Lucent C


ot Distribute

9

The QoS-aware switch notes that the ToS bits have been set and will write these bits into the priority bits in the Tag

Control Information (TCI) field, per the 802.1p protocol, into the user priority bits 802.1Q.

In this example, the softphone has set the DSCP to 46 (101110). It‘s useful to remember that the switch can only

count up to 7 since it has only 3 finger, the User Priority bits. For example, on an OmniStack 6300, CoS = 5 indicates

a high priority frame. These frames will be moved before frames with a lower CoS. Since the switch can‘t directly

correlate DSCP to CoS (6 bits don‘t fit into 3), the default CoS-to-DSCP mapping for this CoS will be changed to 40

(101000) See the table on the next page.

Effective QoS works on a trust model. The assumption being made is that the switch (or the router…‖D‖ in this

example) trusts the markings in the IP packet placed there by the end system. If the switch trusts the VoIP softphone

device, then the packets do not need to be reclassified and, perhaps, re-marked. If the switch does not trust the end

system, the packets entering the switch port from the end system will need to be reclassified to determine the

correct level of QoS. Vendors have multiple mechanisms for classification, with many vendors boasting of near-wire

speed in their algorithms. This is an important distinction since switches (for example) would prefer to be simply

frame in / frame out devices. That they have to consult their FIB (forwarding information base) to make their

forwarding decision is a given. But adding the ability to classify traffic for QoS and give priority forwarding for

critical traffic while also marking frames imbues them with a whole extra layer of sophistication.

As a general rule, switches and routers do not, by default, trust end systems‘ markings for QoS. This must be set up

on a port-by-port basis as needed.

The switch is a marker. The resulting priority will allow the VoIP traffic to enjoy priority over other types of traffic

within the layer 2 domain.

Alcatel-Lucent C


ot Distribute

10

The softphone‘s Ethernet frames are forwarded to the VoIP (SIP) server. Since the VoIP server is on a native VLAN

interface, the 802.1q / 802.1p bit mappings aren‘t preserved when the frame is switched to the port that the VoIP

server is connected to. As a result, the SIP server will use classifiers other than 802.1p markings. It is likely that the

ToS bits will be preserved since there is no reason for the switch to have re-marked these.

Alcatel-Lucent C


ot Distribute

11

As was stated on the last slide, the ToS bits are likely preserved in the IP datagram which is the Ethernet frame‘s

payload. That said, the SIP server may look at more information to classify the packet to determine whether it needs

to mark or re-mark the customer traffic at layer 3. For example, VoIP packets which are used for call setup and

signalling might enjoy higher priority than steady-state conversations. The DSCP values may be re-marked by the

VoIP server to reflect his.

The VoIP server will likely use the well-known or assigned port numbers for VoIP in the TCP or UDP segment header,

and specifically those for the application configured on it in order to prioritize the VoIP traffic. The SIP server is a

marker. It will mark the precedence bits in the DS field to indicate the appropriate level of priority for the VoIP

traffic.

Sidebar: RFC1700 (well-known, assigned and dynamic port numbers) has been superseded by the IANA (the

Internet Assigned Numbers Authority). For the latest information for the assignment of port numbers, visit

http://www.iana.org

Alcatel-Lucent C


ot Distribute

12

The default gateway (the CE) will see the marked IP packets on its access port. It, too, is a marker. It may use the

markings in its own marking decisions or discard them, recognizing that the CE will see more than VoIP traffic. In any

case, it will mark (or re-mark) the traffic depending on which algorithm (IP Precedence, DiffServ or IntServ) it is

configured for.

Most vendors have a mechanism that will queue and dispatch high-priority traffic such as VoIP packets with very little

latency recognizing how intolerant voice traffic is of delay and jitter (variable delay). In our example, the VoIP

traffic is marked with DSCP = 46, indicating the Expedited Forwarding (EF) Per Hop Behaviour (PHB).

Some other QoS mechanisms come into play as the packet is dispatched. For example, if the link to the PE is

relatively slow speed, then Link Fragment & Interleaving (LFI) will come into play. Put succinctly, LFI ensures that

long packets carrying traffic that is not time-sensitive will not choke out time-sensitive packets such as those that

carry VoIP. These long packets (such as FTP and HTTP file transfers) are fragmented and interleaved with the more

time-sensitive traffic so the time-sensitive traffic is not delayed.

Of course, the reason the traffic is being marked in the first place is so that it can enjoy preferential, differentiated

services when it is carried in a microflow in the DS Domain.

Alcatel-Lucent C


ot Distribute

13

Often QoS at the link between the customer and the service provider is managed by a number of different

mechanisms. Congestion avoidance, congestion management and link efficiency mechanisms may come into play

depending on the direction of the traffic. In this scenario, the marked VoIP traffic is arriving at the PE on a junction

between what is often a (relatively) low-speed link between the customer and the high-speed core.

Congestion Management

Congestion may be managed by a variety of queuing mechanisms, some of them hardware mechanisms.

Congestion Avoidance

Random, predictive dropping mechanisms such as Weighted Random Early Detection (WRED) may also be employed in

order to avoid congestion issues entirely if possible. By predicting traffic flow patterns, servicing of ingress and

egress queues can be optimized.

Link Efficiency Mechanisms

Efficiency is simply maximizing the number of bits that are squeezed through an interface per unit time while

ensuring the throughput of high priority traffic. Compression algorithms, some of which can be done at the link layer

in the WAN protocol (like PPP or Frame Relay) as well as LFI are examples of these mechanisms. Given our scenario

which is that the VoIP traffic is traversing the PE to the high-speed core this is probably not a big issue.

Alcatel-Lucent C


ot Distribute

14

The VoIP traffic is almost certainly still marked with the EF PHB DSCP = 46 markings. The PE will recognize this

traffic as high-priority, low-latency and real-time traffic. For example, traffic that is being conformed by the primary

congestion avoidance mechanism used on the Alcatel SR/ESS, WRED, will have no effect on the VoIP traffic. It will

be inserted directly into the hardware queue for forwarding.

Forwarding Classes on the Alcatel-Lucent SR/ESS are defined in the Section 2.

Alcatel-Lucent C


ot Distribute

15

Alcatel-Lucent C


ot Distribute

16

Alcatel-Lucent C


ot Distribute

17

Note:

At first glance, this seems to be a strange place to put a SIP server for VoIP but it isn‘t really. The SIP server might

be part of a managed infrastructure VoIP solution with the customer‘s ISP, hosted on the ―outside‖ of the customer‘s

network for network security reasons. This single VoIP server conceivably could host all of the inter-branch office

calls, recalling that in our scenario, Router D is a CE device at a branch office. Router A could be a stateful firewall,

with a separate perimeter network, or ―DMZ‖, set up on one of its inside access interfaces.

Alcatel-Lucent C


ot Distribute

Alcatel-Lucent C


ot Distribute

19

Classification and marking involves mapping the appropriate bits in a protocol data unit header at OSI layer 2 or layer

3 to indicate differentiating levels of service. It is important that devices in a QoS-aware network understand the

same mappings of QoS information in the customer traffic. While the traffic may be remarked at several natural

demarcation points in the network, QoS peer devices need to adhere to the same protocol so that the treatment of

traffic is consistent as it traverses the network.

Alcatel-Lucent C


ot Distribute

20

Differentiators are provided for at layer 2 or layer 3 of the OSI model.

Layer 2

IEEE 802.1p

802.1p is a specification for giving Layer 2 switches the ability to prioritize traffic. The prioritization specification

works at the media access control (MAC) framing layer of the OSI model.

Layer 3

IP Precedence

A three-bit field in the TOS byte of the IP header. Using IP Precedence, a user can assign values from 0 (the default)

to 7 to classify and prioritize types of traffic. IP Precedence is being phased out in favour of DSCP, but is supported

by many applications and routers.

Differentiated Services Code Point (DSCP)

DiffServ is a modification of the TOS byte. Six bits of this byte are reallocated for use as the DSCP field, where each

DSCP specifies a particular per-hop behaviour that is applied to a packet.

Layer 2/3

Experimental Field (EXP)

A three bit field in the MPLS header commonly used to classify and mark traffic.

Alcatel-Lucent C


ot Distribute

21

IEEE 802.1p

The IEEE 802.1P signalling technique is an IEEE-endorsed specification for prioritizing network traffic at the data-

link/MAC sub layer. The 802.1p standard also offers an important provisions to filter multicast traffic to ensure it

does not flood over layer 2-switched networks. The 802.1p header includes a three-bit field for prioritization, which

allows packets to be grouped into various traffic classes. 3 bits yield 8 choices. IEEE 802.1p is like the priority bits

in Token Ring and IEEE 802.5. It is a useful addition to Ethernet framing since Ethernet framing lacks a built-in

method of denoting priority. 802.1p largely resulted at the urging of large service providers that saw Ethernet‘s

inherent lack of prioritization as a roadblock to its implementation in carrier-class networks.

As can be seen in the graphic, IEEE 802.1p adds 16 bits to the Layer 2 header, including three bits that can be used to

classify priority (the tag). Frames with 802.1p implementation are called "tagged frames". The standard specifies

eight different priorities, which do not offer extensive policy-based service levels. Incidentally, implementing 802.1p

in a network with non-802.1p switches could lead to instability, because older switches would misinterpret the

unexpected 16 bits specified by the standard. Most importantly and from the perspective of QoS, 802.1.p can be used

as a differentiating mechanism since the Layer 2 header is only read at the switch level and since framing is not

preserved when customer traffic is routed at the boundary routers. Ironically, it is at the edge router where

bottlenecks are likely to occur. The edge router, if it is a layer 3-only device, cannot take advantage of

prioritization based on 802.1p unless it is mapped to a Layer 3 prioritization scheme.

The IEEE 802.1p standard is now officially part of IEEE 802.1d-1998. The tag defines eight user priority levels that

provide information to network devices as to the class of service that the frame should receive.

Alcatel-Lucent C


ot Distribute

22

Port / SAP Type Tags on Incoming Packet Pbits Used for Match

Null None None Null Top Tag PBits Null Top & Bottom Tag Top PBits Dot1Q None None Dot1Q Top Tag PBits Dot1Q Top & Bottom Tag Top PBits QinQ / TopQ None None QinQ / TopQ Top Tag Top PBits QinQ / TopQ Top & Bottom Tag Top PBits QinQ / QinQ Top & Bottom Tag Bottom PBits

The table below specifies which tag is used for classification depending on the configuration of the port and/or SAP and on the encapsulation of the packet arriving at the SR/ESS router.

Alcatel-Lucent C


ot Distribute

23

Alcatel-Lucent C


ot Distribute

24

The use of the bit mapping in the ToS field described in RFC 791 is commonly referred to as ―IP Precedence‖.

RFC 791 describes the use of the TOS field as follows:

―The Type of Service provides an indication of the abstract parameters of the quality of service desired. These

parameters are to be used to guide the selection of the actual service parameters when transmitting a datagram

through a particular network. Several networks offer service precedence, which somehow treats high precedence

traffic as more important than other traffic (generally by accepting only traffic above a certain precedence at time

of high load). The major choice is a three way tradeoff between low-delay, high-reliability, and high-throughput.‖

Bits 0-2 are the Precedence Bits

According to the RFC,

The Network Control precedence designation is intended to be used within a network only. The actual use

and control of that designation is up to each network.

The Internetwork Control designation is intended for use by gateway control originators only.

In general, If the actual use of these precedence designations is of concern to a particular network, it is the

responsibility of that network to control the access to, and use of, those precedence designations.

Alcatel-Lucent C


ot Distribute

25

Precedence Bits

Bit 3 = (D)elay: 0=Normal Delay, 1=Low Delay

Bit 4 = (T)hroughput 0=Normal Throughput, 1=High Throughput

Bit 5 = (R)eliability 0=Normal Reliability, 1=High Reliability

Bits 6&7 are reserved for future use

According to the RFC there are often tradeoffs:

“The use of the Delay, Throughput, and Reliability indications may increase the cost (in some sense) of the service.

In many networks better performance for one of these parameters is coupled with worse performance on another.

Except for very unusual cases at most two of these three indications should be set “

There are limitations with the RFC 791 use of these 8 bits. First, it doesn‘t offer much granularity and second, it

isn‘t universally implemented…perhaps for the first reason. DiffServ is a more widely accepted standard for QoS-

aware networks.

Alcatel-Lucent C


ot Distribute

26

DiffServ is an IETF standards track RFC (Request for Comments) which establishes a framework for service

classifications. Unlike IP Precedence, DiffServ does not differentiate traffic based on priority, application, or flow

but rather on the possible, predictive forwarding behaviours of packet called Per Hop Behaviours (PHBs).

DiffServ is rules based. It is a policy-based network management architecture that does not rely on the often

temporary fix of applying more bandwidth to a network in order to ease congestion and related QoS issues.

DiffServ is analogous to consumer-based differentiated service industries, such as parcel delivery. A parcel can travel

by different classes of service with different combinations of surface mail, priority post or courier; regular,

expedited, overnight or rush. Each class of service can be characterized by:

How fast the parcel reaches the destination,

how many stops you make along the way,

Special handling of the parcel along the way, if any.

Some services may have limitations, such as no weekend delivery, and others, such as regular mail, include risk of not

reaching your destination in the time frame expected. In all cases, you pay more for higher quality services.

The Differentiated Services framework offers the same kind of classification system.

Based on network policies, traffic is classified for different classes of forwarding. Network resources can then be

allocated appropriate to the marking on the parcel and the policies within the network.

In the DS architecture,

the IP header includes a Differentiated Services Code Point (DSCP), indicating the level of service desired;

the DSCP maps the packet to a particular forwarding behaviour (PHB) for processing by a DS-compliant router;

the PHB provides a particular service level (bandwidth, queuing, and dropping decisions) in accordance with

network policy.

Alcatel-Lucent C


ot Distribute

27

Alcatel-Lucent C


ot Distribute

28

Alcatel-Lucent C


ot Distribute

29

DSCP stands for Differentiated Services Code Point and was first defined in RFC 2597.

The DiffServ standard uses the first 6 bits (bits 0-5) for finer granularity than RFC 791. The 1st 3 bits (DS5, DS4, and

DS3) are used for class selection by precedence level. With 3 bits, 8 precedence levels (0 to 7) are possible.

The DS5, DS4 and DS3 bits are downward-compatible with devices to support devices which understand the RFC 791

mappings:

When converting between DSCP and IP precedence, match the three most significant bits (bits 0-3)

IP Precedence 3 (011) maps to IP DSCP 011 000

Also, note that precedence levels 1,2,3, & 4 also define (respectively) the 4 Assured Forwarding (AF) PHBs These

DSCPs are used to map traffic to AF classes.

Alcatel-Lucent C


ot Distribute

30

In RFC 2597, the DS2, DS1, and DS0 bits are used to indicate drop probability and are always combined with the DS5,

DS4, and DS3 bits to (together) describe an Assured Forwarding (AF) PHB. This allows a service provider‘s

Differentiated Services domain to offer different levels of forwarding assurances for IP packets received from a

customer DS domain.

The Assured Forwarding PHB guarantees a certain amount of bandwidth to an AF class and has the flexibility of

allowing access to extra bandwidth if available.

Alcatel-Lucent C


ot Distribute

31

The expedited forwarding PHB recognizes and formalizes that the nearest expression of true expedited service in an

end-to-end DS network can be found by combining Precedence Level 5 (Expedited Forwarding) with a high drop

probability (DS2, DS1, & DS0 = 110).

This PHB, creates a point-to-point connection between peers, a ―Premium Service‖ which effectively creates a

preferred, dedicated link across a DiffServ domain.

RFC 2598 is the Expedited Forwarding (EF) PHB:

"The EF PHB can be used to build a low loss, low latency, low jitter, assured bandwidth, end-to-end service through

DS (DiffServ) domains. Such a service appears to the endpoints like a point-to- point connection or a "virtual leased

line." This service has also been described as Premium service."

Alcatel-Lucent C


ot Distribute

32

Assured Forwarding (AF) PHB group is a means for a provider DS domain to offer different levels of forwarding

assurances for IP packets received from a customer DS domain. Four AF classes are defined, where each AF class is in

each DS node allocated a certain amount of forwarding resources (buffer space and bandwidth). IP packets that wish

to use the services provided by the AF PHB group are assigned by the customer or the provider DS domain into one or

more of these AF classes according to the services that the customer has subscribed to.

Within each AF class IP packets are marked (again by the customer or the provider DS domain) with one of three

possible drop precedence values. In case of congestion, the drop precedence of a packet determines the relative

importance of the packet within the AF class. A congested DS node tries to protect packets with a lower drop

precedence value from being lost by preferably discarding packets with a higher drop precedence value. In a DS

node, the level of forwarding assurance of an IP packet thus depends on:

1. How much forwarding resources have been allocated to the AF class that the packet belongs to?

2. What is the current load of the AF class, and, in case of congestion within the class…

3. What is the drop precedence of the packet?

Alcatel-Lucent C


ot Distribute

33

This diagram shows the output of a packet trace, and highlights the DSCP value carried in the packet.

Alcatel-Lucent C


ot Distribute

34•34

The MPLS EXP field is used to specify the QoS treatment of the packet within the MPLS network.

There are two modes for handling the EXP field in the MPLS header.

With uniform mode, the QoS marking of the IP packet is taken into consideration within the MPLS network. With pipe

mode, the QoS marking of the IP packet is only taken into consideration at the ingress and egress of the LSP. It is not

used within the MPLS network.

At the LSP ingress router, with uniform mode the IP packet‘s DSCP value is copied into the EXP field. Typically the

first 3 most significant bits of the DSCP value are copied to the 3 bits of the EXP field. The LSRs within the MPLS may

modify the EXP value, depending on the QoS requirements of the network. At the LSP egress router, the value of the

EXP field is copied back into the DSCP field of the IP header. Therefore, if the EXP value was modified within the

MPLS network, this new value will be used at the egress of the MPLS network.

With pipe mode the LSP ingress router applies a specific value for the EXP field. With the MPLS domain the LSRs may

modify the EXP bit according to QoS requirements. At the LSP egress router , the MPLS header is popped and the

original DSCP value of the IP header is maintained.

Alcatel-Lucent C


ot Distribute

35

This slide summarizes the 5 marking mechanisms.

Alcatel-Lucent SR/ESS devices‘ ―Services Model‖ is based on Differentiated Services in the core but, as has been

seen, they are downward compatible with IP Precedence-compliant devices and can also use 802.1p as classifiers for

marking and re-marking decisions.

Alcatel-Lucent C


ot Distribute

josemac

Accepted

36

Fundamentally, resource allocation starts with the premise that any data network, no matter how many links it

comprises, how much available bandwidth it has, and how many applications there are that use it, is a finite

resource. Application traffic must contend for a share of the available resources. Resource allocation is all about

making sure that resources are shared equitably and that the traffic that the service provider moves across the

network must conform to an SLA with the customer. QoS, as we‘ve seen, is a subjective idea, hard to quantify in

some cases and specific to the application.

Network administrators must, however, attempt to prioritize and optimize traffic flow through a network while

achieving (what will inevitably be) a workable compromise. The solution must be proactive.

As we‘ve seen, there are a number of architectures or frameworks for resource allocation. IP Precedence, DiffServ

and 802.1p are all mechanisms.

Forwarding classes are an integral part of DiffServ architecture. Forwarding classes create macroflows for data

between endpoints vs. microflows. The three forwarding class types, high priority, assured forwarding, and best

effort are explained on the next page.

Alcatel-Lucent C


ot Distribute

37

The SR/ESS supports eight internal forwarding classes. The graphic shows default definitions. Users can create QoS

policies that determine which traffic will be mapped both on ingress and egress into these forwarding classes. As we

have seen previously, Classifiers can inspect PDUs and many different layers of the OSI models in order that the data

traffic is properly marked as it enters and leaves the forwarding classes.

Think of forwarding classes as ―virtual pipes‖, configured as services between PE devices in the core of a network.

These macroflows can further categorized into three class types (view table).

High Priority

High priority forwarding classes are serviced before other forwarding classes. What makes these forwarding classed

(FC ID 4,5,6 & 7) ―high priority‖ is that they are intended for real-time traffic.

Assured

Assured forwarding provide services with a committed information rate (CIR) and a peak information rate (PIR) in the

same way that traditional edge WAN services like Frame Relay do. Assured FC traffic id normally marked as high-

priority or low-priority so that when the network experiences congestion, low priority traffic is essentially ―discard

eligible‖ and will be discarded in favour of high priority traffic.

Best Effort

The Best Effort forwarding classes do not guarantee delivery. What makes this class ―best effort‖ is that at the best,

the network will treat packets in this class like low priority packets in the Assured forwarding class.

Alcatel-Lucent C


ot Distribute

38

Each subclass retains the chassis wide behavior that is defined for the parent class and provides expanded ingress QoS

classification actions. Subclasses are always associated with their parent class queues to prevent out-of-sequence

forwarding. Queues cannot be associated within the context of a subclass.

Subclasses and their parent class can differ in terms of how they mark the profile and how they remark the IP ToS

field of the traffic that flows through them. Subclasses can be used to perform color-aware packet regulation at the

service ingress.

Alcatel-Lucent C


ot Distribute

39

When traffic arrives at the access ingress of a 7x50 SR/ESS it is mapped to a forwarding class in the following order of

matching criteria:

1. The packet is mapped based on the IP-match criteria OR mac-match criteria specified in the sap-ingress policy.

Note that ip-match criteria and mac-match criteria are mutually exclusive, which mean for a given sap-ingress policy

you can specify only one or the other.

2. If there is no ip-match or mac-match criteria configured in the sap-ingress policy, or if traffic does not match any

of the configured match criteria entries, then the mapping is based on the DSCP value of the customer datagram.

3. If the sap-ingress policy does not have a mapping configured for the DSCP value in the customer datagram, then

the mapping is based on the IP Precedence value of the customer datagram.

4. If the sap-ingress policy does not have a mapping configured for the IP Precedence value in the customer

datagram, then the mapping is based on dot1p value of the customer datagram.

5. If the sap-ingress policy does not have a mapping configured for the dot1p value in the customer datagram or if

there is not dot1p value in the customer datagram, then the mapping is based on default-fc value configured in the

sap-ingress policy.

Alcatel-Lucent C


ot Distribute

40

Alcatel-Lucent C


ot Distribute

41

Alcatel-Lucent C


ot Distribute

42

When traffic arrives at the network port of a router, it is mapped to a Forwarding Class based on the following order:

1. The packet is mapped based on its EXP value.

2. If the network policy does not have a mapping configured for the packet‘s EXP value, then the mapping is based

on DSCP value.

3. If the network policy does not have a mapping configured for the DSCP value, then the mapping is based on

dot1p value.

4. If the network policy does not have a mapping configured for the dot1p value or there is no dot1p value, then

the mapping is based on the default value configured in the network policy.

Alcatel-Lucent C


ot Distribute

43

At the network egress, marking FCs and profile state of packets in tunnel headers is performed in accordance with

the associated network QoS policies. Remarking of packets is performed to retain packets‘ service ingress traffic

classification to subsequent network ingresses reference.

Alcatel-Lucent C


ot Distribute

44

At the service ingress of Layer 2 services (i.e. ePipe and VPLS) the TOS bits (either the 6 DSCP bits or the 3 IP

precedence bits) of the IP packets or IP routed frames cannot be remarked. If ingress remarking is configured in the

sap-ingress policy it is ignored. At the first network egress the tunnel encapsulation is marked according to the

configured network policy. When MPLS tunnels are used, the EXP bit is marked, and when GRE tunnels are used, the

DSCP bit is marked.

Layer 2 SAP interfaces are always untrusted.

IP Interface Type Default Trust Behaviour

IES Non-Trusted VPRN Trusted Network Trusted

Alcatel-Lucent C


ot Distribute

45

At the service ingress of IES services the TOS bits (either the 6 DSCP bits or the 3 IP precedence bits) of the IP

packets or IP routed frames can be remarked depending on the profile state and forwarding class of the packet.

The IES SAP interface is untrusted by default but may be configured as trusted.

At the first network egress the DSCP value of the customer datagram may be remarked depending on the

configuration. The table below summarizes the packet remarking behavior at the first network egress given the

various combinations of ingress pre-marking, interface trust state and egress (no) remarking configurations. The slide

above also provides this summary.

Pre-

Marking

I/F Trust

State

Network

policy (no)

remarking

Result

None Untrusted (default)

Remarking or no remarking

The user datagram‟s DSCP/IPrec value will be remarked as per the

network policy regardless of the „remarking‟ parameter in the policy.

None Trusted •No remarking•Remarking

• With „no remarking‟ user datagram DSCP/IPrec value is not

touched. • With „remarking‟ user datagram DSCP/IPrec value will be remarked

as per the network policy.

Yes Trusted or Untrusted


The marking performed at the SAP ingress is maintained regardless of Trust/Untrusted interface and „remarking‟ parameter of the network

policy.

Alcatel-Lucent C


ot Distribute

46

At the service ingress of VPRN services the TOS bits (either the 6 DSCP bits or the 3 IP precedence bits) of the IP

packets or IP routed frames can be remarked depending on the profile state and forwarding class of the packet.

The VPRN SAP interface is trusted by default but may be configured as untrusted.

At the first network egress the DSCP value of the customer datagram may be remarked depending on the

configuration. The table below summarizes the packet remarking behavior at the first network egress given the

various combinations of ingress pre-marking, interface trust state and egress (no) remarking configurations. The slide

above also provides this summary.

Pre-

Marking

I/F Trust

State

Network

policy (no)

remarking

Result

None Untrusted (default)


The user datagram‟s DSCP/IPrec value will be remarked as per the

network policy regardless of the „remarking‟ parameter in the policy.

None Trusted Remarking or no remarking

The user datagram DSCP/IPrec value is not touched regardless of the „remarking‟ setting of the network policy.

Yes Trusted or Untrusted


The marking performed at the SAP ingress is maintained regardless of Trust/Untrusted interface and „remarking‟ parameter of the network

policy.

Alcatel-Lucent C


ot Distribute

47

The network interface is trusted by default but can be configured as untrusted.

At the network egress the EXP value of the tunnel encapsulation in the case of GRE/MPLS encapsulated tunnels or the

DSCP value of the customer datagram in the case of native IP packets may be remarked depending on the

configuration. The table below summarizes the packet remarking behavior at the network egress given the various

combinations of interface trust state and egress (no) remarking configurations. The slide above also provides this

summary.

I/F Trust

State

Network policy

(no) remarking

Result

Trusted (default)

•No remarking•Remarking

•If traffic is encapsulated in MPLS or GRE tunnel (e.g. epipe, vpls, vprn) then the user datagram DSCP/IPrec is not modified. It is the outer tunnel that is marked with the EXP/DSCP value as per the network policy.

•With „no remarking‟ the EXP/DSCP value of outer tunnel is not changed.

•With „remarking‟ the EXP/DSCP value of the outer tunnel is changed as per

the network policy.•If the traffic is “native” IP (e.g. entered from IES) then the IP datagram‟s DSCP/IPrec

value is affected depending on network policy:•With „no remarking‟ DSCP value of the IP datagram is not changed.

•With „remarking‟ the DSCP value of the IP datagram is changed as per the

network policy.

Untrusted Remarking or no remarking

•If traffic is encapsulated in MPLS or GRE tunnel (e.g. epipe, vpls, vprn) then the user datagram DSCP/IPrec is not modified. It is the outer tunnel that is remarked with the EXP/DSCP value as per the network policy, regardless of the „remarking‟ parameter.

•If the traffic is “native” IP (e.g. entered from IES) then the IP datagram‟s DSCP/IPrecvalue is remarked as per the network policy regardless of the „remarking‟ parameter.

Alcatel-Lucent C


ot Distribute

48

In order to remark packets at the network egress port remarking must be explicitly enabled in the network policy. It

is typically not recommended to perform packet remarking at the network egress ports within the service provider‘s

network, as the packet should normally receive the same treatment as it traverses the network. However, if another

network‘s router is connected to the service provider‘ router, the service provider may choose not to trust the

interface, and can configure it to be ‗un-trusted‘.

Alcatel-Lucent C


ot Distribute

49

The DSCP or IP precedence value of IP packets coming in on a IES or VPRN sap can be remarked based on their

forwarding class or sub-forwarding class, and on its profile state. Ingress remarking (sometimes referred to as pre-

marking) is performed using the sap-ingress policy.

In the example above, IP packets arriving at the IES sap are mapped to forwarding class af. Packets that are in-profile

have their DSCP value remarked to af31, while packets that are out-of-profile have their DSCP value remarked to

af33.

The remarking of packets at service ingress may be required when connecting to another DiffServ domain, whose per-

hop-behaviour of DSCP values may not be the same.

Alcatel-Lucent C


ot Distribute

50

The above example demonstrates the various marking behaviors discussed in the previous slides.

In the above example a VPRN service has been created between router PE1 and PE2. MPLS is used as the transport

tunnel.

All interfaces are using their default trust states. The network interfaces are configured with NULL encapsulation.

The saps are configured with dot1p encapsulation. The sap-ingress, sap-egress and network qos policies shown have

been configured. It is assumed that the default network-queue policy is used on each router.

At PE1, customer traffic is arriving marked with DSCP BE and tagged with dot1p value of 4. The packets are mapped

to Forwarding Class AF based on the dot1p marking of 4 and are furthermore marked at ingress. Packets that are in-

profile are marked as DSCP af31 while packets that are out-of-profile are marked as DSCP af33. In the example, it is

assumed that the arriving packet is out-of-profile. Given that the sap is configured to use dot1p encapsulation, the

customer‘s dot1p tag is removed.

At the egress of PE1 the transport tunnel the packet is marked with EXP value of 3. The network policy has the

remark parameter set. However, as the packet was already marked at the sap ingress, this setting is ignored, and the

customer datagram‘s DSCP value is not remarked to DSCP af23. It retains its marking of af33.

At the ingress of P, the packet is mapped to forwarding class af based on its MPLS header EXP value of 3. The

network policy is configured to set the EXP value of out-of-profile af traffic to 5. However, as the remarking

parameter is disabled, the packet‘s EXP value will not be remarked, and will retain its value of 3.

At the ingress of PE2 the packet is mapped to forwarding class af based on its MPLS header EXP value of 3. After

being un-encapsulated the customer‘s datagram‘s dot1p value is remarked to 4.

Note that in the above example only the relevant portion of the configurations are shown.

Alcatel-Lucent C


ot Distribute

51

The above example demonstrates the various marking behaviors discussed in the previous slides.

In the above example a VPLS service has been created between router PE1 and PE2. MPLS is used as the transport

tunnel.

All interfaces are using their default trust states. The network interfaces are configured with NULL encapsulation.

The saps are configured with dot1p encapsulation. The sap-ingress, sap-egress and network qos policies shown have

been configured. It is assumed that the default network-queue policy is used on each router.

At PE1, customer traffic is arriving marked with DSCP BE and tagged with dot1p value of 4. The packets are mapped

to Forwarding Class af based on the dot1p marking of 4. The sap-ingress policy is configured to remark the DSCP

value of the customer datagram. However, as this is a layer 2 service, this configuration is ignored. In the example, it

is assumed that the arriving packet is out-of-profile. Given that the sap is configured to use dot1p encapsulation, the

customer‘s dot1p tag is removed.

At the egress of PE1 the transport tunnel the packet is marked with EXP value of 3.

At the ingress of P, the packet is mapped to forwarding class af based on its MPLS header EXP value of 3. The

network policy is configured to set the EXP value of out-of-profile af traffic to 5. As the remarking parameter is set,

the packet‘s transport tunnel EXP value is remarked to a value of 5.

At the ingress of PE2 the packet is mapped to forwarding class ef based on its MPLS header EXP value of 5.

Note that in the above example only the relevant portion of the configurations are shown.

Alcatel-Lucent C


ot Distribute

Alcatel-Lucent C


ot Distribute

53

Traffic classification and marking is accomplished through the use of different QoS policies applied at different

locations in the network.

The ‗SAP-ingress‘ policy is used to map traffic entering the service provider‘s network to a Forwarding Class based on

a Multi-field classifier. It is applied on Service ingress SAPs.

The ‗SAP-egress‘ policy is used to mark traffic leaving the service provider‘s network. It is applied on the Service

egress SAPs.

The ‗network‘ policy is used to map traffic arriving on a network port on a router within the service provider‘s

network (i.e. on a P router) to a Forwarding Class based on the traffic‘s DSCP, IP Precedence or EXP value. It is also

used to specify the marking/remarking of traffic as it leaves the router on a network port. It is applied on network IP

interfaces.

A default SAP-ingress, SAP-egress and network policy exists on all routers.

Alcatel-Lucent C


ot Distribute

54

Recall that network ―egress‖ refers to the directional flow out of (ie: egress) the router.

The Network QoS Policy is applied to a router IP interface not on a port. On ingress, the policy maps incoming DSCP

and EXP values to forwarding class and profile state for traffic received from the core network. On egress, the policy

maps forwarding class and profile state to DSCP and EXP values for traffic to be transmitted into the core network.

A network QoS policy defines both ingress and egress behaviour.

Alcatel-Lucent C


ot Distribute

55

Description— The description provides a brief overview of policy features.

Scope — A network policy must be defined as having either an exclusive scope for onetime

use, or a template scope which enables its use with multiple SAPs.

Egress criteria — Specifies the forwarding class queues to be instantiated.

→ Forwarding class criteria — The forwarding class name represents an egress que. Specify forwarding class criteria to define the egress characteristics of the queue and the marking criteria of packets flowing through it.

→ Remarking — When enabled, this command remarks ALL packets that egress on the specified network port. The remarking is based on the forwarding class to DSCP and LSP EXP bit mapping defined under the egress node of the network QoS policy.

Ingress criteria — Specifies the DSCP to forwarding class mapping for all IP packets and define the MPLS EXP bits to forwarding class mapping for all labelled packets.

→ Default action — Defines the default action to be taken for packets that have an undefined DSCP or MPLS EXP bits set. The default-action specifies the forwarding class to which such packets are assigned.

→ Dot1P priority — Specifying the forwarding class or queuing priority forces packets that match the dot1p-priority to override the forwarding class and queuing priority based on the parameters included in the dot1p rule.

→ DSCP — Creates a mapping between the DSCP of the network ingress traffic and the forwarding class. Ingress traffic that matches the specified DSCP will be assigned to the corresponding forwarding class.

→ LER-USE-DSCP — Specifies the LERs to use DSCP marking instead of LSP-EXP.

→ LSP EXP — Creates a mapping between the LSP EXP bits of the network ingress traffic and the forwarding class. Ingress traffic that matches the specified LSP-EXP bits will be assigned to the corresponding forwarding class.

Alcatel-Lucent C


ot Distribute

56

Network QoS policies are applied to IP interfaces. On ingress, the policy maps incoming DSCP and EXP values to forwarding class and profile state for traffic received from the core network. On egress, the policy maps forwarding class and profile state to DSCP and EXP values for traffic to be transmitted into the core network.

A network QoS policy defines both ingress and egress behaviour.

Other Configuration Guidelines:

The network QoS policy consists of an ingress and egress component. The ingress component of the policy defines how DiffServ code points (DSCPs) and MPLS EXP bits are mapped to internal forwarding class and profile state. The forwarding class and profile state define the Per Hop Behaviour (PHB or the QoS treatment through the SR/ESS). The mapping on each network interface defaults to the mappings defined in the default network QoS policy until an explicit policy is defined for the network interface.

The egress component of the network QoS policy defines the DiffServ oriented queuing parameters associated with each forwarding class. Each forwarding class defined within the system automatically creates a queue on each network interface. This queue gets all the parameters defined within the default network QoS policy 1 until an explicit policy is defined for the network interface. If the egress packet originated on an ingress SAP, or the remarking parameter is defined for the egress interface, the egress QoS policy also defines the IP DSCP or MPLS EXP bit marking based on the forwarding class and the profile state.

Network policy-id 1 exists as the default policy and is applied to all network interfaces by default. The network policy 1 cannot be modified or deleted. It defines the default DSCP-to-FC mapping and MPLS EXP-to-FC mapping for the ingress. For the egress, it defines six forwarding class which represent individual queues and the packet marking criteria.

New (non-default) network policy parameters can be modified. The no form of the command reverts the object to the default values. A new network policy must include the definition of at least one queue and specify the default-action. Incomplete network policies cannot be applied to network interfaces.

Changes made to a policy are applied immediately to all network interfaces where the policy is applied. For this reason, when a policy requires several changes, it is recommended that you copy the policy to a work area policy-id. The work-in-progress copy can be modified until all the changes are made and then the original policy-id can be overwritten with the config qos copy command.

Alcatel-Lucent C


ot Distribute

57

Alcatel-Lucent C


ot Distribute

58

Configuring and applying QoS policies other than the default policy is optional. A default network policy is applied to

each router interface.

To create an network egress policy, define the following:

A network policy ID value. The system will not dynamically assign a value.

Include a description. The description provides a brief overview of policy features.

You can modify egress criteria to customize the forwarding class queues to be instantiated. Otherwise, the

default values are applied.

→ Remarking — When enabled, this command remarks ALL packets that egress on the specified network port. The

remarking is based on the forwarding class to DSCP and LSP EXP bit mapping defined under the egress node of the

network QoS policy.

→ Forwarding class criteria — The forwarding class name represents an egress queue. Specify forwarding class

criteria to define the egress characteristics of the queue and the marking criteria of packets flowing through it.

→ DSCP — The DSCP value is used for all IP packets requiring marking that egress on this forwarding class queue that

are in or out of profile.

→ LSP EXP — The EXP value is used for all MPLS labelled packets requiring marking that egress on this forwarding

class queue that are in or out of profile.

Ingress criteria — Specifies the DSCP to forwarding class mapping for all IP packets and define the MPLS EXP

bits to forwarding class mapping for all labelled packets.

→ Default action — Defines the default action to be taken for packets that have an undefined DSCP or MPLS EXP bits

set. The default-action specifies the forwarding class to which such packets are assigned.

→ DSCP — Creates a mapping between the DSCP of the network ingress traffic and the forwarding class. Ingress

traffic that matches the specified DSCP will be assigned to the corresponding forwarding class.

→ LSP EXP — Creates a mapping between the LSP EXP bits of the network ingress traffic and the forwarding class.

Ingress traffic that matches the specified LSP EXP bits will be assigned to the corresponding forwarding class.

Alcatel-Lucent C


ot Distribute

59

Alcatel-Lucent C


ot Distribute

60

Alcatel-Lucent C


ot Distribute

61

Alcatel-Lucent C


ot Distribute

62

Alcatel-Lucent C


ot Distribute

63

Alcatel-Lucent C


ot Distribute

64

Alcatel-Lucent C


ot Distribute

65

High (in-profile packets) and low (out-of-profile packets) queuing priorities are differentiated only for the assured

forwarding (AF) type forwarding classes. The reason is that high-priority traffic has stringent QoS requirements to

effect negligible delay and packet loss. Therefore, high-priority packets that conform to SLAs at the service ingress

cannot be dropped. As a result, high-priority packets must not be marked as a low-queuing priority. Conversely, all

the packets of the best-effort (BE) forwarding classes are treated as low-queuing priority. Therefore, packets that

belong to the best-effort forwarding classes do not need to be differentiated between high (in-profile) and low (out-

of-profile) queuing priorities.

Alcatel-Lucent C


ot Distribute

66

The Service Ingress QoS policy (SAP-ingress) serves two main functions in the implementation of QoS – the first is its

use to define traffic classification and marking as discussed in this module; the second is its use to create and define

queues for the different classified traffic as discussed in module 3.

Service ingress QoS policies are applied to the customer-facing Service Access Points (SAPs) and map traffic to

forwarding class queues on ingress. The mapping of traffic to queues can be based on combinations of customer QoS

marking (IEEE 802.1p bits, DSCP, and TOS precedence), IP and MAC criteria. The characteristics of the forwarding

class queues are defined within the policy as to the number of forwarding class queues for unicast traffic and the

queue characteristics.

Alcatel-Lucent C


ot Distribute

67

A service ingress policy is configured with:

Default FC — The default forwarding class for the policy.

Default priority — The default queuing priority for all packets received on an ingress SAP using the policy.

Dot1p — This parameter creates a mapping between the IEEE 802.1p bits of the ingress traffic and the ingress

queue (forwarding class).

DSCP — This parameter creates a mapping between the DSCP of the ingress traffic and the ingress queue-id.

Forwarding class — The explicitly defined default forwarding type overrides for fc-name.

IP criteria or MAC criteria — You can define IP-based or MAC-based SAP ingress policies to select the

appropriate ingress queue and corresponding forwarding class for matched traffic.

Prec — The forwarding class or queuing priority when a packet is marked with an IP precedence value (ip-

prec-value).

Queue — A SAP ingress queue defines the forwarding class, CIR, and PIR associated with the queue.

Scope — A service ingress policy must be defined as having either an exclusive scope for one-time use, or a

template scope which enables its use with multiple SAPs.

Alcatel-Lucent C


ot Distribute

68

Alcatel-Lucent C


ot Distribute

69

The above slide shows the queue definition portion of the SAP-ingress policy, as well as the forwarding class creation

and mapping to a queue portion.

Alcatel-Lucent C


ot Distribute

70

The above slide shows the traffic mapping to a forwarding class portion of the SAP-ingress policy.

The service ingress queuing priority is specified as part of the classification rule and is set to ―high‖ or ―low‖. The

queuing priority of a packet that is determined at the time of the service ingress traffic classification is valid only for

the service ingress queuing and only if the forwarded queue of the packet is configured as priority mode. For the

subsequent queuing points, the queuing priority of the packets is based on their profile state. The profile state of a

packet depends on the queuing mode. The mode of a queue is discussed in module 3.

Alcatel-Lucent C


ot Distribute

71

The following displays the service ingress policy applied on a SAP / Service

#------------------------------------------

echo "Service Configuration"

#------------------------------------------

service

customer 1 create

description "Default customer"

exit

customer 500 create

description "SNA Mainframe SSP”

phone "613-555-1212"

exit

epipe 15 customer 500 create

description “VLL service for customer X"

sap 1/1/1 create

ingress

qos 99

exit

Alcatel-Lucent C


ot Distribute

72

Alcatel-Lucent C


ot Distribute

73

Alcatel-Lucent C


ot Distribute

74

Alcatel-Lucent C


ot Distribute

75

1. Why is traffic classification and marking needed to implement QoS, and what is needed to ensure the traffic receives the treatment it requires?

Answer: Traffic must be classified and marked to indicate differentiating levels of service. It is important that devices in a QoS-aware network understand the same mappings of QoS information in the customer traffic so that they adhere to the same protocol and treat the traffic in a consistent manner as it traverses the network.

2. List the different marking mechanisms.

Answer: DSCP, IP precedence, dot1p, Q-in-Q, EXP

3. If traffic is entering the provider network at an IES SAP, by default, will it be marked at the router‘s network egress?

Answer: By default an IES SAP is an un-trusted boundary, hence traffic will be marked as it exits the router at the egress network port.

4. Which QoS policies are used to configure traffic classification and marking, and where are they applied?

Answer: SAP-ingress, SAP-egress and network policies are used to configure the classification and marking of traffic. SAP-ingress and SAP-egress policies are applied on service SAPs while network policies are applied on the IP interfaces at network ports.

5. List the forwarding classes supported on the SR/ESS and identify their class types.

Answer: NC, H1, EF and H2 are High Priority forwarding classes. L1 and AF are Assured FCs. L2 and BE are best effort FCs.

Alcatel-Lucent C


ot Distribute


Alcatel-Lucent C


ot Distribute








This module focuses on queuing and buffer management on the 7x50 ESS/SR.

2

Alcatel-Lucent C


ot Distribute

Alcatel-Lucent C


ot Distribute

The IOM provides separate buffer pools for ingress and egress on each MDA. On service ingress and egress, each

access port has its own buffer pool. On network egress each port has its own buffer pool. On network ingress all ports

on the same MDA share a buffer pool. The total buffer space on a MDA is 256MB per MDA per direction. These buffer

pools are automatically allocated. The buffer pools allocated to ports is effectively a logical separation of the

available buffer space.

4

Alcatel-Lucent C


ot Distribute

By default, each pool is associated with slope-policy 1. The default slope policy disables WRED.

You can create custom slope policies apply them to the buffer pools.

The minimum buffer block size that can be allocated is 4KB. This means that when the MBS or CBS is configured as 0,

there is actually 4KB of buffer space allocated to the queue.

5

Alcatel-Lucent C


ot Distribute

Each 7x50 forwarding complex has 256 Mb of buffer space available for ingress traffic and 256 Mb for egress traffic queues. Buffer pool management ensures that services are segregated from each other and that no one service will use a disproportionate amount of system resources.

Reserved Buffer Portion

The reserved buffer space is a percentage of the total buffer space and has a default value depending on the MDA type. The percentage of the reserved buffer space is configurable. The Committed Burst Size specified for individual queues is taken from the reserved portion of the buffer pool. The size of the reserved buffer space should be equal to the sum of the CBS assigned to each queue making use of that buffer pool.

Shared Buffer Portion

The shared buffer space is the buffer space that is not reserved for use by specific queues.

Shared Buffers = Total Buffer Pool – Reserved Buffers

Any queue can use non-allocated shared buffer space if its reserved buffer space is full and it has not exceeded its maximum burst size (MBS).

The MBS specified for a queue is taken from the shared buffer pool. Shared buffer utilization is managed by WRED.

Reserved High-Priority-Only Buffers

Memory (the buffer pools) is a finite system resource. Without proper resource allocation of this space, it is possible that without a queuing strategy to manage this space the pool may become over-subscribed. Potentially, traffic that should otherwise be defined as high-priority as part of a QoS policy might be dropped, hence the need to reserve buffer space from the pool for high priority traffic.

A portion of the queue buffer pool can be reserved for high priority (or in-profile) traffic. When a queue depth reaches a specified level, only traffic marked as high-priority can be placed into the queue. Any low priority traffic arriving at the queue at that time is discarded.

6

Alcatel-Lucent C


ot Distribute

The buffer pool allocated to each configured access ingress and access egress points, as well as the buffer pool

allocated to the network egress ports can be viewed using the command ‗show pools <port-id>.

The default pool allocation depends on the type of MDA. The example in the slide above gives the buffer pool

allocation for a 10-port GigE MDA.

There is no buffer pool allocated to the access ingress and access egress because no SAP has been created on the port

1/1/1.

7

Alcatel-Lucent C


ot Distribute

Details of the buffer pool allocated to a network port or access port can be viewed by specifying either ‗network-

egress‘, ‗access-ingress‘ or ‗access-egress‘ as shown in the slide above. By default, 50% of the total bandwidth is for

the reserved portion. The percentage of the reserved buffer pool can be changed.

To view the buffer pool allocated to the network ingress, the MDA must be specified in the ‗show pools‘ command.

Recall that at the network ingress all ports on an MDA share the same buffer pool.

8

Alcatel-Lucent C


ot Distribute

Committed Burst Size (CBS)

The CBS parameter specifies the amount of buffer space reserved for use by a given ingress or egress queue. Once

the reserved buffer space for a queue has been used, the queue contends with other queues for additional buffer

resources up to the Maximum Burst Size (MBS) of the queue. The CBS for a given queue can be configured or the

system can assign a default size.

Maximum Burst Size (MBS)

The Maximum Burst Size parameter specifies the maximum size to which a queue can grow. This parameter

essentially represents the maximum of time a packet could spend in the queue, assuming a servicing rate equal to

the configured PIR value (PIR and CIR are discussed further in the Scheduling section). The MBS for a given queue can

be configured or will be assigned a default value by the system.

High Priority Only (HPO)

The High Priority only parameter specifies the amount of buffer space allocated to the queue, that is reserved for

queuing only high priority packets (or packets that are in-profile). HPO is specified as a percentage of the MBS value.

The difference between the MBS and HPO value gives the threshold mark beyond which only high priority packets are

allowed in the queue. Once this threshold mark is reached, any incoming packet that is ‗out-of-profile‘ is discarded.

9

Alcatel-Lucent C


ot Distribute

This diagram represents the buffer pool utilization for each queue defined at the network or service ports.

Q8 has MBS=CBS=5, therefore it does not make use of any shared buffer space.

Q4 and Q3 both make use of the shared buffer space, and as such will contend for the available resources.

Example:

A queue‘s attributes are:

MBS = 10 KB,

CBS = 8 KB,

HP-only: 3 KB.

other assumptions:

• There is no CBS oversubscription;

• High/low WRED slopes are disabled.

Let the current queue depth be X.

If X = 5 KB: X < CBS < MBS. If an In-Profile or Out-of-Profile packet arrives, the packet will be queued on a reserved buffer.

If X = 7 KB: X < CBS < MBS. Because MBS – HP-only = 7 KB, if an Out-of-Profile packet arrives the packet will be discarded. On the other hand, because X < CBS, if an in-Profile packet arrives it will be queued.

If X = 9 KB: X < MBS. Because MBS – HP-only = 7 KB, if an Out-of-Profile packet arrives the packet will be discarded. On the other hand, because X < MBS, if an In-Profile packet arrives it will contend for a shared buffer space with other queues. HP-only does restrict Out-of-Profile packets; however it does not guarantee an in-profile packet will get a buffer once the CBS is exceeded.

10

Alcatel-Lucent C


ot Distribute

The profile state of the queue impacts the scheduling priority of the packets it holds.

The profile state of the packet dictates its queuing priority. It determines whether the packet is to be considered

High or Low priority when it is queued. This distinction comes into play when the high-priority-only parameter of a

queue is set to a non-zero value, and when WRED is used. The fact that a packet is marked in-profile does not

necessarily mean it will be forwarded before packets marked out-of-profile. The scheduling priority/order is

determined by the profile state of the queue.

By using profile marking during traffic classification at the sap-ingress the color markings made by customers or an

access network on their traffic can be recognized and treated accordingly.

Note that the parameters PIR and CIR are discussed in detail in Module 4.

11

Alcatel-Lucent C


ot Distribute

In the sap-ingress policy, the queues created can be configured to be in Priority mode (default) or Profile mode.

When the Priority mode is used the profile of the packets arriving at the router at an access ingress point is

determined based on the rate at which they are serviced. If the packets are serviced at a rate that is within the

queue‘s configured CIR, they will be marked as ‗in-profile‘. If the packets are serviced at a rate that is above the

queue‘s configured CIR, and within the queue‘s configure PIR, they will be marked as ‗out-of-profile‘.

When the Profile mode is used the profile of the packets arriving at the router at an access ingress point is

determined by the explicit configuration made in the sap-ingress policy or made by the customer or access network.

At the network ingress port the ‗in-profile‘ and ‗out-of-profile‘ marking of the packets is determined by the packet‘s

EXP, DSCP or IP precedence marking used for traffic classification.

At the network egress port and sap egress the profile status of the packets is kept from the status determined at the

network port ingress or sap ingress.

The queues configured at the network ports do not have a ‗mode‘ configuration associated to them. It is only at the

sap-ingress that queues can be configured with a ‗mode‘ type which in turn dictates the profile status of the packet.

12

Alcatel-Lucent C


ot Distribute

1. A traffic source is explicitly marked as ‗in-profile‘ and is transmitted at a rate of 5 Mbps. It is queued in a queue configured in Priority mode with CIR = 10Mbps. The packets‘ profile state will be ‗in-profile‘ because the queue is being serviced at a rate less than its CIR. The packet‘s explicit ‗in-profile‘ marking has no significance.

2. A traffic source is explicitly marked as ‗in-profile‘ and is transmitted at a rate of 15 Mbps. It is queued in a queue configured in Priority mode with CIR = 10Mbps. The packets‘ profile state will be ‗out-of-profile‘ because the queue is being serviced at a rate above its CIR (and assumed below its PIR). The packet‘s explicit ‗in-profile‘ marking has no significance.

3. A traffic source is explicitly marked as ‗out-of-profile‘ and is transmitted at a rate of 5 Mbps. It is queued in a queue configured in Priority mode with CIR = 10Mbps. The packets‘ profile state will be ‗in-profile‘ because the queue is being serviced at a rate less than its CIR. The packet‘s explicit ‗out-of-profile‘ marking has no significance.

4. A traffic source is explicitly marked as ‗out-of-profile‘ and is transmitted at a rate of 15 Mbps. It is queued in a queue configured in Priority mode with CIR = 10Mbps. The packets‘ profile state will be ‗out-of-profile‘ because the queue is being serviced at a rate less than its CIR. The packet‘s explicit ‗out-of-profile‘ marking has no significance.

5. A traffic source is explicitly marked as ‗in-profile‘ and is transmitted at a rate of 5 Mbps. It is queued in a queue configured in Profile mode with CIR = 10Mbps. The packets‘ profile state will be ‗in-profile‘ because it has been explicitly configured as such. The queue‘s profile state has no significance.

6. A traffic source is explicitly marked as ‗in-profile‘ and is transmitted at a rate of 15 Mbps. It is queued in a queue configured in Profile mode with CIR = 10Mbps. The packets‘ profile state will be ‗in-profile‘ because it has been explicitly configured as such. The queue‘s profile state has no significance.

7. A traffic source is explicitly marked as ‗out-of-profile‘ and is transmitted at a rate of 5 Mbps. It is queued in a queue configured in Profile mode with CIR = 10Mbps. The packets‘ profile state will be ‗out-of-profile‘ because it has been explicitly configured as such. The queue‘s profile state has no significance.

8. A traffic source is explicitly marked as ‗out-of-profile‘ and is transmitted at a rate of 15 Mbps. It is queued in a queue configured in Profile mode with CIR = 10Mbps. The packets‘ profile state will be ‗out-of-profile‘ because it has been explicitly configured as such. The queue‘s profile state has no significance.

13

Alcatel-Lucent C


ot Distribute

BUFFER POOL

To manage the use of the shared buffer pool, the WRED algorithm is used to selectively discard packets before the buffer pool becomes completely full. Weighted Random Early Detection (WRED) monitors the shared buffer space utilization over a period of time. WRED uses the shared buffer utilization rather than any individual queue depth to get a better picture of the average resource utilization of the shared buffer space.

For each buffer pool there are two WRED slopes: low-slope and high-slope. The low-slope manages shared buffer access of the low-queuing priority (out-of-profile) traffic. The high-slope manages shared buffer access of the high-queuing priority (in-profile) traffic. Having two slopes allows high priority traffic to receive preferential treatment. By default, both the slopes are disabled and packets are discarded on a tail drop basis. This means that packets are dropped when either the queue depth has reached its MBS value, or the entire buffer pool space available is full.

WRED is useful to avoid TCP Slow-Start synch problem. The TCP transport protocol, commonly used in today‘s Internet, detects congestion only after a packet has been dropped. And, in response to a dropped packet TCP drastically reduces its transmission window to one and goes through Slow-Start algorithm. Under tail drop buffer management, there is a possibility that all the sources contributing to a congestion point can be globally synchronized in controlling their transmission window size. In such synchronized condition, during slow start period, the network bandwidth is heavily under utilized.

Under WRED, congestion is detected ahead and packets are dropped randomly. This avoids transmission windows of contributing sources synchronized globally and thereby avoids bandwidth under utilization.

If WRED is enabled, Any traffic flowing through the shared buffer space is subjected to WRED. Therefore, if it is not desired to subject premium or any other traffic to WRED then it should be prevented from making use of the shared buffer space by configuring MBS = CBS.

14

Alcatel-Lucent C


ot Distribute

The discard probability is a fractional number ranging from zero to one and describes the probability of discarding a packet subject to a WRED slope. Two points relative to weighted average utilization and discard probability define each slope:

The weighted average utilization where discard probability starts to rise above zero

The weighted average utilization and discard probability point defining where discard probability rises straight to one.

Two configurable slopes are defined per buffer pool:

a high slope

a low slope

The WRED curve has four regions:

(0,0) to (start-avg,0): When the shared buffer average utilization is between 0 and the startavg, the packet discard probability is zero and no packets are discarded by the WRED function.

(start-avg,0) to (max-avg, max-prob): When the shared buffer average utilization is between start-avg and max-avg, the packet discard probability is proportional to the average buffer utilization, and ranges from zero to the max-prob.

(max-avg, max-prob) to (max-avg, 1): At the max-avg threshold, the packet discard probability instantaneously increases from max-prob to 1.

(max-avg, 1) to (100%, 1): When the shared buffer average utilization is between max-avg and 100%, the packet discard probability is one. Any incoming packet that requests space in the shared buffer space will be discarded.

Once a queue exceeds its reserved buffer allocation and starts using shared buffers, each service packet mapped to that queue issubject to the probability based drop function. The above slide depicts WRED slope configurable parameters. Each slope is configured with thresholds describing points on the slope that intersect the average utilization of the shared portion of the buffer pool (X-axis or horizontal plot with utilization increasing from 0 to 100%) and the probability of discard (Y-axis or vertical plot with probability rising from 0 to 1).

15

Alcatel-Lucent C


ot Distribute

Default TAF = 7

Instantaneous Utilization Factor = 0.0078125

Historical Utilization Factor = 0.9921875

TAF Range: 0 to 15

@0 IUF = 1

@15 IUF = 0.000030517578125

The WRED function keeps track of the average utilization of the shared buffer space of the associated buffer pool.

1. When each packet is received, the packet discard probability is determined from the WRED slope based on the

existing average utilization.

2. A random number is generated and is compared to the discard probability of the packet. The lower the discard

probability, the lower the chances are that the random number is within the discard range.

3. If the random number is within the discard range, the packet is discarded, which results in no change to the

average utilization of the shared buffers.

4. A packet is also discarded if there is not enough shared buffer space for the packet. Either current utilization is

equal to the maximum size of the shared buffer space, or the actual utilized CBS is oversubscribed and the

reserved buffer space has used buffers from the shared size, which lowers the effective shared buffer size equal

to the shared buffer utilization size.

5. If the packet is queued, a new shared buffer average utilization is calculated using the TAF for the buffer pool.

The TAF is the relative weight of the previous shared buffer average utilization result and the instantaneous

shared buffer utilization.

6. The new shared buffer average utilization is used to determine the discard probability of the next incoming

packet from the WRED slope.

7. If a packet is removed from the shared buffers of a queue, the shared buffer utilization is reduced by the number

of returned buffer. If a packet is removed from the reserved buffers of a queue, the returned buffers do not

result in a change in the shared buffer utilization.

16

Alcatel-Lucent C


ot Distribute

Alcatel-Lucent C


ot Distribute

josemac

Revised

Network Queue policies are applied on egress to network ports and channels and on ingress to MDAs. SAP-ingress

policy is applied on a SAP in the ingress direction. SAP-egress policy is applied on a SAP in the egress direction. The

policies define the forwarding class queue characteristics for these entities.

18

Alcatel-Lucent C


ot Distribute

The Service Ingress QoS policy (SAP-ingress) serves two main functions in the implementation of QoS – the first is its

use to define traffic classification and marking as discussed in Module 2; the second is its use to create and define

queues for the different classified traffic.

There can be up to eight (8) unicast forwarding class queues in the policy; one for each forwarding class.

A service ingress QoS policy also defines up to three (3) queues per forwarding class to be used for multipoint traffic

for multipoint services. The three types of multipoint traffic are: multicast, broadcast, and unknown.

One service ingress QoS policy and one service egress QoS policy can be applied to a specific SAP.

19

Alcatel-Lucent C


ot Distribute

The default SAP-ingress policy (policy ID 1) defines two queues: queue 1 for all unicast packets and queue 11 for all

multipoint packets. It also maps all traffic as best effort with low priority. To implement the desired QoS strategy

new SAP-ingress policies are configured, in which the required queues are created and defined, and the selected

forwarding classes are created and associated to a queue.

The following parameters associated with a queue can be configured, or left at their default values.

Queue Mode: Priority (default) or Profile

Queue Type: Auto-expedite (default), Expedite, Best Effort (note that queue type is addressed in module 4)

Adaptation Rule: Closest (default), Max, Min

Scheduling Parameters: Rate and CIR (kbps)

Queue size parameters: MBS and CBS (KB)

Queue Threshold parameter: High-priority only (percentage of queue size)

The service ingress queuing priority is specified as part of the classification rule and is set to ―high‖ or ―low‖. The

priority of a packet has an impact on its buffering but not its scheduling. The queuing priority of a packet that is

determined at the time of the service ingress traffic classification is valid only if the forwarded queue of the packet

is configured as priority mode.

20

Alcatel-Lucent C


ot Distribute

Network-queue policies define the parameters of the unicast and multipoint queues used to buffer packets on MDAs

as ingress and on ports at egress and specify the mapping of Forwarding Classes to queues. The default network-

queue policy defines 8 unicast and 8 multipoint queues – one for each forwarding class.

The following parameters associated with a queue can be configured, or left at their default values.

Queue Type: Auto-expedite (default), Expedite, Best Effort (note that queue type is addressed in module 4)

Scheduling Parameters: Rate and CIR (as a percentage of the line rate)

Queue size parameters: MBS and CBS (as a percentage of the automatically determined buffer pool size)

Queue Threshold parameter: High-priority only (percentage of queue size)

21

Alcatel-Lucent C


ot Distribute

Description— The description provides a brief overview of policy features.

Forwarding class — The forwarding class contains the PIR, CIR, CBS and MBS commands used to control the

buffer pool resources of each forwarding class queue on the ingress and egress pools that are associated with

the network queue policy.

Queue — The parameters specified in the network queue policy queue overrides the default unicast

forwarding type queue mapping for the forwarding class.

CBS — The relative amount of reserved buffers, given as a percentage, for a specific ingress network MDA

forwarding class queue or egress network port forwarding class queue.

High-prio-only — The relative amount of queue buffers, given as a percentage, for exclusive use by high

priority packets as a default condition for buffer queues for the network queue policy.

MBS — The relative amount of the buffer pool space, given as a percentage, for the maximum buffers for a

specific ingress network MDA forwarding class queue or egress network port forwarding class queue.

Rate — The administrative Peak Information Rate (PIR) and the administrative Committed Information Rate

(CIR) parameters for the queue.

22

Alcatel-Lucent C


ot Distribute

23

Alcatel-Lucent C


ot Distribute

24

Alcatel-Lucent C


ot Distribute

25

Alcatel-Lucent C


ot Distribute

26

Alcatel-Lucent C


ot Distribute

Note that the queue policy “nq1” was created in the previous slides

ALA-7>config>card>mda# info

----------------------------------------------

mda-type m60-10/100eth-tx

network

ingress

queue-policy "default"

exit

exit

----------------------------------------------

27

Alcatel-Lucent C


ot Distribute

The following output displays the port configuration:

A:ALA-49>config>port# info

----------------------------------------------

ethernet

network

queue-policy "nq1"

exit

exit

no shutdown

------------------------

A:ALA-49>config>port#

28

Alcatel-Lucent C


ot Distribute

The following output displays the port configuration:

A:ALA-48>config>port# info

----------------------------------------------

description "OC-12 SONET/SDH"

sonet-sdh

path

network

queue-policy "nq1"

exit

no shutdown

exit

exit

no shutdown

----------------------------------------------

A:ALA-48>config>port#

29

Alcatel-Lucent C


ot Distribute

Service egress QoS policies are applied to SAPs and map forwarding classes to service egress queues for a service. Up

to 8 queues per service can be defined for the 8 forwarding classes. A service egress QoS policy also defines how to

remark the forwarding class to IEEE 802.1p bits in the customer traffic.

One service ingress QoS policy and one service egress QoS policy can be applied to a specific SAP.

30

Alcatel-Lucent C


ot Distribute

A service egress policy is configured with:

Forwarding class — The forwarding class name or names associated with the egress queue. The egress queue

for the service traffic is selected based on the forwarding classes that are associated with the queue.

Queue — Unlike SAP ingress policies, the SAP egress policies map the forwarding class or classes to the queue.

In other words, the egress queue is selected based on the forwarding class of each packet which egresses the

SAP.

Scope — A service egress policy must be defined as having either an exclusive scope for one-time use, or a

template scope which enables its use with multiple SAPs.

Queue ID — Up to 8 queues can be defined to support forwarding classes.

Adaptation rule — The method used by the system to derive the operational CIR and PIR settings when the

queue is provisioned in hardware.

CBS — A mechanism to override the default reserved buffers for the queue when you want to oversubscribe

the total CBS reserved buffers for a given access port egress buffer pool.

High-prio-only — The percentage of buffer space for the queue, used exclusively by high priority packets.

MBS — The explicit definition of the maximum amount of buffers allowed for a specific queue.

Parent — An optional parent scheduler that further governs the available bandwidth given the queue aside

from the queue‘s PIR setting.

Rate — The administrative Peak Information Rate (PIR) and the administrative Committed Information Rate

(CIR) parameters for the queue.

31

Alcatel-Lucent C


ot Distribute

32

Alcatel-Lucent C


ot Distribute

33

Alcatel-Lucent C


ot Distribute

The following displays the egress QoS policy configuration:

ALA-7>config>qos# info

#------------------------------------------

echo "QoS Policy Configuration"

#------------------------------------------

...

sap-egress 105 create

description "SAP egress policy"

queue 1 create

exit

queue 2 create

exit

queue 3 expedite create

parent test1

exit

fc af create

queue 1

exit

fc ef create

queue 2

exit

exit

...

#------------------------------------------

34

Alcatel-Lucent C


ot Distribute

The following displays the egress QoS policy configuration:


--------------------------------------------------

...

sap-egress 105 create

description "SAP egress policy"

queue 1 create

exit

queue 2 create

exit

queue 3 expedite create

exit

fc af create

queue 1

exit

fc ef create

exit

exit

...

------------------------------------------------

ALA-7>config>qos#

35

Alcatel-Lucent C


ot Distribute

36

Alcatel-Lucent C


ot Distribute

Each 10 Gb/s forwarding complex (equivalent to one MDA) in the SR/ESS has 256 MByte of buffer memory for ingress

traffic and 256 Mbytes for egress traffic. The buffer memory is used to create traffic queues at access ingress/egress

and network ingress/egress points. Traffic flow can be controlled by provisioning traffic queue and scheduler

parameters.

A buffer pool is a logical segmentation of the buffer space dedicated to an MDA. Buffer pools are created to reserve a

section of the total buffer space for dedicated use by a group of queues. The buffers used by a queue must all come

from a single buffer pool. For example, the buffers for ingress expedited queues come from an expedited buffer pool.

The number of buffer pools at any one time depends on how the ports on the MDA are provisioned. In general, buffer

pools are created to segregate ingress and egress buffer resources for each forwarding class. Buffer pools ensure that

a forwarding class on ingress and on egress does not starve other forwarding classes.

Note that the size of each buffer pool (access-ingress, access-egress, network-ingress and network-egress) is

calculated depending on the MDA type and cannot be configured in CLI.

37

Alcatel-Lucent C


ot Distribute

View the Default Slope Policy for port 1/1/1

A:Pe1>config>port# info detail

----------------------------------------------

shutdown

description "10/100 Ethernet TX"

access

ingress

pool default

resv-cbs default

slope-policy "default"

exit

exit

egress

pool default

resv-cbs default

slope-policy "default"

exit

exit

exit

network

egress

pool default

resv-cbs default

slope-policy “default”

38

Alcatel-Lucent C


ot Distribute

This is a common error when configuring slope QoS policies (i.e., remembering that only MDAs can be configured for

slope QoS policies both ingress & egress for access and network whereas ports can only have the egress configured on

a network port).

39

Alcatel-Lucent C


ot Distribute

40

Alcatel-Lucent C


ot Distribute

Slope QoS Policies

High slope — Defines the high priority Weighted Random Early Detection (WRED) slope graph.

Low slope — Defines the low priority Weighted Random Early Detection (WRED) slope graph.

Max average — Sets the low priority or high priority Weighted Random Early Detection (WRED) slope position

for the shared buffer average utilization value where the packet discard probability rises directly to one.

Max probability — Sets the low priority or high priority Random Early Detection (RED) slope position for the

maximum non-one packet discard probability value before the packet discard probability rises directly to

one.

Start average — Sets the low priority or high priority Random Early Detection (RED) slope position for the

shared buffer average utilization value where the packet discard probability starts to increase above zero.

TAF — (Time Average Factor) Sets a weighting factor to calculate the new shared buffer average utilization

after assigning buffers for a packet entering a queue.

41

Alcatel-Lucent C


ot Distribute

The following displays the slope policy configuration:


#------------------------------------------

echo "QoS Slope/Queue Policies Configuration"

#------------------------------------------

...

slope-policy "slopePolicy1" create

description "Test"

high-slope

no shutdown

exit

low-slope

no shutdown

exit

exit

...

#------------------------------------------

ALA-7>config>qos#

42

Alcatel-Lucent C


ot Distribute

The following output displays an MDA configuration with the slope policy ―slopePolicy1‖

applied to the network egress pool:

ALA-7>config>card>mda# info

----------------------------------------------

...

mda-type m60-10/100eth-tx

network

ingress

queue-policy "nq1"

exit

egress

pool

slope-policy "slopePolicy1"

exit

exit

exit

----------------------------------------------

ALA-7>config>card>mda#

43

Alcatel-Lucent C


ot Distribute

The following output displays a port configuration with the slope policy ―slopePolicy1‖ (default policy) applied to the access and network egress pools:

ALA-7>config>port# info detail

----------------------------------------------

access

egress

pool default


exit

exit

exit

network

egress

pool default


exit

exit

exit

ethernet

exit

no shutdown

----------------------------------------------

ALA-7>config>port#

44

Alcatel-Lucent C


ot Distribute

The default access ingress and egress policies are identified as policy-id 1. The default policies cannot be edited or

deleted. The slide above displays default policy parameters:

45

Alcatel-Lucent C


ot Distribute

46

Alcatel-Lucent C


ot Distribute

47

Alcatel-Lucent C


ot Distribute

48

Alcatel-Lucent C


ot Distribute

1. Where are buffer pools allocated?

Answer: On the access ingress and access egress points, on the port for egress network ports, and on the MDA for

ingress network ports.

2. On which of the following entities can a slope policy be applied?

A. Access Ingress port

B. Access Egress port

C. Network Ingress port

D. Network Egress port

3. What is the HPO parameter of a queue used for?

Answer: It specifies the amount of buffer space allocated to the queue that is reserved for queuing only packets

that are ‗in-profile‘.

4. How many queues are created with the default SAP-ingress policy?

Answer: Two queues are created by default – one for unicast traffic and one for multipoint traffic (multicast,

broadcast and unknown)

5. If a access ingress queue is configured as Profile mode, how is the profile state of a packet in that queue

determined?

Answer: The packet‘s profile state is determined by its classification.

49

Alcatel-Lucent C


ot Distribute


Alcatel-Lucent C


ot Distribute








This module will start the focus on features of the Alcatel-Lucent products to give the student an appreciation for

the Robust QoS abilities of the platform.

2

Alcatel-Lucent C


ot Distribute

Alcatel-Lucent C


ot Distribute

Scheduling refers to the order in which packets in queues are serviced and how packets queued in different queues

are serviced. All ingress and egress queues operate under the control of one or more schedulers. Several queues may

use the same scheduler. Schedulers control the data transfer between the following queues and destinations:

Service ingress switch fabric destinations (ingress scheduler)

Service egress access egress ports (egress scheduler)

Network ingress switch fabric destinations (ingress scheduler)

Network egress network egress interfaces (egress scheduler)

The 7x50 SR/ESS supports two types of scheduling:

Single-tier scheduling (Default scheduling) – at network and service ports

Multi-tier scheduling (virtual hierarchical scheduling) - at service ports only

4

Alcatel-Lucent C


ot Distribute

The parameters which dictate the scheduling rates and priorities of queues are the:

Peak Information Rate (PIR) – the maximum rate at which packets are serviced from a queue

Committed Information Rate (CIR) - determines the packets‘ queuing priority marking and prioritizes queue

scheduling

Adaptation Rule - dictates how to adapt administrative CIR and PIR values to the underlying default

scheduling rates. This parameter only applies to service ingress and egress queues.

Queue Default Scheduler - dictates how to schedule a queue relative to other queues at the hardware level

5

Alcatel-Lucent C


ot Distribute

Committed Information Rate: The committed information rate for a queue performs two distinct functions:

1. Profile marking - Service ingress queues, by default, mark packets in-profile or out-of-profile based on the queue's CIR. For each packet transmitted from a service ingress queue, the CIR is checked with the current transmission rate of the queue. If the current rate is at or below the CIR threshold, the transmitted packet is internally marked in-profile. If the current rate is above the threshold, the transmitted packet is internally marked out-of-profile. This behaviour applies when the queue mode is ―Priority‖, which is the default mode. Module 3 explains the queue modes.

2. Scheduler queue priority metric - The scheduler serving a group of ingress or egress queues prioritizes individual queues based on their current CIR and PIR states. Queues operating at or below their CIR are always serviced before those queues operating above their CIR.

The CIR for ingress and egress service queue is provisioned, respectively, within SAP-ingress QoS Policy and SAP-egress QoS Policy. The CIR of service queues are defined in Kbps (Kilobits/sec). The CIR for network queues is defined within network-queue QoS policy. The CIR of network queues is defined as a percentage of the network interface bandwidth.

The SR/ESS allows overbooking of CIR. However, care should be taken not to overbook the CIR of high priority class queues otherwise it might not be possible to meet their service commitments.

Peak Information Rate: The peak information rate (PIR) defines the maximum rate at which packets are allowed to exit a queue. It does not specify the maximum rate at which packets may enter a queue. This is governed by the queue's ability to absorb bursts and is defined by its maximum burst size (MBS).

The PIR is provisioned on ingress and egress service queues, respectively, within SAP-ingress QoS Policy and SAP-egress QoS Policy. The PIR of service queues is defined in Kbps (Kilobits/sec). The PIR for network queues are defined within network-queue QoS policy. The PIR for network queues is defined as a percentage of the network interface bandwidth.

Note: The PIR and CIR for a queue specified by service provider is the administrative value. The operational PIR and CIR values depend on the administrative value, specified adaptation rule, and hardware scheduling rates supported in the SR/ESS.

6

Alcatel-Lucent C


ot Distribute

The administrative CIR and PIR rates are the values configured by the user. The operational value is the actual

operational rates enforced by the hardware queue. The adaptation rule provides the QoS provisioning system with

the ability to adapt administrative CIR and PIR values to the underlying hardware scheduling rates which dictate the

operational rates. The rule provides a constraint to adapt when the exact rate is not available due to hardware

implementation tradeoffs. Hardware scheduling of the CIR and PIR rates are MDA dependent.

For the CIR and PIR parameters, the system will attempt to find the best operational rate depending on the defined

constraint. The supported adaptation rules are:

Min - Find the hardware supported rate that is equal to or higher than the specified rate

Max - Find the hardware supported rate that is equal to or less than the specified rate

Closest - Find the hardware supported rate that is closest to the specified rate

The default constraint is Closest. The adaptation rule always assumes that the PIR on the queue is the most

important rate. When multiple available hardware rates exist for a given CIR and PIR rate pair, the PIR constraint is

always evaluated before the CIR. For example, if the PIR is 403Mbps and the CIR is 301kbps, then the rate step given

the PIR rate is 5Mbps while the rate step given the CIR is 8kbps. However as the PIR is evaluated before the CIR, the

rate step applied to both is 5Mbps. Hence, if the adaptation rule is set to Min for both the PIR and CIR, their

respective operational values is 405Mbps and 5Mbps. If the adaptation rule is set to Max for both the PIR and CIR,

their respective operational values is 400Mbps and 0Mbps.

The adaptation-rule parameter is only applicable to the sap queues. It does not apply to the network queues.

Note: PIR cannot be configured to be zero.

7

Alcatel-Lucent C


ot Distribute

The adaptation rule parameter is configured on a per queue basis in the sap-ingress and sap-egress policies.

As shown in the slide above, the show pools <port-id> access-ingress or show pools <port-id> access-egress commands

provide the operational PIR and CIR rates allocated, given the configured (or administrative) rate and cir values, the

adaptation rule and the type of MDA used. In the above example, the rate step for the PIR rate is 5Mbps while the

step for the CIR rate is 8kbps. However, as the PIR value takes precedence, as step of 5Mbps is used to determine

both the operational PIR and CIR values.

8

Alcatel-Lucent C


ot Distribute

The default scheduler for a queue dictates how it will be scheduled relative to other queues at the hardware level.

Packets in Expedite queues are serviced before packets in Best Effort queues. When a queue is defined in a SAP-

ingress, SAP-egress or network-queue QoS Policy, it is possible to explicitly define the hardware scheduler (queue-

type) to use for the queue when it is applied to a SAP.

Being able to define a hardware scheduler is important as a single queue can accommodate packets belonging to

multiple forwarding classes. The default behaviour (auto-expedite) is to automatically choose the expedited or best

effort nature of the queue based on which forwarding classes are mapped to it. As long as all the forwarding classes

mapped to a queue are expedited (NC, EF, H1 or H2) ones, the queue will be treated as an expedited queue by the

hardware schedulers. When any of the best effort forwarding classes are mapped to a queue (BE, AF, L1 or L2), the

queue is treated as best effort by the hardware schedulers.

Expedited Forwarding classes are: NC, H2, EF, H1

Non-expedited (or best-effort) Forwarding classes are: L2, AF, L1, BE

9

Alcatel-Lucent C


ot Distribute

In the example above, with the default configuration of ‗auto-expedite‘, queue 4 will be treated as a best-effort

queue since one of the Forwarding Classes mapped to it is a best-effort FC. If it is desired that queue 4 be treated as

an expedite queue, then it is possible to explicitly configure it as ‗expedite‘.

10

Alcatel-Lucent C


ot Distribute

In a forwarding complex of the SR/ESS IOM, there are 66 Virtual Output Queues (VoQs) available for scheduling user

traffic. A VoQ is a pair of scheduling priority loops. The first loop (high priority VoQ) is for servicing In-Profile packets

and the second loop (low priority VoQ) is for servicing Out-of-Profile packets. Each VoQ, and its associated queues,

transmit packets to a single switch fabric (under ingress scheduling) or an egress port destination (under egress

scheduling).

11

Alcatel-Lucent C


ot Distribute

There are 66 VoQs divided into 33 pairs available for scheduling traffic on each MDA. Each of the first 32 VoQ pairs

service unicast packets from queues that are destined for a particular MDA. The 33rd pair of VoQs services the

multipoint traffic (multicast, broadcast and unknown packets).

Thus on a given ingress MDA, there is a pair of VoQs for each of the possible destination MDAs (including itself) to

service unicast traffic. There is also one pair of VoQs to service multipoint traffic, regardless of the destination MDA.

Thus on a 7750 SR12 system, in which there can be up to 20 MDAs, each MDA has 20 VoQ pairs for unicast traffic + 1

VoQ pair for multipoint traffic on ingress.

12

Alcatel-Lucent C


ot Distribute

There are 66 VoQs divided into 33 pairs available for scheduling traffic out the ports on each MDA. For MDAs that

have 33 ports or less, there is one VoQ pair allocated per port used for both unicast and multipoint traffic. In the

case of the m60-10/100eth-tx MDA, which has 60 ports, a single VoQ is assigned per port. Hence the egress scheduling

on the m60-10/100eth-tx MDA differs from the other MDAs that have fewer than 33 ports.

13

Alcatel-Lucent C


ot Distribute

Default schedulers are implemented in hardware and are the default method of scheduling queues in the SR/ESS.

Queues are scheduled with single-tier scheduling if no explicit hierarchical scheduler policy is defined or applied.

There are no explicit configurable parameters for basic scheduling other than a queue‘s CIR and PIR. Single-Tier

Scheduling is robust and provides a scalable solution to fairly share bandwidth between competing services.

Basic schedulers schedule queues based on the forwarding class of the queue and the operational state of the queue

relative to the queue‘s CIR and PIR. Queues operating within their CIR values are serviced before queue‘s operating

above their CIR values with ―expedited‖ forwarding class queues given preference over ―best effort‖ (or ―non-

expedited‖) forwarding class queues.

Pairs of schedulers send traffic to a switch fabric, service access port, or network port.

Queues are serviced in the following order:

First Pass – Round Robin between expedite queues operating within their CIR.

Second Pass – Round Robin between best effort queues operating within their CIR.

Third Pass – Biased Round Robin between all queues operating within their PIR but above their CIR.

In the third pass, the queues are serviced in Biased Round Robin because the expedite queues obtain at least 50% of

third pass bandwidth if there is enough traffic in those queues. Biased Round Robin is basically a round-robin

scheduler. However, each time it is interrupted by the two higher priority passes, it always resumes servicing with

the expedite queues. Hence, it is referred to as BRR.

14

Alcatel-Lucent C


ot Distribute

In the ingress direction, towards the switch fabric, queues are serviced in three passes. In the first pass, the

scheduler services all the Expedite queues that are operating within their operational CIR. The servicing of a queue is

stopped once it has transmitted packets up to its operational CIR. The Expedite queues are thus, serviced one after

another and the first pass is repeated until the last queue is serviced up to its CIR.

In the second pass, all the Best Effort queues operating within their operational CIR are serviced. The servicing of a

queue is stopped once it has transmitted packets up to its operational CIR. As with the first pass, the second pass is

repeated until the last queue is serviced up to its CIR.

In the third pass, the scheduler services all queues that are operating within their operational PIR but above their

CIR. Similar to the first and second pass, the third pass is repeated until the last queue is serviced up to its PIR.

Thus conforming traffic in the queues associated with the high-priority VoQs is serviced first. Once these queues have

been serviced up to their CIR, or once they are empty, the scheduler services the conforming traffic in the queues

associated with the low-priority VoQs. Once these queues have been serviced up to their CIR, or once they are

empty, the scheduler services the non-conforming traffic regardless of queues’ association to a high or low priority

VoQ. If at any moment there is traffic in the Expedite or Best-effort queues, the scheduler will stop its third pass and

service those queues (i.e. perform first and second pass scheduling). When it finally resumes its third pass scheduling

it always starts with the Expedite queues, hence the reason that the third pass scheduling is considered Biased Round

Robin.

If traffic is arriving at the queues at a rate exceeding PIR, the queues will begin to fill up. If the arrival rate of

packets is maintained the queues may eventually become full and packets could be discarded.

15

Alcatel-Lucent C


ot Distribute

The diagram above illustrates the association of queues to VoQs, and the order in which they are serviced by the

scheduler.

Each of the first 32 VoQ pairs service packets from queues that are destined for a particular MDA. The 33rd pair of

VoQs (i.e.: the last pair = 64 & 65) services all queues, regardless of the destination MDA.

Each unicast queue is associated with a VoQ, based on the destination MDA and the priority (Expedite or Best Effort).

This results in 2 VoQs per destination MDA. All multipoint queues are mapped in 2 VoQs.

As discussed previously, the queues are serviced in strict priority in the following order:

1. Round Robin between conforming (within CIR) Expedite (high priority) queues

2. Round Robin between conforming (within CIR) Best effort (low priority) queues

3. Biased Round Robin between non-conforming (above CIR) Expedite and Best effort queues

If there is congestion in the queues to a particular MDA destination, only that VoQ will be blocked. All traffic to other

egress MDAs continues to be sent to the switch fabric.

16

Alcatel-Lucent C


ot Distribute

On the M60-10/100eth-TX MDA, egress scheduling occurs in two passes. In the first pass all queues operating within

their operational CIR are service in a round robin fashion. This is repeated until either the port bandwidth is

exhausted or each queue has received its operational CIR. In the second pass all queues operating above their

operational CIR but within their PIR are serviced in a round robin fashion. This is repeated until either:

1. The port bandwidth is exhausted or;

2. Each queue has received its operational PIR

On all other MDAs egress scheduling occurs in 3 passes, just as it does on ingress scheduling.

17

Alcatel-Lucent C


ot Distribute

The scheduling of queues in the egress direction (towards the port) is similar to the ingress scheduling. There is a pair

of VoQs to service queues per egress port. Given that 66 VoQs are available in a forwarding complex this allows for 33

VoQ pairs. Therefore, this egress scheduling mode is adopted only in those MDAs that have less than or equal to 33

egress ports. For example, this egress scheduling mode is not adopted in the M60-10/100eth-TX MDA, which has 60

ports.

The diagram above illustrates the egress scheduling with paired VoQs for Port 1. Scheduling to the other ports is

similar to the one illustrated. As with ingress scheduling, the different queues are serviced in the following order:

1. Queues associated with the Expedite (high-priority) VoQ operating within their CIR

2. Queues associated with the Best Effort (low-priority) VoQ operating within their CIR

3. All queues operating within their PIR but above CIR

18

Alcatel-Lucent C


ot Distribute

This mode of egress scheduling is adopted only in M60-10/100eth-TX MDA, which has 60 ports. Under this egress

scheduling mode, a single VoQ services all the queues that are transmitting packets towards a particular egress port.

The reason for the single VoQ per port is that as there are 66 VoQs available per 10G forwarding complex, there can

only be one VoQ per port on the M60-10/100eth-TX MDA.

Egress scheduling with single VoQ for Port 1 is illustrated in the diagram above. Scheduling to the other ports is

similar to the one illustrated. Under egress scheduling with single VoQ, different queues are serviced in the following

order:

1. All queues operating within their CIR

2. All queues operating within their PIR but above their CIR

Egress scheduling towards a port is accomplished with two passes. In the first pass all the queues operating within

their CIR are serviced in round robin. First pass is repeated until either the port bandwidth is exhausted or each

queue has received its operational CIR.

19

Alcatel-Lucent C


ot Distribute

The scheduling parameters (rate, cir, queue-type and adaptation-rule) are configured for each queue defined in the

sap-ingress, sap-egress and network-queue policies. The slide above shows the scheduling parameters configured on a

sap-ingress and a sap-egress policy.

When the sap-ingress policy is applied to a service access point, the traffic arriving at this sap is scheduled in the

ingress direction (i.e. towards the switch fabric) according to the configured scheduling parameters. Likewise, when

the sap-egress policy is applied to a service access point, the traffic is scheduled in the egress direction (i.e. towards

the egress port) based on the configured scheduling parameters.

If the queue-type is not explicitly configured, it is set to auto-expedite by default. This means that the queue‘s type

will be determined based on the forwarding classes associated with it, as described previously. In the example above,

the queue type of queue 3 has not been explicitly configured. As the forwarding class associated with queue 3 is AF,

which is considered a best effort forwarding class, queue 3 will be treated as best-effort. In the case of queue 5, it

has been explicitly configured as best-effort. Thus even though it is associated with forwarding class H2, which is

considered an expedite forwarding class, it will be treated as best-effort.

If a rate and cir is not explicitly configured they will take on default values – zero for CIR and the maximum value

depending on the port‘s line rate for the rate.

If a sap-ingress or sap-egress policy is not explicitly applied to a sap, the default policies will be used.

20

Alcatel-Lucent C


ot Distribute

The configuration of the scheduling parameters at the network port is accomplished using the network-queue policy.

For ingress scheduling, the network-queue policy is applied on the MDAs, while for egress scheduling the policy is

applied on the port.

The scheduling parameters (rate, cir and queue-type) are configured per queue.

As with the sap-ingress and sap-egress policies, if the queue-type is not explicitly configured, it is set to auto-

expedite by default.

And if a network-queue policy is not explicitly applied to a port or MDA, then the default network-queue policy takes

effect.

21

Alcatel-Lucent C


ot Distribute

The use of multi-tiered scheduling enables the implementation of flexible scheduling schemes which can adapt

dynamically depending on what applications are active and how much bandwidth they require. In other words the

rate and CIR values configured for each queue can be dynamically modified.

HQoS can be used to limit a customers overall servicing rate, while still allowing any one application to burst up to

the maximum rate, bandwidth permitting. HQoS can also be used to ensure that a particular type of traffic receives a

higher priority than other high priority traffic, and thus is guaranteed to be serviced ahead of the other high priority

traffic during a congested state. In other words it allows for greater granularity in terms of providing differentiated

treatment between multiple traffic types all associated with high priority VoQs.

Particular scheduling requirements can be implemented with HQoS.

22

Alcatel-Lucent C


ot Distribute

Multi-Application SLA

HQoS is useful in a multi-application SLA scenario, such as a Triple Play offering, in which the high priority

applications, such as voice and video must have guaranteed bandwidth, while allowing the lower priority applications

such as Internet access to make full use of the available bandwidth whenever there is no higher priority applications

transmitting traffic. And furthermore, the overall rate available for all applications is limited to a certain value.

Multi-Site SLA

HQoS can be used to limit the overall bandwidth available to a VPN customer which has multiple offices sharing one

SLA. Each office is allocated its own committed bandwidth, but any one office is allowed to burst and make use of

more bandwidth if it is available; in other words, if one office is not transmitting any traffic, another office that is

sharing the same SLA can make use of the bandwidth vacated by the first office. Furthermore the overall rate can be

limited.

Multi-Service SLA

Similar to the Multi-Site SLA application, HQoS can be used to limit the overall bandwidth available to a customer

sharing one SLA between multiple services, such as VPN and Internet access. Thus, if the customer is not making use

of its VPN (or is using less than its committed bandwidth), the Internet access traffic can burst and make use of that

available bandwidth. Furthermore the overall rate can be limited.

23

Alcatel-Lucent C


ot Distribute

Virtual schedulers are created within the context of a hierarchical scheduler policy. A Hierarchical scheduler policy

defines the hierarchy and scheduling parameters for each virtual scheduler. A virtual scheduler is defined in the

context of a tier, where up to three tiers can be defined on the SR/ESS (Tier 1, Tier 2, Tier 3). The tier level

determines the scheduler‘s position within the hierarchy. When hierarchical scheduling is used, queues are assigned

to a parent scheduler, and this parent scheduler could in turn be assigned to a parent scheduler. This depends on the

number of levels required to implement the desired scheduling behavior. A virtual scheduler can enforce a maximum

rate of operation for all child queues and associated schedulers.

Conceptually a hierarchical scheduler structure on the SR/ESS is very similar to T-array tree data structure. In a

virtual hierarchical scheduler structure, the buffer queues form the leaves of the structure. A parent (intermediate

node or root node) is always a virtual scheduler. As in the case of T-array tree, in a hierarchical scheduler policy a

parent scheduler can have any number of children. A virtual scheduler can have queues and/or other virtual

schedulers as its children. Each child virtual scheduler or queue can have only one parent virtual scheduler. The

number of levels in a T-array tree is called its height, whereas a hierarchical scheduler structure is defined in the

context of tiers.

Referring to the diagram above:

The root schedulers are defined at Tier 1.

Schedulers defined in Tier 2 can have parental associations with schedulers defined in Tier 1.

Schedulers defined in Tier 3 can have parental associations with schedulers defined at Tiers 1 or 2.

Queues can have parental associations with schedulers at any tier level.

24

Alcatel-Lucent C


ot Distribute

25

Alcatel-Lucent C


ot Distribute

The diagram above illustrates the scheduling order, when hierarchical scheduling is used.

A parent scheduler distributes its allocated bandwidth to its children in two passes. The first one is known as the

‗within CIR‘ pass and the second one is the ‗above CIR‘ pass. The first pass of bandwidth allocation to a child ends

once its service rate reaches its configured CIR parameter value. The second pass of bandwidth allocation to a child

ends once its service rate reaches its configured Rate parameter value. During the first pass the allocation of

bandwidth to a child is based on the child‘s CIR level and CIR weight parameters. During the second pass the

allocation of bandwidth to a child is based on the child‘s Level and Weight parameters.

The range of values of the CIR_level parameter is 0 to 8 and the range of the Level parameter is from 1 to 8. A higher

numbered level (8 being the highest priority) is exhaustively serviced over a lower numbered levels.

The range of both the CIR_weight and Weight is from 0 to 100. In both the passes, the (CIR) Weight parameter

defines the weight of a child within the given (CIR) Level. When multiple children share the same (CIR) Level on a

parent scheduler, the ratio of bandwidth given to an individual child is dependent on the ratio of the weights of the

active children. The ratio is calculated by first adding the (CIR) Weights of all active children and then dividing each

child‘s CIR weight by the sum. A CIR weight of zero forces the child to receive bandwidth only after all other children

at that level have received their ‗within CIR‘ bandwidth. When several children share a CIR weight of zero, all are

treated equally.

26

Alcatel-Lucent C


ot Distribute

The diagram above illustrates a structure of hierarchical schedulers for a given hierarchical scheduler policy

implementation at a service ingress. The bandwidth available for the tier 1 (root) scheduler is configured to 15 Mbps

and the traffic is arriving at a rate of 15 Mbps at each of the four queues carrying different CoS traffic. Under this

scenario, the bandwidth allocated by the hierarchical schedulers to each of the four queues is summarized in the

accompanying table. The bandwidth allocation process is described below:

1. The Root scheduler has 15 Mbps of bandwidth available for distribution.

2. There are two children entities to which the Root scheduler must allocate bandwidth: a Tier2 scheduler and

Queue 5 for EF traffic.

3. Queue 5 has a CIR_Level = 6 while Tier2 scheduler has a CIR_Level = 4, therefore queue 5 gets priority for its CIR

bandwidth allocation. However the root scheduler has sufficient bandwidth to allocate the requested CIR of both

of its children. Thus queue 5 receives its CIR bandwidth of 2 Mbps and Tier2 scheduler receives its CIR bandwidth

of 5 Mbps. After this first pass (within CIR) scheduling the root scheduler has 8 Mbps of bandwidth left to

allocate.

4. For the second pass (above CIR) scheduling, Queue 5 requires and additional 3 Mbps of bandwidth to satisfy its

PIR requirement, and Tier2 scheduler needs an additional 10 Mbps of bandwidth to satisfy its PIR requirement.

The root scheduler does not have enough bandwidth remaining to satisfy both of its children’s PIR bandwidth

requirement, thus it must rely on the Level parameters to determine how to distribute the bandwidth it has

between the two children. Both children have the same Level value, thus the remaining available bandwidth is

distributed based on their Weight value, which is also the same. Thus, the available bandwidth is distributed

equally between the children – 4 Mbps for each. As queue 5 only needs an extra 3 Mbps of bandwidth to reach its

PIR, the excess 1 Mbps is allocated to Tier2 scheduler. Hence, Tier2 scheduler receives an additional 5 Mpbs. To

summarize, queue 5 has PIR = 5 Mbps and CIR = 2 Mbps, while Tier2 scheduler has PIR = 10 Mbps and CIR = 5

Mbps.

(example continued on next page)

27

Alcatel-Lucent C


ot Distribute

8. Looking at the allocation of bandwidth by Tier2 to its children. There is 5 Mbps of committed bandwidth and 10

Mbps of peak bandwidth available for distribution.

9. There are three children entities (Queue 4, 3 and 1) to which the Tier2 scheduler must allocate bandwidth.

10. For the first pass (within CIR scheduling) Tier2 scheduler has enough bandwidth to satisfy all of its children’s CIR

requirements. Queue 4 and queue 3 each receive CIR = 2 Mbps while queue 1 receives CIR = 0 Mbps. This leaves 6

Mbps of bandwidth available for distribution.

11. For the second pass (above CIR) scheduling, Queue 4 and Queue 3 each require an additional 13 Mbps of

bandwidth to satisfy their PIR requirements, and Queue 1 needs an additional 15 Mbps of bandwidth to satisfy its

PIR requirement. Tier2 scheduler does not have enough bandwidth available to satisfy all of its children’s PIR

requirements, therefore it must rely on the Level parameter to determine how to allocate its remaining

bandwidth to its children. All children have the same Level value, thus the remaining available bandwidth is

distributed based on their Weight value, which are 50, 30 and 20 respectively. Thus, Queue 5 receives half of the

available bandwidth, Queue 4 receives 3/10th and Queue 1 receives 1/5th. Queue 4 receives 3 Mbps, Queue 3

receives 1.8 Mbps and Queue 1 receives 1.2 Mbps. In summary, Queue 4 will have a PIR = 5 Mbps and CIR = 2

Mbps, Queue 3 will have PIR = 3.8 Mbps and CIR = 2 Mbps and Queue 1 will have PIR = 1.2 Mbps and CIR = 0 Mbps.

NOTE:

If the ingress traffic rate to Queue 5 is at 5 Mbps, then the above division of bandwidth applies. If at one point the

actual ingress traffic rate of the Queue 5 drops to a lower rate, then the bandwidth that is not used is made available

to the other child (Tier2). Thus the Root scheduler re-allocates the unused bandwidth to Tier2. And Tier2 can then

allocate it to its children. Therefore, the total bandwidth available to service the queues is allocated dynamically

and changes as the actual bandwidth usage of any of the higher priority entities change. Thus, it is possible for the

BE queue to burst to its PIR of 15 Mbps if there is no traffic to be service in any of the other queues.

28

Alcatel-Lucent C


ot Distribute

#------------------------------------------

echo "QoS Policy Configuration"

#------------------------------------------

scheduler-policy "Multi-Tier" create

description “HQoS Example"

tier 1

scheduler "root" create

rate 15000 cir 15000

exit

exit

tier 2

scheduler "low" create

parent "root" level 4 weight 50 cir-level 4 cir-weight 50

rate 15000 cir 5000

exit

exit

exit

sap-ingress 5 create

queue 1 create

parent "low" level 4 weight 20 cir-level 4 cir-weight 0

rate 15000

exit

queue 3 create


rate 15000 cir 2000

exit

queue 4 create


rate 15000 cir 2000

exit

queue 5 create

parent "root" level 4 weight 50 cir-level 6 cir-weight 50

rate 5000 cir 2000

exit

queue 11 multipoint create

exit

fc af create

queue 3

exit

fc be create

queue 1

exit

fc ef create

queue 5

exit

fc l1 create

queue 4

exit

exit

#------------------------------------------

29

Alcatel-Lucent C


ot Distribute

HQoS is implemented by first creating a hierarchical-scheduler policy. Several hierarchical-scheduler policies may be

created on a SR/ESS.

It is in the hierarchical-scheduler policy that each scheduler at each of the three possible tiers is defined. Several

Tier 1, Tier 2 and Tier 3 schedulers can be defined within a single hierarchical-scheduler policy. For each scheduler

that is defined the following parameters may be configured: Rate, CIR and parent scheduler. Tier 1 schedulers cannot

have a parent scheduler configured, since they are the root schedulers. A Tier 2 and Tier 3 scheduler can only have

one parent configured, and the parent must be at a higher level in the hierarchy.

Once a hierarchical-scheduler policy has been created, it can be applied to the SAPs (for ePipe, VPLS, IES or VPRN

services) or multi-service customer sites which need to make use of the hierarchical schedulers defined in the

hierarchical-scheduler policy.

The queues that have been defined in the SAP-ingress and/or SAP-egress policy associated with the SAP(s) can then

be modified to associate them with a parent scheduler, and to specify their HQoS scheduling parameters (Level,

Weight, CIR_level and CIR_weight). Alternatively, a new SAP-ingress/SAP-egress policy can be created to implement

the desired hierarchical scheduling. This depends on whether HQoS is being added to an existing service, or to a

brand new service, and also depends on the network operators implementation guidelines and practices.

Note that there is no default hierarchical-scheduler policy.

30

Alcatel-Lucent C


ot Distribute

The Hierarchical-scheduler policy configurable components are:

Tier — The level of hierarchy that a group of schedulers are associated with.

Scheduler — A scheduler defines bandwidth controls that limit each child (other schedulers and queues)

associated with the scheduler.

Parent — An optional parent scheduler that is higher up the policy hierarchy. Only schedulers in tier levels 2

and 3 can have a parental association.

Rate — The maximum bandwidth that the parent scheduler can offer its child queues or schedulers.

31

Alcatel-Lucent C


ot Distribute

In the above example, two schedulers have been created in each tier. The Tier 1 scheduler ―top‖ is a parent to Tier 2

scheduler ―middle‖ and to Tier 3 scheduler ―bottom‖. As shown, the parent of a scheduler (or queue) does not have

to be a scheduler at the next level of the hierarchy.

The Tier 1 scheduler ―master‖ is a parent to Tier 2 scheduler ―subordinate‖, which is in turn a parent to Tier 3

scheduler ―slave‖.

Each of the Tier 2 and Tier 3 schedulers also specify the scheduling parameters (Level, Weight, CIR_level and

CIR_weight). Recall that these values are used to determine the priority the scheduler will have during bandwidth

allocation by its parent.

32

Alcatel-Lucent C


ot Distribute

In order for the queues associated with the SAP to be scheduled according the HQoS requirements, the hierarchical-

scheduler policy must be configured on the SAP(s) of the desired service(s) in both/either the ingress and/or egress

directions. In the case of a multi-service site it must be configured in the customer instance, in both/either the

ingress and/or egress directions, as needed. When a hierarchical-scheduler policy is associated with a multi-service

customer site, the schedulers of the policy are available to any SAPs associated with the site. All the SAPs of this site

have to be associated with the same MDA.

33

Alcatel-Lucent C


ot Distribute

In the sap-ingress and sap-egress policies, the queues are configured with the additional HQoS related parameters, to

associate them with a parent scheduler and to dictate their priority relative to other queues or schedulers which

share a common parent.

In the above example, Queue 6‘s parent scheduler is ―top‖, which is also the parent of scheduler ―middle‖ and

―bottom‖ (as per the hierarchical-scheduler policy configuration shown previously). Given that Queue 6‘s CIR_level

value is greater than that of schedulers ―middle‖ and ―bottom‖ it will receives its CIR bandwidth allocation first.

Queues 4 and 3 share the same parent scheduler ―middle‖. As Queue 4 has a greater CIR_level it will receives its CIR

bandwidth allocation before Queue 3.

34

Alcatel-Lucent C


ot Distribute

Alcatel-Lucent C


ot Distribute

Policing and Shaping are the two functions of Traffic Management used for conformance monitoring. The traffic

conformance monitoring functions ensure that a traffic flow abides by its traffic contract so that if it misbehaves it

does not affect the QoS of other existing traffic flows in the multi-service network. If a traffic flow is transmitting at

a rate that is within its committed rate (CIR), and taking into account the tolerance to potential jitter which may

cause short bursts (Committed Burst Size - CBS), then the packets are conforming, otherwise they are considered

non-conforming.

Misbehaving traffic can be dealt with in one of two ways. The non-conforming packets can either be discarded or

tagged for discard (policing) or they can be rescheduled using buffering (shaping) such that the resulting traffic flow

becomes conforming and pass downstream policers.

With policing non-conforming packets are either tagged or immediately discarded. With shaping, non-conforming

packets are queued and re-scheduled at their contracted rate. During congestion, policing may result in more packet

loss (and thus re-transmissions) than when shaping is used. Conversely, shaping may result in more delay than when

policing is used. Thus the use of policing and shaping depends on the characteristics and requirements of the traffic

flow. For real-time traffic it is preferable not to shape and to minimize the potential for long queuing delays.

36

Alcatel-Lucent C


ot Distribute

The SR/ESS provides two policing approaches to enforce traffic conformance:

Combined policing and shaping approach on a per-queue, per SAP basis on ingress and egress, also known as

soft-policing.

SAP ingress queue shapeless policing with out-of-profile discard at egress, also known as hard-policing.

Irrespective of the policing approach adopted, SR/ESS never service a queue at a rate above its configured PIR, to

help the serviced traffic pass through down stream policer without any hindrance.

37

Alcatel-Lucent C


ot Distribute

The soft-policing approach relies on the queue scheduling rates. SAP queues that are serviced at a rate that is within

their CIR are in the in-profile state, and are serviced with a higher priority (recall the high priority scheduling loop of

the VoQ). The packets that are serviced within the queue‘s CIR rate are marked as in-profile and receive a higher

queuing priority. This means they are more likely to receive buffer space.

SAP queues that are serviced at a rate greater than their CIR but within their PIR are in the out-of-profile state, and

are serviced with a lower priority. The packets serviced above the queue‘s CIR (and within PIR) are marked as out-of-

profile and receive a lower queuing priority.

If traffic is arriving at the SAP queue at a rate greater than the queue‘s PIR, packets will start to buffer in the queue

up to a maximum depth defined by the MBS parameter. The queue can be serviced at a maximum rate equal to its

PIR, thus, if the packet arrival rate continues to exceed the PIR for an extended period of time, the queue will

eventually reach its maximum depth, and subsequent packets will be dropped. However, if the packet arrival rate

subsides the queue may start to empty out as the scheduler is servicing it at its CIR (or above, up to PIR if there is

bandwidth available).

Hence, traffic at a given SAP queue is both shaped to PIR and policed if the arrival rate persistently exceeds the

queue‘s PIR. This approach is applicable to non-real-time traffic that may be also be sensitive to packet loss. The

combined shaping and marking functionality ensures that no queue receives more than its PIR for all traffic, and CIR

for in-profile traffic. This prevents bandwidth starvation for other queues, while reducing the packet discard

probability for bursty traffic. This behaviour emulates a 2-bucket 2-colour policer. The extent to which burst

tolerance is provided to traffic is configured with the PIR and MBS parameters, and is a design decision the service

provider must make based on the characteristics and requirements of the traffic type.

38

Alcatel-Lucent C


ot Distribute

If the traffic arrival rate is less than CIR, the queue is serviced within CIR and thus is considered to be in the in-

profile state. The packets are marked as in-profile and receive high queuing priority.

If the traffic arrival rate bursts beyond CIR but remains within PIR, packets that are serviced within CIR are marked

as in-profile while the packets serviced at a rate between CIR and PIR are marked as out-of-profile and receive a low

queuing priority.

If the traffic arrival rate bursts beyond PIR but only for a period of time that is within MBS, the traffic will be shaped

at PIR, and some packets will be marked in-profile while others will be marked out-of-profile.

If the traffic arrival rate bursts beyond PIR for a period of time that exceeds MBS, the traffic will be policed and

excess packets will be dropped.

39

Alcatel-Lucent C


ot Distribute

The shapeless (hard) policing approach is offered on the ingress SAP on a per-queue basis. This approach allows

packets to flow through a queue unimpeded up to the queue‘s PIR, and immediately discards any excess packets

whose arrival rate exceeds PIR. All packets that are transmitted are in-profile. This approach is more suitable for real

time services where stricter delay commitments are required. Packet delay is minimised because the queue is

effectively scheduled at the available line rate, while emulating a 1-bucket 1-colour policer.

40

Alcatel-Lucent C


ot Distribute

A queue is configured to be real-time rate limiting by defining a rate and using the police keyword. Note that the

use of the police keyword is mutually exclusive with specifying a CIR value in the rate declaration statement. Also, a

queue must be in priority-mode to be real-time.

The slide above shows an example of a SAP-ingress QoS policy with queue 3 configured as real-time rate limiting and

queue 4 configured with the soft-policing approach. Traffic arriving at queue 3 will be policed at the rate of 100kbps.

Any traffic exceeding that rate will be discarded.

41

Alcatel-Lucent C


ot Distribute

42

Alcatel-Lucent C


ot Distribute

43

Alcatel-Lucent C


ot Distribute

44

Alcatel-Lucent C


ot Distribute

Learning Assessment Answers

1. Expedite queues and Best Effort queues. Expedite queues have a higher scheduling priority than Best Effort

queues, for traffic that is within CIR.

2. A VoQ is a pair of scheduling priority loops – one loop services traffic that is within CIR and one loop services

traffic that is above CIR (but within PIR)

3. The order of scheduling for the default scheduler is as follows: Round robin between traffic in Expedite queues

that is within CIR; Round robin between traffic in Best Effort queues that is within CIR; Biased round robin

between traffic in both Expedite and Best Effort queues that is above CIR and within PIR

4. To guarantee that EF traffic receives its bandwidth first, queue 5‘s CIR_level value must be greater than that of

the H2 traffic‘s queue.

5. Some of the packets will be marked in-profile and some will be marked out-of-profile, since the CIR is 200kbps,

but traffic is arriving at a rate of 500kbps. The traffic up to CIR will be schedule before traffic in Best effort

queues, and traffic beyond CIR will be scheduled after conforming traffic in the Best effort queue.

45

Alcatel-Lucent C


ot Distribute


Alcatel-Lucent C


ot Distribute








2

Alcatel-Lucent C


ot Distribute

Alcatel-Lucent C


ot Distribute

Constant Bit Rate (CBR) is used for ATM connections:

That carry constant bit rate traffic

Where there is a fixed timing relationship between samples

That require a guarantee of extremely low cell loss

That require an upper bound on delay

Real-time Variable Bit Rate (rt-VBR) is used for ATM connections:

That carry variable bit rate traffic

Where there is a fixed timing relationship between samples

That require a guarantee of very low cell loss

That require an upper bound on delay

Non-real-time Variable Bit Rate is used for ATM connections:


Where there is no timing relationship between samples

That require a guarantee of very low cell loss

That do not require an upper bound on delay

Unspecified Bit Rate is used for ATM connections:


Where there is no timing relationship between source and destination

Not requiring any guarantees on cell loss

Not requiring an upper bound on delay

4

Alcatel-Lucent C


ot Distribute

The Cell Loss Priority (CLP) bit indicates the relative priority of a cell.

There are two relative cell loss priority levels, these are:

CLP= 0 - High priority, only likely to be discarded in the event of severe congestion

CLP= 1 - Low priority, may be selectively discarded during congested periods

CLP_0/1 and in/out-profile mapping happens in the ingress direction.

CLP is transparent over A-Pipe, however it can be marked in ATM SAP in two cases:

ATM policing with tag can touch the CLP bit.

FR/ATM FRF.5 network interworking, DE and CLP mapping.

5

Alcatel-Lucent C


ot Distribute

Policing is used to enforce a traffic contract. The incoming traffic rate is monitored to verify that it conforms with

the contracted rate. If it does not the non-conforming cells may either be dropped or tagged.

Policing is disabled by default, and can only be enabled on the CBR and VBR service categories.

CBR traffic is policed at the configured PIR rate. Traffic exceeding PIR is discarded.

VBR traffic is policed at the configured SIR rate, and traffic exceeding it may either be discarded or tagged.

Partial Packet Discard (PPD) is a congestion avoidance mechanism which attempts to maximize transmission

efficiency during policing discards.

Once a cell of a PDU is discarded- all subsequent cells for that PDU are dropped, with the exception of the “tail cell”

which is sent to inform the far end that the end of a frame has arrived. The PDU cannot be reconstructed when one

or more cells is dropped, thus forwarding any subsequent cells of the PDU simply wastes bandwidth resources. PPD is

supported when the aal5 sdu mode of encapsulation is used. Goodput‟ refers to the transmission of cells which can

actually be reassembled into a packet.

6

Alcatel-Lucent C


ot Distribute

Shaping is applied by default to CBR and rt-VBR traffic and optionally on nrt-VBR traffic. UBR traffic is not shaped.

Shaping results in cells being transmitted such that they will conform with a downstream ATM UPC (Usage Parameter

Control) function. This is to reduce the likelihood of having cells discarded by the downstream device.

CBR traffic is shaped to its configured PIR value.

Rt-VBR and nrt-VBR traffic is shaped to its configured SIR value, with short bursts up to the PIR value, constrained by

the MBS value.

7

Alcatel-Lucent C


ot Distribute

Each SAP of an ATM VLL has an egress ATM traffic descriptor policy associated with it. By default the service category

is UBR and the MIR is 0. This means that traffic associated this SAP is scheduled at the lowest priority on the ATM

MDA.

On the ATM MDA egress traffic may be shaped or scheduled, depending on the egress ATM traffic descriptor

associated with the SAP. CBR traffic is transmitted at its PIR, while rt-VBR and shaped nrt-VBR traffic is transmitted

at its SIR with short busts up to its PIR. Un-shaped nrt-VBR and UBR traffic is scheduled on a Weighted Round Robin

scheduler, whereby a weight is assigned automatically based on the configured SIR and MIR for the nrt-VBR and UBR

traffic respectively. WRR scheduling of un-shaped nrt-VBR and UBR traffic does not apply a limit to the transmission

rate – the available port bandwidth is shared out by the scheduler based on the weight. Thus, if other traffic flows

(e.g. CBR, rt-VBR, shaped nrt-VBR) are quiescent, a given un-shaped nrt-VBR or UBR traffic flow may burst up to the

port bandwidth.

Shaping and scheduling of egress ATM VLL traffic is performed entirely at the ATM layer and thus is not forwarding-

class-aware

8

Alcatel-Lucent C


ot Distribute

Incoming ATM traffic is classified according to its service category and CLP marking. It is optionally policed at the

ATM MDA, and potentially discarded if it exceeds its contracted rate.

There is no queuing point in the ingress data path between the ATM MDA and IOM, and thus the ATM MDA is lossless as

there is no congestion point.

The ATM traffic coming from the ATM VLL SAP is mapped to a Forwarding Class based on the default forwarding class

configuration on the sap-ingress policy associated with the SAP.

At the ingress of the IOM (Layer 3) each sap of an ATM VLL has a single ingress service queue with default scheduling

parameters of: CIR=0 and PIR=line rate. A non-default QoS policy allows the CIR/PIR to be controlled, regardless of

whether ATM policing is configured.

At the network egress FC-to-EXP mapping is defined by the network QoS policy in the egress direction as usual. At the

network ingress the EXP to FC mapping is also defined by the network QoS policy in the ingress direction.

9

Alcatel-Lucent C


ot Distribute

At the egress of the IOM each SAP of an ATM VLL has a single egress service queue with default scheduling parameters

of: CIR=0 and PIR=line rate. A non-default QoS policy allows the CIR/PIR of the outgoing traffic to be controlled,

regardless of whether ATM shaping is configured.

If traffic is exiting the ATM SAP at a rate exceeding the configured rate congestion will occur, and the ATM MDA will

exert backpressure to the IOM. Therefore, any discards will occur on the IOM at the packet level (layer 3), and not on

the ATM MDA at the cell level.

VC isolation is achieved by enforcing per-VC queue thresholds. Once this threshold is reached, backpressure is applied

on the Layer 3 queues stopping the flow of packets into the per-VC queue in the MDA. When the cells are drained and

the queue utilization for the VC drops below the threshold, the backpressure on the Layer 3 queues is removed.

There are two kinds of backpressure mechanisms - port backpressure is applied when the buffer threshold for the

port is reached and it affects all VCs on the port. VC Backpressure is applied when the per-VC threshold is exceeded

and it affects just the VC whose threshold has been exceeded. The per-VC thresholds are calculated based on the

configured rate of the VC, i.e., PIR for CBR, SIR for rt-VBR and nrt-VBR, and MIR for UBR.

10

Alcatel-Lucent C


ot Distribute

When Ethernet frames are sent over an ATM VC, the scheduling of data occurs at two main levels: packet level

scheduling and per-VC cell level scheduling.

At the first level, packets are queued on a per-CoS (or forwarding class), per-VC basis in order to achieve the proper

class of service differentiation for the frames in the same VC. Each packet is queued based on the VC dedicated

forwarding class queue, as configured in the SAP-egress QoS policy. The packet level scheduling can make use of a

HQoS scheduler policy in order to enforce aggregate bandwidth among a group of queues feeding an ATM VC or to

enforce aggregation of bandwidth across all queues of all VCs at a given customer site.

The frame level scheduling is the same for other types of SAP (Ethernet, FR, and PPP) and all the features available

on the SAP-ingress and SAP-egress QoS policies can be applied.

At the second level, the segmented cells are queued in per-VC queues according to the service category of the ATM

Traffic Descriptor profile applied to the ATM SAP. Scheduling at the ATM level enforces the priority and bandwidth

sharing desired at the cell level.

As mentioned previously, any discard decision are performed exclusively at the packet level. When a per-VC queue

backs up, a backpressure scheme is applied such that the frames are held in the per-forwarding class packet queues

dedicated to this VC.

11

Alcatel-Lucent C


ot Distribute

Cells of a shaped VC flow into two queues which are associated with the VC. The high priority cell queue is serviced

with strict priority over the low priority cell queue of the VC. Traffic from the sets of high and low priority packet

queues of the corresponding SAP flows into the high and low priority cell queues respectively. The packet queue

priority refers to the priority of the forwarding class queues as defined by the Layer 3 SAP egress QoS policy (i.e.

expedited vs. best effort). When the threshold on the high priority cell queue is exceeded, backpressure notification

stops the flow of packets from all the high priority queues of the corresponding SAP in the packet queue. When the

threshold on the low priority cell queue is exceeded, backpressure notification stops the flow of packets from all the

low priority queues of the corresponding SAP.

For a non-shaped VC, a single queue is used in the ATM MDA. When the cell queue threshold is exceeded, traffic flow

is stopped on all packet queues (high and low priority) of the corresponding SAP.

12

Alcatel-Lucent C


ot Distribute

Alcatel-Lucent C


ot Distribute

14

Alcatel-Lucent C


ot Distribute

qos

— [no] atm-td-profile traffic-desc-profile-id

— description description-string

— no description

— descriptor-type type

— [no] policing

— service-category service-category

— [no] shaping

— traffic [sir sir-val] [pir pir-val] [mir mir-val] [mbs mbs-val] [cdvt cdvt-val]

15

Alcatel-Lucent C


ot Distribute

Descriptor-type - This command is used to specify the type of the traffic descriptor profile as per ATM Forum Traffic Management

Specification Version 4.1. Parameter Values: P0_1, P0_1andS0_Tag, P0_1andS0, P0_1andS0_1

Policing – This command determines whether ingress traffic is policed. Policing is valid for CBR, RT-VBR and NRT-VBR. This is cell-

based policing.

Default is disabled.

Service Category - This command is used to configure an ATM service category attribute of an ATM traffic descriptor profile per ATM

Forum Traffic Management Specification Version 4.1. Parameter Values: cbr, rt-vbr, nrt-vbr, ubr.

Shaping - This command determines whether egress shaping should occur. Shaping is only applied in the egress direction. The

default is determined by the service category. The following default applies for shaping depending upon a given service category:

Cbr – shaping enabled and cannot be disabled

Rt-vbr – shaping enabled and cannot be disabled

Nrt-vbr – shaping enabled and can be enabled

Ubr – shaping disabled and cannot be enabled

Traffic - This command is used to configure traffic attributes of an ATM traffic profile as per ATM Forum Traffic Management

Specification Version 4.1.

The traffic parameters of a traffic descriptor that are configurable depends on the service category of this traffic descriptor profile

(see the service-category command). The following defines which traffic descriptor parameters are applicable for what service

category and what are configuration rules between the parameters.

Service Category SIR PIR MBS MIR cdvt

CBR – PIR, CDVT

rt-VBR – PIR (must be > SIR), SIR, MBS

Nrt-VBR - PIR (must be > SIR), SIR, MBS

UBR – PIR

UBR with MIR – PIR (must be > MIR), MIR

16

Alcatel-Lucent C


ot Distribute

17

Alcatel-Lucent C


ot Distribute

18

Alcatel-Lucent C


ot Distribute

This case study demonstrates how both the atm-td-profile and SAP-ingress and egress policies are used to enable the

router (PE1) to discard ATM cells with its CLP bit set to 1 when congestion occurs on the egress OC3 port.

Two apipes are configured, one to carry cbr traffic and one for nrt-vbr traffic. A atm-td-profile policy is created for

each with the parameters set as shown in the diagram.

The atm-td-profile policy applied to apipe 1000 carrying nrt-vbr traffic has been configured to tag cells which exceed

the configured SIR rate of 20Mbps.

19

Alcatel-Lucent C


ot Distribute

50Mb/s of traffic is sent to apipe 1000. The traffic rate is within PIR, thus there are no cell discards at either PE

routers. However, the traffic rate does exceed the SIR value, thus cells above the SIR are tagged by policing at the

ingress of PE2. Thus there are both „in-profile‟ and „out-of-profile‟ packets entering the network.

At PE1 all the traffic arrives as “out-profile”. This is because the default SAP-ingress policy classifies all traffic as BE

„out-of-profile‟. To fix this a sap-ingress policy is configured (policy ID 100) at PE2, and applied to both apipe 1000

and 1001.

Now both “in-profile” and “out-profile” packets are seen in apipe 1000 at PE1. In apipe 1001 all packets are „in-

profile‟ at PE2, since cbr traffic is always considered „in-profile‟.

20

Alcatel-Lucent C


ot Distribute

When 120Mb/s of traffic is sent on apipe 1001 at PE2 congestion occurs at the egress OC3 port on PE1, as there is

120Mbps of cbr traffic and 50Mbps of nrt-vbr traffic trying to exit PE1 through an OC3 (150Mbps). As cbr traffic is

scheduled before nrt-vbr traffic at the egress of the ATM MDA, backpressure will occur on the nrt-vbr queue resulting

in drops of both “in-profile” and “out-profile” packets on apipe 1000 at the egress on PE1

In order to have PE2 only drop packets that are „out-of-profile‟ during this congested state, a sap-egress policy is

configured on PE1 and applied to apipe 1000, in which the High-Priority Only value of the queue is set to 98%. This

ensures that packets marked „in-profile‟ get preference over packets marked „out-of-profile‟. With the sap-egress

policy applied on apipe 1000, only “out-profile” packets get dropped.

21

Alcatel-Lucent C


ot Distribute

22

Alcatel-Lucent C


ot Distribute

23

Alcatel-Lucent C


ot Distribute


1. True. cbr is CLP transparent, therefore, regardless of whether the CLP bit of a cell is 0 or 1, it is considered to be

„in-profile‟.

2. Rt-vbr is always shaped. Nrt-vbr can optionally be configured to be shaped. In both cases they are shaped at SIR.

3. If either the port threshold or the per-vc threshold is reached backpressure to the IOM occurs. Any discards that

may ensue occur at the packet level queues.

4. Traffic from the different service categories is scheduled as follows:

1. Cbr traffic exhaustively over all other traffic

2. Rt-vbr exhaustively over all traffic below

3. Shaped nrt-vbr exhaustively over all traffic below

4. Un-shaped nrt-vbr in WRR with other unshaped nrt-vbr and UBR traffic, where its weight is based on its

SIR

5. UBR(+mir) in WRR with unshaped nrt-VBR and ubr traffic

5. The cells will be tagged. (i.e. the CLP bit is set to 1).

24

Alcatel-Lucent C


ot Distribute


Alcatel-Lucent C


ot Distribute








2

Alcatel-Lucent C


ot Distribute

3

Alcatel-Lucent C


ot Distribute

This case study is meant to demonstrate the overall process for planning and implementing a QoS strategy in the

network. The goal is to highlight the different components that must be considered in establishing a QoS strategy and

to bring together the various qos policies and features discussed in the previous modules. The case study presented

and the values used throughout are an example, and is not to be taken as a definitive guide to designing qos policies

or determining appropriate configuration parameter values. The values to use in any qos policy is highly dependent

on the specific situation and requirements of the service provider, and must be determined on a case by case basis.

Furthermore, as with all aspects of network design, there are often multiple possible solutions to a given design

requirement.

4

Alcatel-Lucent C


ot Distribute

5

Alcatel-Lucent C


ot Distribute

The Alcatel-Lucent Router is based on the service model where service edge routers are deployed at the provider

edge. Services are provisioned on the router and transported across an IP and/or IP/MPLS provider core network in

encapsulation tunnels created using Generic Router Encapsulation (GRE) or MPLS Label Switched Paths (LSPs).

The service model uses logical service entities to construct a service. The logical service entities are designed to

provide a uniform, service-centric configuration, management, and billing model for service provisioning.

The Service model is based on the following components:

Subscribers

SAP

Customer

Service

SDP

Service Tunnels

6

Alcatel-Lucent C


ot Distribute

7

Alcatel-Lucent C


ot Distribute

Service Distribution Path (SDP)

A SDP acts as a logical way of directing traffic from one 7750 SR to another through a uni-directional service tunnel.

An SDP originating on one node terminates at a destination node, which then directs incoming packets to the correct

service egress SAPs on that node. A multi-node service needs at least one SAP and one SDP on each node. For a

service to be bi-directional, a SDP must be provisioned on each node participating in the service. The transport

tunnels to which SDP is bound can be GRE based or MPLS based, using either LDP or RSVP-TE signaling.

Consider the following SDP characteristics:

SDPs can be created as either GRE or MPLS.

Each multi-site service must have an SDP defined for every remote PE to provide ePipe, VPLS, and VPRN

services.

A service must be bound to an SDP. By default, no SDP is associated with a service. Once an SDP is

created, services can be associated with that SDP.

An SDP is not specific or exclusive to any one service or any type of service. An SDP can have more than

one service bound to it.

In order to configure an MPLS SDP, an MPLS infrastructure must be in place.

In the SDP configuration, automatic ingress and egress labeling (targeted LDP) is enabled by default.

Ingress and egress VC labels are signaled over a TLDP connection between two PE routers.

Note: if signaling on an SDP is disabled, service labels must be manually configured.

8

Alcatel-Lucent C


ot Distribute

Service Access Point (SAP)

A SAP is a logical entity that serves as the customer’s point of access into a service. Each subscriber service is configured with at least one SAP. A SAP can only be configured on a port that has been configured as an access port.

The default configuration for most ports is network, which means that you may need to reconfigure a port before you can configure a SAP on it. SAPs for IES and VPRN services are configured on IP interfaces.

ePipe:

SAPs can be defined on Ethernet ports, SONET/SDH or TDM channels

Two SAPs are defined for a service that originates and terminates on the same 7750 SR; one SAP and one SDP are defined for each 7750 SR in a two-node ePipe service

IES:

SAPs can be defined on Ethernet ports, SONET/SDH or TDM channels

SAPs are associated with an IP interface; one SAP per logical interface

VPLS:

SAPs can be defined on Ethernet or POS (BCP) interfaces

VPRN:

SAPs can be defined on Ethernet ports or SONET/SDH (IPCP) interfaces

Apipe:

SAPs can be defined on ATM OC3/OC12 ports.

Consider the following when configuring a SAP:

A SAP is locally unique, in other words the same SAP ID value can be used on another 7750 SR

A SAP is associated with a single service and can only be configured on an access port

A port or channel can have more than one SAP configured on it

All SAPs must be explicitly created and are administratively enabled at the time of creation (no default SAPs)

VLAN IDs have local significance.

9

Alcatel-Lucent C


ot Distribute

By default ATM ports are configured as mode access.

The Apipe service that extends between the two PEs has one SAP and one SDP on each PE.

The max-cells parameter specifies the maximum number of ATM cells that will be concatenated together into a single

packet before forwarding it.

The max-delay parameter specifies the maximum amount of time the node will wait for a packet to fill up with ATM

cells, before forwarding it.

The packet will be forwarded when the first of these thresholds is met.

10

Alcatel-Lucent C


ot Distribute

Recall that by default ethernet ports are configured as network mode. To configure a port as a SAP it must first be

configured as access mode.

The VPLS service between the two PEs, has one SAP and one mesh-sdp on each PE. Note that in this example the VPLS

consists only of two sites, and as such essentially behaves like an ePipe service (point-to-point). In practice, there

would be multiple other sites either on the same PEs or on other PEs.

CLI Syntax: A:RouterC>config#

port 1/1/1

ethernet

mode access

exit

no shutdown

exit

11

Alcatel-Lucent C


ot Distribute

The diagram shows one Apipe service, however in this case study there are 3 Apipe services, one for each of the

following service categories: CBR, nrt-VBR and UBR.

All services can use the same SDP.

12

Alcatel-Lucent C


ot Distribute

The service provider must determine and identify the types of services they will offer, and the type of traffic that

will traverse the network, in order to apply an appropriate traffic classification policy. They must also determine the

characteristics of the types of traffic, and the expected bandwidth requirements for each.

The service provider plans to offer three different levels of services identified as, Premium, Enhanced and Standard.

Premium services consists of traffic that requires minimal end-to-end delay, jitter and packet loss.

Enhanced services consists of traffic that requires minimal packet loss and jitter and reasonable end-to-end

delay.

Standard services consists of traffic that requires minimal packet loss, but can tolerate delay.

The service provider’s own network control traffic, such as routing and signaling protocol traffic, or SNMP traffic for

network management must also be taken into consideration.

13

Alcatel-Lucent C


ot Distribute

The service provider wants to start migrating the traffic from its ATM network onto its 7x50 SR IP/MPLS network. It

plans to do so by removing the OC12 links between the core ATM switches and using instead the IP/MPLS network to

transport the ATM traffic between the core ATM switches. The service provider will do this by emulating the OC12

links using ATM VLLs or Apipes. The ATM network carries CBR, nrt-VBR and UBR traffic, and as such, the service

provider will use 3 separate Apipes – one per ATM service category – to transport the ATM traffic from one ATM switch

to the other, across the IP/MPLS network.

14

Alcatel-Lucent C


ot Distribute

After having identified the various types of traffic which will traverse the network, the service provider decides to

classify traffic as per the above table. Traffic with similar characteristics or SLA requirements are mapped to the

same Forwarding Class.

15

Alcatel-Lucent C


ot Distribute

The classification of traffic within the network is applied with the ‘network policy’ which is applied at the network

interfaces. The network policy is split into two sections, ingress and egress. The ingress section defines the EXP and

DSCP mappings into the internal forwarding classes for traffic entering the node. The mapping at the network ingress

must retain and conform with traffic QoS classification done at the service ingress (service classification is addressed

later on). The egress section defines the egress marking to be applied to traffic that has not already been marked.

Hence egress marking is applied only by the source node as transit nodes forward traffic that has already been

marked. That is, on transit nodes, traffic entering the node has already been marked (at the source node) and should

not be re-marked.

Traffic in the Apipe and VPLS services are transported inside MPLS packets and as such the EXP bits are used for

marking. The network policy must specify the mapping from Forwarding Class to EXP bit at the egress. As stated

above, this marking will apply only at the source node.

Once traffic has entered the service provider’s network, and has been marked, there is no need to remark the traffic

within the network.

Only one network policy should be applied within the entire network regardless of the speed/media of interfaces in

order to ensure that traffic is treated in the same manner across the whole network.

16

Alcatel-Lucent C


ot Distribute

Any packet that has an undefined EXP (or DSCP) value is mapped to the default Forwarding Class specified (BE) and is

marked as out-of-profile.

17

Alcatel-Lucent C


ot Distribute

18

Alcatel-Lucent C


ot Distribute

Recall that there is a default network policy defined and automatically applied to every interface configured.

19

Alcatel-Lucent C


ot Distribute

Each Forwarding Class is mapped to its own queue. Thus all ATM CBR traffic, for example, is queued in Queue 7.

Queue 1 is used for any traffic that has been mis-classified. There should normally be no traffic in Queue 1, however,

by mapping these forwarding classes to Queue 1 when the service provider monitors the port statistics and sees

traffic in Queue 1 they will know that there is some traffic entering their network that is not classified according to

their defined policy.

20

Alcatel-Lucent C


ot Distribute

The ‘rate’ parameter within a network-queue policy defines the percentage of the outgoing bandwidth that is available to a given queue. The CIR rate sub-parameter within a network-queue policy specifies the percentage at which the system prioritises the queue over other queues competing for the same bandwidth.

The CIR value of each queue is set according to the expected bandwidth required for the combined ATM and packet traffic mapped to that queue. Oversubscription is not desired, thus the sum of the CIR values for all queues should not exceed 100%.

The Rate value of each queue is based on how much, if any, burst in traffic is allowed. This depends on the type of traffic.

The ATM CBR traffic is expected to be arriving at a constant rate, and therefore no burst should occur. As such, its Rate value is set equal to its CIR value. The maximum expected ATM CBR traffic is 300Mbps, which is about 30% of a 1Gig port, thus the Rate and CIR are set to 30%

The Network Control traffic requires little bandwidth, but is critical to the proper functioning of the network and must therefore be guaranteed some bandwidth. As there is no desire to restrict Network Control traffic, its Rate can be left at the maximum. Thus the CIR is set to 2% and the Rate at 100%.

The Premium traffic is expected to be about 20% of the port capacity and should have this amount of bandwidth guaranteed. The Premium traffic is bursty in nature, and should be allowed to burst at higher rates, when bandwidth is available. The CIR is set to 20% while the Rate is set to 50%.

The Enhanced traffic is expected to be about 30% of the port capacity, while the nrt-VBR ATM traffic is expected to be about 100Mbps (or 10% of a 1 Gig port). This traffic is also bursty in nature and should be allowed to use more bandwidth when it is available. The CIR is set to 40% and the Rate to 100%

The Standard traffic is expected to be about 35% of the port capacity, while the UBR ATM traffic is expected to be about 200Mbps (or 20% of a 1 Gig port). However, as this traffic is considered best effort, it does not have to be guaranteed its expected bandwidth. However, in the absence of other higher priority traffic, it should be able to make use of all the available bandwidth. The CIR is set to 8% and the Rate to 100%.

Note that although the Forwarding Classes H2, L2 and BE Queue 1 to which they map, is allocated a non-zero Rate, in case some traffic entering the network happens to be classified into these FCs, as a result of a mis-configuration or oversight. Otherwise, with a Rate of 0, any traffic mapped to these queues will be dropped.

21

Alcatel-Lucent C


ot Distribute

The CBS and MBS define the buffer allocation for each queue. CBS defines the guaranteed (committed) buffer space and is taken

from the reserved portion of the buffer pool. MBS defines the maximum buffer allocation and is taken from the shared portion of the

buffer pool. For network queues, this is defined as a percentage of the total available pools, where the available pool depends on

the type of port.

The allocation of CBS and MBS depends on the nature of the traffic to be placed in the queue. The characteristics to take into

consideration include, burstiness, latency sensitivity, traffic throttling mechanism.

The CBS and MBS values are specified as percentages of the buffer pool, but in effect represent the maximum delay a packet may

encounter while waiting in the queue to be serviced. The CBS can be determined based on a servicing rate equal to the CIR of the

queue, as this gives the maximum delay the packets may encounter in the reserved portion of the queue based on the rate

committed. The MBS can be determined based on a servicing rate equal to the PIR, as this gives the maximum delay the packets may

encounter in the queue based on the maximum possible rate at which the queue can be serviced.

Some points to consider:

Traffic that is sensitive to delay and jitter should not be queued for too long, and as such should have small queues.

Traffic in queues that are scheduled first (i.e. the Expedite queue type) should not be subject to congestion and thus the

queues should never significantly fill up. Therefore, Expedite queues do not need to be very large.

Traffic that is not sensitive to delays, but that is sensitive to packet loss should be allocated to larger queues which can

absorb bursts.

Traffic such as UDP which has no built in throttling mechanism should not be allowed to use the shared buffer space, since

congestion management mechanisms such as WRED would have no effect on the traffic rate. On the other hand, TCP traffic

which does throttle back its traffic rate when packet drops are detected, will take advantage of WRED, and thus, should be

allowed to make use of the share buffer space.

The High-priority only parameter is useful in the case where traffic in the same queue may have different markings (i.e. in-profile or

out-of-profile). In such a case, during periods of congestion it is desirable to apply congestion control mechanisms which will give

preferential treatment to traffic that is respecting its traffic contract. Using the HPO parameter a portion of the queue buffer space

can be reserved exclusively for In-profile traffic.

22

Alcatel-Lucent C


ot Distribute

The Network Control traffic is small but bursty and is critical to the proper functioning of the network and

must therefore be guaranteed some buffer space. The MBS and CBS values of Queue 8 are both set to 5% to

give a maximum buffer occupancy time of 8ms, and the HPO is left at its default value.

The ATM CBR traffic is not bursty, is delay sensitive, and is considered high priority. Therefore it is allocated

some reserved buffer space and has its MBS value equal to its CBS value to minimize latency. Also, as it is

scheduled ahead of most other traffic, it should not experience congestion and thus does not require a large

queue. Both the MBS and CBS of Queue 7 are configured to be 3% in order to guarantee the buffer space and

not to let the buffer occupancy exceed 5ms worth of CBR traffic. All traffic in this queue should normally be

In-profile, thus the HPO value is left at its default.

The Premium traffic is scheduled ahead of most other traffic and thus is not expected to encounter

congestion within the network and as such will never queue to any significant amount. It does not need a

large queue, but does need guaranteed buffer space. The majority of traffic will be of non-responsive nature

such as UDP which has no inherent congestion control mechanism. For this reason, the Premium traffic

should not be allowed to buffer into the shared buffer space where WRED will be enabled (slope policy is

addressed later) . Thus, MBS and CBS values for Queue 6 are both set to 5% and HPO to its default.

The Enhanced traffic and nrt-VBR ATM traffic may burst and can tolerate reasonable delay. The traffic in this

forwarding class is expected to consist largely of TCP based traffic and as such is responsive to congestion

control mechanisms. Thus, it will be allowed to make use of the shared buffer space. For Queue 4 the MBS is

set to 100% and the CBS to 30%. As the traffic can be in-profile or out-of-profile some of the buffer space

should be reserved for In-profile traffic, by setting HPO to 50%.

The Standard traffic and UBR ATM traffic is not sensitive to delay and can be very bursty. The traffic in this

forwarding class is also expected to consist largely of TCP based traffic and as such is responsive to

congestion control mechanisms. Thus, it will be allowed to make use of the shared buffer space. For Queue 3

the MBS is set to 100% and its CBS to 20%. As the traffic can be in-profile or out-of-profile some of the buffer

space should be reserved for In-profile traffic, by setting HPO to 30%.

Queue 1 for best effort forwarding class traffic should have no traffic, but to accommodate any traffic which

may have entered the network without being correctly classified, only shared buffer space is allocated to the

queue. Its MBS is set to 50% and its CBS to 0%. HPO is left at the default of 10%.

23

Alcatel-Lucent C


ot Distribute

Only the queue configuration portion of the network queue policy is shown above.

The multipoint queues are not shown.

24

Alcatel-Lucent C


ot Distribute

25

Alcatel-Lucent C


ot Distribute

Recall that there is one default network queue policy defined, and applied to every network port and MDA network

ingress by default.

26

Alcatel-Lucent C


ot Distribute

The use of shared buffer space must be controlled to ensure that out-of-profile traffic is discarded before in-profile

traffic, when congestion occurs. This is achieved using WRED applied with the slope-policy.

Given the queue configuration only Enhanced and Standard traffic types are subject to WRED buffer management.

WRED drops traffic with increasing probability as the shared buffer occupancy increases. Responsive flows such as

TCP will respond to WRED random drops by reducing the rate at which traffic is transmitted, resulting in a more

stable utilisation of network resources. However, UDP type traffic does not respond to WRED random drops.

To ensure that Out-of-profile traffic is dropped before In-profile traffic, when congestion occurs, the slope-policy is

configured with a ‘low slope’ and a ‘high slope’. The ‘low slope’ specifies when the node will start to drop Out-of-

profile traffic, while the ‘high slope’ specifies when In-profile traffic will be dropped. All Out-of-profile traffic is to

be dropped before any In-Profile traffic is.

The ‘low slope’ is configured with start-avg, max-avg and max-prob set to 40%, 65%, 80% respectively.

The ‘high slope’ is configured with start-avg, max-avg and max-prob set to 70%, 90%, 80% respectively.

The time average factor (TAF) effectively defines the ‘responsiveness’ of the WRED function. A lower TAF means

that WRED is very quick to respond to buffer depth changes; conversely, a higher TAF means that WRED is very slow

to respond to network changes. To accommodate both transient burst of traffic, and still enable WRED to respond in

a timely manner to increasing congestion, the TAF value is left at its default of 7.

27

Alcatel-Lucent C


ot Distribute

28

Alcatel-Lucent C


ot Distribute

Recall that there is a default slope policy defined but that it is shutdown by default.

29

Alcatel-Lucent C


ot Distribute

CBR, nrt-VBR and UBR traffic is classified to Forwarding Classes H1, L1 and AF and to queues 7, 4 and 3 respectively,

as per the network policies.

For the CBR queue, both the MBS and CBS are configured to be 4 Kbytes in order to guarantee the buffer space and

not to let the buffer occupancy exceed 100 microsecond worth of CBR traffic, based on the assumption that the

servicing rate is at 300Mbps. Since there is about 300Mbps of traffic expected and it is constant, the CIR are set to

300Mbps.

For VBR queue the CBS is configured to be 12 Kbytes in order to guarantee a buffer space of at least 1 millisecond

worth of VBR traffic based on the assumption that the servicing rate is at 100Mbps. MBS is left at the default value to

allow for burst. The CIR is set to the expected traffic rate of 100 Mbps.

For UBR queue the CBS is configured to be 3 Kbytes in order to guarantee some buffer space and MBS is left at the

default value to allow for burst. The CIR is set to the expected traffic rate of 200 Mbps.

For all three queues, the Rate is set to ‘max’ to allow each queue to be serviced beyond its committed rate, when

bandwidth is available.

In order to guarantee that the CBR and VBR Apipe services receive their configured CIR values the scheduler

adaptation rule for the respective traffic queues are configured to be ‘min’.

30

Alcatel-Lucent C


ot Distribute

Based on the service provider’s analysis of expected traffic rates for CBR, nrt-VBR and UBR traffic across the

corresponding Apipes (300Mbps, 100Mbps and 200Mbps respectively), the PIR and SIR/MIR values are set accordingly.

Policing is disabled as this is typically performed at the ATM UNI (i.e. the interface between the service provider’s

ATM switch and its customer’s CPE), and as such is not required within the service provider’s own network.

In the ATM MDA scheduling between non-shaped nrt-VBR traffic and UBR traffic is through CBWRR. For a nrt-VBR

connection, the configured SIR value is used as the weight. For a UBR connection, the configured MIR value is used as

the weight. Given the SIR/MIR values of the nrt-VBR and UBR queues, the service ratio between them is 2:1 for the

UBR queue.

31

Alcatel-Lucent C


ot Distribute

The sap-ingress policy 30 is applied to the Apipe for CBR traffic.

32

Alcatel-Lucent C


ot Distribute

These are the SAP-ingress policies for the VBR and UBR Apipes.

33

Alcatel-Lucent C


ot Distribute

The SAP-egress policies are identical to their SAP-ingress counter-parts, with the exception that no default

forwarding class is configured.

34

Alcatel-Lucent C


ot Distribute

35

Alcatel-Lucent C


ot Distribute

The Traffic descriptor profiles applied to the SAP egress is identical to the Traffic Descriptor profile created for the

SAP ingress. The same Traffic Descriptor profile could be used for both ingress and egress. However, two separate

profiles were used, to allow the flexibility of changing any of the Traffic Descriptor parameters on either the ingress

or egress side.

36

Alcatel-Lucent C


ot Distribute

37

Alcatel-Lucent C


ot Distribute

Each customer of the VPLS service will transmit traffic which fall into three categories: Premium, Enhanced and

Standard, to align with the service provider’s overall service categories. The customer is assumed to mark its traffic

appropriately to correspond to one of the three categories, using the dot1p bits of the ethernet frames.

The Premium traffic is scheduled ahead of most other traffic and thus is not expected to encounter congestion within

the network and as such will never queue to any significant amount. To ensure that the Premium queue does not

introduce additional delay/jitter to real-time traffic by holding packets in buffers for any prolonged period, a

minimal amount of buffer space is allocated to this queue. The offered rate for this service is 10Mbps. The MBS and

CBS for queue 6 is set to have a maximum buffer latency of 1ms. MBS and CBS are set to 2 kbytes. The service rate is

taken to be the ‘rate’ value.

The Enhanced traffic may burst and can tolerate reasonable delay. The guaranteed rate for this service is 15Mbps but

it can burst to 40Mbps. The MBS for queue 4 is set to have a maximum buffer latency of 100ms. MBS is set to 188

kbytes. The CBS is left at default. The service rate is taken to be the ‘cir’ value.

The Standard traffic is not sensitive to delay and can be very bursty. The guaranteed rate for this service is 5Mbps,

but it is allowed to burst to 100Mbps. The MBS for queue 3 is also set to have a maximum buffer latency of 100ms.

MBS is set to 63 kbytes. The CBS is left at default. The service rate is taken to be the ‘cir’ value.

Queue 1 used for the unmatched traffic is left at its default values.

38

Alcatel-Lucent C


ot Distribute

39

Alcatel-Lucent C


ot Distribute

The SAP-egress policies are identical to their SAP-ingress counter-parts, with the exception that no forwarding class

mapping needs to be configured.

40

Alcatel-Lucent C


ot Distribute

41

Alcatel-Lucent C


ot Distribute

A hierarchical scheduler policy is used in order to rate limit the sum of all classes of service on the SAP to 100Mbps.

The customer can send any combination of Premium, Enhanced and Standard traffic that conforms to their specified

PIR values while not exceeding the overall rate of 100Mbps.

The Premium service queue is serviced in strict priority over other queues.

The Enhanced service queue is serviced along with the Standard queue. The queue is offered 3/4 of the servicing

opportunities for level 1 when the queue is in profile (serviced below CIR) and equally shares any excess available

bandwidth if the queue is being serviced above CIR.

The Standard queue is serviced along with the Enhanced queue. The queue is offered 1/4 of the servicing

opportunities for level 1 when the queue is in profile (serviced below CIR) and equally shares any excess available

bandwidth if the queue is being serviced above CIR.

42

Alcatel-Lucent C


ot Distribute

The Premium service queue is serviced before the other queues, since its CIR_level is 5 (higher than the other two

queues). It is allocated its CIR bandwidth of 10Mbps. The remaining bandwidth (90Mbps) is allocated to the other two

queues.

The Enhanced and Standard service queues have the same CIR_level. Since there is sufficient bandwidth to satisfy

their CIR requirement, both queues receive their CIR bandwidth of 15Mbps and 5Mbps respectively. The remaining

available bandwidth is 70Mbps.

The Premium service queue has priority for using the extra bandwidth available, but as it has already received its

PIR’s worth of bandwidth it does not need anymore. The Enhanced and Standard service queues equally share the

extra bandwidth, up to a maximum of their PIR. The Enhanced queue would receive an additional 25Mbps to reach its

PIR, while the Standard queue would receive and additional 95Mbps to reach its PIR. There is only 70Mbps left. Each

queue is entitle to receive an additional 35Mbps. As the Enhanced queue only needs 25Mbps, the Standard queue

receives the remaining 45Mbps.

When there is traffic arriving at all queues, their PIR/CIR values will be:

Premium: 10Mbps/10Mbps

Enhanced: 40Mbps/15Mbps

Standard: 50Mbps/5Mbps

If there is less, or no Enhanced or Premium traffic sent, then the Standard queue can be serviced at a higher rate,

possibly reaching its PIR of 100Mbps.

43

Alcatel-Lucent C


ot Distribute

A scheduler policy can be applied to SAPs from any service for which the rate sold to the customer’s is 100Mbps.

44

Alcatel-Lucent C


ot Distribute

The queues defined in the SAP-ingress and SAP-egress policies are assigned the appropriate scheduler, from the

scheduler-policy that has been applied to the SAP.

45

Alcatel-Lucent C


ot Distribute

46

Alcatel-Lucent C


ot Distribute

47

Alcatel-Lucent C


ot Distribute

The SAP-ingress policy classifies the customer’s packets to Forwarding Classes based on the dot1p marking

which they would have applied.

The traffic is then queued at the ingress SAP according to their Forwarding Class, and is scheduled towards

the switch fabric according to the scheduler policy and the configured level, weight, CIR_level and

CIR_weight parameters configured for each queue.

At the egress of PE1 traffic is queued at the egress port based on the Forwarding Class to queue mapping

defined in the network queue policy. The traffic is also marked to the appropriate EXP bit based on the

Forwarding Class to EXP mapping defined in the network policy.

At the ingress of P, traffic is mapped to the Forwarding Class according to the EXP bit of the MPLS header, as

defined in the network policy and placed in the corresponding queue, as defined in the network queue policy.

At the egress of P traffic is queued at the egress port based on its FC (as assigned at the ingress), and as

defined by the FC to queue mapping in the network queue policy. The traffic is not remarked at the egress,

and thus maintains the EXP value that was assigned at the egress of PE1.

At the ingress of PE2, traffic is mapped to the Forwarding Class according to the EXP bit of the MPLS header,

as defined in the network policy and placed in the corresponding queue, as defined in the network queue

policy. The MPLS header is stripped off.

At the egress of PE2, traffic is queued at the egress SAP based on its FC (as assigned at the ingress), and as

defined by the FC to queue mapping in the SAP-egress policy. The traffic is scheduled towards the port to the

customer according to the scheduler policy and the configured level, weight, CIR_level and CIR_weight

parameters configured for each queue.

The dot1p marking is retained across the service provider’s IP/MPLS network, and used within the customer’s

network.

48

Alcatel-Lucent C


ot Distribute

There are three separate Apipe services each transporting ATM traffic of one type of service category – CBR,

nrt-VBR or UBR. Thus, at the ingress of PE1, the SAP-ingress policy of each Apipe maps all incoming traffic to

a single Forwarding Class, using the ‘default-fc’ option and places all traffic in a single queue. That is, the

‘CBR Apipe’ classifies all incoming traffic to FC h1 and puts the traffic in queue 7. The ‘nrt-VBR Apipe’

classifies all incoming traffic to FC af and puts the traffic in queue 4. The ‘UBR Apipe’ classifies all incoming

traffic to FC l1 and puts the traffic in queue 3. Traffic is scheduled towards the switch fabric according to the

Default scheduler.

At the egress of PE1 traffic is queued at the egress port based on the Forwarding Class to queue mapping

defined in the network queue policy. The traffic is also marked to the appropriate EXP bit based on the

Forwarding Class to EXP mapping defined in the network policy.

At the ingress of P, traffic is mapped to the Forwarding Class according to the EXP bit of the MPLS header, as

defined in the network policy and placed in the corresponding queue, as defined in the network queue policy.

At the egress of P traffic is queued at the egress port based on its FC (as assigned at the ingress), and as

defined by the FC to queue mapping in the network queue policy. The traffic is not remarked at the egress,

and thus maintains the EXP value that was assigned at the egress of PE1.

At the ingress of PE2, traffic is mapped to the Forwarding Class according to the EXP bit of the MPLS header,

as defined in the network policy and placed in the corresponding queue, as defined in the network queue

policy. The MPLS header is stripped off.

At the egress of PE2, traffic is queued at the egress SAP based on its FC (as assigned at the ingress), and as

defined by the FC to queue mapping in the SAP-egress policy (recall that there is only one FC and one queue

in the SAP-egress policy). The ATM cells are taken out of the packets and queued per virtual circuit. at the

ATM MDA. The ATM cells are scheduled according to their ATM service category. The CBR traffic is scheduled

in strict priority before the nrt-VBR and UBR traffic. Since the nrt-VBR traffic has been configured with

shaping disabled, it is scheduled in a weighted round robin fashion with the UBR traffic, where the SIR/MIR

value of each service category (as defined in the ATM Traffic Descriptor profiles) is used as the weight.

49

Alcatel-Lucent C


ot Distribute

This diagram displays the scheduling order at the network ports.

50

Alcatel-Lucent C


ot Distribute

This diagram displays the buffer pool utilization for each queue at the network ports.

51

Alcatel-Lucent C


ot Distribute

52

Alcatel-Lucent C


ot Distribute

53

Alcatel-Lucent C


ot Distribute

Service Ingress

Traffic can be classified into one of eight forwarding classes (FC); each FC has at least one unicast queue

In addition to a unicast queue, each FC in a VPLS service can also have its own multicast, broadcast, and unknown

unicast queue

Each SAP supports up to 32 ingress queues

Service Egress

Up to eight queues per service can be defined, corresponding to the eight FCs

Network Egress

Each network egress port can have up to eight predefined queues, one for each FC

A network queue policy can be applied to each network egress port

Network Ingress

DSCP or EXP bits can be mapped to one of eight predefined FCs, each having its own queue

One network queue policy applies to all network ingress ports on the MDA

54

Alcatel-Lucent C


ot Distribute


Alcatel-Lucent C


ot Distribute








2

Alcatel-Lucent C


ot Distribute

3

Alcatel-Lucent C


ot Distribute

Alcatel-Lucent C


ot Distribute

5

Alcatel-Lucent C


ot Distribute

6

Alcatel-Lucent C


ot Distribute

7

Alcatel-Lucent C


ot Distribute

This command is useful to determine whether traffic is being queued, and hence whether congestion is occurring on

the ESS/SR.

8

Alcatel-Lucent C


ot Distribute


the ESS/SR.

9

Alcatel-Lucent C


ot Distribute


the ESS/SR.

10

Alcatel-Lucent C


ot Distribute

11

Alcatel-Lucent C


ot Distribute

12

Alcatel-Lucent C


ot Distribute

This command updates the display every x seconds (10 seconds by default) up to a specified number of times (10 by

default.

13

Alcatel-Lucent C


ot Distribute

Alcatel-Lucent C


ot Distribute

15

Alcatel-Lucent C


ot Distribute

16

Alcatel-Lucent C


ot Distribute

The rollover time is specified in minutes. It specifies the time during which stats records collected are written to a

file, before that file is closed, compressed and ftped to SAM (i.e. node notifies SAM that a file is ready for ftp), and a

new file is opened to collect the stats.

The rollover time must be greater than the accounting policy interval (collection) time, otherwise some of the files

will be empty.

The retention time, in hours, specifies how long the file is kept on the compact flash before being deleted. It is not

recommended to store accounting statistics on cf3 as this is where the primary image and configuration files are

stored. It is recommended to store them on a separate compact flash card, and to periodically transfer the log files

to an external management system, such as the 5620 SAM, or other server for storage.

The length of the rollover time and retention time depends on the size of the compact flash, the number of entities

for which stats are collected and the number of records being collected for each entity.

17

Alcatel-Lucent C


ot Distribute

The optional “interval” parameter (in minutes) which can be specified when we create an accounting policy defines

the data collection interval – i.e. the statistics of the record (stat class) referenced by this accounting policy will be

retrieved every X minutes as specified by the interval value. If no value is specified, then the default value, which is

specific to each record type will be used.

The destination file to which the gathered statistics are stored must be specified. This is a log file which must have

been previously created.

A log file can only be associated with one accounting policy.

An accounting policy can be applied to multiple service access points or network ports. If the same accounting policy

is applied to multiple ports, then the log file will contain stats for all those ports.

The selection of the collection interval time, and the file rollover time can be selected such that all stats for a given

period of time are stored in the same file. For example, if we want the file to contain hourly stats for a one day

period then the collection interval time is set to 60 minutes and the file rollover time is set to 1440 minutes.

18

Alcatel-Lucent C


ot Distribute

19

Alcatel-Lucent C


ot Distribute

Only accounting policies configured to collect access related records can be applied to service access points. And

only accounting policies configured to collect network related records can be applied to network ports. En warning is

generated by the system if an incompatible policy is applied.

20

Alcatel-Lucent C


ot Distribute

21

Alcatel-Lucent C


ot Distribute

22

Alcatel-Lucent C


ot Distribute

Refer to the ESS/SR product manuals for more information on the record types.

23

Alcatel-Lucent C


ot Distribute

Alcatel-Lucent C


ot Distribute

25

Alcatel-Lucent C


ot Distribute

SDP Ping performs in-band uni-directional or round-trip connectivity tests on SDPs. The SDP Ping OAM packets are

sent in-band, in the tunnel encapsulation, so it will follow the same path as traffic within the service. The SDP Ping

response can be received out-of-band in the control plane, or in-band using the data plane for a round-trip test.

The sdp-ping command accepts an originating SDP-ID and an optional responding SDP-ID. The size, number of

requests sent, message time-out and message send interval can be specified. All sdp-ping requests and replies are

sent with PLP OAM-Label encapsulation, as a service-id is not specified.

For round trip connectivity testing, the resp-sdp keyword must be specified. If resp-sdp is not specified, a uni-

directional SDP test is performed.

To terminate an sdp-ping in progress, use the CLI break sequence <Ctrl-C>.

An sdp-ping response message indicates the result of the sdp-ping message request. When multiple response

messages apply to a single SDP Echo Request/Reply sequence, the response message with the highest precedence will

be displayed. The following table displays the response messages sorted by precedence.

26

Alcatel-Lucent C


ot Distribute

Result of Request (parameters described below) Displayed Response Message

Precedence

Request timeout without reply Request Timeout

1

Request not sent due to non-existent orig-sdp-id Orig-SDP Non-Existent

2

Request not sent due to administratively down orig-sdp-id

Orig-SDP Admin-Down

3

Request not sent due to operation-ally down orig-sdp-id

Orig-SDP Oper-Down

4

Request terminated by user before reply or timeout Request Terminated

5

Reply received, invalid origination-id Far End: Originator-ID Invalid

6

Reply received, invalid responder-id Far End: Responder-ID Error

7

Reply received, non-existent resp-sdp-id Far End: Resp-SDP Non-Existent

8

Reply received, invalid resp-sdp-id Far End: Resp-SDP Invalid

9

Reply received, resp-sdp-id down (admin or oper) Far-end: Resp-SDP Down

10

Reply received, No Error Success 11

Parameters orig-sdp-id — The SDP-ID to be used by sdp-ping, expressed as a decimal integer. The far-end address of

the specified SDP-ID is the expected responder-id within each reply received. The specified SDP-ID

defines the encapsulation of the SDP tunnel encapsulation used to reach the far end. This can be IP/GRE or

MPLS. If orig-sdp-id is invalid or administratively down or unavailable for some reason, the SDP Echo

Request message is not sent and an appropriate error message is displayed (once the interval timer expires, sdp-ping will attempt to send the next request if required).

Values 1 – 17407

resp-sdp resp-sdp-id — Optional parameter is used to specify the return SDP-ID to be used by the far-end

7450 ESS for the message reply for round trip SDP connectivity testing. If resp-sdp-id does not exist on the

far-end 7450 ESS, terminates on another 7450 ESS different than the originating 7450 ESS, or another issue

prevents the far-end 7450 ESS from using resp-sdp-id, the SDP Echo Reply will be sent using generic

IP/GRE OAM encapsulaton. The received forwarding class (as mapped on the ingress network interface for

the far end) defines the forwarding class encapsulation for the reply message.

Default null, use the non-SDP return path for message reply

Values 1 – 17407

27

Alcatel-Lucent C


ot Distribute

Parameters (cont.)

fc fc-name [profile {in | out}] — The fc and profile parameters are used to indicate the forwarding class of

the SDP encapsulation. The actual forwarding class encoding is controlled by the network egress DSCP or

LSP-EXP mappings. The DSCP or LSP-EXP mappings on the receive network interface controls the

mapping back to the internal forwarding class used by the far-end 7450 ESS that receives the message

request. The egress mappings of the egress network interface on the far-end 7450 ESS controls the

forwarding class markings on the return reply message. The DSCP or LSP-EXP mappings on the receive

network interface controls the mapping of the message reply back at the originating 7450 ESS. This is

displayed in the response message output upon receipt of the message reply.

fc-name — The forwarding class of the SDP encapsulation.

Default be

Values be, l2, af, l1, h2, ef, h1, nc

profile {in | out} — The profile state of the SDP encapsulation.

Default out

timeout seconds — The timeout parameter in seconds, expressed as a decimal integer. This value is used

to override the default timeout value and is the amount of time that the router will wait for a message reply

after sending the message request. Upon the expiration of message timeout, the requesting router assumes that the message response will not be received. A ‘request timeout’ message is displayed by the CLI for

each message request sent that expires. Any response received after the request times out will be silently

discarded.

Default 5

Values 1 - 10

interval seconds — The interval parameter in seconds, expressed as a decimal integer. This parameter is

used to override the default request message send interval and defines the minimum amount of time that

must expire before the next message request is sent. If the interval is set to 1 second, and the timeout

value is set to 10 seconds, then the maximum time between message requests is 10 seconds and the

minimum is 1 second. This depends upon the receipt of a message reply corresponding to the outstanding

message request.

Default 1

Values 1 – 10

size octets — The size parameter in octets, expressed as a decimal integer. This parameter is used to

override the default message size for the sdp-ping request. Changing the message size is a method of

checking the ability of an SDP to support a path-mtu. The size of the message does not include the SDP

encapsulation, VC-Label (if applied) or any DLC headers or trailers.

When the OAM message request is encapsulated in an IP/GRE SDP, the IP ‘DF’ (Do Not Fragment) bit is set. If any segment of the path between the sender and receiver cannot handle the message size, the

message is discarded. MPLS LSPs are not expected to fragment the message either, as the message

contained in the LSP is not an IP packet.

Default 40

Values 40 – 9198

count send-count — The number of messages to send, expressed as a decimal integer. The count

parameter is used to override the default number of message requests sent. Each message request must

either timeout or receive a reply before the next message request is sent. The message interval value must

be expired before the next message request is sent.

Default 1

Values 1 - 100

28

Alcatel-Lucent C


ot Distribute

For a unidirectional test, SDP Ping tests the:

Egress SDP ID encapsulation

Ability to reach the far-end IP address of the SDP ID within the SDP encapsulation

Path MTU to the far-end IP address over the SDP ID

Forwarding class mapping between the near-end SDP ID encapsulation and the far-end tunnel termination

Note that since this is a uni-directional test, the remote SDP-id, administrative and operative state and the path MTU

are not known.

29

Alcatel-Lucent C


ot Distribute

For round trip connectivity testing, the resp-sdp keyword must be specified. If resp-sdp is not specified, a uni-

directional SDP test is performed.

For a round-trip test, SDP Ping uses a local egress SDP ID and an expected remote SDP ID. Since SDPs are

unidirectional tunnels, the remote SDP ID must be specified and must exist as a configured SDP ID on the far-end 7750

SR. SDP round trip testing is an extension of SDP connectivity testing with the additional ability to test:

Remote SDP ID encapsulation

Potential service round trip time

Round trip path MTU

Round trip forwarding class mapping

30

Alcatel-Lucent C


ot Distribute

By specifying the Forwarding Class and optionally the profile of the ping packets being sent in the SDP-ping, the

correctness of the network and network-queue policies can be verified. This verification can be done in conjunction

with the use of the „show port <port-id> detail‟ command to verify the queues in which the ping packets are mapped.

31

Alcatel-Lucent C


ot Distribute

Alcatel-Lucent C


ot Distribute

Service Assurance Agent Overview

In the last few years, service delivery to customers has drastically changed. Services such as different types of VPLS

services are offered. The introduction of Broadband Service Termination

Architecture (BSTA) applications such as Voice over IP (VoIP), TV delivery, video and high speed Internet services

force carriers to produce services where the health and quality of Service Level Agreement (SLA) commitments are

verifiable to the customer and internally within the carrier.

SAA is a feature that monitors network operations using statistics such as jitter, latency, response time, and packet

loss. The information can be used to troubleshoot network problems, problem prevention, and network topology

planning.

The results are saved in SNMP tables are queried by either the CLI or a management system.

Threshold monitors allow for both rising and falling threshold events to alert the provider if SLA performance

statistics deviate from the required parameters.

33

Alcatel-Lucent C


ot Distribute

SAA configuration commands

CLI Syntax: PE1>config>saa#

Parameter Explanation

test test-id Identifies a test and enables the context to provide the test parameters for the named test

jitter-event At the termination of an SAA test probe, both rising and falling thresholds are evaluated versus the configuration and events generated as required.

latency-event At the termination of an SAA test probe, both rising and falling thresholds are evaluated versus the configuration and events generated as required.

loss-event At the termination of an SAA test run, both rising and falling thresholds are evaluated versus the configuration and events generated as required.

shutdown/no shutdown

In order to modify an existing test it must be shut down first. When a test is created it is in shutdown mode until a no shutdown command is executed.

type Creates the context to provide the test type for the named test. Only a single test type can be configured.

lsp-ping Specifies that lsp-ping packets be used for this test. lsp-trace Specifies that lsp-trace packets be used for this test. mac-ping Specifies that mac-ping packets be used for this test mac-trace Specifies that mac-trace packets be used for this test sdp-ping Performs an SAA test on a SDP for either one-way or

two-way timing.

34

Alcatel-Lucent C


ot Distribute

CLI Syntax: saa test-name [owner owner-name] {start | stop}

Context

oam

Description

Use this command to start or stop an SAA test.

Parameters

test-name — Name of the SAA test. The test name must already be configured in the config>saa>test context.

owner owner-name — Specifies the owner of an SAA operation up to 32 characters in length. If an owner-name value

is not specified, tests created by the CLI have a default owner “TiMOS CLI”.

start — This keyword starts the test. A test cannot be started if the same test is still running.

A test cannot be started if it is in a shut-down state. An error message and log event will be generated to indicate a

failed attempt to start an SAA test run.

stop — This keyword stops a test in progress. A test cannot be stopped if it is not in progress. A log message will be

generated to indicate that an SAA test run has been aborted

35

Alcatel-Lucent C


ot Distribute

CLI Syntax saa [test-name] [owner owner-name]]

Context

show>saa

Description

Use this command to display information about the SAA test.

If no specific test is specified a summary of all configured tests is displayed.

If a specific test is specified then detailed test results for that test are displayed for the last three occurrences that

this test has been executed, or since the last time the counters have been reset via a system reboot or clear

command.

Parameters

test-name — Enter the name of the SAA test for which the information needs to be displayed. The test name must

already be configured in the config>saa>test context. This is an optional parameter.

owner owner-name — Specifies the owner of an SAA operation up to 32 characters in length. If an owner-name value

is not specified, tests created by the CLI have a default owner “TiMOS CLI”.

36

Alcatel-Lucent C


ot Distribute

Alcatel-Lucent C


ot Distribute

The current behavior with SAP-ingress and SAP-egress policies allows the operator to reuse a given QoS policy on

different customer SAPs. This may be sufficient in an environment where many customers use a limited number of

types of policies. However, in an environment where each customer is assumed to pay for a combination of service

classes and bandwidth that may change independently from other customers, the simple model of QoS policy

instantiation might not be sufficient.

QoS Policy Runtime Instantiation introduces the capability to override the queue parameters of a QoS policy at the

SAP level and thus create many customized forms of a single QoS policy template. Thus, only a few base policies for

the most common parameters need to be configured on the router. These will address the QoS requirements of the

majority of customers. For those customers with different needs, the QoS override feature is used to alter the

pertinent parameters for those customers only.

38

Alcatel-Lucent C


ot Distribute

The QoS policies which can be overridden are the SAP-ingress, SAP-egress and scheduler policies. For the SAP-ingress

and SAP-egress policies one or more of the following queue parameters can be overridden: Rate (PIR/CIR), MBS, CBS,

High-Priority-Only and adaptation-rule. For the scheduler policy, the Rate (PIR/CIR) and/or parent parameters can be

overridden.

For SAP ingress and SAP egress QoS policies, queue parameters can be overridden on a per-SAP basis. For scheduling

policies, parameters such as parent and rate can be customized on a per-scheduler policy instance.

QoS Runtime instantiation can be applied to SAPs in all service types – IES, ePipe, aPipe, fPipe, iPipe, VPLS and VPRN.

39

Alcatel-Lucent C


ot Distribute

On a given SAP the parameters of one or more of the queues defined in the applied SAP-ingress/SAP-egress policy can be

overridden. For example, given the following SAP-ingress policy, on a given SAP where this policy is applied it would be possible to

override the Rate of queue 3 and the MBS of queue 5. It is also possible to override queue parameters in either or both the ingress

and egress queues.

sap-ingress 22 create

description "For ATM UBR PVC traffic arriving through an OC12 ATM port"

queue 1 create

exit

queue 3 create

rate max cir 42000

cbs 3

exit

queue 5 create

rate max cir 70000

mbs 30

exit

queue 11 multipoint create

exit

fc af create

queue 3

exit

fc h1 create

queue 5

default-fc af

exit

To remove a queue-override parameter use the “no queue-override” form of the command.

40

Alcatel-Lucent C


ot Distribute

On a given SAP the parameters of one or more of the schedulers defined in the applied scheduler policy can be

overridden. For example, given the following scheduler policy, on a given SAP where this policy is applied it would be

possible to override the PIR of scheduler “high” and the CIR of the scheduler “low” . It is also possible to override

scheduler parameters in either or both the ingress and egress SAP.

scheduler-policy “Internet" create

description "10Megabits/s policy"

tier 1

scheduler “high" create

rate 10000

exit

scheduler “low" create

rate 5000

exit

exit

exit

To remove a scheduler-override parameter use the “no scheduler-override” form of the command.

41

Alcatel-Lucent C


ot Distribute

The service provider is offering three different types of services each with different possible rates. Their customers

can purchase any combination of the offered services and rates, which means that there are up to 47 possible

different combinations of services (i.e. service packages). For example, the service provider could have some of the

following packages:

“Deluxe Bundle”: HSI @ 6Mbps, Video @ 12Mbps and Voice @ 1536kbps

“Basic Bundle”: HSI @ 2Mbps, Video @ 6Mbps and Voice @ 384kbps.

“Simply Voice – Premium, Standard, Budget”: Voice at 1536kbps, 768kbps or 284kbps respectively

“Data User – Power user, Standard user, Frugal user”: HSI @6Mbps and Video @ 12Mbps, HSI @4Mbps and Video @

12Mbps, HSI @2Mbps and Video @ 6Mbps

Etc…..

42

Alcatel-Lucent C


ot Distribute

43

Alcatel-Lucent C


ot Distribute

The SAP-egress qos profile is shown for the “Basic Bundle” service which includes all three service types at their basic

traffic rates. This is a popular service and hence the most commonly purchased. For customers who are willing to pay

more to receive better services, the service provider uses the override functionality to adjust the rates for these

customers only.

44

Alcatel-Lucent C


ot Distribute

45

Alcatel-Lucent C


ot Distribute

46

Alcatel-Lucent C


ot Distribute


1. Show pool <port-id> network-egress

2. On the sap-ingress and sap-egress policies.

3. Round-trip delay, jitter and packet loss.

4. A network policy along the sdp-ping path has been configured to remark L1 traffic to EF.

5. True

47

Alcatel-Lucent C


ot Distribute


Alcatel-Lucent C


ot Distribute

student guide alcatel lucent qos

Documents

internal use

alcatellucent website

complex quality of service

servicecentered product

superior standard of

customers traffic

technical practices

service level agreement