Topology constrained label switching for multicast

TOPOLOGY CONSTRAINED LABEL SWITCHING FOR MULTICAST ROUTING I. C. Arkut ([email protected]) Girne American University Girne, North Cyprus

A. Basak ([email protected]) European University of Lefke Lefke, North Cyprus

R.C. Arkut ([email protected]) Oksijen Teknoloji Istanbul, Turkey

Abstract In this paper we have further elaborated MPLS multicasting under the specific graph (graceful) labeling with the use of specific multicast tree topology called caterpillar which is next higher topological structure other than the path; that is a central concept in the IP unicast routing. The use of caterpillar as the multicast tree has been analyzed and compared with the other tree topologies under the new measure of the multicast network metric. We have applied graceful label distributions to the links of the spanning caterpillars associated to the autonomous sub-networks (AN) that involved in the multicasting. The labeling algorithm proposed uniquely assigns link labels based on the node numbering which in turn enables to give a sharp estimate to the time-to-live parameter, optimal selection of RP (rendezvous points) of multicast caterpillar topology to nodes in the ANs by transmitting of ‘graceful code’ in the form of sequence of (n-2) node numbers. The graceful code for the caterpillar has revealed an efficient method (G-trace) of the reconstruction of multicast tree topology which in turn to be used for maintability and for the other purposes in the management site. Key words- Multicast, MPLS, label switching, tree topology discovery, forwarding state 1. Introduction IP multicasting initiated by the Mbone [23,26], Mhealth [24] have attracted considerable interests from the industry since possible many applications of distributing information through the internet in a one-to-many or many-to-many fashion [25]. On the other hand IETF has not yet completely finalized the related protocols mainly due to complexity (scalability) and maintability issues of the multicast tree in the IP multicasting [1-7,26]. The situation is not clear at all in the QoS assured MPLS (Multi Protocol Label Switching) multicasting routing except a few propositions and results [10,12,16]. The evolution of the multicast techniques were given in [27]. In this paper we have further elaborated MPLS multicasting under the specific graph (graceful) labeling with the use of specific multicast tree topology called caterpillar which is the next higher topological structure other than the path that is a central concept in the IP unicast routing. The use of caterpillar as the multicast

tree has been analyzed and compared with the other tree topologies under the new measure of the multicast network metric. We have applied graceful label distributions to the links of the spanning caterpillars associated to the autonomous sub-networks (AN) that involved in the multicasting. The labeling algorithm proposed uniquely assigns link labels based on the node numbering which in turn enables to give a sharp estimate to the time-to-live parameter, optimal selection of RP (rendezvous points) of multicast caterpillar topology to nodes in the ANs by transmitting of ‘graceful code’ in the form of sequence of (n-2) node numbers. The plan of the paper is the following: Section 2 gives an overview on the multicasting on spanning trees and the related protocols. In Section 3 for the sake of completeness we have given the graceful label numbering of the spanning caterpillars with special reference to the TTL (Time-To-Live) values and RP (Rendezvous Points). We have also given the application of the numbering algorithm for the network consisted of several subnetworks together with the application of the graceful codes to inform the topology of the spanning caterpillars among the backbone path. The graceful code for the caterpillar has revealed an efficient method (Gtrace) of the re-construction of multicast tree topology which in turn to be used for maintability and for the other purposes in the management site.

2. Background 2.1. Spanning Trees For efficient transmission, Designated Routers construct a spanning tree that connects all members of an IP Multicast group (see Fig. 1). #

#

#

# #

#

#

# #

# # #

#

$ 6XEQHW

#

# #

# #

#

#

6SDQQLQJ 7UHH URRWHG DW 05

Fig. 1 - Spanning Trees

Proceedings of the Eighth IEEE International Symposium on Computers and Communication (ISCC’03) 1530-1346/03 $17.00 © 2003 IEEE

# #

A spanning tree has just enough connectivity so that there is only one path between every pair of routers, and it is loop-free. If each router knows which of its lines belong to the spanning tree, it can copy an incoming multicast datagram onto all of its outgoing branches, generating only the minimum needed number of copies. Finding an specific spanning tree (such as Steiner tree [15]) satisfying one or several network metrics on its nodes or links efficiently [10], [13] was the main problem from the point of scalability etc. [10]-[12]. For example in [16] the average number of joint hops in a shortest path multicast tree from a root to m arbitrary chosen group members nodes is studied. Messages are replicated only when the tree branches, thus minimizing the number of copies of the messages that are transmitted through the network. Since multicast groups are dynamic, with members joining or leaving a group at any time, the spanning tree must be dynamically updated. Branches in which no listeners exist must be discarded (pruned). A router selects a spanning tree based on the network layer source address of a multicast packet, and prunes that spanning tree based on the network layer destination address. The spanning algorithm used and how multicast routers interact depends on the objectives of the routing protocol. Several IP Multicast routing algorithms and protocols have been designed with different objectives and features.

