UNCLE: A Unified Unicast and Multicast Label ... - IEEE Xplore

1 downloads 0 Views 583KB Size Report
Abstract—This paper presents a novel cross-layer forwarding scheme, called UNified unicast and multiCast LabEling (UNCLE), for mobile ad hoc networks ...
Globecom 2012 - Wireless Networking Symposium

UNCLE: A Unified Unicast and Multicast Label Forwarding Architecture in MANETs Wen-Kang Jia

Li-Chun Wang

Department of Electrical and Computer Engineering National Chiao Tung University Hsinchu, Taiwan [email protected]

Department of Electrical and Computer Engineering National Chiao Tung University Hsinchu, Taiwan [email protected]

Abstract—This paper presents a novel cross-layer forwarding scheme, called UNified unicast and multiCast LabEling (UNCLE), for mobile ad hoc networks (MANETs). Unlike traditional unicast and multicast forwarding schemes requiring two different protocol stacks, the proposed UNCLE forwarding method requires only one single protocol stack, and thus avoid the need of distinguishing unicast frames from multicast frames. Furthermore, the header of the stateless UNCLE forwarding scheme is designed based on a simple modulo approach, resulting in much lower protocol overheads than the traditional stateless unicast Dynamic Source Routing (DSR) and the Differential Destination Multicast (DDM) schemes. In addition to low forwarding latency the proposed UNCLE is very scalable for various network sizes and the multicast group sizes without table lookup in layers 2 and 3. Therefore, the UNCLE forwarding scheme can facilitate the deployment and management for providing both unicast and multicast services significantly. Keywords-Multicast; Wireless Label Forwarding; UNCLE; MANET.

I.

INTRODUCTION

Mobile Ad-hoc Networks (MANETs) play an important role in the next generation wireless systems. Numerous unicast and multicast routing protocols for MANETs have been proposed in the literature. Usually, each wireless node logically operates similarly to a router. However, unlike a router in wired networks requires multiple interfaces, a MANET node is usually equipped with a single wireless interface. The differences between an MANET node and a router in the wired-line network were addressed in [1]. The current unicast multicast routing protocols for MANET face the following issues: (1) high protocol overhead, (2) long forwarding latency, and (3) high different of unicast and multicast routing schemes. Firstly, the stateless unicast (e.g., Dynamic Source Routing (DSR) [3]) and multicast (e.g., Differential Destination Multicast (DDM) [4]) routing protocols, may result in high overhead for long paths, large group size, and huge network size due to the source routing and explicit nature. Secondly, current medium access schemes for ad-hoc mode of IEEE 802.11 WLAN cannot forward the data frames in the link layer. Thus packets will be passed up to the network-layer protocol suits (e.g., TCP/IP). Then, an IP “routing function” can determine whether a given packet is destined to the node itself or forwarded to other nodes. This operation requires several thousand table lookups. As the

978-1-4673-0921-9/12/$31.00 ©2012 IEEE

packet traverses through these nodes, it encounters both delay and jitter depending on dynamitic processing time at nodes; an accumulation of the jitters may cause further packet loss randomly, thus highly complex QoS problems are facing in MANETs. This forwarding and routing processing is unfavorable to handle the large traffic loads for the “delaysensitive” and “bandwidth-sensitive” operations in the MANETs. Thirdly, since multicast routing protocols are functionally different from unicast routing, nodes execute independent routing protocols to decide how to forward unicast and multicast packets respectively. Consequently, from the aforementioned point of view, designing MANETs endowed with a link-layer routing capacity will be a reasonable choice. Maintaining large IP routing information is very complicated and costly in the linklayer. Link-layer label is simpler than network-layer IP header thus an accessional label to indicate the packet’s direction becomes a reasonable choice. Various labeling architectures have been proposed for efficient packet forwarding in MANETs. [2-3, 12-16] The labeled forwarding offers solutions to this rapid growth and large networks by allowing a large number of IP addresses to be associated with a shorter label. Compared to IP routing, label forwarding is much faster because the label value placed in an incoming packet header is used to access the forwarding table at the intermediate nodes. That is, the label is used to index the table hop-by-hop. Once MANET nodes are equipped with the label forwarding capacity, it can receive a packet from a superordinate node and then immediately transmit the packet to a subordinate node as an atomic operation by medium access controller on pure link-layer, thus it no longer rely on the routing function. This can lead to extremely short forwarding latency at the inner nodes, and better utilization of the wireless channel. Except label forwarding operation has established and maintained the labeled paths, and distributed the labels between nodes, and then forwarding label traffic across an MANET is very simple. This approach will further reduce the size of address (actually label) tables and enables a MANET to support a larger network size, more traffic, more multicast groups, and more multicast receivers (multicast group size). Further, because huge costs in the presence of frequent topological changes a source-routing and stateless approach become a reasonable choice for wireless label forwarding. In addition, because MANETs are with restricted resources

