EBM: A New Approach for Scalable DiffServ ... - Semantic Scholar

EBM: A New Approach for Scalable DiffServ Multicasting A. Striegel1 , A. Bouabdallah2 , H. Bettahar2 , and G. Manimaran3 1

2

Dept. of Comp. Sci & Engr., Univ. of Notre Dame, Notre Dame, IN {striegel}@cse.nd.edu Lab Heudiasyc, Universit´e de Technologie - Compi`egne 60200 Compi`egne France {bouabdal,hatem.bettahar}@utc.fr 3 Dependable Computing & Networking Dept. of Electrical and Computer Engineering Iowa State University, Ames, IA 50010 USA [email protected]

Abstract. The phenomenal growths of group communications and QoSaware applications over the Internet have respectively accelerated the development of two key technologies, namely, multicasting and Differentiated Services (DiffServ). Although both are complementary technologies, their integration is a non-trivial task due to architectural conflicts between them. In this paper, we propose a new approach, Edge-Based Multicasting (EBM), for providing multicast transport across a DiffServ domain. EBM leverages the intelligence of edge routers in DiffServ and a new entity called a Multicast Broker (MB) to provide such services. Unlike traditional IP multicast, our approach keeps core routers stateless and multicast-unaware. Our approach has significant implications for multicasting regarding scalability, deployment, security, heterogeneous users, and resource management. In our paper, we outline the EBM model and propose a novel tree construction algorithm, Edge Cluster Trees (ECT), which captures the unique aspects of DiffServ and EBM. Finally, we present detailed simulation studies of our approach and contrast our approach versus previous work.

1

Introduction

Although the available bandwidth of the Internet is continually increasing, new applications are continually being developed which erode gains in network capacity. For many of these new applications (ex. video/audio on demand, peer to peer sharing, teleconferencing, distributed gaming), the traditional unicast model is highly inefficient for supporting such applications. To address such inefficiency, the concept of multicasting was proposed to eliminate such unnecessary data transmissions by reducing the connections to a multicast tree with minimal bandwidth cost.

From the perspective of both the end user and the network service provider, multicasting could offer tremendous benefit to both network efficiency and QoS. However, the issue of how to support multicasting in one of the more promising QoS models, Differentiated Services [1], has received relatively little research attention. Although the two concepts of bandwidth conservation (multicast) and scalable QoS management (DiffServ) are complementary, the emphasis on scalability by DiffServ creates architectural conflicts with multicasting that make the integration of the two technologies a non-trivial task [2]. 1.1

Differentiated Services & Multicasting

The Differentiated Services (DiffServ) architecture [1] was proposed by the IETF for providing scalable QoS across the Internet. In the DiffServ architecture, intelligence is migrated to the edge of the domain in order to keep the core of the network simple and scalable. Routers in a DiffServ domain are divided into two categories, core routers (simple and high speed) and edge routers (stateful and intelligent). Core routers do not have per-flow state and differentiate packets according to the marking (DSCP - DiffServ Code Point) of the packet. In contrast, edge routers are stateful entities that are responsible for policing and/or marking all packets according to an SLA (Service Level Agreement) between the source (other ISP, user, company) and the domain, or between two domains. Whereas DiffServ relies on only edge routers possessing intelligence and state information, multicasting relies on per-group state throughout the entire network. Thus, when trying to integrate the two technologies, one is faced with two conflicting principles, core statelessness for scalability versus per-group state information for efficiency. The natural question is, which principle is more important, state information (storage and router complexity) or maximal network efficiency (bandwidth)? It is our belief that state information is vastly more costly than bandwidth. Whereas one could argue that if one can increase bandwidth capacity, one can also increase the state storage capacity, it is the maintenance of such state information (router complexity) that is the problem. Thus, we pose a simple question: Why not follow the DiffServ approach and minimize the number of routers that must maintain such state information? If bandwidth can be thought of as significantly cheaper than maintaining state information at all routers, can one leverage the DiffServ model to provide a better and more scalable multicast? These questions provide the motivation for our paper. In our paper, we propose a novel approach for DiffServ multicasting, Edge-Based Multicasting (EBM), which leverages the unique aspects of the DiffServ architecture to exploit the intelligence of edge routers and maintain core statelessness. Rather than employing a multicast everywhere approach, EBM reduces the problem to edge-to-edge transport across a single DiffServ domain. In addition, we introduce the concept of a Multicast Broker (MB) for group management and a novel algorithm for tree construction, (Edge Cluster Tree (ECT)), that addresses the unique characteristics of the DiffServ environment. Our approach introduces several other benefits as well:

– Core simplicity - In EBM, core routers do not have to support any multicast operations (routing, replication, resource management). – Multicast deployment - Rather than requiring the same multicast protocol from end-to-end, the black box nature of EBM allows for seamless translation between multicast protocols. – Security - The EBM architecture lends itself both to security (protection against spoofing, malicious attacks) as well as traffic management (protection against DoS attacks). – Resource management - Rather than requiring core routers to negotiate resources [3], EBM simplifies the process to a single interaction between the MB and Bandwidth Broker (BB). The rest of our paper is organized as follows. In Section 2, we describe the key components of the EBM architecture. Next, in Section 3 we describe the ECT algorithm for tree construction. In Section 4 we conduct extensive simulation studies and in Section 5, we examine related work. Finally, in Section 6 we make several concluding remarks.

Rcvr

Rcvr

Rcvr

ER

Multicast Broker (MB)

BB

ER Source

ER

ER

DiffServ domain Rcvr

Rcvr

ER

ER ER Rcvr

Fig. 1. EBM Network Architecture

2

EBM: Edge-based Multicasting

The primary goal of the Edge-Based Multicasting (EBM) architecture is to provide scalable multicast transport across a single DiffServ (DS) domain. The first step is to apply the scalability principles of DiffServ to multicasting, i.e. push the state to the edge of the domain. This concept fits perfectly with the notion of a multicast transport service that allows the core routers to remain as simple, stateless routers. Figure 1 shows the fundamental principles of the EBM architecture and is summarized below:

– Stateless core: Core routers are multicast unaware and therefore do not maintain any multicast state information. – Tunneled packets: Packets are tunneled from edge to edge, thus reducing the multicast packet to a true unicast packet in the core. – Edge replication: Packets may only be replicated at edge routers. The replication information may be included in the packet (encapsulated tree) or maintained as state information at the edge router. – Multicast Broker: The Multicast Broker (MB) manages all egress join/leave requests and multicast trees for the entire DS domain. In addition, the multicast broker manages all QoS interactions for multicasting (security, resource reservation, etc.). 2.1

EBM Multicast Transport

In order to provide a multicast transport service, the edge router must provide two new functions, namely packet replication/tunneling and join/leave forwarding. Both functions are fairly straightforward and require only minimal changes to the edge router. For packet replication and tunneling functionality, an edge router must be able to recognize a multicast packet and appropriately replicate/tunnel the packet onto the domain. When a multicast packet arrives at an edge router from outside the domain, the edge router will examine its state information (provided by interactions with the MB) and replicate/tunnel the packet via a modified Minimal Encapsulation header [4] to downstream egress points in the multicast domain. If the packet should be replicated to outside of the DS domain, the encapsulation header is stripped off and the original information replaced in the multicast packet. The second function (join/leave forwarding) involves acting as an attendant for inter-domain routing requests that require the intervention of the MB. For any join/leave request, the edge router must tunnel the request to the MB along with information about the QoS requested (PHB) and the egress point requesting the multicast service. The MB processes the join/leave request and the appropriate edge routers are updated with the new tree information. Thus, the edge router need not be concerned with the specifics of multicast routing, only the appropriate mechanisms for packet tunneling, replication, and forwarding to the MB. 2.2

EBM Multicast Broker (MB)

In order to simplify group management, the EBM architecture incorporates the use of an entity known as the Multicast Broker (MB). The responsibilities of the MB include tree construction, tree rearrangement, and security management. The MB may be either a centralized or distributed entity. In this paper, we address the MB from the perspective of a centralized entity near (but separate) from the Bandwidth Broker (BB). In order to meet the high levels of group

dynamics, we propose that the MB services would be provided using a tiered scheme employing load balancing. The centralization of all multicast information offers several significant benefits. First, QoS negotiations for a tree are greatly simplified. Due to the distributed nature of routing in traditional IP multicasting, each router may need to negotiate resources individually [5]. In contrast, the MB can negotiate with the BB for the entire multicast tree in one exchange. Second, the centralized approach lends itself towards a more robust security scheme as well. In contrast to traditional IP multicasting, the centralized approach makes it easier to force security features (authentication/encryption) on all group dynamics (topology changes, etc.) and can also serve as a starting point for managing secure groups. Finally, the centralized architecture is ideal for tree construction and tree rearrangement [6]. 2.3

