The solution needs to be able to offer quantitative QoS support for some services and qualitative for others, to support a retail/wholesale split in the QoS business model, to provide upstream QoS, especially across the access link, and to support multiple service edges.
The usage of at least four traffic classes (real-time, streaming, transactional and best-effort) is recommended by MUSE as the way for differentiating traffic whereas keeping the scalability of the network.
MUSE recommends a user-centric approach where classification of traffic into traffic classes is a responsibility of the user, although it is still expected to be often delegated to the providers. Traffic policing is recommended to be used for ensuring that the usage of each traffic class does not exceed what has been planned, agreed or contracted.
There are some basic questions that need answering before defining the MUSE QoS solution:
MUSE recommends simple traffic differentiation (i.e. DiffServ) as one of the basic QoS techniques. However the differentiation should be done in such a way that it does not impose a heavy burden in terms of complexity and performance. Therefore, MUSE advocates using a limited set of traffic classes (e.g. four classes) inside the access and aggregation networks.
The nature and importance of the traffic should be taken into consideration in assigning the responsibility to classify traffic, and these aspects are better known to the users of the network (Residential, Corporate, Service Providers, Packagers, etc). Indeed, classification of traffic into traffic classes should be done before the ingress point of the network acknowledging the right of the users to decide this and this is the only way to guarantee QoS on all the network segments.
However, as most users are laymen and do not know how or not want to make this kind of decisions, it is expected that most of them would delegate these decisions to the network as part of the function of users’ preferences. Note also that, whereas it is legitimate to try to offer this capability as an added value so that network users can be liberated from taking decisions, it is also true that some users could prefer to keep the control, and hence this model should not be imposed but offered as a possibility.
Requesting QoS, once a DiffServ approach has been selected, is implicit to the fact of belonging to a given traffic class, as the network will normally define a set of constraints (e.g. a given maximum mean bitrate per traffic class) for using the different available traffic classes on a per user basis. This will basically depend on the physical constraints of the access technology and on the contract negotiated with the user. Verifying that the constraints for using the traffic classes are being fulfilled by the users is part of the policy enforcement, and this should ideally be done at the ingress points of the network. Note that these constraints are expected to be rather static in time, although they may be altered upon previous negotiation between the user and the network. Additionally, explicit guarantees per session can be provided to some services by means of a CAC (Call/Connection Admission Control) system so that service session requests are accepted or rejected based on the availability of requested network resources for the traffic class applicable to the session. Such a CAC system will receive explicit requests through application’s own signalling (e.g. in the Session Description Protocol) or from application servers.
The goal of CAC is to verify in real time that there are available resources enough for satisfying the QoS guarantees. In this sense, admission control has a complementary role to network dimensioning, which should have provided the necessary resources in advance. Note that QoS should be largely achieved by the correct network dimensioning. Even with CAC, if the network is largely underprovisioned, a significant number of session requests will be denied, thereby leading to a poor customer experience. CAC is therefore not a substitute for good network dimensioning, which is the basic means of providing the necessary resources for QoS support.
A central CAC system is where all CAC decisions are made at the same place. The central CAC system has a complete view of the resources of the appropriate parts of the network. All call admission requests have to be signalled to this central system. For each and every call (signalled) request or (non-signalled) detection, the central CAC system is consulted, which, on the basis of resource availability, decides whether to allow or block the requested call. This decision is sent to the boundary node where enforcement may be done. The main advantage of a central CAC system is that it is simple to manage. However, it requires the exchange of signalling messages, which may compromise the scalability and adds delay in the decision process.
A local CAC system is where uncoordinated CAC decisions are made at the appropriate nodes on the basis of the state of a local link. For a CAC decision to be made locally and independently of other nodes, it is necessary that there be a local view of the availability of network resources that can be used by that node. To do that, it is necessary to partition network resources for each traffic class and to allocate them to the different nodes. Resource partitioning naturally leads to a reduction in the potential multiplexing gains as unused resources allocated to a given node can not be used by another node or by another traffic class at the same node. In order to avoid this, partitions should be updated on a regular basis by a central authority that has a historic and global view of network resource usage or when a threshold associated to a given allocation is exceeded. Any re-allocation of resources should take into account the commercial agreements (SLAs) between network operators and service providers, which might specify bandwidth on a link-by-link basis.
A local CAC system reduces both the time to make decisions and the exchange of signalling messages. It can take advantage of direct interaction with IGMP messages, hence offering a way of implementing CAC for multicast traffic. However, its implementation is complex and must be carefully done in order to avoid problems such as the lack of information consistency.
A diagram of the MUSE QoS architecture is described in Figure 1.
While traffic class differentiation will be used for most of the traffic keeping the solution simple and scalable, per flow differentiation can also be supported for certain types of traffic in the appropriate parts of the network. A small set of traffic classes will be used to deal with most of the traffic, establishing simple scheduling algorithms in the network elements to differentiate them.
Traffic classification will normally be performed by the traffic originator, unless delegated to the network operator. However, the network will ensure that the load of each traffic class is below the level that has been used for dimensioning by means of policing the different traffic classes on a per subscriber basis. This traffic policing should be done as close to the user as possible in order to react faster, to guarantee enough network resources, to protect sensitive traffic, etc; that is, at the access nodes (AN). The policies could be statically provisioned for common residential services. However, personalised policies could be applied in association with the authentication process, so that richer and more dynamic services could be supported. Inside the network, nodes must have dedicated queues per traffic class at the output ports, which will be attended by a scheduling mechanism with strict priority or weighted mechanisms.
CAC is not necessary for all services, but only for those featuring difficulty in demand prediction and require a large amount of resource. This is likely to happen on the access links, because of their relatively high associated cost, and especially for the upstream traffic when using asymmetric access technologies. It may also happen on aggregate links which carry a mix of basic Internet traffic and video. Hence, CAC is recommended to be applied at least for protecting the traffic of the most sensitive services; that is, real-time or loss-sensitive ones, and especially those that require a relatively big amount of bandwidth (e.g. IPTV and VoD).
Appropriate network dimensioning will reduce the chances of having congestion problems and hence will diminish the need for widespread deployment and usage of resource reservation and admission control mechanisms; these can be difficult to deploy as they add the need for signalling and stateful management at network elements. Of course, an appropriate network dimensioning requires an awareness of possible traffic evolution patterns in the network. Hence, traffic monitoring and reporting per node are required.
A natural way to group telecommunication services is as a function of the type of traffic they generate. The main differentiators identified in MUSE are:
|Traffic class||Terminology proposed in MUSE||3GPP||ITU|
|Inelastic interactive||Real Time||Conversational||Interactive|
It is recommended that all network nodes support at least the 4 classes of services defined in the previous table. Every operator can obviously provide additional classes of services.
In large access network domains, there could be a scalability problem when implementing signalled and central CAC for each and every flow. Hence, MUSE recommends the use of central CAC for the (small) subset of services that actually need it, and only in those parts of the network where the network operator has identified a potential dimensioning problem, whereas local CAC or no CAC can be used for the rest of the traffic.
A mechanism is needed to segregate the network resources into:
The next section describes the mechanism selected by MUSE to segregate the network resources.
Note that a given set of resources can either be completely dedicated to traffic subject to CAC or, to improve network utilisation, may also be shared by traffic not subject to CAC. In the case of sharing, prioritisation mechanisms will be required in addition to CAC. Depending on the network architecture and dimensioning, CAC may only be needed for certain links within an end-to-end path.
In addition to any admission control performed by the network operator, it is the responsibility of the service provider, through a separate service admission control, to check whether necessary resources are still available on the services platform and at the traffic classes contracted to the network operator (in a wholesale scenario).
MUSE recommends a “provisioning” scenario where the central CAC, which has a view of all network resource usage, is able to allocate to a local CAC a certain amount of resources that will then be managed locally. A scheme of this provisioning scenario can be seen in Figure 2.
Simpler scenarios could be designed where each CAC system just controls a dedicated set of resources and no interrelation is needed between them. However, the main drawback of such an approach is that optimization of resource usage is difficult to achieve.
Within this approach, the central CAC regularly monitors the usage of local resources at the Access Nodes (AN) and adjusts the resources allocated to the local CAC entities if needed.
The usage of WFQ is recommended as scheduling algorithm in those links where capacity is high enough, as it helps to provision the required bandwidth for each traffic class by appropriately setting the different weights. However, use of SP is recommended for guaranteeing a low queuing delay for real time traffic in those links where capacity is relatively low, whereas WFQ can be used for sharing the remaining bandwidth among the rest of classes.
This approach is recommended as it gives more flexibility to share resources between central and local CAC, and allows more reactivity if a significant evolution occurs between central and local traffic proportions. This mechanism could be used to adjust the threshold for local resources over a day, allowing, for instance, attractive prices on VoD when TV bandwidth is not heavily used, or even close to real-time when local allocated resources are exhausted while there are still global available resources, so that resource allocation is kept to an optimum.
More complex and dynamic scenarios can be envisioned where local CAC entities are able to request additional resources to the central CAC system in a proactive way. However, the added complexity does not justify going for such approaches in the medium term.
Central CAC is usually considered as the simplest approach, and hence is in principle recommended to be used for applications requiring explicit CAC (e.g. VoD) where neither scalability nor setup delays are special concerns.
A central CAC entity has a single but complete view of the availability of all network resources in a network area. This is usually done by listening to link-state routing protocols running on the network, in conjunction with a database containing the installed network elements and the installed bandwidth per interface. The admission control entity receives all the requests for starting a service and, since it has a current view of the status of the network, it decides whether it is possible or not to accept the request. Once this decision has been made, resource reservation can be done.
However, for the admission control of multicast flows, a centralized implementation of the CAC function is not appropriate. A centralized admission control would have to decide if a new requested channel could be delivered or not each time it receives a request to join a multicast channel. There are three problems with this:
Two of these problems can be solved by a distributed CAC system, but there will still be a need to maintain a mapping of multicast group addresses to channel bandwidth.
Within MUSE project, it has been proposed the analysis of a centralized CAC mechanism using Impact Matrixes.
An impact matrix shows the different types of interference (or impact) that a concrete network traffic (pre-computed end-to-end path) causes in the rest, in terms of available bandwidth. We consider three types of impact:
The size of an impact matrix is (number of network nodes)x(number of network nodes). Each matrix position represents a network traffic identifier.
There are several steps for computing the impact matrixes:
How to use these impact matrixes for the admission control?
Firstly, it is necessary to introduce the concept of Acceptance Matrix:;* It contains the minimum available bandwidth along the links that compound the path between every pair of network nodes, that is, the bottleneck of each path.
Once this term has been defined, we must mention that the proposed admission control is carried out according the available bandwidth that the acceptance matrix indicates for each one of the traffics.
The impact matrixes, once they have been built in the initialization phase, tell us how to modify/update each one of the acceptance matrix positions, that is, the available bandwidth for supporting future traffic requests.
So, when the central CAC entity receives a traffic request from a network node, it has to carry out several steps:
Before it has been described the acceptance procedure of an incoming traffic request. Now, we present the release process of an established connection that is equivalent to the explained previously:
In further analysis, the four traffic classes proposed by MUSE will be considered.
By using traffic classes, it is possible to decouple the checking of available resources into two parts: a CAC per traffic class, which consists of verifying that the traffic class involved in the session request has available resources, and a policing of traffic classes.
Note that local CAC can be performed independently in different nodes (i.e. RGW, AN, EN), so that a single reject decision is enough for denying the service request. In this way, local CAC can be deployed at those parts of the network where congestion is more likely to appear.
This decoupling approach allows a positive local CAC decision made by a single node to be enough for guaranteeing that there will be available resources in the corresponding traffic class, provided that such a traffic class is dimensioned to be used at the maximum rate by every user. This is not a special concern for multicast traffic, as this does not depend on the number of users but on the number of channels that are being simultaneously watched. But this approach could also be followed for unicast traffic. By taking into account the statistical nature of the traffic generated by the services of a given traffic class, the amount of resources needed is reduced and scalability is improved.
In addition, under congestion conditions, the network operator may decide to unilaterally vary the policing of the traffic classes, communicating to the local CAC entities the new limits for each traffic class so that the new conditions for using the traffic classes can be taken into account. Besides, traffic policing could be dynamically varied upon request from the network users provided that there are enough available resources in the network.
Note that local CAC can be applied at the Residential Gateways, independently of other CAC systems running in the network. This way, services that are not subject to CAC in the network could be delivered with QoS guarantees without the network being aware of such service sessions. However, the Residential Gateway should have awareness of those service sessions, by snooping the application signalling or by using service signatures provided by the service providers. This last approach is better, as it requires the cooperation of the service provider, which can provide also the parameters needed for evaluating the CAC, i.e. the effective bandwidth. It can also provide the necessary signalling messages for informing the service provider about the denial of service and/or the user when the Residential Gateway CAC decides to block the session.
In this case, within MUSE project it has been proposed an admission control (CAC) technique based on local quotas for accepting the incoming traffic requests. Although it considers a central system that computes these local quotas, we must mention that the operation of the proposed admission control technique is based on a local scheme, since each node in the network with admission control functions manage their assigned quotas locally, without intervention of the central system.
We must start by defining what a local quota is:;* It is the assigned percentage of the total available bandwidth in a node for a determined traffic in the network. This assigned amount of capacity can be managed locally by the node in order to accept or reject an incoming traffic request, without asking for permission for establishing it to the central system. This is possible because the assigned quotas for each one of the traffics take into account the minimum available bandwidth for the rest of traffics. So, if a node has enough capacity for serving a traffic request, this node can accept it guaranteeing that it is going to be established by all the pre-determined links successfully, that is, there is going to be available capacity enough along the pre-computed path for this traffic.
Local quotas computation
The local quotas computation process that is carried out by the central system is explained following:
Again, in further analysis, the four traffic classes proposed by MUSE will be taking into account.
A policy is the combination of rules and services where rules define the criteria for resource access and usage.
According to the Common Open Policy Service (COPS) terminology, three functional elements are defined for using policies in a network:
Traffic policing consists of verifying that a given traffic class does not exceed a certain profile. Enforcement of the allowed QoS policy (bandwidth, maximum size of packet, etc.) maybe required so that misbehaving traffic does not impact the QoS of the other users/classes. Protection can only be provided if such enforcement is done on a per user and per traffic class basis. Note that as a result of the policy enforcement, out of profile traffic could be dropped, remarked or delayed until it complies to the profile (i.e. traffic shaping).
For the upstream traffic, it is recommended that the policy enforcement be done at the Access Nodes (AN). This will minimise the chances of misbehaving users altering the QoS of other users in the aggregation network. Otherwise, excessive traffic marked as high priority by some users may cause starvation of lower priority traffic of other users.
However, for the downstream traffic, it is recommended that policy enforcement be done at the Edge Nodes (EN) on aggregate of IP flows (i.e. traffic classes) in order to lower the processing power required at these nodes. This will not prevent a single misbehaving user from impacting the aggregate, but will limit any damage to that aggregate.
In addition to the aggregate enforcement at the Edge Nodes for downstream traffic, it is recommended to have per user shaping of downstream traffic at the Access Node to prevent congestion in the first mile. Shaping is commonly done at the BRAS in current architectures. However this is no longer viable in a multi-edge architecture. The only point at which all the traffic for a given line comes together may be the Access node itself.
The link between the Residential Gateway and the Access Node (AN) is usually the main bottleneck, especially since its capacity cannot easily be increased. To solve the contest for bandwidth on this link, the usage of prioritization mechanisms for handling traffic classes is recommended. Additionally, traffic policing can be used for avoiding starvation of lower priority traffic and fulfilling the usage limitations per traffic class.
Classification of upstream traffic into the traffic classes, and its prioritization onto the access link will be realized by the RGW according to user preferences (note that these preferences can be delegated to the network operator or to any service provider, and that traffic could have been previously marked by a terminal). This classification can be done by identifying application signatures, by using predefined ports at the RGW, by evaluating the Ethertype, etc. The policing of upstream traffic will be done by the Access Node according to the rules defined above.
Prioritization of downstream traffic per traffic class is made by the network according to the rules described in the user contracts (i.e. residential and corporate users, service providers, etc). This is currently done at Edge Nodes (EN). However, when having multiple Edge Nodes in the network, there is not a single point of control of downstream traffic except for the Access Node.
MUSE recommends a user-centric approach where classification of traffic into traffic classes is a responsibility of the user even if it is expected to be normally delegated to the providers. However, the network will ascertain that the usage of each traffic class does not exceed what has been planned, agreed or contracted by means of traffic policing. For the upstream traffic, it is recommended that the policy enforcement be done at the Access Nodes per Traffic Class and per Access Line. However, for the downstream traffic, it is recommended that the policy enforcement be done at the Edge Nodes per Traffic Class. It is also recommended to have per user shaping at the Access Node of downstream traffic to prevent congestion in the first mile.
MUSE recommends the use of central CAC for the small subset of services that actually need it and only in those parts of the network where the network operator has identified a potential dimensioning problem. Local CAC at the Access Nodes or no CAC can be used for the rest of the traffic. Appropriate network dimensioning will help to minimize the risk of congestion or blocking problems.
Central CAC is recommended for applications requiring explicit CAC where neither scalability nor setup delays are special concerns (e.g. VoD). Local CAC is recommended to handle multicast traffic (e.g. IPTV) because of its better scalability and lower reaction time.
MUSE recommends a “provisioning” scenario where the central CAC, which has a view of all network resource usage, is able to allocate to a local CAC a certain amount of resources that will then be managed locally. Within this approach, the central CAC regularly monitors the usage of local resources at the Access Nodes and readjusts the resources allocated to the local CAC entities if necessary.
It is recommended that all network nodes support at least the four traffic classes proposed by MUSE (real-time, streaming, transactional and best-effort). At every link, outgoing traffic will be placed into a different queue according to what traffic class it belongs. These queues will be served by Strict Priority (SP) and/or WFQ scheduling mechanisms. SP is recommended to be used for guaranteeing a low delay for real time traffic in those links where capacity is relatively low, whereas WFQ can be used for the rest of classes. When capacity is high enough, WFQ can help to provision the required bandwidth to each traffic class.