5711

comprehensively, an integrated unicast and multicast routing is a much more attractive approach for MANETs to disseminate information using a single routing protocol. Moreover, label switching networks do not need a lot of resources such as signaling, bandwidth, memory occupancy and access, computation; the advantages will reflect on energy efficiency in entire MANETs.

1 illustrates the architecture of a UNCLE node. The label is constructed by arithmetic of continued multiplication of primes, which is performed at the source. The detailed description and proof of the arithmetic can be found in next section. Since the order of keys in proposed arithmetic is irrelevant, thus such scheme is also suitable in multicast routing. Each packet then encapsulates and carries the labels during their LFP.

MANETs owe to the success of Information and Communications Technology (ICT) industry the low-cost embedded system, the processing of packets in MANET’s nodes is implemented in the general purpose processor which implements the appropriate algorithms. Although wireless label forwarding introduces a new minor complication that the link layer must deal with label forwarding operations can be implemented either in software or in hardware circuits. In addition, a protocol and architecture should be “lower-layer independent” in order to improve flexibility and expansibility for long-term deployment. All the fore mentioned still should be based on the reasonable cost of the MANET’s applications and services. The rest of the paper is organized as follows: In Section II, the proposed scheme is elaborated. We also demonstrate that in detail by example. In Section III, performance evaluation including simulation, numerical results and comparison are discussed. Finally, Section IV gives the concluding remarks. II.

PROPOSED SCHEME

A. Architecture Overview We attempt to propose a novel unified unicast and multicast routing architecture to deal with various existing issues regarding multicast packet forwarding in MANETs. Our expected goals are to 1) enhance the performances; 2) improve the scalability; 3) reduce the overheads of both the control and data; 4) provide higher flexibility (e.g., in high mobility environment) in the deployment of new unified unicast and multicast services in medium-scale groups with few hundreds of participant nodes. The proposed scheme—UNified unicast and MultiCast LabEling (UNCLE) is motivated in part by the approach to unicast routing of 1) DSR [3] and derived in part from the work of 2) stateless mode of DDM [4]. The DSR uses explicit source routing strategy, in which each packet sent carries in its header the ordered list of on-path nodes through which the packet will forward. Similarly, a DDM source explicitly mentions the list of destinations in the packet header, resulting in packets being self-routed towards the destinations using the underlying unicast routing protocol at each intermediate nodes. Both DSR and DDM avoid maintaining complex routing information at each node, especially in multicasting, since per-group multicast forwarding states are eliminated at intermediate nodes and thus salable the number of multicast group. In UNCLE, data transmission occurs on Label Forwarded Paths (LFPs). LFPs are a sequence of nodes along the path from the source to the destination(s). LFPs are established upon reactive (on-demand) routing protocols such as DSR. Thus, the label distribution protocols likely In MPLS are no long necessary. There are two key elements to construct the LFPs of UNCLE: 1) source-specific label; 2) node-specific key. Figure

Figure 1. Architecture for label processing at nodes

B. Labeling Arithmetic In the case of unicast forwarding, when a source node nS wants to establish a connection toward a destination node nD , it first needs to complete the path discovery procedure through flooding to gathering all forwarded nodes along the end-to-end path nS nD  nS , n1 , n2 ,..., nd , nD (sequence of nodes), assume that each forwarded node with a unique node ID ni , where d denotes the path length, so that nodes n1 , n2 ,..., nd being requested will become forwarders and thus forming a Forwarding Set (FS) FS  nS nD   n1 , n2 ,..., nd  , (a.k.a Label Forwarded Path (LFP)), note that nS , nD   FS  nS nD  . Then, the Key Set (KS)   nS nD   k1 , k2 ,..., kd  is transferring from node sequence by ki  kth _ prime  ni  , ni . Finally, we obtain a label by 

