scalable multicast provisioning in diffserv with mpls labeling

Telecommunication Systems 27:2–4, 253–272, 2004 2004 Kluwer Academic Publishers. Manufactured in The Netherlands.

Scalable Multicast Provisioning in DiffServ with MPLSLabeling

M. EL HACHIMI, A. ABOUAISSA and P. LORENZ {m.elhachimi;a.abouaissa;p.lorenz}@uha.frUniversity of Haute Alsace, 38 Rue Grillenbreit, 68000, Colmar, France

M.O. LEE [email protected] of Dongshin, School of Information and Communication Engineering, 252 Daeho-Dong, Naju,Chonnam, 520-714, South of Korea

Abstract. The phenomenal growth of multimedia applications imposes scalable and efficient network sup-port. The DiffServ and MPLS architectures were developed to provide QoS. The combination of botharchitectures presents a very attractive strategy to backbone network providers. However, integrating nativeIP multicasting with MPLS supports DiffServ is a quite comple issue. Major problems are: the lack oflabels in MPLS networks, the core routers simplicity in DiffServ and the multicast state scalability prob-lems, since it requires routers to keep a forwarding state for every multicast tree passing through it. Inaddition, the number of states grows with the number of groups. Under such circumstance, we proposean hybrid label aggregation algorithm in order to solve multicast scalability problem and provide a solu-tion for multicast in MPLS support DiffServ. In the proposed scheme, one label is assigned per multicastgroups (logical aggregation) and different multicast groups sharing the same output interface in a router areaggregated locally (physical aggregation). Also, in order to support the proposed algorithm, we proposea separate treatment and labels space (prime numbers range) for multicast traffic. The proposed solutionallows consuming fewer labels, reducing the forwarding table and consequently the total packet processingdelay.

Keywords: mutlicast, QoS, DiffServ, MPLS, scalability, label aggregation

Introduction

The recent evolution of multimedia applications and the growth of user communitiesdemanding Quality of Service (QoS) impose scalable multicast and efficient networksupport. Indeed, high-speed networks, like ATM, have largely contributed to emergedifferent traffics, requiring different bandwidth and QoS such as: teleconferencing, dis-tributed network games, cooperative mutimedia applications, etc. However, the Internet,in its current form, can provide only a Best-Effort traffic as model of quality of ser-vice. Such service can not support the interactive real-time applications, especially thosewhich are used in the group communications systems. Indeed, the group communicationabstraction [Abouaissa and Benslimane, 1] is essential for the modular design of group-ware and other multi-user applications in such networks. The most important aspectsof this abstraction are the maintenance of group membership and the semantics of inter-leaving membership change notifications within the flow of regular messages. Different

254 EL HACHIMI ET AL.

applications utilize group communication for different purposes, and hence require dif-ferent types of QoS. Many of these applications make use of highly dynamic multicastgroups. One example is a TV broadcasting service that serves groups of clients that mayjoin and leave at any time. Moreover, these applications can not be effectively supportedby multiple unicast connections, since they are excessively resource consuming. There-fore, it is important to offer an efficient QoS multicast support to the Internet, since thisarchitecture represents the backbone of the total network.

Apart from QoS assurances, another important aspect of the Internet usage is thebandwidth utilization. To reduce the bandwidth consummation, multicasting is a usefuloperation. Users traffic are transmitted from a source to several destinations by sharingthe communication channel bandwidth. This allows to multicast to essentially increasethe QoS given to other users of the network. In Internet, although the bandwidth iscontinually increasing, the backbone network itself is still far from being able to sup-port QoS without appropriate resource allocation mechanisms. Thus, for the foreseeablefuture, some form of resource provisioning in necessary to provide QoS across the In-ternet. One of solutions to provide QoS and multicast, to users across the Internet, is theDifferentiated Services (DiffServ) architecture [Nichols et al., 15]. This architecture wasdeveloped to support QoS and achieve scalability by avoiding complexity in core routers.The simplicity of core routers causes also fundamental problems in conjunction with theprovision of IP multicast in DiffServ domain. The primary conflict between DiffServ andmulticasting can be attributed to how DiffServ attempts to achieve scalability. WhereasDiffServ relies on only edge routers possessing intelligence and state information, multi-casting relies on per-group state information throughout the entire network. Thus, whentrying to integrate the two technologies, one is faced with two conflicting principles,core statelessness for scalability versus per-group state information for efficiency. Onone hand, core routers in DiffServ must be maintained as simple as possible. On theother hand, using native IP multicast, the number of forwarding states grows with thenumber of multicast groups and consequently the routers complexity.

