Qos in Isam - Module 2 Policing & Shaping: Victor Cortijo

QoS in ISAM Module 2 Policing & Shaping
Victor Cortijo
EMEA S&M Fixed Access DBC
BB Access Expert Technical Pre-sales

June 2010
Context ISAM Forwarding Discovered

EMEA Solutions & Marketing Fixed Access DBC
Alcatel Lucent University Learning2.GO
Broadband Access Discovered
This module is part of a series of training modules on forwarding in ISAM.

The series is created in partnership between ALU University and the EMEA S&M Fixed Access DBC (Domain Business Center) The modules are made available via 2 channels: ALU University Learning2.Go EMEA Fixed Access DBC Portal
2 | ISAM forwarding Telenor | March 2009
All Rights Reserved Alcatel-Lucent 2009, XXXXX
Target Audience How to use these slides This is an Alcatel-Lucent internal training module Prime target audience of this module are (technical) pre-sales people who are looking for in depth understanding of the QoS feature in ISAM The material in this presentation can in general be reused in customer presentations, however this will require some adaptations. The module has NOT been designed to be presented as such to customers.
This training module is NOT an operator course. If you are looking for a training on how to operate the ISAM, dedicated courses are available from ALU University.
This module is available in 2 formats Powerpoint slideset Recorded audio with slides
Objectives of this Module After attending this module, you will: understand the QoS policing and shaping features available in ISAM R4.2 for the SHUB NT and the standard LT cards. be able to discuss these features with customers.
The goal of this training module is not so much explaining the technology (e.g. exact working of TrTCM, which can be learnt via books or courses) but explaining what features
are available in ISAM, the reasons behind and how they are organized or handled. The idea
is to present a visual 'enciclopaedia' (to a certain level) of ISAM QoS so that the exact functionality may be further explored if so desired.
Prerequisite Knowledge This module assumes that the student: has basic understanding of the ISAM product family
has a basic knowledge of Ethernet/VLAN technology
If you havent done so yet, it may be a good idea to have a look first to the following training modules: Competency pick-up on forwarding ISAM QoS Marking
Important Notes This module was created in May, 2010. Consequently it describes the ISAM functionality as available in release 4.2 As the ISAM product evolves, features may be subject to change. For actual up to date information on system functionality, make sure to check the product roadmap information. In particular
Both the new R4.0.02 NANT-D and the new R4.2 NANT-E have a different QoS treatment than the standard NANT-A since they are based on the new IHUB switching block. They will be described in a specific training module. The new R4.0.10 NGLT-A/NGLT-B cards present some differences with respect to the standard LT cards as described in this presentation. These differences are described in a specific training module.
This module is the second one of a series of six on ISAM QoS functionality. This second module describes the generic policing and shaping functionality for the SHUB NT and the standard LT cards.
Agenda
1. QoS basics policing & shaping 2. ISAM QoS policing & shaping 3. Conclusions
QoS basics policing & shaping
QoS
Network dimensioning
In the first QoS module we learnt how to differentiate traffic by using marking. So, the nodes will use the marking information to handle correctly the traffic (which, in a DiffServ architecture, means that lower priority traffic will be dropped before higher priority traffic if congestion happens).
But.. Still the goal would be not having any sustained packet loss at any node, right?
Question: How can operators ensure that there is no sustained packet loss at one node? Answer: They need to dimension the network correctly for sustained traffic throughput. So, how do they know what the sustained traffic throughput is? Statistical approach (they know how much a user typically sends and receives). This is ok for normal, residential users, whose habits are well studied and known. Service Level Agreements (they sign special agreements with users limiting the amount
of traffic). This is specially true in wholesale environments where users need to pay for
the amount of network they are using.
9 | ISAM forwarding Telenor | March 2009 All Rights Reserved Alcatel-Lucent 2009, XXXXX
Policing/shaping concepts
Why?
For services, end-customers or interfaces that are contractually or physically binded to a certain treatment.
Needed for both policing and shaping: - a classifier to differentiate the flow to be policed/shaped - a meter to meter the flow in time -an action based on the result of the metering (normally discard/delay or pass)
A policer will drop the not-conforming traffic while a shaper will delay the same traffic. The difference is explained graphically below. Shaping always involves queueing (which means delay) Shaping is not Traffic IN Traffic OUT recommended for voice BW Policer Burst tolerance = 0 flows since it will impact the end-to-end delay
time Policer Burst tolerance = 0
Several ways to do policing and shaping: single/dual token bucket, single/dual rate three colour marking
Shaper
Single token bucket
Also known as 1R2C
Single token bucket policing/shaping is the easiest one.

