illustrates two providers – A and B, the services
they offer to each other, and their relationship
captured in TCSs.
The technical aspects of these agreements that
relate to the delivery of differentiated services
are captured in two TCSs – (1) for the services
provided by Provider A to B, (2) for services
provided by Provider B to A. Similar to the ana-
logue discussion on SLAs and dependencies on
different interfaces, TCSs needed by a provider
at any boundary will be dictated by TCSs negoti-
ated at the other boundaries. Provider A may
serve a number of customers with services termi-
nating at various boundary points in Provider
B’s network. The TCS between Provider A and
Provider B must represent the aggregate require-
ments of the TCSs of all Provider A’s customers.
In order to provide end-to-end services to its
customers, Provider A must be able to assure
the support for these services across multiple
domains, which requires several issues to be
solved:
- The service provided by a certain domain may
not be compatible with the services provided
by neighbouring domains; - The services provided by a domain may be
compatible with the services provided by
neighbouring domains, but the PHB used to
obtain the service might be different; - The PHB might be the same, but the codepoint
used to request the PHB might be different; - The PHB and the codepoint are the same but
differences in provisioning and charging mod-
els result in different service.
Determination of compatible services and nego-
tiation of PHB codepoints for requesting the ser-
vices is required. This process may be greatly
simplified by the provision of a set of universal
services using universally recognised codepoints.
The extension of quantitative services across
multiple domains will require more uniformity
in the nature of services provided. Qualitative
services may on the other hand be extended end-
to-end by a concatenation of service elements
that may vary from domain to domain. For
example, one domain may base a qualitative
service on a Weighted Fair Queueing (WFQ)
scheme with Random Early Discard (RED),
while another may use priority queuing with
RIO. Since the assurance end-to-end is looser
it is possible that a meaningful service can be
provided end-to-end by concatenating these two
types of services.
A host may be directly attached to a differenti-
ated service domain. Legacy hosts are unlikely
to perform marking of their packets into Diff-
Serv classes and are also unlikely to shape or
police their traffic. These services may be pro-
vided on behalf of the customer. The policies
used for marking and shaping have to be negoti-
ated at the time the agreement is made between
the network provider and the customer (host).
Newer hosts may be capable of marking and
traffic shaping. The overall resource constraints
in the agreements may likely be somewhat static
in this case. The host determines the manner in
which the host shares these resources among its
various traffic flows. The provider still has to
configure policers to assure that the host does
not seize more than its share of the resources or
the amount of traffic in the various classes than
agreed in the SLS or TCS.6.2.2 Tequila – Traffic Engineering for
Quality of Service in the Internet,
at Large Scale
The aim of the Tequila draft [tequila] is to iden-
tify the basic information to be included in SLS
considering the deployment of value-added IP
service offerings over the Internet. When such IP
service offerings are provided with a given QoS,
the QoS should be defined in such an SLS from
a technical perspective. Since these IP services
are likely to be provided over the whole Internet,
their corresponding QoS will be based upon a set
of technical parameters that both customers and
service providers will have to agree upon. Hav-
ing this perspective, this draft aims at listing
(and promoting a standard formalism for) a set
of basic parameters that will actually compose
the elementary contents of an SLS.The Tequila specification effort tries to address
the following:- Provide a standard set of information to be
negotiated between a customer and a service
provider or amongst service providers within
the context of processing an SLS; - Provide the corresponding semantics of such
information, so that it might be appropriately
modelled and processed by the above men-
tioned parties (in an automated fashion).
It seems useful to consider the specification of
an SLS template that these service providers
would agree upon, so as to enforce an inter-
domain QoS policy.It is necessary to be able to allow for a highly
developed level of automation and dynamic
negotiation of SLSs between customers and
providers. Automation and dynamics are helpful
in providing customers (as well as providers)
with the technical means for the dynamic provi-