Through most research works on QoS multicast focus on solving QoS-constrainedmulticast routing problem, such as QoSMIC [Faloutsos et al., 8], QMRP [Chen et al., 5],RIMQoS [Fei and Gerla, 10], QoS extension to CBT [Hou et al., 11], and PIM-SM QoSextension [Biswas et al., 2]. More precisely, all these solutions use per-flow state. Re-cent trends use per class architectures namely Differentiated Services (DiffSev) [Blakeet al., 3] or/and Multiple Protocol Label Switching technology (MPLS) [Rosen et al., 16].It is worth noting that incorporating the per-flow state requirement and traffic manage-ment of multicast in a per-class architecture to address the QoS issue dos not solve themulticast state scalability ptoblem since each router still need to maintain separate statesfor each multicast group that pass through it.

Recent researches to allow to MPLS support of DiffServ [Blake et al., 3] were pre-sented, but the authors dealt only with the problem of unicast. There also some proposalsabout supporting multicast in MPLS networks [Faucheur et al., 9] but their focus is toconstruct a multicast traffic engineering tree by building multicast trees immediatelyon layer L2 or mapping layer L3 trees onto L2. These approches increase the router’s

SCALABLE MULTICAST PROVISIONING 255

complexity in term of required memory and time processing and thus, the total packetsprocessing delays are increased.

In this paper, our approach is quite different of previous works in this area. Wepropose a new multicast trees aggregation using MPLS labels in order to solve multicastscalability and to provide QoS to multicast group in DiffServ. The proposed approach isbased on an hybrid logical and physical aggregation: Logical, by assigning one label permulticast group and physical by using an aggregated label for groups sharing the same(Interface) physical location. The proposed solution consists to use prime numbers formulticast. Prime numbers properties allow to construct aggregated labels and providesmulticast trees aggregation. Thus, the forwarding state in core routers becomes smalland the number of labels consumed is reduced.

The proposed algorithm performing label aggregation has an advantage in reduc-ing the number of multicast states and consequently the total packet processing delaysthan the general algorithm which not performing label aggregation. In order to supportthis new approach, we defined a new MPLS Forwarding table, called Multicast MPLSForwarding Table called (MMFT). This table contains the router interface (IF) and anAggregated Label (AL) for all multicast groups served via this interface (figure 1). TheMMFT remains constant and does not grow with the number of multicast groups, sinceit contains only router interfaces and the corresponding AL. In addition, the use of sepa-rate labels (prime numbers) for multicast does not exclude the use of the same labels forunicast since separate treatment and forwarding tables are defined for multicast and thuswe extended the label distribution algorithm.

1. Multicasting in DiffServ

The Internet Engineering Task Force (IETF) has proposed several models to provideQoS across the Internet. The DiffServ architecture was selected as the model which pro-vides QoS over the Internet [Nichols et al., 15; Blake et al., 3]. This model containstwo types of routers, namely, Edge routers and core routers. Core routers are rela-tively simple routers designed for the purpose of high-speed routing over the networkbackbone. Core routers do not maintain any per-flow state information and scheduleuser packets following the DSCP within each packet. Thus, all the treatments and thedecision-makings were migrated towards the edge routers. The edge routers are thekey element for proper functioning of the DiffServ domain. They are responsible ofmarking non-DiffServ-aware traffic, traffic policing, and traffic shaping. Moreover, it isthe responsibility of the edge routers to maintain proper traffic levels to achieves QoSdifferentiation in the network core. Integration of multicasting support in the DiffServdomain is useful. However, fundamental conflicts between these approaches lies withinthe structure of the mutlicast tree.

The primary conflict between DiffServ and multicasting can be attributed to howDiffServ attempts to achieve scalability. Whereas DiffServ relies on only edge routerspossessing intelligence and state information, multicasting relies on per-group state in-formation throughout the entire network. With multicast-aware routers, the tree struc-


ture is maintained in the routing table. Users data are appropriately replicated onto linksbased on entries inside the routing table. Under DiffServ, all core routers are assumedto be simple routers maintaining no state information regarding the flows. They react toflows according to a PHB (Per-Hop Behavior) as per the DSCP (DiffServ Code Point) ofthe packet data. Information for the PHB of the packets is maintained on a per-class basisthat information is maintained for each individual core router only. Thus, the multicasttree violates the key principles of DiffServ, because multicast trees require per-groupinformation at each core router in terms of the routing table entries.

A secondary conflict arises with how information for member join/leave is con-veyed for resource allocation. In [Bless and Wehrle, 4], was noted that a resource reser-vation problem called the NRS (Neglected Reservation Subtree) problem can occur ifmember join (graft) messages are not approved for resource allocation before data istransmitted on the branch. The NRS problem finds its basis in the distributed nature ofthe multicast tree and the separation of multicast routing/replication from the ingress-based policing/allocation of DiffServ. Since an edge node does not necessarily knowthe makeup of the multicast trees that may exist in the domain, it cannot determine theresource requirements to graft onto the multicast tree.