Two parameters: -token accumulation rate (Commited Information Rate or CIR) -burst tolerance (Commited Burst Size or CBS)
Tokens: -represent traffic volume (bucket stores tokens, never actual data). -accumulate at constant pace (until the bucket is full), representing traffic allowed per time period. -are removed when traffic arrives to the meter (exactly an amount that corresponds to the size of the packet)
Packets that arrive to the meter at a moment when there are sufficient tokens in the bucket corresponding to its size are declared Conforming or In Profile. Single token bucket policing is not appropriate for TCP traffic. The reason is that TCP traffic has flow control rules triggered by packet delay. Since policing does not introduce delays, many packets are lost when using single token bucket policing until the flow control limits the TCP traffic.
Dual token bucket
Dual token bucket policing/shaping is a refined version of the single token bucket.
Four parameters: -normal token accumulation rate (Commited Information Rate or CIR) -normal burst tolerance (Commited Burst Size or CBS) -peak token accumulation rate (Peak Information Rate or PIR) -peak burst tolerance (Peak Burst Size or PBS) The philosophy is exactly the same but, while in the single token bucket the packets can burst at any speed (provided that enough tokens remain in the bucket), in the dual token bucket, the packets can only burst at the controlled rate marked by the PIR.
The conformance condition requires both buckets to have sufficient tokens to match the size of a newly arriving packet. If at least one of the buckets have insufficient tokens then the packet is non-conforming and tokens are removed from neither buckets.
Dual token bucket policing/shaping is useful for traffic with big burst size values.
Single rate three colour marking (SrTCM)
Also known as 1R3C (RFC2697)
Single rate three colour marking uses the concept of a main token bucket and an excess tokens bucket.
Four parameters: -normal token accumulation rate (Commited Information Rate or CIR) -normal burst tolerance (Commited Burst Size or CBS) -excess burst tolerance (Excess Burst Size or EBS) -color-mode flag (to define if the policer/shaper is working in color-blind or color-aware mode)
Three conformance levels (color-blind mode): -Green - when sufficient tokens are present in bucket B1 -Yellow - when B1 has insufficient tokens, but B2 has -Red - when neither B1 nor B2 have sufficient tokens
The only difference in color-aware mode is that incoming colour marking is taken into account (green packets are checked against both buckets (and marked accordingly), yellow packets are only checked against B2 (so they can continue being yellow or become red) and red packets are always nonconforming (and remain red))
Two rate three colour marking (TrTCM)
Also known as 2R3C (RFC2698)
Two rate three colour marking is a mixture of Single Rate Three Colour Marking and a dual token bucket.
Colour marking is Five parameters: often used in the -normal token accumulation rate (Commited Information Rate or CIR) BAC mechanism to -normal burst tolerance (Commited Burst Size or CBS) drop traffic (WRED) -peak token accumulation rate (Peak Information Rate or PIR) -peak burst tolerance (Peak Burst Size or PBS) -color-mode flag (to define if the policer/shaper is working in color-blind or color-aware mode)
Three conformance levels (color-blind mode): -Green - when sufficient tokens are present in both buckets (tokens are removed from both) -Yellow - when CIR bucket has insufficient tokens, but the PIR bucket has (tokens are removed from PIR bucket) CIR PIR -Red - when neither CIR nor PIR buckets have sufficient tokens
The only difference in color-aware mode is that incoming colour marking is taken into account (green packets are checked against both buckets (and marked accordingly), yellow packets are only checked against PIR bucket (so they can continue being yellow or become red) and red packets are always nonconforming (and remain red))
CBS PBS
Ingress traffic
Red Traffic
Passed traffic
ISAM QoS policing &