Member Join

In EBM, a member is defined as an egress point (edge router) that wishes to receive packets for the multicast group. An egress point may have many other downstream domains or receivers. The maximum size of an EBM multicast group is bounded by the number of edge routers (potential egress points) and is independent of the number of receivers, hence reducing the practical size of the scalability problem. Initial Join Request: The join process begins when an inter-domain join request reaches the edge of the DS domain. The request may be sent by any of the existing multicast protocols (SSM, IGMP, PIM) and would be intercepted by an edge router. Upon receiving a join request at an edge router, the request is forwarded to the MB for the domain (known via configuration or discovery). The request is forwarded to the MB using either a signaling PHB or other appropriate low loss/reduced delay PHB. The join message includes the ID of the new egress point, the requested PHB (if possible), and the information from the inter-domain join request. MB Processing: Upon receiving an join message, the MB must first determine the status of the group in the DS domain. If the group already exists in the domain (has ingress or egress points), the MB does not need to search for the group. However, if the multicast group does not exist in the DS domain, the MB must locate the multicast group. For cases where the join request is using SSM or CBT (Core-Based Trees) where a source address is included, the problem is vastly simplified as the location of the multicast group is easily identified. In other cases, the MB must search for the multicast group using a multicast inter-domain routing protocol such as MBGP or MSDP as the multicast group address does not necessarily imply location and thus must be discovered. The actual edge routers to which the new egress point can be grafted to is discussed in more detail in Section 3. A simple (but not optimal) solution is to graft the new egress point to the closest on-tree edge node that satisfies the edge-to-edge PHB of the new egress point. Such topology information would be readily available from the underlying link state routing protocol.

Graft: After the MB has determined the appropriate grafting point; the MB will inform both the new egress point and the upstream edge router of the change in the multicast tree. If the tree is not being rearranged, only the two edge routers involved, the MB, and the BB (optional) need to know about the change in the multicast tree. The MB sends an update message to the two edge routers containing the ID of the new edge router (leaf), the ID of the parent edge router, the ID of the multicast group, and the DSCP for the new branch. Both of the edge routers will update their replication information and future data transmissions to the group will now flow to the new egress point. In the event that non-ingress edge routers do not keep replication state information (i.e. tree encapsulation), the MB will send the update message to the ingress router rather than the grafting point. The advantage of employing tree encapsulation is that tree rearrangement can be conveyed via a single packet to the ingress router(s) rather than all effected nodes. For single sourced multicast trees (such as SSM), such an approach may be advantageous for faster tree optimization. For multi-sourced trees (shared and many to many), multiple nodes may need to be updated. 2.4

EBM Member Leave

When an edge router wishes to leave the multicast group, it sends an leave message to the MB. It is assumed that such a message will only be sent when the edge router has no additional downstream receivers (i.e. the last of its downstream receivers sends a prune or times out). The member leave operation is less critical from the user perspective as the user no longer desires service from the multicast group. However, from the perspective of a service provider, the quick execution of a member leave operation minimizes wasted resources. Similar to the join operation, the prune operation can be conducted using the MB with the addition of domain-wide tree rearrangement for optimal packet distribution.

3

Edge-Clustered Trees (ECT)

The construction of multicast trees in an environment such as DiffServ is governed by several constraints that must/should be obeyed. These constraints include: – PHB priority: An egress point with a higher priority PHB must not sit downstream from an egress point with a lower PHB. For example, a packet cannot be tunneled to a BE (Best Effort) egress point with the BE PHB and then tunneled to an EF (Expedited Forwarding [7]) egress point using the EF PHB. – PHB promotion: Conversely, an egress point with a lower priority PHB should not receive a higher priority PHB for its packets than requested. For example, a packet should not be tunneled to an AF (Assured Forwarding [8]) egress point with the EF PHB and then tunneled to an EF egress point with the EF PHB.

– Minimal hop count: Packets should be delivered with the minimal hop count possible since no per-flow state exists to balance the cost of additional hops (i.e. shorter path is better than a longer path). Because of these constraints, traditional multicast tree construction algorithms such as KMB [9] and others cannot be applied to the problem directly. Since existing algorithms are not sufficient for addressing such constraints, we developed a novel approach called the Edge Clustered Tree (ECT) for constructing trees in such an environment. 3.1

ECT Algorithm