2.2 Basic Approaches to IP Multicast Routing IP Multicast routing algorithms and protocols generally follow one of two basic approaches, depending on the distribution of multicast group members throughout the network. The first approach is based on the assumption that the multicast group members are densely distributed throughout the network and bandwidth is plentiful, i.e., almost all hosts on the network belong to the group. Socalled “dense-mode” multicast routing protocols rely on periodic flooding of the network with multicast traffic to set up and maintain the spanning tree. Dense-mode routing protocols include Distance Vector Multicast Routing Protocol (DVMRP), Multicast Open Shortest Path First (MOSPF), and Protocol-Independent Multicast-Dense Mode (PIM-DM). The second approach to multicast routing is based on the assumption that the multicast group members are sparsely distributed throughout the network and bandwidth is not necessarily widely available, for example across many regions of the Internet. It is important to note that sparse-mode does not imply that the group has a few members, just that they are widely dispersed. In this case, flooding would unnecessarily waste network bandwidth and hence could cause serious performance problems. Hence, “sparse-mode”' multicast routing protocols must rely on more selective techniques to set up and maintain multicast trees. Sparse-mode

routing protocols include Core Based Trees (CBT) and Protocol-Independent Multicast-Sparse Mode (PIM-SM).

2.3 Other Protocols which use IP Multicast There are a number of exciting protocols presently being developed by the Internet community, IETF working groups and industry vendors to support new applications of IP Multicast. Only a brief introduction is possible here. RTP, the Real-Time Transport Protocol, provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data, over multicast or unicast network services. RSVP, the ReSerVation Protocol, enhances the current Internet architecture with support requests for a specific quality of service (QoS) from the network for particular data streams or flows. RTSP, the Real-Time Streaming Protocol is an application-level protocol for control over the delivery of data with realtime properties to enable controlled, on-demand delivery of real-time data, such as audio and video. Reliable multicast protocols are being developed to overcome the limitations of unreliable multicast datagram delivery and expand the uses of IP Multicast.

2.4 Multicast Metric for Multicast Trees In general the primary benefit of using multicast is its scalability in terms of required resources per receiver. Since multicast groups are loosely coupled, the server does not necessarily have knowledge of individual receivers and consequently does not need to maintain a logical connection for each new customer. Based on this and other motivations in [28] a network metric for multicasting has been defined which its value depends on the network topology. The metric can be defined as a function of the ratio of multicast hops (links) to unicast hops: ∆ = 1−

multicast − hops unicast − hops

The multicast metric will be a fraction in the range 0 ≤ ∆ ≤ 1 . When ∆ = 0 unicast will do the job multicast. On the otherhand as the value approaches one, the benefit of using multicast increases. As our multicast tree is always a caterpillar tree that consists of a backbone path and links attached to the backbone nodes, for a given AN with n nodes the length of the backbone path of the multicast caterpillar would be dominate on the value of the metric ∆ . That is if length of the backbone path is order of n than ∆ ≈ 0, on the other hand as the length of the backbone path decreases the value of the multicast metric approaches to ∆ ≈ 1. In the first case the topology of the multicast tree looks like an Hamiltoian path in the AN, where Hamiltoian path is a path which traverses all the nodes in the AN only once. This unicast-like covering all nodes may be desirable in


case of the subnetwork is consisted of all optical nodes since reduces complexity of the internal structure of the nodes. On the other hand the benefits of the short backbone path of the multicast spanning caterpillar is appeartent from the point overall small avearge link delay. The two cases is illustrated in Fig. 2(a) and (b) so that in Fig.2(a) a multicast tree is formed in the form of a hamilton path hence with ∆ =0 while in Fig. 2(b) a shorter backbone path (more dense caterpillar) is used which results in the value of the multicast metric as ∆=0.36.

$ D

$ E

Fig. 2 Multicast metric in the extreme cases: (a) ∆=0, (b) ∆=0.36

2.5 The Role of Time-To-Live (TTL) Each IP Multicast packet uses the time-to-live (TTL) field of the IP header as a scope-limiting parameter. The TTL field controls the number of hops that a IP Multicast packet is allowed to propagate. Each time a router forwards a packet, its TTL is decremented. A multicast packet whose TTL has expired (is 0) is dropped, without an error notification to the sender. This mechanism prevents messages from needless transmission to regions of the worldwide Internet that lie beyond the subnets containing the multicast group members. A local network multicast reaches all immediatelyneighboring members of the destination host group (the IP TTL is 1 by default). If a multicast datagram has a TTL greater than 1, the multicast router(s) attached to the local network take responsibility for internetwork forwarding. The datagram is forwarded to other networks that have members of the destination group. On those other member networks that are reachable within the IP time-to-live, an attached multicast router completes delivery by transmitting the datagram as a local multicast. TTL thresholds in multicast routers prevent datagrams with less than a certain TTL from traversing certain subnets. This can provide a convenient mechanism for confining multicast traffic to within campus or enterprise networks. Several standard settings for TTL are specified for the MBONE: 1 for local net, 15 for site, 63 for region and 127 for world. In the case of multicast packet whose TTL has expired is simply dropped; no ICMP (or IGMP) packet is sent backward. Since we know the size of each AN and by establishing the spanning caterpillar covering all the nodes of the AN