shaping
QoS
ISAM Architecture schematic overview
Ethernet aggregation Several multiDSL lines per LT card
Control function
LT 1
ONT*
LT n
Uplinks
direct Ethernet i/f

NT**
subtending i/f
Additional uplink interfaces
NT I/O (optional)
*Since R4.2 onwards, ISAM supports the GPON-technology NGLT-A/B line cards and hence ONTs. The NGLT-A/B QoS features are the objective of a specific training module. ** Since R4.0.02, ISAM supports a new type of High Capacity NTs (the NANT-D/NANT-E(R4.2)). These cards feature a new switching block called the IHUB instead of the previous SHUB. The IHUB QoS features are the objective of a specific training module.
QoS
QoS profiles
For reasons that we will see in following slides, the

QoS treatment at the LT cards is somewhat more complicated that the one at the NT card. For this reason, and to help with the reusability of the QoS provisioning, the LT cards make use of the concept of QoS profiles, a common set of QoS characteristics that are later applied to different subscribers. QoS MIB 2 3
Actor
(CLI/AWS/ Radius) 1 4
QoS mgmt NT
This concept of QoS profiles is implemented through a generic entity called a QoS session profile.
This QoS session profile is thoroughly explained in a dedicated module but, all
throughout the next slides, it is pointed out when a specific LT QoS feature is applied through a QoS session profile or is applied directly over the subscriber interface entity. The SHUB NT QoS settings are always applied directly over the NT interfaces. They never make use of the QoS session profile settings.
QoS
Basic policing cases
A) Ingress policing of upstream traffic coming from the user is the most important policing action. It assures that users are not sending more traffic into the network than allowed by their subscription*. B) On top of being a traffic limitation feature, ingress policing can also be seen as a security feature (implementing ACLs), which basically means a discard/pass choice of the policed traffic.
Ingress policing is normally driven by pure commercial considerations though sometimes fairness between
users can also be important.
Notice that for these two cases, discarding the out-of-profile traffic is allowed. Hence, policing is used instead of shaping (so that it does not introduce extra delay).
Ingress policing at subscriber interfaces (per SAP and per subflow) is the main requirement for this case**.
*Typically, the requirement is to police per service. Depending on the network model, this can be realised in different ways: In a multi-PVC/multi-VLAN model, typically the operator will choose to apply policing per PVC/VLAN. In a single PVC/VLAN model, the operator will probably police per IP destination address, which implies subflow filtering. ** While subscribers are normally connected to subscriber interfaces at the LTs, it may happen ocassionally that some business subscribers are directly connected to the NT. For these subscribers, the SHUB NT interfaces also support ingress policing.
QoS
Basic shaping cases (1)
A) Tuning egress traffic to fit the network capacity is the most important shaping action* e.g. an ISAM GE is connected to a node that can handle only 600 Mbps.
In this case, it is clear that the main goal is trying to maximize the capacity of the link (already limited per se). Due to this, shaping is normally applied instead of policing.
B) Enforcing SLAs for aggregate egress traffic is the second case in which shaping is applied. This is normally done in wholesale environments in which the network owner rents a specified capacity to a service provider.
In this case, the goal is not to maximize capacity (out-of-profile traffic can be dropped) so egress policing could be used. However, since the SHUB NT policers are single token
bucket, to avoid problems with TCP traffic, it is better to use shaping for this case**.
Egress shaping at SHUB NT interfaces is the main requirement for this.