The premise of the ECT algorithm is fairly simple, cluster similarly QoS-classed egress points together in an effort to balance the cost of the tree versus the additional hops required for edge-based branching. The ingress node tunnels the packets to clusters that then tunnel the packets to the egress points in their clusters and other downstream clusters. The ECT algorithm itself can be broken into two key phases, cluster construction and cluster linkage. 3.2

Cluster Construction

In the first phase, a cluster is constructed centered on each egress point of the multicast group. A cluster consists of all other egress points within H hops of an edge router (EX ) whose PHBs can be satisfied by the PHB used for packets sent to EX 4 . The cost of the cluster consists of the costs of tunneling to the nodes in the cluster (from EX to the cluster nodes) and the cost of the tunnel from the ingress router to EX . The metric M (EX ) for evaluating a cluster centered at node EX is defined as: M (EX ) =

D(IG , EX ) +

P|CX | i=0

D(EX , CX,i )

|CX |

where D(X, Y ) is the number of hops between X and Y , IG is the ingress router for the group (single source), |CX | is the number of nodes within H hops that are satisfied by EX ’s PHB, and CX,i is the ith node in the cluster centered around EX . A lower value of M (EX ) denotes that the average cost of servicing the nodes in a cluster is lower as well. The ingress node is a special cluster whose PHB satisfies any egress point. 3.3

Cluster Linkage

In the next phase, the clusters are linked together via tunnels to connect the multicast distribution tree for the domain5 . The algorithm proceeds by connecting the best cluster according to the metric. In the first iteration, only the ingress 4

5

The precedence of various PHBs is a topic beyond the scope of this paper. We assume that rules to govern such precedence exist in the MB. The complete ECT algorithm is available in [10].

cluster may be tunneled from (although its cluster may not be selected). Once a cluster is selected, the cluster becomes available as a candidate for future clusters to be tunneled from provided that the PHB priority is still satisfied. Ties are resolved by connecting the highest PHB first in order to maximize the chances that other clusters may be tunneled from that cluster. When a cluster is selected, all of the nodes inside of the cluster are removed from consideration as members of other clusters. The metric of the remaining clusters is recomputed based on the new cluster membership and the potential new grafting points of previously selected clusters (cluster centers only). An additional constraint may be imposed, cluster depth D, such that a cluster may not be more than D tunnels away from the ingress point, thus capping the maximum tunnels to an egress point at D + 1 tunnels (tunnels to cluster+tunnel from cluster). 3.4

ECT Example

Figure 2 shows an example of the ECT algorithm with H = 2. In the figure, only paths between edge nodes that are egress points (members) of the group are shown. Each link label denotes the hop count between the nodes. – Step 1: The clusters around each node are constructed considering all egress points within H = 2 hops. For the cluster centered on N 1, it finds two nodes within 2 hops whose PHB is still satisfied by its PHB. Conversely for N 0, although it can find N 1 within 2 hops, it cannot offer service (BE < AF 10). The figure shows a total of 6 clusters. – Step 2a: The best cluster is linked to the tree. In this case, the ingress point (I) is the best cluster. – Step 2b: The next best cluster is centered on N 1. The cluster is linked to the tree via the ingress point and the nodes within N 1’s cluster (N 0 and N 2) are removed from all other clusters. The remaining clusters (N 3, N 4) check to see if N 1 is closer than the ingress point. – Step 2c: The next best cluster is centered on N 4. The cluster is linked to the tree via the ingress point and node N 3 is removed from the remaining cluster. After Step 2c, the tree is constructed covering all the egress points for the multicast group and satisfying the PHB priority rules.

4

Simulation Studies

In order to evaluate the performance of the EBM architecture, we used the ns-2 simulator for the following models: – Ingress-only - Packets are tunneled out from the ingress node to all egress points in the DS domain. Replication is done only at the ingress node.

AF11 BE

AF11

AF10 1

BE

2

N0

AF10

N2

1

N1

N2

N0

N1

2

2

2

5

4

5

N3

N3

Step 1

AF12

AF12

5 I

I

2 N4

3

Ingress

2 N4

Ingress AF11

Step 2a

Step 2b

Step 2c

Node Ing N1 N4 N0 N2 N3

Size Cost 1 0 3 1+2+5=7 2 2+3=5 1 5 2 2+5=7 1 5

Metric 0.00 2.33 2.50 5.00 3.50 5.00

Node N1 N4 N0 N2 N3

Size Cost 3 1+2+5=7 2 2+3=5 1 5 2 2+5=7 1 5

Metric 2.33 2.50 5.00 3.50 5.00

