Towards self-adaptation in DiffServ-GMPLS network … · Towards self-adaptation in DiffServ-GMPLS...

9
54 Int. J. Internet Protocol Technology, Vol. 3, No. 1, 2008 Copyright © 2008 Inderscience Enterprises Ltd. Towards self-adaptation in DiffServ-GMPLS network for video-conferencing services Hassine Moungla* INRIA – ARLES Project Team, Domaine de Voluceau, Rocquencourt, B.P. 105, 78153 Le Chesnay Cedex, France Fax: +33 (0)139 63 54 00 E-mail: [email protected] LIPN Laboratory – UMR 7030 CNRS, Paris XIII University, 99, Avenue Jean-Baptiste Clément, 93430 Villetaneuse, France E-mail: [email protected] *Corresponding author Francine Krief LaBRI Laboratory – UMR 5800 CNRS, University of Bordeaux I, 351, cours de la Libération, 33400 Talence, France E-mail: [email protected] Abstract: The recently developed H.264 video standard achieves efficient encoding over a bandwidth ranging from a few kilobits per second to several megabits per second. Hence, transporting H.264 video is expected to be an important component of many networks multimedia services. However, due to lack of QoS support reaction networks, the basic GMPLS network management is not sufficient to deliver real-time traffic. The delivery should be augmented by appropriate mechanisms to adjust the QoS parameters. In this paper we address H.264 video transmission over GMPLS networks by proposing a robust policy based control architecture that leverages the inherent H.264 error resilience tools. Keywords: DiffServ; GMPLS; policy; policy based control; MPEG4, H.264; video; self-adaptation. Reference to this paper should be made as follows: Moungla, H. and Krief, F. (2008) ‘Towards self-adaptation in DiffServ-GMPLS network for video-conferencing services’, Int. J. Internet Protocol Technology, Vol. 3, No. 1, pp.54–62. Biographical notes: Hassine Moungla received a BS Degree in Computer Engineering from USTHB, Algiers, in 1999. He received an MS in Application of Artificial Intelligence in Telecommunication Management from the University of Paris XIII in 2002. He obtained his PhD Degree in Computer Science from the University of Paris XIII in November 2006, on Evolution towards an autonomic network management: Extension about policy based management. He is now a researcher at INRIA Rocquencourt France. His other interests are in mobility management in AdHoc networks and multimedia transport over wireless and MPLS/GMPLS networks. F. Krief is a Professor of Computer Science at the University of Bordeaux1, France. She received her PhD in Computer Science from Pierre-et-Marie Curie’s University of Paris, France. Her current research focuses on automatic services deployments for mobile and fixes terminals, security and QoS communications. 1 Introduction One of the driving forces of the next networks generation is the promise of high-speed multimedia service, providing multimedia services to mobiles and fixed users. However, networks characteristics such as multipath, fading, and interferences still limit the available bandwidth for the deployed applications. Consequently, video compression techniques are a crucial part of multimedia applications over LAN.

Transcript of Towards self-adaptation in DiffServ-GMPLS network … · Towards self-adaptation in DiffServ-GMPLS...

54 Int. J. Internet Protocol Technology, Vol. 3, No. 1, 2008

Copyright © 2008 Inderscience Enterprises Ltd.

Towards self-adaptation in DiffServ-GMPLS network for video-conferencing services

Hassine Moungla* INRIA – ARLES Project Team, Domaine de Voluceau, Rocquencourt, B.P. 105, 78153 Le Chesnay Cedex, France Fax: +33 (0)139 63 54 00 E-mail: [email protected]

LIPN Laboratory – UMR 7030 CNRS, Paris XIII University, 99, Avenue Jean-Baptiste Clément, 93430 Villetaneuse, France E-mail: [email protected] *Corresponding author

Francine Krief LaBRI Laboratory – UMR 5800 CNRS, University of Bordeaux I, 351, cours de la Libération, 33400 Talence, France E-mail: [email protected]

Abstract: The recently developed H.264 video standard achieves efficient encoding over a bandwidth ranging from a few kilobits per second to several megabits per second. Hence, transporting H.264 video is expected to be an important component of many networks multimedia services. However, due to lack of QoS support reaction networks, the basic GMPLS network management is not sufficient to deliver real-time traffic. The delivery should be augmented by appropriate mechanisms to adjust the QoS parameters. In this paper we address H.264 video transmission over GMPLS networks by proposing a robust policy based control architecture that leverages the inherent H.264 error resilience tools.

Keywords: DiffServ; GMPLS; policy; policy based control; MPEG4, H.264; video; self-adaptation.