*Notice that this is true for either uplinks (connected to network nodes) or subtended nodes (other DSLAMs) but, in any case, NT interfaces. ** Using shaping could adversely impact the voice traffic quality (if present) due the extra delay added. To solve this, shaping per VLAN at the NT would be required. However, this is not implemented in the SHUB NTs.
QoS
Basic shaping cases (2)
C) Enforcing SLAs for subscriber egress traffic is the third case in which shaping is applied. This is normally done for specific services and not for the whole subscriber line.
Per SAP egress policing is supported at the LT cards. However, since the ISAM LT cards policers are single token bucket, to avoid problems with TCP traffic, it is better to use shaping for this case*.
Egress shaping at the subscriber interfaces** is the main requirement for this.
* Using shaping could adversely impact voice traffic (if present) due the extra delay added. Implementing shaping per queue at the LT card subscriber interfaces is a way to solve this problem. ** Notice that downstream per queue shaping at the subscriber interfaces is only supported since R4.1.02 and only for new generation line cards (as of R4.2, the NVLT-G/H and all the new VDSL2 line cards derived from it and the NELT-B). The NGLT-A card also has per queue downstream shapers but they will be explained in the specific NGLT-A QoS module.
Policing/shaping at LTs
QoS
Policing at the LTs (downstream and upstream)
Guidelines (discussed in detail in the QoS session profile module) Applying policing at the LTs subscriber interfaces is done by either:
A) creating a QoS session profile that includes a policer profile (upstream and/or
downstream) and attaching it to the SAP*.

B) Creating a QoS session profile that includes a subflow filter and a policer profile (to be applied to that subflow, upstream and/or downstream) and attaching it to the SAP*. The policing settings come only from the QoS session profile. There are no static policing settings provisioned directly at the SAP.
Both policing settings (at SAP level and subflow level) can coexist in the same QoS sesion profile. In this case, obviously, the subflow settings have precedence over the SAP level for that specific subflow.
*SAPs in ISAM are:
bridge-ports (subscriber PVCs (ATM) or ports (Ethernet/PTM)). VLAN-ports (bridge-ports with a subscriber VLAN associated to them; always set on top of bridge-ports) PPP client ports (connection to a PPP forwarder; can be set on top of either a VLAN-port or the DSL port).
QoS
Shaper profiles at the LTs (only downstream)
Shaper profiles are used to configure the shaper settings per queue.
Scheduler configuration occurs by associating a shaper profile to one or more queues. The shaper profile contains the CIR and the CBS parameters of the shaper (notice that the shapers are all single token bucket) with the following constraints: CIR : 32Kbps to 128Mbps CBS: 256 bytes to 256Kbytes
Shaper Profile Name CIR 1000 8000 600 10000 CBS 6000 6400 4800 5000 EIR* 0 0 0 0 Type** SingleTokenBucket SingleTokenBucket SingleTokenBucket SingleTokenBucket voice Shaper Shaper Shaper Shaper
SP WFQ
video CL BE
The max number of shaper profiles at any moment in time is 128 per ISAM.
Shaper_prof1 Shaper_prof2 Shaper_prof3 Shaper_prof4
* The EIR (Excess Information Rate) value is used for the NGLT-A shapers and will be explained in the FD GPON QoS module. ** The shaper type is always SingleTokenBucket except for the NGLT-A shapers. This will be explained in the FD GPON QoS module.
Policing/shaping at SHUB NT
QoS
Ingress policing at the NT
Applying ingress policing at the SHUB NT external interfaces is done by:

A) creating a NT interface flow with the following characteristics: Flow type (port, VLAN, VLAN+specific P-bits, VLAN+specific DSCP-bits) VLAN ID (if needed) P-bits (if needed) Up to a maximum total of 64 flows and policers can be created per SHUB NT.
DSCP-bits (if needed)
B) creating a NT policer entity, defined by 1) CIR : 1Kbps to 10Gbps (or the maximum rate of the interface) in increments of 64Kbps and 2) CBS: 3Kbytes to 512Kbytes coded as [0..7] (8 discrete values)
C) attaching both the NT interface flow and the NT policer to one of the SHUB NT external physical interfaces. Up to 16 policers can be attached to a single SHUB NT interface.
Ingress policing at SHUB NT interfaces is not a common case and it is only supported so that users connected directly to the NT have some ingress policing capability. The main interest for this case is in a wholesale environment in which the network owner wants to limit the bandwidth offered to a service provider connected directly to a NT port.
QoS
L2 ingress filtering at the NT*
Applying L2 ingress filtering at the SHUB NT interfaces is done by:

creating a NT L2 filter with the following characteristics (only ingress direction): Index number Port (type and number of the ports to which the filter is applied) MAC SA/MAC DA VLAN ID Ethertype
Up to a maximum total of 128 L2

filters can be defined per NT.
Action (drop)
The index number implements also the precedence rule for the case in which several filters are applied at the same port. The lower the index number, the higher the precedence of the filter.
* While filtering is not strictly a QoS mechanism (more like a security one), since it has been explained as a QoS feature for the LTs, it is explained here also as part of the NT QoS features.
QoS
L3 ingress/egress filtering at the NT* for specific IP protocols
Applying ICMP/UDP/TCP L3 filtering at the SHUB NT interfaces is done by:

A) creating a NT L3 filter for an specific IP protocol with the following characteristics: Filter type (TCP, UDP, ICMP)
Index number
IP DA/IP SA and masks
Up to a maximum total of 128 L3 filters can be defined per SHUB NT.
Protocol-dependant attributes (msg-type, msg-code, dst-port range, src-port range, ack, rst, tos) VLAN ID Direction (in/out) Action (drop) this is not supported for filters in out direction
B) Applying the created L3 filter to a list of ports (either in input or in output direction). The index number implements also the precedence rule for the case in which several filters are applied at the same port. The lower the index number, the higher the precedence of the filter.
QoS
L3 ingress/egress filtering at the NT* for other IP protocols
Applying a other-protocol L3 filtering at the SHUB NT interfaces is done by:

A) creating a NT L3 filter (in ingress/egress direction) with the following characteristics: Index number
Port (type and number of the ports to which the filter is applied)
IP DA/IP SA and masks Protocol (IGMP, RSVP, MSRP, OSPF,..,any) VLAN ID Up to a maximum total of 128 L3 filters can be defined per SHUB NT.
Action (drop) this is not supported for filters in egress direction
The index number implements also the precedence rule for the case in which several filters are applied at the same port. The lower the index number, the higher the precedence of the filter.
QoS
Egress shaping at the SHUB NT
Applying egress shaping at the SHUB NT external interfaces is done by:

Applying a shaping rate to the SHUB NT external physical interface. The shaping rate is specified in increments of 64Kbps with a range between 1Kbps and 10Gbps (or the maximum rate of the interface).
Notice that egress shaping per VLAN at the SHUB NT external interfaces would really fulfill the requirement in a true wholesale environment in which several service providers can share the bandwidth offered by one of the NT external interfaces. Also, it would
solve the problem of the extra delay caused by shaping to voice flows. This feature is not
implemented in the SHUB NT. The egress shaping rate is applied directly as part of the characteristics of the SHUB NT
ports and, as such, does not consume any system resources. Hence, shaping can always
be applied to the SHUB NT ports without any dimensioning limitation.
Conclusions
Conclusions In this module you have learned: In which way ISAM supports QoS policing and shaping for the SHUB NT and the standard LT cards. Ingress/egress policing at the LT cards applied through a QoS Session Profile. Egress shaping at the LT cards applied through a shaper profile. Ingress policing applied directly over the network interfaces at the SHUB NT Egress shaping applied directly over the network interfaces at the SHUB NT
For further information For feedback, questions, comments on this module, please contact: Victor.Cortijo_Fernandez@alcatel-lucent.com
Cesar.Campuzano@alcatel-lucent.com
More information on QoS is available here: http://en.wikipedia.org/wiki/Quality_of_service
EMEA S&M Wireline CC Portal