LabelUnicast  nS nD

d

  k i 1

i





In the case of multicast forwarding: To receive an interested multicast data stream, receivers must join a particular multicast group by sending a join request message to the source. A multicast channel in UNCLE is identified by (S,G) according to the specification of Source Specific Multicast (SSM) [5, 6], where S is the address of the source and G is a multicast group (channel) ID allocated by the source, where G must be unique within the S only, but not on the global network. This definition solves the multicast address allocation scalability problem. We assume that the group of source (S,G) with group members= nD1 , nD 2 ,..., nDr  , where r denotes the group size (number of receivers) of channel (S,G). When source discovers and collects multiple KSs K( n n ) ,K( n n ) ,...,K( n n )

{

S D1

S D2

S Dr

}

between that itself and multiple receivers, a multicast label is constructed by all the involved node-specific keys based on merging all the KSs. We obtain the multicast label by

5712







Label Multicast  S , G    ki  , i 1

r



where     nS nDj j 1







The derived label is placed in a special control header extension between link-layer and network-layer header, and that label must be processed by every node along the unicast delivery path and multicast delivery tree hop by hop. The result of the operation will be used to determine whether to forward such packet or not each at each intermediate node. The details of operations are described in the following subsections. Furthermore, the label in case of multicast will be frequently modified because the multicast tree might be frequently changed by pruning or grafting. Once a new member joined and leaved the group, whether a multicast packet should be copied to the new delivery path, or should not be copied to an existing path, are indicated by the updated label. The receiver performs path-discovery during a “join” or “leave” requirement, and then the source recalculates the new label by obtained current forwarding sets. C. Labeled Packet Forwarding Each incoming labeled packets are in-need duplicated and forwarded to next-hop neighbor node(s) indicated by relaycontrol at each intermediate nodes ni ,which constructed by using a simple modulo operation: Let label Label ( ni-1nD ) be the dividend and node-specific key ki be the divisor. Through a long integer divider, the desired relay-control for each intermediate node i is obtained by the reminder Âi , which converting to a boolean, if the Âi that is zero, forwarding this packet with new label, and a quotient be the new outgoing new label Label ( ninD ) which replaced the original incoming label Label ( ni-1nD ) ; else if the Âi that is nonzero, dropping this packet. Note that the procedure is no distinction between unicast and multicast. The labeled packet forwarding logic is given by 

Label ( ni nDm ) ...Âi = Label ( ni -1nDm

) mod ki 



The ingenious of the proposed scheme consists in its simple and distinctive design. In MPLS, each Label Switch Router   (LSR) need to judge where the packet is heading to and which label should be assigned to the packet. Oppositely, in UNLCE, Label is using to determine whether a packet should be relayed towards either neighbor (make forwarding decision), but which target neighbor(s) is unconcerned. Hence the IP header is only using for determining whether a packet should be passed to upper-layer applications, but not used for making routing decision. For unicasting, a packet is either “relayed” or “received”, or “dropped” (noninvolvement); that is, simultaneously receives and relays a packet is impossible. For multicasting, a packet whether to relaying or receiving is independence, that is, a received packet may be “received only”, “relayed only”, “received and relayed”, and “dropped”. In UNCLE, we separate forwarding function from routing function as it requires very different processing, note that the forwarding decision is making earlier than receiving decision, thus the forwarding task can be finished ahead of time. Highspeed forwarding of packets is possible because the label can be used by hardware to forward packets quickly between nodes. Moreover, the label contains completed LFP itself, thus forwarding decision is stateless, and that will avoids the lookup of neighbor list and unicast/ multicast routing table in each forwarded node, so it results in much better forwarding performance than most existing forwarding/routing schemes. In the proposed scheme, There are two approaches to accomplish this modulo operation: Software (S/W) and Hardware (H/W) implementations. In the former, a generalpurpose processor is used at intermediate nodes. Normally, such platforms have only 16-bit or 32-bit division (DIV) instruction, thus modulo operation with long operands is calculated based on multiple divisions, multiplications, and proper truncations using a shorter-length instruction set [7]. The complexity regarding the processing time of UNCLE is bounded by 

(

O Label ( ni -1nDst

)-

)

ki + 1 