The thirdly problem is Heterogeneous QoS support: due to the fact that differentmulticast receivers may require different levels of QoS, it is necessary to offer supportfor heterogeneous QoS via the DiffServ (DS) domain. The issue is how differentiatethe service level supported on different paths inside the same multicast distribution tree.In this paper we focus on the first one which is the multicast scalability problem inDiffServ.

2. Overview of approaches and related works

Recently, significant research effort has focused on the multicast scalability problemin DiffServ. The multicast state scalability problem arises as it is required that eachrouter should keep a forwarding state for each multicast group passing through it. Someschemes attempt to reduce forwarding state by limiting branching points only at the EdgeRouters (ERs) [Striegel et al., 17], by encapsulation [Striegel and Manimaran, 18], or byforwarding state aggregation.

Edge-based approach. Thi main idea in this approach is to restrict the location of mul-ticast capable routers within the DiffServ domain. Rather than allowing all routers to bemulticast capable, only the edge routers of a DiffServ domain are allowed to be multicastcapable.

Encapsulation-based approach. This approach consists to embed the multicast infor-mation within the packet itself. In the encapsulation-based approach, the multicast treefor the domain is encapsulated within the multicast packet. First problem using thisapproach is that the encapsulation consumes additional bandwidth for each packet in


the form of encoding the multicast and second, the additional CPU cost incurred due toheader processing.

Aggregation-based approach. The principal idea of this approach is to reduce the mul-ticast state. The aggregation forces groups multicast to use and to share the same treecalled the aggregated multicast tree [8 in Gerla]. Thus, data of each user of a givengroup are multiplexed, identified and are transmitted across this tree. The enforcementtakes place at the border routers of DiffServ or MPLS domain, namely, Edge Routers.These routers need to hold more information to multiplex/demultiplex and to encapsu-late the user data according to the label of the multicast group (in the case of MPLSdomain). Then, by this ways routers into these domains, namely, core routers, need tokeep state only per aggregated tree, which are much less in number than the groups theyare servicing.

In [Cui et al., 6], the authors have proposed an architecture, called Aggregated QoSMulticast (AQoSM). The key idea is that, instead of constructing a tree for each individ-ual multicast session in the core Network, one can have multiple multicast sessions sharea single aggregated tree to reduce multicast state and correspondingly tree maintenanceoverhead at network core. As it is mentioned in [Cui et al., 6], the problem, using thistype of aggregation, is the following. It is possible that the shared tree does not havea perfect matching with a given multicast group G. This means that some of the leafnodes of the shared tree are not necessarily member nodes of the group G. Therefore,replicated packets could reach some destinations even if they are not involved in themulticast group, which leads to a bandwidth wasting.

For example, let us suppose a network of three edge routers E1, E2 and E3, andonly one core router, as illustrated in figure 1. Let us consider that E1 and E3 aggregatethree groups G1, G2 and G3, but the edge E2 can aggregate only two groups G1 and G2.Now, if the edge E1 sends data of the group G1 or G2, then all members of the aggregatemulticast tree will receive these data. On the other hand, the edge E2 should not receivedata of G3 since members of this group do not belong to the aggregate muticast treeinto E2. In other words, data are sent to parts of the tree that is not wanted by anyone.

Figure 1. Aggregated multicast tree.


Thus, a disadvantage of this approach is that some bandwidth is wasted to deliver datato nodes that are not members for the group.

In our work, we use an MPLS based approach. A key concept in MPLS is theseparation of an IP router’s functions into two parts: forwarding and control. The for-warding part, responsible for how data packets are relayed between IP routers, useslabel swapping. A label is a short fixed length number independent of the network layer.The label swapping technique essentially involves a table lookup of a packet’s labelto determine its route and new label value. Label swapping is considerably simplerthan normal datagram processing involving longest prefix matching, and thus improvesprice/performance and scalability. A router capable of MPLS is a label switching router(LSR), and a set of LSRs traversed by a packet is called a label-switched path (LSP).By this way, the proposed algorithm solves the aggregated muticast trees problem andavoids the transmission of users data towards undesirable destinations. Thus, the pro-posed solution optimizes the shared multicast tree and ensures correct use of the band-width.

3. Multicast trees aggregation using prime numbers

In unicast, the destination address having the same prefix can be aggregated to one en-try in routing table. But in multicast, the address of a multicast group corresponds toa logical group and does not convey any information on the location of its members.Our solution consists of an aggregate of multicast trees using MPLS labels. Both hy-brid logical and physical aggregation are proposed: logical, by assigning one label permulticast group and physical by using an aggregated label for groups sharing the sameoutput interface in a router (i.e., physical location). The proposed solution makes useof prime numbers for multicast sessions identification. More precisely, prime numbersproperties allow to construct aggregated labels and to provide a Multicast trees aggrega-tion. As a consequence, the DiffServ/MPLS core router’s complexity (required memoryand time processing) is optimized and therefore the total packets processing delays areconsiderably reduced.