we can exactly find the value of the TTL for each AN at the source node as: TTL= |the length of the backbone path of the spanning caterpillar| +1

A more detailed studies of the exact selection of the TTL value based on the label numbering of the spanning caterpillars will be given elsewhere.

3. Graceful Label Numbering Algorithm 3.1 The Algorithm Definition 3.1. A tree T is called a caterpillar if it contains a dominating (backbone) path P such that T − V ( P ) contains no links. A caterpillar is called spanning caterpillar, denoted by Ts if it has of all n nodes of the network N. Construction of a spanning caterpillar which will carry multicast packets from the source node S will be based on a selected single network metric for its backbone path P of Ts . It is well known that path computation algorithms (e.g., OSPF) with a single metric such as delay and/or hop-count are widely used in most current IP networks. For purposes herein (with local selection with respect to the links connected to a node), the network metric is chosen as the minimum delay δ for each backbone link of the spanning caterpillar. Note that the selection of minimum delay δ at the current node in the MPLS graceful numbering is a concave network function at the node nk i.e., δ ( n k , n ) = min{ δ ( n k , n j ) | ( n k , n j ) ∈ N , j = 1 , 2 ,..., p } i

For the sake of completeness, graceful numbering of caterpillars (string) trees [17] is first repeated here and then the formulation applied to the case multicast MPLS routing in a given network N. Let V(T)={v1,v2,…,vn} be the set of nodes of caterpillar tree T of network N. Let Li also stand for the nodes of hop-level Li ,1 ≤ i ≤ k < n. Let N = {1 , 2 , 3 ,..., n } be the set of positive integers. Let v p (i ) denote the node labeled by i ∈ N . By N ( Li ) it is denoted the integers subset formed from N by deleting all integers which have been used in labeling the nodes of level Li . Algorithm B. Graceful numbering of a caterpillar Step 1. Label the source node S which is the first node of the backbone path of the caterpilar by the integer 1. Remove the integer 1 from the set N and call it N ( L1 ). Step 2. Consider | L2 | nodes of the hop-level L2 . Take up the | L2 | largest integers from N ( L1 ) . Number the 2

node v | L 2| (the node on the backbone path) with the minimum of these integers. Next number the remaining nodes of L2 arbitrarily with the other integers. Remove


Step 3. Consider the | L3 | nodes of the hop-level L3 .

the nodes of the shortest path. However in this case, in order to assure that the resulting multicast spanning tree is a caterpillar, the neighborhood of every backbone node along the path has to be searched locally.

Take up the | L3 | smallest integers from N ( L1 ∪ L2 ).

3.2. Link Labeling and Placement of the RPs

the integers used from N ( L1 ) and call the resulting set

N ( L1 ∪ L2 ).

3

Number the node v | L3 | (the node on the backbone path) with the maximum of these integers. The remaining nodes of L3 are then arbitrarily numbered by the other integers. Step 4. Repeat the similar process of numbering the nodes in other levels, alternatingly, first like Step 2 and then like Step 3. Step 5. If all nodes of the caterpillar T have been numbered, then terminate the algorithm. In the above algorithm the induced link labels are taken as the absolute node numbers differences among the adjacent nodes which are distinct integers from the set N={1,2,…,n-1} [17] however the algorithm can equally be applied to m, m@

> @ > @

F 6103EDVHG DSSURDFK

297, . 0

4XHULHU

E

*UDFHIXO &RGH

> @ > @

G *WUDFH *UDFHIX O 1X PEHULQJ

Fig. 5. Comparison of topology discovery techniques

References [1] E. Rosen, A. Viswanathan, A. Callon, ‘Multiprotocol Label Switching Architecture’, draft-ietf-mpls-arch-05.txt, April 1999. [2] S. Deering, D. Estrin, D. Farinacci, V. Jacobson, A. Helmy, D. Meyer, L. Wei, ‘Protocol Independent Multicast Version 2 Dense Mode Specification’, draft-ietf-idmr-pim-dm-05.txt, May 1997. [3] D. Waitzman, C. Partridge, ‘Distance Vector Multicast Routing Protocol’, RFC 1075, November 1988. [4] D. Farinacci, Y. Rekhter, ‘Multicast Label Binding and Distribution using PIM’, draft-farinacci-multicast-tagsw-01.txt, November 1998.