If you liked this module, make sure to check out other modules in this series: ISAM QoS marking ISAM QoS queuing and scheduling ISAM QoS Session Profiles
www.alcatel-lucent.com www.alcatel-lucent.com

Qos in Isam - Module 2 Policing & Shaping: Victor Cortijo

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Qos in Isam - Module 2 Policing & Shaping: Victor Cortijo

Uploaded by

Copyright:

Available Formats

QoS in ISAM Module 2 Policing & Shaping

BB Access Expert Technical Pre-sales

Context ISAM Forwarding Discovered

Alcatel Lucent University Learning2.GO

Broadband Access Discovered

This module is part of a series of training modules on forwarding in ISAM.

2 | ISAM forwarding Telenor | March 2009

All Rights Reserved Alcatel-Lucent 2009, XXXXX

3 | ISAM forwarding Telenor | March 2009

All Rights Reserved Alcatel-Lucent 2009, XXXXX

4 | ISAM forwarding Telenor | March 2009

All Rights Reserved Alcatel-Lucent 2009, XXXXX

has a basic knowledge of Ethernet/VLAN technology

5 | ISAM forwarding Telenor | March 2009

All Rights Reserved Alcatel-Lucent 2009, XXXXX

6 | ISAM forwarding Telenor | March 2009

All Rights Reserved Alcatel-Lucent 2009, XXXXX

7 | ISAM forwarding Telenor | March 2009

All Rights Reserved Alcatel-Lucent 2009, XXXXX

QoS basics policing & shaping

8 | ISAM forwarding Telenor | March 2009

All Rights Reserved Alcatel-Lucent 2009, XXXXX

10 | ISAM forwarding Telenor | March 2009

Also known as 1R2C

Single token bucket policing/shaping is the easiest one.

Also known as 1R3C (RFC2697)

Also known as 2R3C (RFC2698)

All Rights Reserved Alcatel-Lucent 2009, XXXXX

ISAM QoS policing &

15 | ISAM forwarding Telenor | March 2009

All Rights Reserved Alcatel-Lucent 2009, XXXXX

direct Ethernet i/f

For reasons that we will see in following slides, the

users can also be important.

Egress shaping at SHUB NT interfaces is the main requirement for this.

21 | ISAM forwarding Telenor | March 2009

All Rights Reserved Alcatel-Lucent 2009, XXXXX

downstream) and attaching it to the SAP*.

*SAPs in ISAM are:

Shaper_prof1 Shaper_prof2 Shaper_prof3 Shaper_prof4

24 | ISAM forwarding Telenor | March 2009

All Rights Reserved Alcatel-Lucent 2009, XXXXX

Applying ingress policing at the SHUB NT external interfaces is done by:

DSCP-bits (if needed)

Applying L2 ingress filtering at the SHUB NT interfaces is done by:

Up to a maximum total of 128 L2

Applying ICMP/UDP/TCP L3 filtering at the SHUB NT interfaces is done by:

Up to a maximum total of 128 L3 filters can be defined per SHUB NT.

Applying a other-protocol L3 filtering at the SHUB NT interfaces is done by:

Action (drop) this is not supported for filters in egress direction

Applying egress shaping at the SHUB NT external interfaces is done by:

29 | ISAM forwarding Telenor | March 2009

All Rights Reserved Alcatel-Lucent 2009, XXXXX

30 | ISAM forwarding Telenor | March 2009

All Rights Reserved Alcatel-Lucent 2009, XXXXX

31 | ISAM forwarding Telenor | March 2009

All Rights Reserved Alcatel-Lucent 2009, XXXXX

EMEA S&M Wireline CC Portal

32 | ISAM forwarding Telenor | March 2009

All Rights Reserved Alcatel-Lucent 2009, XXXXX

33 | ISAM forwarding Telenor | March 2009

All Rights Reserved Alcatel-Lucent 2009, XXXXX