Reference to this paper should be made as follows: Moungla, H. and Krief, F. (2008) ‘Towards self-adaptation in DiffServ-GMPLS network for video-conferencing services’, Int. J. Internet Protocol Technology, Vol. 3, No. 1, pp.54–62.

Biographical notes: Hassine Moungla received a BS Degree in Computer Engineering from USTHB, Algiers, in 1999. He received an MS in Application of Artificial Intelligence in Telecommunication Management from the University of Paris XIII in 2002. He obtained his PhD Degree in Computer Science from the University of Paris XIII in November 2006, on Evolution towards an autonomic network management: Extension about policy based management. He is now a researcher at INRIA Rocquencourt France. His other interests are in mobility management in AdHoc networks and multimedia transport over wireless and MPLS/GMPLS networks.

F. Krief is a Professor of Computer Science at the University of Bordeaux1, France. She received her PhD in Computer Science from Pierre-et-Marie Curie’s University of Paris, France. Her current research focuses on automatic services deployments for mobile and fixes terminals, security and QoS communications.

1 Introduction

One of the driving forces of the next networks generation is the promise of high-speed multimedia service, providing multimedia services to mobiles and fixed users. However,

networks characteristics such as multipath, fading, and interferences still limit the available bandwidth for the deployed applications. Consequently, video compression techniques are a crucial part of multimedia applications over LAN.

Towards self-adaptation in DiffServ-GMPLS network for video-conferencing services 55

Recently, the H.264/AVC (ITU-T Rec. H.264/ISO/ IEC 14496-10 AVC, JVT-G050, 2003) video coding standard, proposed by both the Joint Video Team (JVT) of the International Telecommunication Union – Telecommunication Standardization Sector (ITU-T) and the Moving Picture Experts Group (MPEG), achieved a significant improvement in compression efficiency over the existing standards. For instance, digital satellite TV quality was reported to be achievable at 1.5 Mb/s, compared to the current operation point of MPEG-4 part 2 video codec (ISO/IEC 14496-2, 01, 2001) at around 3 Mb/s.

Additionally, H.264 standard introduces a set of error resiliency techniques such as slice structure, Data Partitioning (DP), and Flexible Macro-block Ordering (FMO). However, these techniques are insufficient because the resource management and protection strategies available in the lower layers are not optimised explicitly considering the specific characteristics of multimedia applications.

This paper focuses on the transmission of H.264 video streams over Generalized Multi-Protocol Label Switching (GMPLS) networks by proposing self-adaptation through differentiations services over GMPLS and a policy based control architecture. The proposed self-adaptation are setting-up by closing the loop of QoS reaction in the proposed cross-layer architecture relies on a DP technique at the application layer and an appropriate QoS mapping at the LSP. Through employing the differentiation services based LSPs.

Thus, we allow the application layer to pass its streams along with their requirements in order to protect the most important H.264 information, which guarantees low degradation of received H.264 stream.

We give a brief overview of H.264 video standard in the following section.

1.1 H.264 standard overview

H.264 consists of two conceptually different layers. First, the Video Coding Layer (VCL) contains the specification of the core video compression engines that achieve basic functions such as motion compensation, transform coding of coefficients, and entropy coding.

This layer is transport-unaware, and its highest data structure is the video slice – a collection of coded Macroblocks (MBs) in scan order. Second, the Network Abstraction Layer (NAL) is responsible for the encapsulation of the coded slices into transport entities of the network. In this H.264 overview, we particularly focus on the NAL layer features and transport possibilities. The reader can refer to ITU-T Rec. H.264/ISO/IEC 14496-10 AVC, JVT-G050 (2003) for more details of VCL layer characteristics.

1.2 Network abstraction layer

The NAL defines an interface between the video codec itself and the transport world. It operates on NAL Units (NALUs) that improve transport abilities over almost all

existing networks. An NALU consists of a one-byte header and a bit string that represents, in fact, the bits constituting the MBs of a slice. The header byte itself consists of an error flag, a disposable NALU flag, and the NALU type. Finally, the NAL provides a means to transport high-level syntax (i.e., syntax assigned to more than one slice, e.g., to a picture or group of pictures) to an entire sequence.

1.3 Parameter Set Concept

One very fundamental design concept of the H.264 codec resides in its ability to generate self-contained packets, making mechanisms such as header duplication and MPEG-4’s Header Extension Code (HEC) unnecessary. The way this is achieved is to decouple information relevant to more than one slice from the media stream. This higher-layer Meta information should be sent reliably, asynchronously, and before transmitting video slices. Here, provisions for sending this information in-band are also available for applications that do not have an out-of-band transport channel appropriate for the purpose. The combination of higher-level parameters is called the Parameter Set Concept (PSC). The PSC contains information such as picture size, display window, optional coding modes employed, MB allocation map, and so on. In order to be able to change picture parameters without necessarily retransmitting PSC updates, the video codec can continuously maintain a list of parameter set combinations to switch on. In this case each slice header would contain a codeword that indicates the PSC to be used.