[5] A. Acharya, F. Griffoul, F. Ansari,’IP Multicast Support in MPLS Networks’, draft-acharya-ipsofacto-mpls-00.txt, February 1999. [6] D. Ooms, W. Livens, B. Sales, M. Ramahlo, ‘Framework for IP Multicast in MPLS’, draft-ooms-mpls-multicast-01.txt, February 1999. [7] D. Ooms, W. Livens, B. Sales,’MPLS for PIM-SM’, draft-oomsmpls-pimsm-00.txt, November 1998. [8] R.C. Chalmers and K.C. Almeroth, “Developing a multicast metric”,Proc. of IEEE, Globecom2000, San Fransisco, Calif., December 2000. [9] A. Acharya, F. Griffoul, F. Ansari, ‘IP Multicast Support in MPLS’, preprint. [10] F. Kuipers, P. Van Mieghem,’MAMCRA: A Constrained-Based Multicast Routing Algorithm’, submitted to Computer Communications, 2001. [11] S. Chen and J. Crowcroft,’Building Shared Trees Using a One-toMany Joining Mechanism’, Computer Communication Review, pp.511, January 1997. [12] S. Chen, K. Nahrstedt and Y. Shavitt, ‘A QoS-Aware Multicast Routing Protocol’, INFOCOM 2000. [13] M.R. Garey and D.S. Johnson, ‘Computers and Intractability, A Guide to the Theory of NP-Completeness’, Freeman, San Francisco, 1979. [14] C. Huitema, ‘Routing in the Internet’, Prentice Hall 2000. [15] F.K. Hwang, D.S. Richards, P. Winter,’The Steiner Tree Problem’, North-Holland,1985. [16] P. Van Mieghem, G. Hooghiemstra, R. Van der Hofstad, ‘On the Efficiency of Multicast”, [17] I. Cahit and R. Cahit, ‘On the Graceful Numbering of Spanning Trees’, Information Processing Letters, 3(4), March 1975, pp. 115-118. [18] I. C. Arkut, R.C. Arkut, and N. Ghani,’Graceful Label Numbering in Optical MPLS Networks’, Opticomm 2000, (I. Ghlamtac, Editor), Proc. of SPIE Vol.4233, 22-26 October 2000, Richardson, Texas. [20] I.C. Arkut and R.C. Arkut, ‘Generalizied Label Numbering for GMPLS in WDM Networks’, preprint. [21] N. Deo, P. Micikevicius, ‘A New Encoding for Labeled Trees Employing a Stack and a Queue’, Bulletin of ICA, to appear. [22] P. Micikevicius, ‘Encoding Gracefully-Labeled Trees’, to appear. [23] N. Deo, P. Micikevicius, ‘Prüfer-Like Tree Codes: Their Properties and Parallel Computation’, Invited Talk, FH80 Conference, Illinois Institute of Technology, Illinois, November 2, 2001. [24] H. Eriksson, ‘The Multicast Backbone’, Communications of the ACM, vol.8,pp. S4-60,1994. [25] D. Makofske, and K. Almeroth, ‘Mhealth-Real-Time Multicast Tree Health Monitoring Tool’, August 1998, http://imj.ucsb.edu/mhealth/ [26] http://www.multicasttech.com [27] http://www.ietf.org/html.charters/mboned-charter.html [28] K.C. Almeroth, ‘The Evolution of Multicast: From the Mbone to Inter-Domain Multicast to Internet2 Deployment’, IEEE Network (Special Issue on Multicasting), Jan./Feb. 2000. [29] W. Fenner and S. Casner, ‘A “traceroute” Facility for IP Multicast’, IETF, , Work in Progress. [30] K. Saraç and K.C. Almeroth, ‘Tracetree: A Scalable Mechanism to Discover Multicast Tree Topologies in the Network’, submitted to ACM/IEEE Transactions on Networking. [31] D. Makofske and K. Almeroth, ‘Mhealth-Real-Time Multicast Tree Health Monitoring Tool’, August 1998, available from http://imj.ucsb.edu/mhealth . [32] K. Saraç and K. Almeroth, ‘Supporting multicast deployment efforts: A survey of tools for multicast monitoring’, J. of High Speed Networks, vol.9, no. 3,4, pp.191-211, 2000. [33] K. Saraç and K.C. Almeroth, ‘Comparison of Topology Scalable Techniques for Discovering Multicast Tree Topology’, to appear. [34] B. Cain, S. Deering, B. Fenner, J. Kouvelas, A. Thyagarajan, ‘Internet Group Management Protocol, Version 3’, , 2002.