where Label ( n n ) denotes the reminder length of label at i-1 Dst current  node ni , and ki denotes the length of key for the node ni . Assume an intermediate node with a 1GHz 32-bit processer with 15-cycle multiply (MUL) instruction, we can calculate the 64-bit modulo operation and obtain the remainder (relaycontrol) using only three multiplications of 32-bit multiplier, thus there is an   n1.58  algorithm (actually 1.58=log2(3)) in

The UNCLE label will be consumed up hop by hop until reach the destination(s). In unicast, label always become 1 while labeled packet arrival at the designated destination, note that 1 will not divide into any key, thus the forwarding action will be stopped at the destination node. In multicast, since the branching of delivery tree makes the useless keys carried towards incorrect destinations, thus the useless keys will remain on the label and forwarded to incorrect destinations. However, the forwarding action will also be stopped at the all destination nodes.

Knuth's semi-numerical algorithms [7]. Suppose we have 1024-bit label, we need 485 multiplications (≈7.275μs) to compute the remainder recursively. Without loss of generality, UNCLE can accomplish packet forwarding with very low latency in reasonable multicast group size (  32 receivers).

In UNCLE, the labeled packets contain different channels’ self-routing information traverse a specific intermediate node, the different relay-control actions will obtain from extracting different label-value with the same key. Therefore one unique key with different multicast label is sufficient to distinguish one relay-control from another without any confliction, and limitless multicast channels theoretically.

In H/W-implementation, a hardware accelerator [8, 9] based on either a Field Programmable Gate Array (FPGA) or an Application Specific Integrated Circuit (ASIC), or a practical long integer divider, is used at each UNCLE node. Once a partial label which aligns high-order word contained within a packet header, is arriving at the MAC of network interface at the intermediate nodes, a hardware divider will be activated per

5713



word in advance, and the remainder will be simultaneously calculated upon receiving the least significant bit (LSB) of the label. Hence, the processing latency would be negligible (≤ tens of cycles) in theory [9]. D. An Example of UNCLE operations Figure 2 shows an example of the multicast data distribution in UNCLE. There is a MANET which can be modeled as a geometric undirected graph G(V,E), in which the node represents a vertex in the plane, and an edge exists between two nodes if the distance between the neighbors is less than the wireless transmission range. Before any receiver node originates a join request to source, we assume that the MANET had well self-organized through a unicast routing protocol such as DSR. Each node has a unique key, but does not have any control state or table entry. Normally, the source will obtain a suitable source route by searching its route cache by previously learned; if no route is found in its cache, the source will initiate the route discovery procedure include Route Request (RREQ) and Route Reply (RREP) to dynamically find a new route to this destination node.

forming 1547 mod 7 (kD) operation, and forwards the packet with revised label=221 (1547 mod 7(kD)) to all the neighbors. Then, A, B, C, E, F, G receive the labeled packet simultaneously, but only F and G re-forwarding the packet by performing modulo operation like that in pervious step. For A, such received packet with label=221 could be treat as a positive acknowledgment. F and G receive the packet and process it like that on previous step, then the packet is copy towards H and I respectively. When the packet finally arrival at H and I, the remaining are both nonzero by modulo operations (13 mod 19 (kH)) and 17 mod 23 (kI)), thus such packet is stopping to forward to anywhere. In MANETs, a forwarded node must maintain state about packets that have already been forwarded to ensure they are not forwarded again. This procedure is known as Duplicate Packet Detection (DPD). In traditional DPD, the posterior packet will be dropped that follow the sequence number based approach, but this solution vary significantly in the resources consumed because of larger label. In UNCLE, a specialized DPD algorithm such as between F and G is in need of keeps the smaller label. Thus, in terms of state maintenance, overhead, energy consumption, and forwarding delay are to be reduced. On the other hand, an important issue to consider when deploying proposed architecture is its capability to detect and prevent forwarding loops within the MANET topology. Unlike the traditional manners, UNCLE employs the mechanism that keeps decreasing label length along the path/tree, so it is inherently a loop detection mechanism for wireless label forwarding. III.

Figure 2. Labeled packet distribution of a tree {A,B,D,F,G,H,I} in a reference MANET