Gauss’s lemma. Let a, b, c be any three integers and suppose that a divides the prod-uct bc. If a is relatively prime to b then a divides c: if bc|a and if GCD(a, b) = 1then c|a. (GCD denotes the Greatest Common Divisor.)

Consequence 1. If a prime number p divides the product bc, then p divides b or c.

Fundamental Theorem of Arithmetic. Every natural number is either prime or can beuniquely factored as a product of primes in a unique way.

Consequence 2 derived from consequence 1 and the Fundamental Theorem ofArithmetic is the following.


Consequence 2. If a prime number divides a product n of prime numbers, then it isequal to one of them. Thus, there exist no prime number other than prime numbersconstituting the product n and divide n.

The main idea underlying our label aggregation algorithm described in section 4comes from this consequence 2. Prime numbers correspond to multicast group labels andtheir product corresponds to Aggregated Labels (AL). By using this labelling scheme,multicast trees can be aggregated to solve the multicast scalability problem. In addition,we avoid the wasting bandwidth problem since destinations that are not involved in amulticast group will not be reached by replicated packets.

4. Proposed algorithms

4.1. Label aggregation algorithm

In order to support the proposed approach, we use a new MPLS forwarding table, calledMulticast MPLS Forwarding Table (MMFT). Each entry in this table contains a routerinterface identifier (IF) and the Aggregated Label (AL) associated with all the multicastgroups served via this interface (figure 2). It should be noted that the MMFT table sizeremains constant and does not grow with the number of multicast groups since it con-tains only router interfaces and their corresponding AL. In addition, the use of separateranges of labels (prime numbers) for multicast does not exclude the use of the samelabels for unicast since separate treatment and forwarding tables are used. The mul-ticast trees construction and the labelling distributed assignment algorithm have beenpresented in detail in [Bless and Wehrle, 4]. In this section, we focus on the multicasttrees aggregation and packets forwarding algorithms. The new MPLS forwarding tableused for multicast traffic is called Multicast MPLS Forwarding Table (MMFT) whereineach entry contains an interface identifier (IF) and a corresponding label called Aggre-gated Label (AL) (figure 2). Thus, the MMFT table has exactly p lines, where p is thenumber of the physical interfaces of the router. when a member wants to join a multi-cast group, it sends a ‘join’ message in order to be connected to the multicast tree. Thismessage contains the group label (GL) and an explicit path toward the multicast tree(the discovery algorithm of feasible paths toward the multicast tree have been presentedin details in [El Hachimi et al., 7]. The ‘join’ message is also used here to update allthe router’s MMFT tables encountered along its corresponding path. Note that the joinmessage in this paper corresponds to the modified LDP (Label Distribution Protocol)message as presented in section 5. When a label switching router (LSR) receives thejoin message, first it extracts the multicast.

Group Label (GL) and the AL, corresponding to the interface from which thejoin message is received, from the MMFT table. Then, it executes the following algo-rithm A1. In the algorithm A1, if the condition (LCM(AL, GL) = AL) is satisfied, thismeans that the current router belongs to the multicast tree which the receiver wants tojoin, otherwise, the current router updates its MMFT table and send up the join messageto the next router.


Figure 2. Multicast MPLS forwarding table update.

Algorithm A1.if (LCM(AL, GL) = AL) then

/*LCM denotes the Least Common Multiple*/.stop, an on- tree node is reached

else /*Update the Aggregated Label (AL)*/AL ← LCM(AL, GL)

and send up the join message with the same label (GL)./*Note that initially AL = 1*/.

Example. The example below shows how the multicast MPLS forwarding table is up-dated. Let us suppose that the LSR, in figure 2, receives a ‘join’ message for the multicastgroup G1 where (GL = 3) via the interface ‘c’. The aggregated label is initially set to 1.Thus, the new aggregated label for the interface ‘c’ will be LCM(1, 3) = 3. The sametreatment is performed when the LSR receives a ‘join’ message via the interface ‘c’ forthe multicast group G2 where (GL = 7), then it updates the Aggregated Label (AL) forthe interface ‘c’ (AL = LCM(3, 7) = 21). Thus, this algorithm resolves the aggregatedmulticast trees problem, without flooding the part of the tree which not desire to receivemulticast data.

4.2. Multicast packet forwarding algorithm

Multicast and unicast traffic require different types of processing from routers. For in-stance, IP identifies multicast packets by looking at the multicast address range. InMPLS, unicast and multicast packets have already been assigned a different type codein the link-layer header [El Hachimi et al., 7]. Therefore, MPLS routers know whethera packet is from a unicast or a multicast flow. When a multicast packet is received bya LSR, first, it extracts multicast group label in the packet, we call it here Packet La-


bel (PL). Second, for each interface in multicast MPLS forwarding table except the onefrom which the packet is received the following algorithm is executed in order to decidein which interface the packet will be replicated.

Algorithm A2.For (i = 1; i < p; i + +)

/*p is the number of interfaces in the router*/If (AL <> 1) then

If ((AL mod (PL)) = 0) thenreplicate the packet with the same labelelse nothing.

else nothing

The algorithm used in classical multicast routing without aggregation may be de-scribed as follow:

Algorithm (used in the classical routing).For (j = 1; j < M; j + +)

/*M is the number of multicast sessions in the router*/For (i = 1; i < p − 1; i + +)

/*p − 1 is the number of replications in bad case*//*p is the number of interfaces in the router*/

If (PL = InputLabel)Push the Output Label in the packet.Forward packet.

else nothing.

The complexity of the proposed algorithm A2 is O(1) since the number of entriesin the MMFT is constant and is equal to the number of interfaces p in the router inde-pendently of the number of multicast sessions passing through it. However, in MPLSwithout using aggregation, the number of entries in forwarding table is at least M with M

is the number of multicast sessions passing through the router and consequently the com-plexity of the algorithm used to forward packets in MPLS without aggregation is O(M).

Example. The following example, illustrated in figure 3, explains the multicast packetforwarding using the multicast packet forwarding algorithm and the multicast MPLS for-warding table proposed in this paper and described above. In this example, the multicastsource S sends traffic to multicast group G2. At the LER1 the label 5 is associated tomulticast group G2 and pushed into the packet. When the packets arrives to LSR1, itperforms the multicast packet forwarding algorithm and decides to replicate the packetvia interfaces ‘e’ and ‘f’, since 5 mod (5) = 0 and 105 mod (5) = 0. When the packetarrives in the next LSR2, the same treatment is done and the router replicates the packetvia the interface ‘b’, since 15 mod (5) = 0 but not via ‘c’ because 21 mod (5) <> 0.


Figure 3. Multicast MPLS forwarding table.

4.3. Leaf-initiated traffic engineered tree

A leaf-initiated traffic engineered tree is a tree built from the leafs to the root. This solu-tion has been proposed in [Abouaissa and Benslimane, 1]. We describe here a modifiedversion, since in this paper the label assigned to each group remains fixed in all MPLSdomain. Then a LSR does not need to allocate a new label when receiving join message.The reverse path from the leaf to the multicast tree can also be calculated by the leaf ofthe tree.

Each LER node sends a join message (note that this is not a multicast routing joinmessage, but an extension to an MPLS signalling protocol) with the explicit reversepath and an MPLS label corresponding to the multicast group towards the root. At thesubsequent upstream router, the multicast MPLS forwarding table is updated using thelabel aggregation algorithm described in section 4. When a join reaches a on-tree router,the router processes the join, modifies the multicast MPLS forwarding table and endsthe join procedure.

When a leaf node wants to leave the group, it sends a leave message to its upstreamrouter. When all the down streams neighbours of a router leave the group, the routershould send a leave message to its upstream neighbour. When an LSR receive leavemessage it updates its multicast MPLS forwarding table using the following instruction:AL ← AL/GL.

The join message is a new CR-LDP message proposed in [Abouaissa and Bensli-mane, 1] to allow the leaf-initiated tree construction. It is sent from downstream routerstowards the root. It contains the explicit path from leaf towards root and the multicastgroup label (GL). The format of the join message is as follows:


0 Join Message(TBA) Length

Message IDFEC TLVLabel TLV

LSPID TLV (CR LDP, mandatory)ER TLV (CR LDP, mandatory)Traffic TLV (CR LDP, optional)

Resource Class (CR LDP, optional)Pre-emption TLV (CR LDP, optional)

Figure 4. New CR-LDP join message.

5. Multicast group label allocation

In this paper, we propose to use disjoint label space for multicast traffic. This spaceconsists of the set of prime numbers. The use of disjoint label space for multicast doesnot exclude to use the same space for unicast since we use different processing anddifferent MPLS forwarding tables for unicast and multicast. The LER keeps a tablein which a multicast group (S, G) has a corresponding label (GL). This label remainsunchanged in the MPLS domain. Moreover, if two LERs (LERi and LERj ) associatethe same label to two different groups and send this information to the other LERs in thesame time, then LERs keep only the one with the highest IP address. The one having thelowest IP address will be assigned a label that is the next one in the prime number range.In the following algorithm, GLi is a group label assigned to the group Gi and receivedfrom a LERi . GLj is the group label assigned to the group Gj and received from anotherLERj .

Algorithm A3.if (GLi = GLj ) then

if (LERi <> LERj ) thenif (IP_address(Gi) > IP_address(Gj )) thenkeep (Gi , GLi)assign (Gj , next(GLi))

elsekeep (Gj , GLj )

assign (Gi , next(GLj ))

elsekeep (Gi, GLi)

assign (Gj , next(GLi ))

elsekeep (Gj , GLj )


6. Simulation and validation with colored Petri nets

In this section, we present the specification and the validation of the algorithm A3. Weuse the Colored Petri Nets (CPN) jointly with a functional language CPN-ML (extensionof Standard-ML) [Milner et al., 13; Milner and Tofte, 14]. These high-level nets arenow in widespread use for many practical purposes. The main reason for the greatsuccess of this kind of nets is the fact that it has a graphical representation and well-defined semantics allowing formal analysis of large systems. CPN combine the power offormal inscriptions (i.e. mathematical expressions) with the clarity of graphical modelsto provide concise representation of complex systems.

6.1. Description of CPN tool

We give here the informal introduction of CPN. Readers should refer to [Jensen, 12,Vols. 1, 2] for formal definition. A CPN consists of a set of places, representing thepossible states of a system and indicated by ellipses, each place has an association typedetermining the kind of data that the place may contain. A set of transitions representingthe actions of a system and indicated by rectangles. A set of directed arrows, calledarcs connect places and transition in the nets. Each place must include the followinginscription:

• Color set definitions specify the types of tokens in the model. Each place in CPN hasassociated color set which contains the tokens allowed to occupy it. In Design/CPNa colorsets to be used in the net are defined in declaration node.

• Marking specify the multi-set of tokens occupying each place, represented as an al-gebraic sum.

Each transition can include the following inscriptions:

• Guard is a Boolean expression with colors as terms. It restricts the allowable bindingsif the variables occurring in the arc expression.

• Code region calculates the output inscription and they can be used for graphical ani-mations.

Arcs must have expressions

• Arc expressions characterize the multi-set of tokens that will move along an arc whenthe association transition occurs. Arc expressions contains variables, predefined oruser defined functions and Boolean selectors, along with the usual operators. For anyoccurrence of a transition, the variables in the associated arc expressions are boundto particular values. A CPN model can be represented as illustrated in figure 5.

In contrast to most specification languages, Petri nets are state and action orientedat the same time – providing an explicit description of both the states and the actions.This means that the modeller can determine freely whether – at a given moment of time –he wants to concentrate on states or on actions.


Figure 5. Colored Petri net model.

Figure 6. Simulation topology.

All the CPN inscriptions are declared in CPN-ML. CPN-ML is an extension of afunctional programming language called “Standard ML”. It allows to declare color setsthat are primitive ML types, such as Boolean, integer, real, and string color sets may alsobe constructed from non-primitive ML types. From theses types we can construct newcolor sets by forming Cartesian products, records, union, lists and subtypes. In addition,ML supports abstracts data types allowing the listing of the details of color sets. Themain feature of the CPN is its hierarchical CP-nets. The basic idea behind hierarchicalCP-nets is to allow the modeller to construct a large model by using a number of smallCPN nets which are related to each other in a well-defined way. In a hierarchical CPNnets it is possible to relate a transition (and its surrounding arcs and places) to a separateCP-net providing a more precise and detailed description of the activity represented bythe transition.

6.2. Description of the model

We present in this part the simulation and validation of the propsed MPLS-based ap-proach. We simulate this algorithm with a CPN hierarchical architecture made up ofthree edge router LER and one LSR. Figure 6, which initialize the new request at anymoment. The group members are indefinite. We suppose that all the processes are inthe same phase and that no ‘join’ message is in transit. In order to study all the pos-sible cases, we have choose two LERs which start simultaneously to sent their “join”message with their label. In addition, the end-to-end transmission delay is known, thecommunication is reliable and respects FIFO order at message delivery level.

Let us consider figure 7, which highlights our model that assigns labels at eachnew ‘join’ message. We examine the different process treatments into each edge LERto ensure assignment labels. The principal page of the model of Petri nets is made up


Figure 7. CPN model of MPLS labelling.


of five transitions. The transitions indicated by “Join_Req_is_sent or join_req_sent”represent the diffusion of the ‘join’ message with a given label in the network. However,in our simulation, to simplify our model, we used only prime numbers range as a joinmessage in order to assign labels to each demand. This can help us to follow the stagesof execution of our algorithm in order to study all the possible cases of communicationand process treatment between and into these LERs edges. The “LER_Router” and“O_LER_Router” places represent states of the LER edge routers, which start to send“join” message at any moment. The transition “LER_rcv_req” represents the diffusionof the request message to initialize a new treatment, formulated by the “LER_router orO_LER_Router” through the communication channels connecting this last one with thedestination edge represented by the place “current_LER_table”.

Thus, when an edge LER send a “join” message, the end destination must checkif the received label is already in use by another concurrent request or not. To simplifythis process, the “Req_duplcated” and “Virtual_table” places are represented to checklabels and to assign a new one, following the different declaration of CPN variables andfunctions, as shown in figure 8. Note that the “Virtual_table” is used in our model onlyto replace the complex computation of the next prime number function.

To study all possible cases of the proposed algorithm, the “LER_Router” and“O_LER_Routers” places have independent markings. These markings can be sent asjoin request at any moment. We can observe that these places have some similar mark-ings that will represent concurrent message. Thus, we can verify and study all possiblecases.

�Declarations�Standard declarations

�color INTcolor INT=int;

�color LISTcolor LIST=list INT;

�var n p ppvar n, p, pp:LIST;

�fun check x nil=[]fun check x nil=[]|check x (M as y::l)=if member (hd(x)) M then check(tl(x)) M else (insert (hd(x)) nil);

�fun exist x y=if member (hd(x)) y then y else [];fun exist x y=if member (hd(x)) y then y else [];

�fun member x nil=falsefun member x nil=false|member x (y::l)=x=y orelse member xl;fun insert x nil=[x]|insert x (y::l)=if x<y then x::y::l else y::insert xl;fun new x nil=x|new x y=if member (hd(x)) y then y else insert (hd(x)) y;

Mpls labeling

Figure 8. Global declaration node in CPN.


Figure 9. Final result of the CPN simulation.


After the execution phase, all LERs edges receive all join messages and assign thesame labels. In addition, the communication respects the FIFO order and the maximumend-to-end delay between the LERS is known, then all the processes in the distributedsystem will take the same routing table as illustrated in figure 9.

6.3. State space graph analysis

We validate this model with the colored Petri nets to construct the state space graph. Weuse the Design/CPN tool, that generates automatically the state space of the protocol.The objective is to study the behaviour of the protocol, by verifying different propertiessuch as, boundness, liveness, etc.

In this section, we show that the liveness property of the model (figure 10) and themarking of the initial and final node of the state space graph in order to describe the stateof each place of the model and to present at which moments the new assignment labelswas started (figure 11). According to figure 10, the model does not present any blockingstate during the demand phase. Thus, all the requests were received, processed and alllabels were assigned.

In addition, figure 11 shows the maximal and minimal marking in each place ofthe simulation model. This proof that each LER edge has received and checked all joinmessage (in our model, we have send 11 join messages). We denote that in spite ofdifferent place markings, the label assignment phases are carried out at the same timefor all the processes of the system.

7. Performance study

In this section we study the number of entries in the forwarding table using the generalalgorithm used in MPLS and the proposed algorithm. This information is importantsince packet-processing delay depends on how big is this table.

Occurrence Graph:Nodes: 16919Arcs: 47682Secs: 155Status: Full

Liveness Properties:Dead Markings: [16919]Dead Transitions Instances: NoneLive Transitions Instances: None

Figure 10. Occurrence graph andliveness property.

BoundednessPropertiesBest Integers Bounds U Lo

p wep rer

Mpls_labeling’Current_LER_Table 1 0Mpls_labeling’LER_Router 1 1Mpls_labeling’LER_rcv_req 1 0Mpls_labeling’New_label_req 1 0Mpls_labeling’Req_duplicated 1 0Mpls_labeling’Virtual_table 1 1Mpls_labeling’check_labels 1 0

Mpls_labeling’O_LER_Routers 1 1

Figure 11. Boundedeness properties.


7.1. Simple case

Suppose a LSR router having n interfaces. Consider the simple case where the inputinterface for multicast groups is the interface a of the router. First, suppose we haveonly one multicast group, then in bad case the number of outgoing interfaces for thisgroup will be n − 1. Using general algorithm used in MPLS imply that the number ofentries in forwarding table for the interface a is n−1 entries. Second, suppose we have k

multicast groups coming via the interface a, in bad case also the number of entries (NE)in forwarding table for the interface a is given by

NE = k(n − 1). (1)

Using the proposed algorithm the number of entries in multicast MPLS forwardingtable (MMFT) is always equal to the number of interfaces the router have independentlyof the number of multicast groups. In this case we will have n entries in the MMFT

NE = n. (2)

Figure 12 shows a comparison between general algorithm and the proposed algo-rithm in the simple case. A general form of the curves is showed. By fixing the numberof interfaces n we plot the number of entries in forwarding table in function of the num-ber of multicast groups using (1) and (2).

From figure 12 we conclude that for one multicast group, and using general algo-rithm, the number of entries NE is equal to n − 1 and using the proposed algorithm thenumber of entries NE is equal to n. For (n/n − 1) multicast groups, using both algo-rithms, we obtain the same result. But up to (n/n − 1), using the proposed algorithm,the number of entries remains constant (2). In contrast, using the general algorithm theNE grows linearly in function of the number of multicast groups (1).

Figure 12. Comparison between general and proposed algorithm in simple case.


7.2. General case

In general case, suppose we have kl groups coming via the first interface IF1, ki groupsvia the interface IFi and kn groups via the interface IFn. Then the total number NEtot ofentries in forwarding table using the general algorithm is given by (3):

NEtot = NE1 + NE2 + · · · + NEi + · · · + NEn.

Using (1) we have NEtot = ∑i=1,n ki(n − 1) then

NEtot = (n − 1)∑

i=1,n

ki. (3)

In general case the total number NEtot is greater than in the simple case. In contrast,using the proposed algorithm in both cases the NEtot remains constant and equal to thenumber of interfaces n in the router:

NEtot = n. (4)

8. Conclusion

In this paper, a label aggregation approach to solve the multicast scalability problem to-gether in DiffServ/MPLS is presented. this approach makes use of prime numbers prop-erties to aggregate different multicast trees and thus reduce multicast states in routers.As a consequence, the label aggregation approach allows to maintain a constant multi-cast MPLS forwarding table size independently of the number of multicast sessions andthe multicast packet processing delay is reduced in each router. In addition, This ap-proach avoids the wasting bandwidth problem since destinations that are not involved ina multicast group will not be reached by replicated packets. We simulate and validate theassignment MPLS labelling with CPN (Colored Petri Nets) to obtain a state space graph.The objective is to study the behaviour of this model, by verifying different propertiessuch as, boundness, liveness. The results show that the proposed solution based in thelabel assignment is carried out at the same time for all the processes of the system.

Acknowledgments

This research has been sponsored by the Korean Ministry of Science and Technologyand the French Embassy in Seoul.

References

[1] A. Abouaissa and A. Benslimane, A multicast synchronization protocol for real-time distributed sys-tems, in: Proc. of the IEEE Internat. Conf. on Networks (ICON’99) Brisbane, Australia (September–October 1999).


[2] S. Biswas, R. Izmailov and B. Rajagopalan, A QoS-aware routing framework for PIM-SM-basedIP-multicast, Inetrnet draft: draft-biswas-pim-sm-qos-00.txt (June 1999).

[3] S. Blake, D. Black and et al. An architecture for differentiated services, IETF RFC 2475 (June 1998).[4] R. Bless and K. Wehrle, IP multicast in differentiated services networks, IETF Internet Draft draft-

bless-di_serv-multicast-02.txt (November 2001).[5] S. Chen, K. Nahrstedt and Y. Shavitt, A QoS-aware multicast routing protocol, in: Proc. of IEEE

INFOCOM (March 2000).[6] J.-H. Cui, J. Kim, A. Fei, M. Faloutsos and M. Gerla, Scalable QoS multicast provisioning in DiffServ

supported MPLS networks, in: Proc. of IEEE GLOBECOM’02, Taipei, Taiwan (17–21 November2002).

[7] M. El Hachimi, A. Abouaissa and P. Lorenz, Mobile agents based multicast QoS routing, in: Proc. of5th WSEAS, EC’04, Udine, Italy (2004).

[8] M. Faloutsos, A. Banerjea and R. Pankaj, QoSMIC: Quality of service seneitive multicast Internetprotocol, in: ACM SIGCOMM’98, Vancouver, British Columbia (September 1998).

[9] L. Faucheur et al., Multiprotocol label switching architecture, Internet dreaft: draft-ietf-mpls-diff-ext-09.txt (April 2001).

[10] A. Fei and M. Gerla, Receiver-initiated multicast with multiple QoS constraints, in: Proc. of IEEEINFOCOM (March 2000).

[11] J. Hou, H.Y. Tyan, B. Wang and B. Nandy, QoS extension to CBT, Internet draft: draft-hou-cbt-qos-00.txt (February 1999).

[12] K. Jensen, Colored Petri Nets. Basic Concepts, Analysis Methods and Practical Use, Vol. 1: BasicConcepts (1992); Vol. 2: Analysis Methods (1994); Vol. 3: Practical Use (1997), Monographs inTheoretical Computer Science (Springer, New York).

[13] R. Milner, R. Harper and M. Tofte, The Definition of Standard ML (MIT Press, Cambridge, MA,1990).

[14] R. Milner and M. Tofte, Commentary on Standard ML (MIT Press, Cambridge, MA, 1991).[15] K. Nichols, S. Blake, F. Baker and D.L. Black, Definition of the differentiated seriveces field (DS

field) in the IPv4 and IPv6 hearders, IETF RFC2472 (December 1998).[16] E. Rosen, A. Viswanathan and R. Callon, Multiprotocol label switching architecture, IETF RFC3031

(January 2001).[17] A. Striegel, A. Bouabdallah, H. Bettahar and G. Manimaran, EBM: A new approach for scalable

DiffServ multicasting, in: IEEE INFOCOM (2003).[18] A. Striegel and G. Manimaran, Dynamic DSCPs for heterogeneous QoS in DiffServ multicasting, in:

Proc. of IEEE GLOBECOM’02 (2002).

scalable multicast provisioning in diffserv with mpls labeling

Documents