Node N4 N3

Size 2 1

Metric 2.50 5.00

Cost 2+3=5 5

AF11 AF11 BE

AF10 1

N0

2

N2

N1

4 N3 I Ingress

AF12

2 3

N4 AF11

Edge Cluster Tree

1+2+4+3+2 = 12

Ingress-only tree

5+4+5+5+3 = 22

Fig. 2. Example of Edge Cluster Tree construction

– EBM - The EBM model is studied using two variations, the simple algorithm (outlined in EBM architecture) and ECT. – DSMCast - The adaptive DSMCast model [11] is studied that selects either DSMCast or ingress-only branching depending upon which is the least cost approach. – Traditional IP - Although we believe traditional IP multicasting is not scalable, it provides an excellent baseline for evaluating the relative overhead of the algorithms versus the best possible case for performance. The simulations were conducted for a single domain scenario of varying random network topologies and varying QoS distributions (uniform and nonuniform). The models were evaluated on three performance metrics, the average bandwidth consumed per link, the average number of hops, and the average number of tunnels to an egress point. The average bandwidth consumed per link gives an indication of the relative impact of multicast traffic on each link provided that no multicast packets are dropped. The average hops and average tunnels metrics demonstrate the additional impact of tunneling that occurs since packets may take a longer router to reach edge nodes versus ingress-only tunneling. The parameters for the simulations are available in [10]. Effect of Group Density In Figure 3(a), we examine the impact of the group size (egress points) on the performance of the various models. As would be expected, traditional IP multicast performs the best in terms of the bandwidth cost of multicasting. In order to better study the additional overhead of core statelessness, the figure shows the simulation results normalized as a ratio to the cost of traditional IP multicasting. DSMCast follows traditional IP multicasting the closest as it uses an actual multicast tree embedded inside the packet,

thus achieving much of the benefit of the multicast tree. Next, the two EBM approaches follow with ECT offering a marginal improvement over the simple approach. The ingress-only approach comes in last as it sees no savings for multicasting across a given domain. Although such an approach would save on an end-to-end basis, it performs essentially the same as unicasting each packet across the domain. However, as we see in Figure 3(b), the performance of traditional IP multicast comes at a cost. Whereas the state cost of stateless core multicasting follows the predicted average group size quite closely, the state cost increases much more rapidly in traditional IP multicasting. Due to space requirements, the similar results with a non-uniform PHB distribution are not included but are available in [10].

1.25

30

DSMCast-Adaptive Ingress-only EBM (Cluster) EBM (Simple)

Traditional IP (Stateful) Stateless Core Average Group Size

25

Average State Requirements (per group)

Normalized Bandwidth

1.2

1.15

1.1

20

15

10

1.05 5

1

0 3

4 5 6 7 Avg. Egress Points per Group

8

3

4 5 6 7 Avg. Egress Points per Group

8

Fig. 3. Effect of group size (Uniform distribution) - (a) normalized (b) state information

Effect of ECT Parameters: Figure 4(a) examines the impact of the H (hops) setting on the performance of the ECT algorithm with the performance of DSMCast, the simple EBM algorithm, and ingress-only branching included as a baseline. With a low H, the algorithm performs similar to the simple EBM algorithm since only selected clusters can allow intermediate tunneling. With an increase in H, the cluster algorithm is able to find more nodes within reach and hence reduce the overall cost of the distribution tree. However, beyond a certain point, ECT performs worse as nodes are absorbed that would be better optimized by being in separate clusters. Figure 4(b) shows the tunneling impact on groups of AF (Assured Forwarding) classes by the hops setting. At the point where the average number of tunnels for all classes is maximized (H = 3), the best performance (see Figure 4) is also achieved as well. Once the threshold of H = 3 is passed, the clusters contain too many nodes as is evidenced by the lower average tunneling value. In fact, even the lower classed AF PHBs dramatically lower their average tunneling value and begin to converge together. In actuality, it is

when the opposite effect (increased average tunneling between nodes) is seen, a more efficient multicast distribution tree is achieved. 1.25

2

DSMCast-Adaptive Ingress-only EBM (Cluster) EBM (Simple)

1.8

Average Tunnels per Egress Point

Normalized Bandwidth

1.2

AF (All) AF1x AF2x AF3x AF4x

1.15

1.1

1.05

1.6

1.4

1.2

1

1 0

2

4 6 8 ECT Hops Settings (H)

10

0

2

4 6 8 ECT Hops Settings (H)