When source S receives the JOIN requests form the group members {B, G, H, I}, a source tree was established by its associated source S and group ID (A,G1), and a multicast delivery tree can be found by source S: {A, B, D, F, G, H, I}, which denoted by red lines in the multicast overlay. And a forwarding set of such multicast delivery tree can be devised by source S: {D, G, F}. Node that the G acts both the intermediate node and receiver among all the nodes. Based on the proposed arithmetic as descripted in previous subsection, A creates seven entries {D, F, G} associate with keys {kD, kF, kG}, we obtained the label=1547 by calculating labeling arithmetic, where real value of label and keys are show in the figure. A labeled packet(s) with a UNCLE label contains the product of keys, is transmitting from A to all the neighbors. Note that the order of key entries is irrelevant. B and C receive the multicast packet, both them obtain the relay-control=nonzero by performing 1547 mod 3 (kB) and 1547 mod 5 (kC) operations respectively, thus B and C do not forwards this packet anywhere. But B as one of receiver, this packet will be passed towards network layer. D also receives the multicast packet, obtains the relay-control=zero by per-

PERFORMANCE EVALUATIONS

In this section, we analyze the characteristics and evaluate the performance of our proposed scheme against the competing works. We wrote programs in EstiNet 7.0 (previously NCTUns) [10] simulator to compare UNCLE with other multicast schemes from the various viewpoints and parameters. We have used the following metrics which suggested by the IETF reliable multicast transport working group [11], to evaluate the performance of various multicast protocols. As stated in previous section regarding the scalability of the proposed scheme, the network size is important due to the requirements of storing the keys. In order to show an indication regarding the scalability of the UNCLE, a large number (from 26 to 216 mobile nodes) of randomly generated MANET have been constructed through simulation. Nodes are randomly placed in a 6400m  6400m area. Each node in that graph is connected randomly with each adjacent node. The topology was randomly generated with 2~8 degrees and the average degree of each node is 4. The radio transmission range is approximately 25 meters. For the simulations that follow, we have considered the Maximum Transmission Unit (MTU) was limited to 2,272 bytes (Compliance with the IEEE 802.11a/b/g) in both link layer and network layer. Before the simulation starts, group members and sources are randomly selected among all nodes, and each node must be randomly assigned a unique ID and associated key in the

5714

reference network. Since there are one million prime numbers within 24 bits, which thus can represent the keys for all UNCLE nodes, and no more than 32 bits for future extension. In multicast scenario, a source and multiple destinations are selected randomly in the reference MANET; all group members join the multicast group at the beginning of the simulation and remain members till the end of simulation. The shortest paths connecting each receiver to its source were found by using flooding and unicast routing, and the proposed scheme were operation, its expected value increases as the network size grows and number of participating receivers’ increases.

Assume that the payload size is 1k bytes; we still can accommodate 895 hops in a group; or about 1194 hops with 500 bytes payload in a labeled packet. If the characteristic of applications such as VoIP that features small payload size (  100 bytes), it might accommodate more than 1,400 hops in a labeled packet which the network size N=320K nodes. However, the scalability is much bigger than the theoretical maximum path length, 568 and 142, in DSRv4 and DSRv6 respectively with empty payload in any network size. In other words, the unicast delivery distance is also much wider than the theoretical maximum number of on-path nodes, 374 and 92, in DSRv4 and DSRv6 respectively with empty payload.

A. Scalability and Overhead in Unicast A (multicast) routing protocol is considered scalable with respect to network size, group size and number of groups, if it is suitably efficient and practical when applied to large situations. Larger numbers of nodes means increased management complexity, as well as a more overhead and issues such as throughput and latency between nodes. In sourcerouting approach unicasting and explicit approach multicasting, the packet overhead is defined as the quantity of control header transmitted per data packet. Since the effective payload on the link layer is limited furthermore by the MTU. In UNCEL, that is a tradeoff between the effective payload and path length/group size in MANETs.

B. Scalability and Overhead in Multicast In multicast scenario, we compare UNCLE to stateless mode DDM over IPv4 (DDMv4-SM) and IPv6 (DDMv6-SM) in the same situations previously. Similar to DDM’s header, a plenty of receivers lead to a longer label in UNCLE, a longer label causes a larger overhead that reduces the effective payload in expected. The difference is, DDM’s overhead does not affected by the network size, but UNCLE does, thus the DDR’s overhead is constant with increasing numbers of destinations in any network size. The simulation results are depicted in Figure 4 and 5 display the low and high network scalability respectively.