1.4 Error resilience tools: data partitioning

The H.264 standard includes a number of error resilience techniques. Among these techniques, DP is an effective application-level framing technique that divides the compressed data into separate units of different importance. Generally, all symbols of MBs are coded together in a single bit string that forms a slice. However, DP creates more than one bit string (partition) per slice, and allocates all symbols of a slice into an individual partition with a close semantic relationship.

In H.264 three different partition types are used:

• Partition A, containing header information such as MB types, quantisation parameters, and motion vectors. This information is the most important because without it, symbols of the other partitions cannot be used.

• Partition B (intra partition), carrying intra coded block pattern (CBP) and intra coefficients. The type B partition requires the availability of the type A partition in order to be useful at the decoding level. In contrast to the inter information partition, intra information can stop further drift and hence is more important than the inter partition.

• Partition C (inter partition), containing only inter CBPs and inter coefficients. Inter partitions are the least important because their information does not

56 H. Moungla and F. Krief

resynchronise the encoder and decoder. In order to be used it requires the availability of the type A partition, but not of the type B partition.

Usually, if the inter or intra partitions (B or C) are missing, the available header information can still be used to improve the efficiency of error concealment. More specifically, due to the availability of the MB types and motion vectors, a comparatively high reproduction quality can be achieved as only texture information is missing.

2 Our approach

The Multi-Protocol Label Switching (MPLS) technology is a suitable method to provide Traffic Engineering (TE), independent of the underlying layer2 technology (Awduche et al., 1999, 2001). MPLS cannot provide a mapping between a LSP and a service differentiation, which brings up the need to complete it with another technology capable of providing such a feature: DiffServ. It is becoming prominent in providing scalable network designs supporting multiple classes of services. Currently, in Internet Engineering Task Force (IETF), DiffServ and MPLS, both provide their own benefits (Seo et al., 2006).

GMPLS is a new technology proposed by the IETF (Mannie, 2004). GMPLS is a protocol (Berger, 2003a, 2003b) that use advanced network signaling and routing mechanisms to automate set up of end-to-end connections for all types of network traffic: TDM, Packets or Cell-based, Waveband or Wavelength. GMPLS extends MPLS to encompass new technologies (optical networks). We would also like to extend the differentiation of service in this GMPLS networks. In this paper, a new method is proposed to engineer QoS paths within a Diffserv over GMPLS domain. This notion applies a set of rules across the domain (GMPLS domain) to allocate LSP to the traffic based on the Diffserv classes of service and dynamic link metrics.

We will apply policy-based management (PBM) concepts to manage a DiffServ GMPLS network, because we consider this as an appropriate way of dealing with large sets of managed elements. Using PBM for networks and systems in QoS or security is very popular since the early work on policies such as Beigi et al. (2004), Moffett and Sloman (2004) and Teo and Ahn (2007).

The remainder of this paper is organised as follows. Section 3 describes Diffserv over MPLS, GMPLS and its basic mechanisms; Section 4 describes our method to make the differentiation services mechanism over GMPLS. Sections 5 and 6, we describe the proposed cross-layer architecture which it deals with the application for PBM in DiffServ/GMPLS networks. We also devote a Section 7 to the performance evaluations. Finally, we conclude this paper.

3 From MPLS to GMPLS

Traditional MPLS is designed to carry Layer 3 IP traffic using established IP-based paths and associated these paths

with arbitrarily assigned labels. These labels can be configured explicitly by a network manager, or be dynamically assigned by means of a protocol such as the Label Distribution Protocol (LDP) or the Resource Reservation Protocol (RSVP).

But how the differential services are making over MPLS?

In a multi-service network, different applications have varying Quality of Service (QoS) requirements. The IETF has proposed the Diffserv architecture as a scalable solution to provide QoS in IP Networks. In order to provide quantitative guarantees and optimisation of transmission resources, Diffserv mechanisms should be complemented with efficient TE mechanisms, which operate on an aggregate basis across all classes of service. The MPLS technology is a suitable method to provide TE, independently of the underlying layer2 technology (Seo et al., 2006).

In recent years there has been active research in the field of MPLS and an increasing number of networks are supporting MPLS. An MPLS network consists of LSPs and edge/core label switch routers (LERs/LSRs). The LSRs store the label translation tables. Core LSRs provide transit services in the middle of the network while LERs (edge LSRs) provide an interface with external networks. The RFC 3270 gives an answer to a research problem related to the Diffserv model and MPLS, this document (Le Faucheur et al., 2002) presents a solution for the support of DiffServ over MPLS networks. There are two types of MPLS LSPs that support DiffServ extensions the E-LSP and the L-LSP, see in Figure 1:

• EXP-inferred-PSC LSPs (E-LSP). This type of LSP can support only eight Behaviour Aggregates (BA). This is because the three-bit EXP field is used to infer the PHB that is applied to a packet. These LSPs are referred to as E-LSP. The PHB Scheduling Class (PSC) of a packet transported on this LSP type depends on the EXP field value for that packet. With this approach, a single LSP can be used to support one or more Ordered Aggregates (OAs). Here, the mapping of an EXP field with a PHB is either explicitly done during label establishment or pre-configured.

• Label-Only-Inferred-PSC LSP (L-LSP). Separate LSPs are established for a single <FEC, OA> pair. With such LSPs, PSC is explicitly signaled at the time of label establishment, so that after label establishment, the LSR can exclusively infer, the PSC to be applied to a labelled packet from the label value. When the Shim Header is used, the Drop Precedence to be applied by the LSR to the labelled packet is conveyed inside the labelled packet MPLS Shim Header using the EXP field. When the Shim Header is not used (e.g., MPLS Over ATM), the Drop Precedence to be applied by the LSR to the labelled packet is conveyed inside the link layer header encapsulation, using link layer specific drop precedence fields (e.g., ATM CLP) (Chiu et al., 2003).

Towards self-adaptation in DiffServ-GMPLS network for video-conferencing services 57

Figure 1 E-LSP et L-LSP representation (see online version for colours)

GMPLS by defining labels, to switch varying types of Layer traffic. A functional description of extensions MPLS signaling needed to support the new classes of interfaces and switching is provided in Berger (2003a). GMPLS nodes can have links with one or more of the following switching capabilities:

• Fiber-Switched Capable (FSC)

• Lambda-Switched Capable (LSC)

• Time Division Multiplexing (TDM)

• Time Switched-Capable (TSC)

• Packet-Switched Capable (PSC).

LSPs must start and end on links with the same switching capabilities GMPLS extends the reach of MPLS through a control plane allowing it to reach into other networks and provide centralised control and management of these networks. This will bring greater flexibility to somehow rigid optical networks and provide a centralised management and control.

GMPLS uses a set of mechanisms to achieve scalability, handle the network heterogeneity regarding switch and forward mechanisms and ease of configuration, besides the requirements for resiliency. Some of these GMPLS specific mechanisms are Banerjee et al. (2001) and Ibáñez (2003):

• a separation of control channel from data channel

• a suggested label to speed up label assignment

• USE of Forwarding Adjacency (FA) Routing and Signalling.

4 DiffServ over GMPLS

As for MPLS, in GMPLS, the setting up of QoS based differentiated services rests on TE and DiffServ, but here E-LSP solution is excluded and only that based on L-LSP can considered. For the simple reason, that data routing in the optical nodes is transparent. Indeed, in the optical nodes,

the label is quite simply a time slot, a wavelength or a fibre. Thus, here the QoS management mechanisms are gathered around two techniques:

• Traffic Engineering (TE). It rests on in GMPLS an evolved RSVP-TE for the resource reservation, the generalised LSP establishment, on routing protocols adapted to GMPLS for the topology knowledge and on other network characteristics.

• DiffServ L-LSP. It consists in associating the PHB (class of traffic and drop precedence) with a LSP. In fact, neither the Class of Service (CoS) nor the drop precedence can be transported in the data.

4.1 Traffic Engineering in GMPLS

The objectives and principles of TE in GMPLS are identical to those of MPLS. On the other hand the mechanisms and protocols evolved in order to adapt to heterogeneous environments and optical networks constraints. In GMPLS, routing and signalling processes are optimised and adapted to the heterogeneous networks. They use an out of band signalisation (control channel) established by LMP. LMP provides also effective mechanisms for the checking and the detection of breakdown on the links. We limit ourselves here to describe, in what follows, their differences compared to those of MPLS.

The link information included in the Label Switch, which is transmitted by the node, is similar to that in MPLS: maximum bandwidth, Maximum reserved Bandwidth, Unreserved bandwidth, TE metric, etc. However, they are related here to interface type and coding information: Package, Ethernet, time slot (SDH/Sonet), lambda (wavelength) or fibre.

Note. The evolutions of RSVP-TE for GMPLS are proposed in RFC 3473 at the IETF [18]. RSVP-TE for GMPLS is an evolution of the RSVP-TE; it allows the establishment of a generalised LSP and the setting up of complex management resource reservation for heterogeneous environments.