10

Fig. 4. Effect of cluster hops setting - uniform distribution - (a) normalized (b) average tunnels (class-wise)

5

Related Work

Most of the works that we are aware of fail to address the issue of scalability (core statelessness). In [3], the authors examine support for multicasting in a DiffServ environment using traditional IP multicasting. The work identifies the NRS (Neglected Reservation Subtree) problem regarding resource reservation issues with grafting new branches onto the multicast tree. MBone & SGM: The closest work to EBM is the original MBone architecture. Our work differs from MBone in several key respects. First, our solution is specifically geared towards the DiffServ architecture and towards providing a transport functionality only. Whereas MBone is interested in end-to-end service, EBM focuses solely on the unique aspects of the DS domain. Second, due to the close coupling of EBM with DiffServ, EBM allows for unique functionality that cannot be offered with MBone. For example, rather than relying on other ISPs as would occur with MBone, a single ISP using EBM can force authentication for all multicast routing updates in the domain and manage the QoS impacts via the MB. Although EBM at its lowest level can essentially be thought of a specialized topology of MBone, it is the coupling of the MB, the uniqueness of the DiffServ topology, and the ECT algorithm that offer EBM its true distinction versus MBone. Beyond MBone, the other two similar works are Small Group Multicasting (SGM) [12] and DSMCast (DiffServ MultiCast) [11]. EBM differs significantly from SGM in that the trees need not be encapsulated in the header. DSMCast

represents our previous work that encapsulated the edge-to-edge multicast tree in the header and relied on stateless but multicast-aware hardware in the core.

6

Conclusions

In this paper, we proposed a new approach for DiffServ multicasting, Edge Based Multicasting (EBM) that relies on edge-based replication, tunneling, and a Multicast Broker (MB) entity to deliver a scalable multicast transport service across a single DiffServ domain. In addition, we proposed a novel algorithm, the Edge Cluster Tree (ECT), that captures the unique aspects of heterogeneous QoS management in a DiffServ domain. We believe that the EBM architecture has tremendous potential for expediting the wide scale deployment of multicasting as DiffServ is deployed. Our approach minimizes the impact of multicasting support by requiring only modifications to the edge routers and the inclusion of a Multicast Broker. Thus, we believe the EBM architecture represents a viable approach for joining the two technologies of DiffServ and multicasting.

References 1. K. Nichols, S. Blake, F. Baker, and D. Black, “Definition of the Differentiated Services field (DS Field) in the IPv4 and IPv6 headers,” IETF RFC 2474, Dec. 1998. 2. A. Striegel and G. Manimaran, “A survey of QoS multicasting issues,” IEEE Communications, pp. 82–87, June 2002. 3. R. Bless and K. Wehrle, “Group Communication in Differentiated Services Networks,” in Internet QoS for the Global Computing 2001 (IQ 2001), Workshop at CCGRID 2001, Brisbane, Australia, May 2001, pp. 618–625. 4. C. Perkins, “Minimal Encapsulation within IP,” IETF RFC 2004, Oct. 1996. 5. A. Striegel and G. Manimaran, “Dynamic DSCPs for heterogeneous QoS in DiffServ multicasting,” in Proc. of GLOBECOM, Taipei, Taiwan, Nov. 2002. 6. R. Sriram, G. Manimaran, and C. S. R. Murthy, “A rearrangeable algorithm for the construction of delay-constrained dynamic multicast trees,” IEEE/ACM Trans. Networking, pp. 514–529, Aug. 1999. 7. B. D. et. al, “An expedited forwarding PHB (per-hop behavior),” IETF RFC 3246, Mar. 2002. 8. J. Heinanen, F. Baker, W. Weiss, and J. Wroclawski, “Assured forwarding PHB group,” IETF RFC 2597, June 1999. 9. L. Kou, G. Markowsky, and L. Berman, “A fast algorithm for Steiner trees,” Acta Informatica, vol. 15, no. 2, pp. 141–145, 1981. 10. A. Striegel, A. Bouabdallah, H. Bettahar, and G. Manimaran, “EBM: Edge-based multicasting in DiffServ networks,” in Notre Dame CSE Technical Report, Apr. 2003. 11. A. Striegel and G. Manimaran, “A scalable approach to DiffServ multicasting,” in Proc. of ICC’2001, Helsinki, Finland, June 2001. 12. R. Boivie, “A new multicast scheme for small groups,” IBM Research Report RC21512, June 1999.