Figure 3. Required overhead vs. network sizes and path lengths in unicast

The required in-packet overhead can sometimes reflect the scalability. We observe scalability from two perspectives: 1) unicast path length, and 2) multicast group size. The simulation results are depicted in Figure 3 that shows the required number of bytes in the UNCLE label verse varied group sizes and in different network sizes, which is incremented progressively. In unicast scenario, we compare UNCLE to DSR over IPv4 (DSRv4) and IPv6 (DSRv6). We consider that for the network sizes=1024 and 320K nodes, respectively. Although a distance between a source and its destination, accurate UNCLE label length becomes increasingly. The packet overhead of UNCLE is very lower than that in both DSRv4 and DSRv6 in any conditions as can be seen in Figure 3. That is because in such network scalability, the selected keys are usually kept in a low sized range, and the source routing information are compressed into incredibly small size by proposed arithmetic. In a 1024-node MANET, we find the maximum path length can reach 1,452 hops while UNCLE label size reaches the MTU and the effective payload is zero in this situation.

We firstly consider that for the network sizes   50, 65, 80, 100, 120, 150, 180, 200, 225, and 250, respectively in Figure 4. Even at its least efficient, UNCLE will carries more payload far exceeds both DDMs are capable of. As shown in Figure 5, we then consider that for the network sizes   29, 210, 211, and 212, respectively. We find that the maximum group size can reach 292 and 123 receivers while UNCLE label size reaches the MTU and the effective payload is zero in case of N=211, and 212, respectively. As regards   29 and 210, a group consists of total nodes still more efficient than that in DDMs’. Another interesting observation from Figure 5 is that for the network sizes   29 nodes, the overhead of UNCLE is higher than DDMv4-SM even DDMv6-SM in few receivers (sparse) scenarios, but along with the group size continuously increasing (density), the increasing overhead is slowed down until the overhead is large less than DDMs’. That is because of the incunabular receivers are possible far away from the source (comprising many on-tree forwarded nodes) while the superior key values are chosen, and each receiver may has an entirely different path. Significantly, when the network size and group size are both increased, it is observed that the packet overhead is also getting increased due to the source routing nature of UNCLE and this in turn reduces the efficiency of UNCLE. This has been accompanied by increasing member density through rising number of receivers resulting in redundant and therefore, slowing down the increase of length of UNCLE label. Although a practical MANET rarely exceeds 1,000 nodes nowadays, we cannot rule out the possibility in the near future. Compare to DDM, the simulation results indicate that UNCLE offers a remarkable performance in scalability while simplifying the deployment and management of multicast service for medium-scale even large-scale groups (depend on required payload size for specific applications) in large-scale MANETs.

5715

C. Packet Processing Latency As mentioned above, the proposed scheme is a stateless and self-routing approach for multicast packet delivery, thus massive resource will be saved in the on-tree nodes. It is expected that packet processing latency can be reduced by our proposed scheme. In this subsection, we compare packet processing performance of the UNCLE with existing methods. The simulation scenario is as follows: Without loss of generality, we randomly select several forwarded nodes in the reference network. Each node serves over 210 multicast groups in the meantime, and each group size=20~213 increasingly. In addition, we assume that each random memory access in the nodes spends 50ns, and each link has sufficient bandwidth to accommodate the traffic need in the reference network. Figure 6 presents the average packet processing latency versus group size (number of receivers) in the reference network. We compare UNCLE with various existing works such as DDMv4SM, DDMv6-SM, DDMv4-SSM Tree Nodes (TR), DDMv4SSM Branching Nodes (BR), and MAODV with 210/214/218/222 channels respectively. The curves show that S/Wimplementation UNCLE is much efficient than all existing schemes in the packet processing latency with no more than 26 receivers, and H/W-implementation UNCLE has the advantage over any existing schemes. Now we can see that the DDM-SM protocols are affected by the group size, the massive processing cost leads to poorer performance than others when the group size goes large. On the contrary, the curves for DDM-SSM and MOADV are almost unaffected by increasing the group size. IV.

CONCLUSIONS