4.2 DiffServ L-Lsp in GMPLS The objectives and principles of TE in GMPLS are identical to those of MPLS. On the other hand the mechanisms and L-LSP (Label only inferred PHB Scheduling Class LSP) is the only solution making it possible to associate a generalised LSP with a couple <FEC, OA>. Indeed, for two points:

• in the optical networks, there is no header added to the packet

• the optical nodes can not examine header.

For the same reasons, we will not be able to manage either drop precedence within the same CoS in the optical nodes. The PHB will depend only on the value of the label, that amounts establishing a LSP by CoS towards the same recipient. In a given L-LSP, each LSR will use the label for at the same time conveying the packet and to determine

58 H. Moungla and F. Krief

which treatment or PHB (CoS) apply to the packets. In the case of classes AF and only in the not-optics nodes, we can use the EXP field of the ‘shim header’ for the drop precedence.

4.3 Our suggested method

We have modified the work presented in Keswani and Labrador (2002), and adapted it to GMPLS networks. In order to support the differentiation of service, we propose that the L-LSP is established according to the priority of the customers, the best link corresponding to the best class according to the Explicit Routing. The cost of the link will depend on:

• the priority of the customer

• the Link Utility (LU) (appearance frequency in the shortest link)

• the available bandwidth.

The first stage consists in calculating the various links utilities by using Disjktra algorithm. From each peripheral node (Edge Router), we seek with Disjktra algorithm the shortest ways towards all the other peripheral nodes. The LU is the number of their individual appearances in these shorter ways. Thus each link will have a Utility called LU which will be used for the costs calculation.

The second stage consists in calculating the costs of the various links for each class of flow according to a formula which will be detailed further. Lastly, we calculate the best ways for each class by minimising the total cost given by the following formula:

( ) ( )N

=∑C Total C Link I

such as: N a number of links in the way and I Link included to the way.

The calculation of the ways for a given class is used for the distribution of labels and construction of the switching table. For the same destination we will have eight different labels corresponding to eight different ways referring each one to a given class (a given priority level). The links cost are calculated using the formulas below. The first corresponds to the first two priority levels, the second concerns the two following levels and so on.

where:

• B1 and B2 are two entities such as B1 > B2, chosen by the operator to differentiate the classes.

• P1 and P2 with P2 > P1 and P1 + P2 = 1.

• Lu (Link utility) is a frequency of link appearance in the shortest ways

• LUmax the greatest value of LU in the network.

• LPmax the max capacity of link bandwidth.

• BPrest remaining bandwidth for an arriving flow. This parameter depends on its class.

If, at one moment Ti, a flow of priority J arrives, then:

BPrest = BPmax – ΣBPreserved (I) (I has a greater priority than J)

To homogenise the parameters of our formula, we divide LU by LUmax and BPresv by BPmax.

5 Policy based control architecture

Policy based QoS management has been widely supported by standardisation organisations such as IETF and DMTF to address the need of QoS traffic management. They proposed a PBM framework that defines a set of components to enable policy rules that govern network resources, including conditions and actions, with parameters that determine when the policies are to be implemented in the network. Many works have been carried out in the area of policy-based QoS management for wired networks, but only few works concern GMPLS networks.

Policy scheme is one of the powerful tools to control resources allocation and automate network behaviour based on the QoS requirements specified at different levels.

A policy rule is a translation of the Service Level Agreements (SLAs) to a set of actions to be performed on target provided that some conditions are satisfied (Moffett and Sloman, 1994). Given a different levels of policies that describe users and applications needs and system constraints, a flexible framework, which we describe later, is required to manage these policies, translate them into lower level policies and monitor different events that can trigger one or more policy actions.

The requirements and high-level architecture have been defined in Cortese et al. (2001) see Figure 2. In the following, we focus on DiffServ over GMPLS specific configurations in backbone network provider and briefly mention DiffServ, because this issue is already covered by the IETF.

