QOS BASED ROUTEING FOR HIGH SPEED ... - CiteSeerX

QOS BASED ROUTEING FOR HIGH SPEED ENVIRONMENT. Laurent FRANCK, Bernard SALES Université Libre de Bruxelles Service Télématique et Communication Bd du Triomphe CP 230, B-1050 Brussels, Belgium {franck, sales}@helios.iihe.rtt.be C=be; ADMD=rtt; PRMD=iihe; O=helios; S={franck, sales}

Abstract:With the new rise of applications such as multimedia, the networking environment has to provide more and more bandwidth and should be able to meet the user requirement . The deployment of optical fibers with the emergence of the ATM technology which relies on a Virtual Call (VC) model is the necessary infrastructure to support these applications.. However, we believe that the QoS routeing for VC model has received little attention from the researcher community. In this paper, we propose to extend the classical method for packet switching, namely the distance vector and the link state method to cover these new user requirements. We present routeing architectures using route recording and source routeing which are based on "pre-computed" and "on-demand" routes. Simulation results are provided for the on-demand DV algorithm we propose.

1 Introduction With the new rise of applications such as multimedia, the networking environment has to provide more and more bandwidth and should be able to meet the user requirements such as throughput and transit delay. These guaranties can not be easily ensured by environments based on the datagram packet switching techniques since no communication path is set up between the communicating systems. Furthermore, the network can not efficiently control the quality of the communications. The deployment of optical fibers at a large scale in conjunction with the development of the ATM technology which relies on a Virtual Call (VC) model is the necessary infrastructure to support these modern applications. In this model, the key point is the establishment of a communication path that fulfils the application requirements in terms of a pattern of characteristics called QoS parameters which can be handled by the network. The combination of QoS requirements and VC switching techniques leads to a new class of protocols we call "VC/ QoS" algorithms. The routeing protocols which have been designed in the datagram context only provide the applications with QoS values corresponding to the best effort semantics [NajSal2]. In this context, we need to revisit the existing routeing architectures in order to cover this new use and understanding of QoS parameters.

2 Environment considered and basic definitions The environment we are considering may be modelled as a set of Host Systems (HS) (i.e. systems hosting application processes) and a set of Network Nodes (NN) (switching equipment) arbitrarily interconnected with links. Each System is identified by an address which is unique in the context of the network. Every link interconnecting two Systems is weighted by a set of QoS parameter values. While the VC/QoS multipoint scheme is being investigated in our laboratory, we only consider in this paper the point to point situation. The concept of routeing domains (RD) introduced in ISO/IEC 9575 or any other equivalent term, has been introduced to cover the requirements of administrative-like structure in several architectures (e.g. Internet, OSI, ...). The environment we are considering will also be structured in this way. In this context, the routeing is involved in two separate levels: Intra-RD (the route within a domain) and Inter-RD (the routes linking the RDs). For the purpose of this paper, only the Intra RD case will be discussed. The Inter RD routeing in a VC/QoS environment is addressed in [NajSal2]. Finally, we define the following terms that we will use in the next sections: Border NN: an NN with a least one HS attached. Transit NN: an NN with no HS attached. Source NN: for a call, a selected NN attached to the HS which has originated the call. Destination NN: for a call, a selected NN attached to the HS to which the call is destined.

3 VC set up model In the existing VC/QoS models (e.g. X.25, ATM [DePryck], ...), the connection is first established from the calling HS to the called HS. This allows the calling user to specify its QoS requirements during the set-up phase and gives the network the opportunity to take the appropriate actions in order to guarantee these requirements for the lifetime of the VC. With the current model, as the call packet traverses the network from the calling to the called HS, the route is established step by step according to the calling HS requirements and the network capabilities (This is modelled in ISO/IECּ10028). Once the called HS is informed of the incoming call it has the possibility to negotiate the QoS. This negotiation does not imply a route re-calculation at all. This means that the

route selection is based only on the calling HS requirements and the network capabilities. The called HS requirements and/or capabilities do not influence the route selection mechanism. As a result of this, a new model for VC set-up is proposed where the connection is established from the called HS to the calling HS. In this model, the calling HS sends a message carrying the QoS requirents to the called HS. This HS selects QoS it can support, and the VC is set up from the called HS to the calling HS by using a route matching these QoS requirements This new style of VC set up model leads to a more accurate resource allocation and management scheme. In particular, this increases the number of potential routes between the calling and the called hosts. It is also well suited for supporting multi-point and conference calls. This model has been proposed in [NajSal2] in a QoS negotiation context and in [RSVP] for a multi-point environment.

4 Routeing architecture for high speed QOS environment 4.1

Basic algorithms