In this paper, we presented a novel self-routing unified unicast and multicast label forwarding architecture in MANETs, named UNCLE, to overcome the scalability problems in terms of number of source-routing unicast and explicit multicast. The proposed scheme entirely eliminate the multicast routing states in the intermediate nodes by explicitly encoding the ciphered list of forwarding set in the packets instead of using a multicast group address. Besides, scalability was improved because of proposed scheme typically enabled very high encoding efficiency, and the forwarding latency was improved because of proposed scheme enabled very simple decoding efficiency. A major contribution of proposed scheme is to significantly increase the maximum number of participants comparing with the original explicit multicast scheme (e.g. DDM-SM), and it would benefit the deployment of medium-scale (or large-scale) few-to-few (>1,000 nodes) applications especially in multiparty conferencing in the largescale (>2,000 nodes) MANETs. Our proposed architecture

Figure 4. Required overhead vs. group sizes.

supports the growing demands of hard real-time applications in the delay-intolerant networks, and guarantees such emerging applications against all ineffective information which delay in arrival, hence the bandwidth are saved. REFERENCES [1]

[2]

[3]

[4]

[5] [6] [7]

[8] [9]

[10] [11] [12]

[13]

[14]

[15]

[16]

A. Acharya, A. Misra, and S. Bensal, “A Label-switching Packet Forwarding Architecture for Multi-hop Wireless LANs,” in Proceedings of the ACM Workshop on Mobile Multimedia (WoWMoM 2002), Atlanta, GA, Sep. 2002. A. Acharya, S. Ganu, and A. Misra, “DCMA: A Label Switching MAC for Efficient Packet. Forwarding in Multihop Wireless Networks,” IEEE Journal on Selected Areas in Communications, vol. 24, no. 11, pp.1995–2004. Nov. 2006. D. Johnson, “Routing in Ad Hoc Networks of Mobile Hosts,” in Proceedings of the Workshop on Mobile Computing Systems and Applications (WMCSA 1994), pp.158–163, Santa Cruz, CA, Dec. 1994. L. Ji and M. Corson, “Differential Destination Multicast- A MANET Multicast Routing Protocol for small Groups”, in Proc. of INFOCOM 2001, pp. 1192–1202, 2001. S. Bhattacharyya, “An Overview of Source-Specific Multicast (SSM),” IETF RFC 3569, Jul. 2003. H. Holbrook and B. Cain, “Source-Specific Multicast for IP,” IETF RFC 4607, Aug. 2006. D. E. Knuth, The Art of Computer Programming–Seminumerical Algorithms, Volume 2 of The Art of Computer Programming 3/e, MA, USA, Addison-Wesley, 1998. D. M. Ciletti, Advanced Digital Design with the Verilog HDL, Prentice Hall, Upper Saddle River, New Jersey, 2003. R. Trummer, P. Zinterho, and R. Trobec, “A High-Performance. DataDependent Hardware Divider,” in Proc. The International Workshop on Parallel Numerics 2005 (PARNUM 2005), Portoroz, Slovenia, pp. 193206, Apr. 2005. EstiNet 7.0, http://www.estinet.com. Reliable Multicast Transport Working Group, http://www.ietf.org/html.charters/rmt-charter.html J. M. Chung, K. Srinivasan, and A. Marricio, “Wireless multiprotocol label switching(WMPLS),” IETF draft: http://www.ietf.org/iternetdrafts/draft-chung-mpls-wmpls-00. J.S. Liu and C.H.R. Lin, “ECTP: An Energy-Efficiency LabelSwitching MAC Protocol for Infrastructure Wireless Networks,” IEEE Transactions on Vehicular Technology, vol. 56, no. 3, pp. 1399–1417, May 2007. L. Romdhani and C. Bonnet, “Cross-Layer QoS Routing Framework for Wireless Mesh Networks,” in Proc. Of Wireless and Mobile Communications (ICWMC '08), pp. 382–388, 2008. Y. Wang and J. Wu, “Label Routing Protocol: A New Cross-layer Protocol for Multi-hop Ad hoc Wirrdess Networks,” in Proc. Of IEEE International Conference on Mobile Adhoc and Sensor Systems Conference (MASS '05), 2005. Y. Yu and D. Makrakis, “MAC Layer Label Switching for Wireless Sensor Networks,” in Proc. Of International Conference on Communications and Mobile Computing (CMC '10), vol. 2, pp. 243– 249, Apr. 2010.

Figure 5. Required overhead vs. network sizes.

5716

Figure 6. Packet processing latency vs. group sizes.