sioning of QoS. The work on SLS in Tequila is
focused on an IP network that will be composed
of DiffServ-aware network elements able to
implement PHBs like Assured Forwarding (AF)
and Expected Forwarding (EF).
SLS Template in Tequila
1.Scope– The scope indicates where the QoS
policy is to be enforced. The geographical/
topological region is indicated by the bound-
aries of the region. An SLS is associated with
unidirectional traffic flows. A couple of
ingress and egress interfaces denote the entry/
exit points of the IP packets. The ingress and
egress may be:
- One-to-one;
- One-to-many;
- One-to-any;
- Many-to-one;
- Any-to-one.
Many-to-many is excluded from the list but
may be decomposed into many times one-to-
many.
2.Flow description– Indicates for which IP
packets the QoS guarantees are to be enforced.
A flow description identifies a stream of IP
datagrams sharing at least one common char-
acteristic. An SLS contains one (and only one)
flow description, which may formally be spec-
ified by providing one or more of the follow-
ing attributes:
- Differentiated Services information = DSCP;
- Source information = source address;
- Destination information = destination
address; - Application information = protocol number,
source port, destination port.
The flow description provides the necessary
information for classifying packets at a DS
boundary node. BA classification requires
only DSCP codepoint, while MF classification
requires that the other information is given.
3.Traffic envelope and traffic conformance–
Describes the traffic characteristics of the IP
packet stream identified by the flow descrip-
tion.
A binary traffic conformance identifies in-pro-
file and out-of-profile (or excess) packets of
an IP packet stream. Multi-level traffic confor-
mance gives the opportunity for tagging the
packets when reaching various threshold val-
ues.
Traffic conformance parameters:
- Peak rate (bits per second);
- Token bucket rate (bits per second);
- Bucket depth (bytes);
- Maximum transport unit (bytes);
- Minimum packet size (bytes).
4.Excess treatment– Excess treatment de-
scribes how the service provider will process
excess traffic, i.e. out-of-profile traffic (in case
of binary conformance testing) or n-level traf-
fic (in case of n-level conformance testing).
Excess traffic may be dropped, shaped and/or
remarked.
- Dropped– if excess traffic is dropped, then
all packets marked as ‘out-of-profile’ by
the Traffic Conformance Algorithm are
dropped. No extra parameters are needed. - Shaped– if excess traffic is shaped, then all
packets marked as ‘out-of-profile’ by the
Traffic Conformance Algorithm are delayed
until they are ‘in-profile’. The shaping rate
is the policing/token bucket rate. The extra
parameter is the buffer size of the shaper. - Marked– if excess traffic is marked or
remarked, then all packets marked as ‘out-
of-profile’ by the Traffic Conformance
Algorithm are (re-)marked with a particular
DSCP-value (yellow or red). The extra
parameter is the DSCP.
The SLS must specify the appropriate action,
otherwise the excess traffic is dropped.
5.Performance guarantees– Performance
guarantees describe the service guarantees
offered to the packet stream identified by
the flow description.
There are four performance parameters:
- delay, time interval, optional quantile;
- jitter, time interval, optional quantile;
- packet loss, time interval;
- throughput, time interval.
Some further details on these parameters are
given in the following.
Delay, jitter and packet loss guarantees are for
the in-profile traffic in case of binary confor-
mance testing. Having multi-level confor-
mance testing, delay, jitter and loss guarantees
may be specified for each conformance level
respectively, except the last one. For example
having three levels, one can have a delay
guarantee for the “conformance level-1” pack-
ets and a different delay guarantee for the
“conformance level-2” packets. No guarantees