Taking in the consideration the network model (GMPLS) presented in the last section, we suggest the configuration of such networks with policy-based concepts (http://www.ietf.org/). We extend it with GMPLS networks and service level policies.

Since we need to manage different policies at different levels, we propose a three level architecture for the policy server. The upper level is concerned with the handle of services, the midlevel deals with the network

Towards self-adaptation in DiffServ-GMPLS network for video-conferencing services 59

configurations, and the lowest layer configures the network-element. With the three-layered architecture we get a clear separation of different levels. Note that the layering is just logical, each layer may be implemented separately with different tools and deployed independent from the other layers. We map this three level policy on CADENUS architecture, in the purpose of enabling the automation of a number of processes collectively defined as SLA-based service creation for end-user services. The CADENUS Mediation Component architecture proposes the partitioning of system functionalities into three major blocks, called Access Mediator, Service Mediator and Resource Mediator (Cortese et al., 2001).

Figure 2 Logical three-level policy over CADENUS architecture (see online version for colours)

6 GMPLS policy

PBM allows the network control as a whole instead of controlling each individual managed object (network device, interface, queue, LSP) in an independent way. Policies in the GMPLS networks focus on mapping of DiffServ traffic on LSPs, for the purpose of TE and life-cycle management of LSPs.

Configuring DiffServ/GMPLS mainly consists of configuring the LERs. However, the information about routers capabilities is needed by the policy server, in order to take appropriate/device-specific decisions. Information about the capabilities of the LER is needed to decide which configuration applied on the device.

Policies are concerned with LSPs, including the mapping of traffic to LSPs. This LSP is related to a Forward Equivalence Class (FEC), an OA, a traffic profile, a route specification, a role and a resource class.

The <FEC, OA> couple specifies what type of traffic is used by the LSP and the traffic profile specifies a resource profile for the LSP, e.g., delay, bandwidth, etc. The route specification may be used for explicitly set up the route of an LSP or it is used to store the route chosen by the network

independently of the policy server. The ‘role’ concept, introduced in PCIM, permits the grouping of the network entities (ex.LSPs) according to the role they play in the network. The role is used to assign a certain property to an LSP from a management point of view. This concept of assigning roles to LSPs allows a network administrator to specify policies which are valid for all LSPs having the same role. The management of a GMPLS network is simplified. The resource class parameter specifies the class from which the LSP may find the resources.

The policy rule set is extended in order to perform the mapping from DiffServ Ordered Aggregates (DOA) to GMPLS paths. The mapping of traffic to LSPs is generally performed in the LER (edge LSR) of a DiffServ-GMPLS network. However, the traffic mapping is often referred to as <FEC, OA> couple, which forwards a group of packets along the same path with the same per-hop behaviour (service differentiation with L-LSP method). The concept of a FEC specifies, what traffic is mapped into a specific LSP. The specification of FECs can be just the destination IP address or a set of filters including IP addresses, ports, DSCPs etc.

In the following example, we are considering a network policy that varies bandwidth allocations based on the time of day and the type of traffic. Traffics in the network are assigned to ‘roles’ in accordance with the Olympic Services Model, i.e., they are marked as ‘gold’, ‘silver’, or ‘bronze’ according to the QoS traffic properties that they carry. A network policy controls the bandwidth allocation associated with this traffic. When the traffic profiles of the gold Traffic, for example, are modified, the ‘module’ (a suggested method in above section) is activated to verify whether the current mapping of traffic to LSPs is still valid. For each modified traffic, the module might also modify the bandwidth of the currently assigned LSPs.

We define an action to modify some parameters of the method proposed in order to calculate a new LSP, and to have an LSP which favourites for example the bandwidth by using, in this case P1 and P2 variables. After the <FEC, OA> mapping LSPs can be established. Example:

• IF Time is between 9h00 and 11H00 THEN Attribute 2/3 to p2 variable and 1/3 to p1 variable (LSPs will be calculate with the suggested method with new parameters).

This policy can change the manner to calculate the best LSP by minimising the LSP cost (with the suggested method in Section 4.4), where p1 and p2 are weights assigned to the variables used to favourite the utility and bandwidth, respectively.

LSP life-cycle management policies. The control and management of LSP life-cycles include mainly the creation and update of LSPs and the assignment of QoS properties to LSPs. Signalling in GMPLS consists of setting up, releasing and updating an LSP. It should be possible to control the initiation and the execution of these processes using policies. The typical example comprises signalling of an LSP with QoS requirements, Examples:

60 H. Moungla and F. Krief

• the signalled request for a bandwidth X may be permitted or refused, depending on the policies of the network domain

• IF Destination address = 192.247.93.4 THEN do not choice Y LSR in currant LSP.

Because the LSP setting-up requires signalling or configuration mechanisms. Fundamentally two types are possible using an extended hop-by-hop signalling protocol like RSVP-TE, or configuring the LSP over SNMP or COPS.

7 Simulation and results

In order to evaluate the advantage of the proposed self-adaptation method integrated in the policy based control architecture for Diffserv-GMPLS networks, we have constructed simulated GMPLS network using C++ program. The QoS architecture (also called policy cross-layer architecture) including self-adaptation module which really realised in Java program is compared to a normal control plane of GMPLS without Self-adaptation module and policy based control. All H.264 slices share the same network.

7.1 Simulation model

For the simulations (see Figure 3), we used the H.264 Foreman CIF sequence (10 s). This sequence is coded at 25 frame/s with an intra period of 50 (i.e., after each 50 video pictures we transmit an intracoded picture refreshment to prevent eventual error propagation). We simulate unicast H.264 video transmission (one video server and one video client) utilising an architecture at 2 Mb/s. Besides the H.264 stream, the server station generates background traffic (300 kb/s) using Constant Bit Rate (CBR) traffic over User Datagram Protocol (UDP). Furthermore, we include four stations where each station generates 300 kb/s of data using CBR traffic in order to overload the network. Each simulation run consists of 15.1 s of simulated network lifetime.

Figure 3 The network topology simulation (see online version for colours)

From t = 0 s to t = 5 s, the selected LSP (route) is empty. Beginning at t = 5 s, H.264 and CBR flows are started and begin competing for the LSP. Here CBR flows are started at 0.5 s intervals. Between t = 5 s and t = 5.1 s, only the PSC (see Section 1.3) stream is sent. Finally, at t = 5.1 s, the other flows are started. These flows make some degradation for our H.264 video; we contact that by observing the loss rate and delay increasing.

At this point, it is important to note that the self-adaptation module, which propose a new LSP and mapping into Real-Time.

The IETF RFC defines generally three priority access categories; Gold services correspond to the highest access priority, and bronze services to the lowest. Based on this traffic specification it is possible to differentiate the H.264 partitions at the DiffServ-GMPLS module layer. In this context we have proposed (see Section 4) a marking algorithm in order to map the H.264 stream to a suitable LSP (route) traffic class and thus allow for QoS continuity between the different the two extremities of our network.

Thus, each service application arrives (ex: FTP, Video, VoIP) at our module along with a specific priority value, consequently a specific LSP. The choice of LSP is based on QoS metrics such as bandwidth, packets loss and link utilities (see Section 4). Thus, the LSP is mapped to the highest-priority service category. We argue this by the fact that the stream is very sensitive to packet loss and bandwidth because a missing parameter set leads to delay of the whole video transmission.

7.2 Results analysis

Figure 4 illustrates the instantaneous loss rates affecting all packets at 6th second in both architectures. This leads to filling the queue very quickly, causing increased probability of dropping incoming packets.

Figure 4 H.264 packet loss rate with and without cross-layer architecture (see online version for colours)

The architecture without our cross-layer achieves at mean 20% loss rate. In contrast, the cross-layer architecture achieves maximum 10% loss, despite the increase in the channel’s load. This is mainly due to the fact that our cross-layer architecture associates a new LSP with better QoS parameters to H.264 video stream. The increased packet loss rate between 6th and 7th second in the

Towards self-adaptation in DiffServ-GMPLS network for video-conferencing services 61

cross-layer architecture is due to the needed time to propose a new LSP by our self-adaptation module.

Note that although partitions B and C (see Section 1.4) undergo high packet loss rates in the cross-layer architecture, the results on the final decoded frame are less harmful compared to the case when partition A or IDR packets are lost. In fact, a loss of partition C’s or B’s packet belonging to a frame leads to degradation of only the quality of the decoded frame (only texture information is lost). Nevertheless, when either partition A’s or IDR’s packet belonging to a frame is lost, this frame is automatically dropped. Where the 10% packet loss rate.

Figures 5 show both the delays experienced by cross-layer architecture and without cross-layer architecture, respectively. Our architecture reduces the delay to the minimum level, indicating that packets are transmitted almost immediately. However without our cross-layer architecture, we observe a greatly increased packet delays.

Figures 6(a) and 6(b), represent a final decoded frame (n°80) when using old architecture and our cross-layer architecture, respectively. It is readily realised that QoS mapping outperforms for the old LSP. At this point, it is interesting to note that we experienced 87 and 39 dropped frames that cannot be decoded when transmitting video using old LSP. In contrast, in our cross-layer architecture we were able to decode the whole video sequence (250 frames).

Figure 5 H.264 delay transmission with and without cross-layer architecture (see online version for colours)

Figure 6(a) Decoded frame (n°80) without cross-layer architecture (see online version for colours)

Figure 6(b) Decoded frame (n°80) with cross-layer architecture (see online version for colours)

8 Conclusion and future work This paper proposes a method and PBM architecture for GMPLS networks using DiffServ. However the suggested method of differentiation service presented in previous sections can be used with CoS instead of DiffServ. Policy architecture has been introduced with three logical levels. This architecture extends the IETF policy architecture for DiffServ over GMPLS. Particularly the policies rules are used for the LSP life-cycle management, service level request handling, and TE capabilities. This mainly includes the mapping of DiffServ specific traffic into LSPs on the LERs, and the mapping of LSRs to Per-Hop Behaviors on the core LSRs. This work defines a flexible solution for the support of DiffServ over GMPLS networks. This new cross-layer architecture ensures robust H.264 video transmission over Diffserv/GMPLS networks.

Experimental results show that the proposed architecture achieves better performances in terms of delays and loss rate than the actual GMPLS standard and its QoS enhancement mechanism. Through these performance improvements, the cross-layer architecture considerably increases the perceived video quality over that obtained by the standard architecture.

Networks management is now well established. However, control, management and optimisation schemes are provided in a static and basic way.

Network control and management schemes using autonomic based technology, offer a new way to master QoS, security and mobility management. This new paradigm allows a dynamic and intelligent control of the equipment in a local manner for example in our work we propose a new LSP to improve a QoS. It is useful to propose a global network control in a cooperative manner which provides a more powerful network management, and a better guaranty of all vital functionalities like end to end QoS and security. We think about provide a way to implement such paradigm through the generation automatically a new management policies rule in order to optimise the quality of service through the networks.

62 H. Moungla and F. Krief

References Awduche, D.O., Berger, L., Gan, D., Li, T., Srinivasan, V. and

Swallow, G. (2001) RSVP-TE: Extensions to RSVP for LSP Tunnels, IETF RFC 3209, December, IEEE Communications Magazine, January, pp.144–150.

Awduche, D.O., Malcom, J., Agogbua, J., O’Dell, M. and McManus, J. (1999) Requirements for Traffic Engineering over MPLS, IETF RFC 2702, September.

Banerjee, A., Drake, J., Lang, J.P., Turner, B., Kompella, K. and Rekhter, Y. (2001) ‘Generalized multiprotocol label switching: an overview of routing and management enhancements’, IEEE Communications Magazine, January.

Beigi, M., Calo, S., Verma, D., IBM and Watson, T.J. (2004) ‘Policy transformation techniques in policy-based systems management’, IEEE Policy, Research Center, USA, pp.13–22.

Berger, L. (2003a) Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description, RFC 3471, January.

Berger, L. (2003b) Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol (RSVP-TE) Extensions, RFC 3473, January.

Chiu, J-F., Huang, Z-P., Lo, C-W., Hwang, W-S. and Shieh, C-K. (2003) ‘Supporting end-to-end QoS in DiffServ/MPLS networks’, IEEE – ICT ‘03. (10th International Conference on Telecommunications, Vol. 1, pp.261–266.

Cortese, G., Fiutem, R. and Matteucci, D. (Eds.) (2001) CADENUS Deliverable D3.2: ‘Service Con.guration and Provisioning Framework: Requirements, Architecture, Design’, CADENUS consortium.

Ibáñez, G. (2003) GMPLS. Towards a Common Control and Management Plane: Generalized Multiprotocol Label Switching in Optical Transport Networks (GMPLS), September, Congreso Iberoamericano de Telemática: CITA2003, Montevideo.

ISO/IEC 14496-2, 01 (2001) Coding of Audio-Visual Objects – Part 2: Video – Final Committee Draft, v. 3, January.

ITU-T Rec. H.264/ISO/IEC 14496-10 AVC, JVT-G050 (2003) Joint Video Team (JVT) ISO/IEC MPEG, ITU-T VCEG, Final Draft, International Standard on Joint Video Specification, http://www.itu.int/ITU-T/publications/recs.html

Keswani, G. and Labrador, M.A. (2002) ‘Service differentiation in IP over DWDM optical networks’, IEEE Globcom.

Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P., Krishnan, R., Cheval, P. and Heinanen, J. (2002) Multi-Protocol Label Switching (MPLS) Support of Differentiated Services, RFC 3270, May.

Lymberopoulos, L., Lupu, E. and Sloman, M. (2002) An Adaptive ‘Policy based framework for network services management’. Journal of Network and Systems Management, September 2003, Vol. 11, No. 3, pp.277–303.

Mannie, E. (Ed.) (2004) Generalized Multi-Protocol Label Switching (GMPLS) Architecture, IETF–RFC 3945.

Moffett, J. and Sloman, M. (1994) ‘Policy hierarchies for distributed systems management’, IEEE JSAC Special Issue on Network Management, December, Vol. 11, pp.1404–1414.

Seo, J-C., Kim, H-S., Yun, D-S. and Kim, Y-T. (2006) ‘WBEM-based SLA management across multi-domain networks for QoS-guaranteed DiffServ-over-MPLS provisioning’, APNOMS. Management of convergence Networks and Services, Lecture Notes in Computer Science, Springer Berlin/ Heidelberg, Vol. 4238/2006, pp.312–321.

Teo, L. and Ahn, G-J. (2007) ‘Towards effective security policy management for heterogeneous network environments’, Eighth IEEE International Workshop on Policies for Distributed Systems and Networks Policy’07, Bologna, Italy, 13–15 June, pp.241–245.

Websites IETF Policy Framework Working Group, http://www.ietf.org http://www.ietf.org/