The SPF methods used for packet switching routeing can be classified in two main families: the Distance Vector (DV) algorithms (e.g. RFC 1058, ...) based on a method developed by Bellman-Ford [BellFord] and the Link-State (LS) (e.g. RFC 1583, ISO10589, ...) based on a method originally proposed by Dijkstra [Dijk]. In the following sections, we will consider the DV and LS algorithms in the VC/QoS environment, outlining problems that may arise in this new context and proposing solutions. With the DV method [Perlman], the route calculation is performed in a distributed way, each system keeping one or more routes for each Destination HS it can reach. For instance, only the shortest path can be maintained in the NNs. The storage complexity for a basic DV is given by O(m.d.g) where m is the number of metrics, d is the number of HSs in the RD and g is the maximum number of links that an NN may be connected with. In addition, an NN must store the distance to every other adjacent NN (i.e. a storage complexity of O(m.g)) On the other hand, with the basic LS technique, when an NN is aware of local topological changes, it constructs an LS PDU (Link State PDU,which will be broadcasted in the whole RD [Rosen]). This will allow an NN to maintain the complete topological map of the network. The storage complexity is of O(m.n.g) for the entire topology of the RD and O(m.d) for every SPF route (n is the number of Systems = HS+NN). In the basic LS method, such as described in ISO/IECּ10589 and in RFC 1583, the routes to every destination HS are computed in each NN using the topological map (i.e. a Dijkstra-like algorithm is performed

[Dijk] [Perlman]). Such a computation is started each time an LS PDU is received. (This processing is in at most O(m.d.n.g.log(n)).) In some LS environment, NNs are grouped into "clusters" to limit the resource required for route computation and maintenance (e.g. OSPF (RFCּ1583), IS-IS (ISO/IECּ10589), [Nimrod]).

4.2 The loop problem Both DV and LS can suffer from two kinds of loops [Garcia] [GuNajSal]: Long term loops which are caused by the algorithms computing the routes. Transient loops appearing during the convergence process of the algorithm. More precisely, transient loops only result from a temporary loss of synchronisation among NN routeing bases. These inconsistencies are caused by the inherent delay existing in the distribution of routeing information. In a VC environment, since the route computed at the set up phase will be used during the whole lifetime of the VC, the routeing protocol should provide "loop free" routes in any circumstances [NajSal1]. For the LS, two cases are to be studied: either the route is calculated in a distributed way (e.g. each NN uses its complete topology map to compute the next step leading to the destination) or the entire route is calculated by a single NN (i.e. a border NN). In the first case, in order to prevent "long term loop", the SPF algorithm in each NN should be the same. If not, NNs may disagree on the "best" route to be used (ISO/IECּ10589 , RFC 1583, [Nimrod],[PNNI]). Transient loops can be avoided by implementing some kind of synchronisation protocol. The second solution enables, by definition, to avoid any kind of loops without processing overhead. With that respect, this solution might be better. Another advantage of this centralised solution is that NNs can use different algorithms, this can be useful, e.g., for testing purposes. This solution implies that the whole route is transported in the packet establishing the route (source routeing). For the DV method, solutions have been proposed to avoid both transient and long term loops [MerlSeg] [Cheng] [JafMos] [ZauGar] [Garcia] [Humblet] or to detect long term loops (complete route recording) ([GuNajSal] [NajSal1], ISO/IEC 10747]). However, the suggested solutions for loop avoidance for "DV-like" algorithms were usually related to SPF (Shortest-Path First) calculation which either prevents their adaptation to QoS based routeing [Awerb] or introduces a very poor performance [Garcia]. At the time being, the application of the DV in a VC/ QoS context implies that only detection techniques such as route recording are workable. As a result, the update packets which are used by the DV algorithm to compute the route record the complete route. This will allow the NN using this route to specify the complete route at the VC set up phase (source routeing). The knowledge of the complete route prevents "short term loops" for DV as well.

4.3 Pre-computed calculation

vs.

on

demand

In a datagram environment such as Internet, the routes can be computed "in advance" since a best effort policy is applied. Furthermore, this solution is more efficient in terms of routeing and forwarding performance. This pre-computation is feasible since: These architectures use a limited number of metrics. These metrics are never combined. Only the shortest path route according to one routeing metrics is calculated. If we consider the QoS/VC case, the pre-computation and storage of routes supporting each source/destination/ QoS combination would be too expensive. For the DV method, this means that the NNs should continuously maintain a routeing base in the order of O(v**q.d.g), where q is the number of different QoS parameters and v is the maximum number of different values for one QoS parameter. In addition, an NN has to propagate information for each route concerned with an update, this means that an NN has to send in the worst case O(v**q.d) route notifications. In contrast, with the LS case, an LS PDU can carry the m QoS values characterising a given link. In this way, the complete topology map including QoS characteristics associated to each link can easily be maintained [NajSal1] [PNNI]. However, a pre-computed method requires to execute in the order of O(v**q.d) times the route calculation algorithm in each node concerned. It can also be noted that, in the LS method, the QoS model implies to compute locally in the NNs concerned a multi criteria algorithm which is in the order of O(Exp(n)). This is caused by the independence of QoS with each other. It is impossible to map an aggregation of QoS values to a single metric, which is the basic requirement to run an SPF style algorithm. Some methods have been proposed to reduce this complexity to the one of an SPF calculation [PNNI]. These methods, however, do not guarantee that, even if a route supporting the user requirements exists, this route will be discovered by the algorithm.

4.4

Pre-computed route

We can notice that the requests in terms of QoS initiated by the HSs in the network correspond in most cases to a few well-known patterns of QoS (e.g. file transfer service, remote terminal access,ּ...) (This was first mentionned in RFCּ1322). This means that the routes for which the requests are predictable in terms of QoS combination requirements can be computed by the network in advance. Nevertheless, this method has drawbacks since the performance of pre-computed routes is bounded to the reliability and accuracy related (to the age) of information stored in the routeing base at the time information is used. The number of different routes to a single Destination HS that the network should maintain will be equal to P (P is the number of predictable QoS combination values for

which the network is able to maintain a route), with P