On Fundamental Issues in IP over WDM Multicast

Transcription

1 On Fundamental Issues in IP over WDM Multicast Xijun Zhangz, John Wei3, and Chunming Qiao4 21nterNetworking Systems, Lucent Technologies Inc., Westford, MA Phone: (978) Fax: (978) xijun.zhangqlucent.com 3Telcordia Technologies Inc. (formerly Bellcore), Red Bank, NJ Phone: (732) Fax: (732) Dept. of CSE, University at Buffalo (SUNY), Buffalo, NY Phone: (716) ext Fax: (716) Abstract As WDM technology matures, IP over WDM multicast becomes a new challenging topic. Supporting multicast at the WDM layer provides additional advantages, but also raises many new issues that do not exist in IP multicast. For example, the limitation on the light splitting capability of switches is one major difficulty in WDM multicast, and in addition, the limitations on both the wavelength conversion capability and optical buffer space may affect multicast routing as well. In this paper, we focus on the IP over WDM multicast routing problem, i.e. how to construct multicast trees at the WDM layer based on IP multicast routing protocols. More specifically, we study how label switched paths for optical label switching can be set up for multicast traffic. We propose two approaches, one without modification of existing IP multicast routing protocols, and the other with modification of existing IP multicast routing protocols. Keywords: IF over WDM, multicast routing, DVMRP, MOSPF, MPLS, optical label switching. I. INTRODUCTION The explosion of Internet traffic and the advance in the wavelength division multiplexing (WDM) optical networking technology make optical Internet desirable and possible [ 11. In addition, for connectionless networks, multi-protocol label switching (MPLS) is emerging as a new forwarding technology [5, 151. MPLS extends the traditional IP forwarding, and has many advantages such as simplified forwarding, efficient explicit routing, traffic engineering and QoS routing. MPLS is likely to be used as a unifying network management and traffic engineering protocol for a variety of transport systems. Optical label switching (OLS) [6] can be considered as the optical version of MPLS, and is likely to be suitable for optical Internet. Applications that require multicast services are becoming increasingly popular on the Internet. Many efforts have been given in the past to the design of IP multicast routing protocols, and an abundance of IP multicast routing protocols has been proposed and developed. The deployment of IP multicast has This research, done while Xijun Zhang was working at Telcordia Technologies Inc. (formerly Bellcore), was supported in part by DARPA under contract F C-0202, and in part by NSF under grant The views contained therein are those of the authors and should not be expressed otherwise. also been growing rapidly. A good example is MBone, which is a virtual network layered on top of the physical Internet to support IP multicast. As WDM networks emerge, supporting WDM multicast becomes attractive for it has the following advantages: (1) With the knowledge of the physical (optical layer) topology, which may not be the same as that seen at the upper electronic layer, more efficient multicast trees can be constructed; (2) With the inherent light splitting capability of some optical switches, it is more efficient to do light splitting than copying IP datagrams in electronics; (3) Performing multicast in optics provides consistent support of format and bit-rate transparencies across both unicast and multicast transmissions. Research on WDM multicast begun only recently. The main focus of the work in [lo, 16, 171 is that given the network topology and the multicast membership information, how to construct a wavelength-routed WDM multicast tree in order to lower the droppinghlocking probability, utilize the bandwidth more efficiently, and/or reduce the number of electronic components. In a wavelength routed multicast tree, a dedicated wavelength is needed for each of its branches (or links) as in circuit-switching. Hence, the tree is suitable only for multicast applications such as video distribution, which constantly require a high bandwidth for multicast traffic during a relatively long period of time. One problem which needs to be addressed is how the physical (i.e. WDM layer) topology information as well as multicast membership information is obtained and maintained. Other problems include how to support multicast applications generating bursty traffic by using transport mechanisms such as optical burst switching (OBS) [18], and in particular, how to interwork with IP multicast. In this paper, we will address some fundamental issues related to supporting IP multicast over WDM with the optical label switching technique, but leave out the performance evaluation and other detailed implementation issues. Our main focus is IP over WDM multicast routing in backbone networks. In other words, no LAN and host-router behavior is considered, and member, source and destination refer to routers in the context of this paper. In IP over WDM multicast using label switching, as illustrated in Figure 1, multicast label switched paths (LSPs) are set up first. Afterwards, only the optical labels carried by the IP datagrams (or bursts) need O/E conversions for /99/$10.00 Q 1999 IEEE 84

2 electronic processing, whereas the IP datagrams (or bursts) will be transmitted, copied (via light splitting) and switched in optics without going through O/E and WO conversions at intermediate nodes (switches). light splitting Figure 1: IP over WDM multicast using multicast LSPs. The rest of this paper is organized as follows. We will first briefly review the existing IP multicast routing protocols in Section 11, with more details on DVMRP [14] and MOSPF [ 111 since we will use them as examples later. We then will discuss IP multicast in MPLS, and IP over WDM multicast in Sections III and IV, respectively. In Section V, we will present the first approach in which no modification of IP multicast routing is allowed. The second approach, in which we assume modification of IP multicast routing, is presented in Section VI. We summarize this paper in Section VII. 11. IP MULTICAST ROUTING PROTOCOLS IP multicast routing protocols generally can be classified in two different ways. The densehparse mode classification depends on the expected distribution of multicast group members throughout the network, and the source-baseashared tree classification depends on the root of the multicast tree constructed. The most popular dense mode multicast routing protocols, DVMRP [14], PIM-DM [7], and MOSPF [ll], all use source-based tree, while the sparse mode multicast routing protocols, PIM-SM [8], and CBT [3, 41, all use shared tree (PIM-SM uses both). There are advantages to each type of distribution trees. In this paper, we will focus on source-based trees only. However, some of the ideas can also be used or adapted in the case of shared trees. For example, JOIN/QUIT behavior in a shared tree is similar to GRAFTFRLJNE behavior in a source-based tree if the root of shared tree (e.g. core in CBT or rendezvous point in PIM-SM) is considered as the source. In particular, we will use DVMRP and MOSPF as examples since PIM-DM is quite similar to DVMRP. In existing IP multicast routing protocols, either both the network topology and the multicast group membership are known or none of them is known. It is unlikely to have an efficient routing protocol with the knowledge of only one of the two. DVMRP is the first routing protocol developed to support IP multicast. It is the most implemented protocol and has been widely used on the MBone. DVMRP constructs a different distribution tree for each source and its destination group. Each tree is a reverse shortest path tree (the path from the source to each individual destination is the reverse of the shortest path from the destination to the source). DVMRP contains its own integrated unicast routing protocol and supports tunneling to 85 span nodes that are not multicast capable (i.e. with no DVMRP running). In DVMRF', IP multicast datagrams are broadcast from the source using Reverse Path Forwarding (RF'F) in the entire network. Branches are pruned if no downstream members exist. On pruned branches, new members can join the multicast group by sending explicit GRAFT messages upstream. Since IP multicast routers may be restarted at any time and lose the state information about existing prunes, it is necessary to limit the lifetime of a prune and periodically resume the flooding procedure. MOSPF is intended for use within a single routing domain, and is dependent on the use of OSPF as the accompanying unicast routing protocol. MOSPF has seen considerable deployment in private internets and limited deployment at the edges of MBone. In MOSPF, each router maintains up-to-date topology knowledge by exchanging link state information with others. In addition, multicast group membership is flooded among all the routers periodically. Upon receiving the first datagram in a session, each router computes a shortest path (in terms of a specific link state metric) tree using the Dijkstra's algorithm and stores the result for future forwarding of the multicast traffic IP MULTICAST IN MPLS In conventional IP forwarding, each router runs a network layer (layer 3) routing algorithm. As a packet travels through the network, each router analyzes the packet header, and chooses the next hop based on the header information and the result of running the routing algorithm. In MPLS [5, 151, short fixed-size labels are assigned to packets so that they can be forwarded at layer 2 (L2) based on the information carried in the labels without going through layer 3 (L3) routing. Label switched path (LSP) can be set up via either ordered or independent LSP control. MPLS facilitates the use of explicit routing without requiring that each IP packet carry the explicit route. Explicit routing may be useful to support policy routing and traffic engineering. Recently, IP multicast in MPLS is discussed in several Internet-Drafts [2,9, 12, 131. Multicast traffic flows that have long-duration and high-bandwidth (e.g. video streams) are prime candidates to be label switched with multicast LSPs. In general, the creation of an LSP for multicast traffic can be triggered by different events, which can be classified as one of three categories [ 131, namely, Request Driven, Topology Driven, and Traffic Driven. In Request Driven, each node needs to intercept the sending or receiving of control messages (e.g. multicast routing messages), then set up LSPs. In Topology Driven, each nodes maps a L3 tree, which is available in the Multicast Routing Table (MRT), to a L2 tree even if there is no traffic on the tree. In Traffic Driven, a L3 tree is mapped to a L2 tree only when data arrives on the tree. In some implementations of IP multicast protocols, a subset of MRT - with only entries corresponding to trees carrying data - can be found in the Multicast Forwarding Cache (MFC). When it experiences a cache miss, MFC can send a request to a multicast daemon, and the multicast daemon can provide the missing routing

3 information. The multicast daemon can also update MFC if there are changes to the route. MFC performs L3 measurements to determine when to time out its cache. If no traffic corresponding to an entry is received for a certain period, that entry is removed from MFC. When label switching is applied to a certain MFC entry, L3 will not see packets arriving anymore. To obtain a normal MFC behavior, the L3 counters of MFC need to be updated by L2 measurements on the LSPs. Since MFC is implemented as a common component (part of the kernel), it can be transparently used for any IP multicast routing protocol. Iv. IP OVER WDM MULTICAST ROUTING In this section, we discuss some unique characteristics of WDM networks which make supporting IP multicast at the WDM layer challenging. First, as mentioned earlier, when supporting IP multicast at the WDM layer, IP controllers and WDM switches may not have a one-to-one mapping. Even if they have a one-to-one mapping, the topologies seen at the IP and WDM layers could be different due to switch setup and existence of virtual switching topology. Secondly, switches with the splitting capability are expensive. In addition, splitting light causes power drop and crosstalk. Due to these reasons, there are limitations on the splitting capability in real networks. In sparse splitting, only a subset of switches is multicast capable, while in limited splitting, an input can only be split to limited number of outputs and only a subset of the input signals can be split simultaneously. Note that, hereafter, we consider drop and continue as a special case of limited splitting, and we assume that every switch can support this. Based on previous study [lo], we also note that it may not be necessary for all the switches to be multicast capable to support multicast efficiently. In IP multicast, multicast capable means having the multicast routing protocol running, and IP datagrams are only replicated when the paths to different routers diverge. At the WDM layer, multicast capable means enough light splitting capability, and optical packets may be split even when the paths to different routers do not diverge, i.e. it is possible to have multiple branches of the multicast tree on the same link as described later in Section V. Note that in MOSPF, it is allowed to mix multicast capable routers with non-multicast routers. However, non-delivery of multicast datagrams is possible even though there is a path to reach the destinations because non-multicast routers are not considered when constructing the multicast tree. At the WDM layer, even if a switch does not support light splitting, it has the same multicast protocol riinning as the other switches, and multicast traffic may have to be switched at this switch. There are two options for overcoming the above limitations on the splitting capability. One is to use O/E and E/O conversions, and make copies in the electronic domain, while the other is to avoid branching at switches that are not multicast capable. The design of WDM multicast routing protocol 86 should not rely on the first option to simplify the problem because this is contradictory to the concept of all-optical networking and OLS. However, one may use the first option as a backup in certain cases. For example, when the local node is one of the destinations and has to receive the data anyway, or when branching at other switches will consume much more bandwidth (or may be even blocked). In the next section, we will propose two approaches for the second option. Similar to the limitations on the splitting capability, there are several cases corresponding to no, sparse, limited and full wavelength conversion. Before a packet is forwarded, it has to be assigned a wavelength. Since there are tens of wavelengths on each outgoing fiber, scheduling has to be performed to find out which wavelength is available at what time. If no wavelength is available at the time the packet should be forwarded, the packet has to be either buffered for transmission at a later time (maybe on a different wavelength) or dropped. Wavelength conversion capability not only affects the blocking/dropping performance, but also affects multicast tree formation in certain cases as to be shown in an example in Section V. In WDM networks, optical buffer space is very limited while current IP multicast routing protocols are designed under the assumption that buffer space is unlimited (or very large). Buffer space limitation has a significant impact on the blocking/dropping probability. For multicast traffic, the buffer space limitation may also affect multicast routing (see Section V for an example). Partial failure will occur in case of congestion on any subset of downstream interfaces. How to deal with congestion (e.g. by rerouting around some congested branches or by using intelligent multicast routing algorithm to balance the traffic load on each link) is a challenging issue. Hereafter, we will focus on the routing problem when supporting IP multicast at the WDM layer assuming that only a subset of switches is multicast capable. For simplicity, we also assume that one and only one IP controller runs on top of each WDM switch (i.e. one-to-one mapping between IP controllers and WDM switches), and the topologies seen at both layers are identical. All the IP controllers run the same IP multicast routing protocol. Based on the study of IP multicast routing protocols and the above discussions, we propose two approaches: (1) without modification of existing IP multicast routing protocols; and (2) with modification of existing IP multicast routing protocols. In the next section, we present the first approach. The second approach will be presented in Section VI. v. AN APPROACH WITHOUT MODIFICATION OF EXISTING IP MULTICAST ROUTING PROTOCOLS In this section, we assume: (1) No modification should be made to the IP multicast routing protocol; (2) A multicast controller on each optical switch (OSW) controls the WDM layer multicast, and it knows the splitting capability of the local switch (see Figure 2); (3) Multicast controllers do not interpret

4 the routing control messages exchanged between peer IP controllers, but can learn the forwarding interfaces from MRT; (4) The membership information (local or global) known by an IP controller is also available to the corresponding multicast controller; IP controller multicast controller Figure 2: An optical label switching router. We also assume that a switch can have a wide range of splitting capability. The splitting capability is checked dynamically at the time the multicast tree is constructed. Since only a subset of the switches is multicast capable, and even if a node is multicast capable, it may have already reached its splitting capability as a result of supporting other multicast sessions, a special technique has to be used to avoid branching at switches that do not have enough multicast capability although the multicast tree constructed by IP controllers may use these switches as branching points. This can be explained using the following example. In Figure 3, A is the source, and B, C, D, E and F are members. Assume that the multicast tree diverges at node C and the forwarding entry desired at C is as follows, where FEC stands for forwarding equivalent class and G stands for the multicast group. Labelln FEC Label-Out Next Hop L1 (A,G) L3 F LA E. L1 I (A.GI 1 L3 1 F Interface 1 2 We define the following three new messages that can only be understood by multicast controllers and exchanged between peer multicast controllers: (1) REQUEST - used to set up a new LSP branch; (2) CUT - used to tear down a LSP branch; and (3) ACTIVE - used to tell downstream nodes the status of a multicast source.. 1 A. DVMRP as the IP multicast routing protocol When DVMRP is used at the IP layer, for those branches that cannot be supported, we have the following three options. 1) Parent-initiated UP setup The multicast controller at C, which is the parent of E, can send a REQUEST upstream to B to initiate LSP setup. A new branch will be added on link B-C. The triggers described in Section I11 can be used to set up the LSP from B to C (e.g. using Request Driven and ordered mode). The corresponding forwarding entry at B will be updated (i.e. a new outgoing interface is added and a different outgoing label is assigned). The REQUEST message should be acknowledged by sending REQACK back to C. Source $ REQACK REQUEST s, F Figure 3: Parent-initiated LSP setup. Note that on link B-C, there are two branches of the multicast tree, and they can be assigned either the same or different wavelengths. If the same wavelength is assigned (see Figure 4 (a)), congestion will occur every time an incoming packet arrives, and the packet on one of these two branches on link B-C has to be buffered (or rather delayed). If different wavelengths are assigned (see Figure 4 (b)), wavelength conversion is required (assuming only one fiber on each link). When no buffer is available for the former case, or no wavelength conversion capability is available for the latter case, simply let B split light is not enough to support two branches on B-C. This shows how the wavelength conversion capability and optical buffer space affect multicast routing. In this case, a new forwarding entry has to be built at B (instead of adding outgoing interface and label in the existing one), and the REQUEST needs to be forwarded towards the source along the reverse path. In the worst case, the source will have to unicast to C a separate copy using the LSPs for C to forward to E. Similarly, if B already reaches its splitting capability, the REQUEST is also forwarded upstream by B and handled in the same way. All the above is hidden from IP controllers. AqQ Source \ 0 C (a) same wavelength, requires buffer (b) without buffer, different wavelengths, requires wavelength conversion Figure 4: Both wavelength conversion and optical buffer space affect multicast routing. U C 87

5 2) Relative-assisted U P setup If E can be reached via an alternate path, say from D to E, a multicast LSP can be set up on D-E instead of C-E (see Figure 5). Since E-D is not (but E-C is) on the path from E to A, D is not the parent of E (according to the RPF rule) but only a relative. In DVMRP, a PRUNE message will be sent from E to D. However, since this is the only path for the multicast traffic to reach E, it must not be pruned. Unaware of the PRUNE message sent by the IP controller, the multicast controller at E sends a REQUEST to D to set up a LSP from D to E. In addition, the incoming data packets from the interface 1 of node E need to be redirected so that the IP controller at E thinks that the incoming data is from interface 2. This intelface swapping should be done by the multicast controller and hidden from the IP controller. source A REQUEST:' I..._.... F C Figure 5: Relative-assisted LSP setup., jreqack This option has some advantages. First, the total number of branches (or hops) on the multicast tree is at least one branch less than that would be needed when adding a new branch on B-C and relying on C to forward the multicast traffic to E. Comparing with the first option (also the third one to be described next), this bandwidth saving could be significant since the source may have to unicast to E using the first option, especially when there are many nodes like E. Second, the control overhead involved in this option is less than that involved in the first option. However, there may be other issues need to be considered. For example, if D leaves the group and sends PRUNE to B, the multicast controller at D has to send REQUEST to B to keep the LSP or set up new LSP on B-D in order to receive multicast traffic and forward to E. In addition, the MRT constructed by the IP controllers and the multicast LSPs established by the multicast controllers are not consistent. What could be the consequence of such inconsistency is an open issue. 3) Child-initiated LSP setup If there is no alternate path to reach E, or in other words, all the paths from the source to E have been disabled because the intermediate nodes do not have enough splitting capability, E (a child of C) has to explicitly join the multicast group (see Figure 6). In fact, even when D forwards multicast traffic to E, the multicast controller at E has the flexibility to either do an interface swapping or explicitly join. In order for E to join, E has to know where the source is. E can learn the location of the source when it receives L3 forwarded data from C before LSPs are set up on B-C and C-F, or when it receives data from D. We can also let the multicast controller at C send ACTIVE messages periodically to E for the current active multicast session based on L2 measurement. Note that this ACTIVE message may need to be forwarded downstream by E so that downstream members can learn about the source. F ACTIVE' - - Figure 6: Child-initiated LSP setup. In DVMRP, joining a group is done by sending the GRAFT message (by the IP controller). Since the multicast controller also knows that E is a member (but not aware of the GRAFT message), it will send a REQUEST message upstream to the multicast controller at C which then forwards the REQUEST to B. Similar to the first option, multicast traffic can reach E via the new branch added on B-C (and maybe other upstream new branches). Again, this is hidden from IP controllers. Note that when the multicast controller at C learns from the MRT that it has to support two downstream branches, it cannot tell whether this is the normal reverse path forwarding behavior or this is because of the reception of GRAFT from downstream members. If the multicast controller at E does not send the REQUEST, we will have to rely on C to generate the REQUEST whenever it cannot support all its downstream branches, as in the first option described earlier. For the first and third option, after a new branch is added on link B-C, the forwarding table at C will have two separate entries as follows. Label& I FEC I Label-Out I NextHop I Interface L1 I (A,G) I L3 I F I 1 If E leaves the group later, the new branch added on link B-C as well as the second forwarding entry at C has to be removed. The IP controller at E sends a PRUNE message upstream to C, and the MRT at C will be modified accordingly. Then, the multicast controller at C can send a CUT message to B to tear down the LSP on B-C that is used for forwarding data to E. If there are other upstream branches added (e.g. due to not enough splitting capability at B), B will forward the CUT message upstream. Note that there is no need for E to send a CUT message to C. For the second option, after a LSP is set up on D-E, the forwarding entry at D will contain the downstream interface to E. When E leaves the group, the IP controller at E will send a PRUNE to C, while the multicast controller will have to send a CUT message to D. Later on, if any forwarded data reaches E, the normal prune behavior is resumed. B. MOSPF as the IP multicast routing protocol In this case, every node has the full membership information. The multicast trees constructed by different nodes 88

6 are identical, and every member is reached via one and only one path. Assume that link C-E is (and link D-E is not) on the multicast tree calculated. When the multicast controller at C learns from the MRT or L3 forwarding behavior that E is a downstream member, it knows that C-E is the only path to reach E (D will not forward the multicast traffic to E), and it will send a REQUEST upstream to B. After that, everything is similar to the first option described earlier when DVMRP is the IP multicast routing protocol. When E leaves the group, new membership information will be received at C, and the corresponding MRT entry for this group will be removed. When a new multicast datagram comes, the IP controller at C will recalculate the multicast tree and build a new MRT entry accordingly. VI. AN APPROACH WITH MODIFICATION OF EXISTING IP MULTICAST ROUTING PROTOCOLS In this section, we present the second approach to support IP over WDM multicast, which differs from the first approach presented in Section V in that IP multicast routing protocols are modified to take the splitting capability of switches into consideration. Again, we use DVMRP and MOSPF as examples. A. DVMRP as the IP multicast routing protocol Assume that the splitting capability of the local switch is known at each IP controller. By adding the knowledge of local switch s splitting capability, each IP controller is able to construct only MRT entries that can be supported by the underlying switch. Using Figure 3 as an example again, the forwarding table at C will contain only the enby to F initially. Since it is allowed to modify the multicast routing protocol, there is no need to have multicast-controllers for setting up LSPs hidden from IP controllers. In addition, GRAFT and PRUNE messages can be modified to include the functionality of REQUEST and CUT so that REQUEST and CUT are no longer needed. More specifically, we can add and set certain fields in GRAFT so that it can have the following two different meanings: (1) a downstream member joining the group (not necessarily involving LSP setups); and (2) a downstream member asking for one more LSP branch on a link (there may be one or more LSP branches on the link already), e.g. C asks B for a new branch on B-C. Similarly, PRUNE can be modified to have the exact reverse effect. In the following discussion, we assume that this modification is made, and hence will use GRAFT and PRUNE only. Similar to the first approach, we have three options. First, when a LSP needs to be set up on B-C, C can send GRAFT to B asking for a new LSP branch. Second, we can also modify the IP multicast pruning policy so that a node does not prune a branch until it receives the multicast traffic of the same session along a better path. In this way, when E receives data from D, no interface swapping is necessary. E does not send PRUNE to D until it receives data from C. The IP controller at E knows that data is from D and D-E is on the current best path for the multicast traffic to reach E. Later, if F sends PRUNE to C, C will forward the data to E. After E receives the data from C, it can send PRUNE to D since C-E is a better path. Third, C can send ACTIVE message to E so that E can learn about the source and send GRAFT message to C. Since the IP controller at C knows that the splitting capability of the local switch is not enough, it will forward the GRAFT towards the source. For the first and third option, when E leaves the group, PRUNE is sent to C, and forwarded by C to B. On B-C, there will still be one LSP branch left for forwarding data to C and F, while on C-E, no LSP is left and no data will be forwarded. For the second option, when E leaves the group, PRUNE will be sent by the IP controller to the current upstream node (D or C) and handled in the same way as that used in DVMRP. 89 B. MOSPF as the IP multicast routing protocol If MOSPF is the IP multicast routing protocol, modifications can be made so that not only the topology and the group membership but also the locations of all multicast capable switches (MCSWs) are known by every IP controller. Then, a heuristic tree formation algorithm can be used to construct a multicast tree that avoids branching at switches that are not multicast capable. Previously proposed multicast tree formation algorithms assumed almost exclusively that any node can be a branching point of a multicast tree, and can have as many children as needed, or in other words, every node is multicast capable. This is true when packets are copied (or transmitted multiple times) in the electronic domain. However, as described in Section IV, it may not be true when optical packet is copied via light splitting which may not be supported by all the nodes. Even if a node does support light splitting, it is possible that at the time a specific multicast tree is constructed, the node can only support some of the downstream branches due to its limited splitting capability, or it has reached its splitting capability as a result of supporting other multicast trees. We have proposed four new multicast tree formation algorithms, namely, Re-route to Source, Re-route to Any, Member First and Member Only, taking into consideration of the limitations on the light splitting capability of switches [19]. Note that the only inputs required in these algorithms are the network topology, the membership information and the distribution of MCSWs. Since the first two required inputs are already available in MOSPF, by modifying MOSPF and adding the third input, all the above four algorithms can be used in MOSPF to construct multicast trees that can be supported at the WDM layer. Note that, modifying IP multicast routing protocol increases the efficiency and reduces the redundancy and complexity since no multicast controller is needed and nothing is hidden from IP controllers. In addition, with the distribution of MCSWs, multicast tree construction in MOSPF can be more efficient. On the other hand, the approach is not attractive for networks that have already deployed the existing IP multicast routing

7 protocols. VII. SUMMARY IP over WDM multicast is a new challenging topic that will have a profound impact on the future optical Internet design. In this paper, we have addressed routing issues involved in supporting IP multicast at the WDM layer using optical label switching. Two routing approaches have been proposed along with possible variations and options. The first approach does not modify the existing IP multicast routing protocols, but requires additional functional components such as multicast controllers to hide WDM multicast routing from IP controllers. On the other hand, the second approach has a lower control overhead and may result in more efficient LSPs, but requires modification of the IP multicast routing protocols, and hence, be problematic in practice. Which approach to pursue is still a debatable issue. Further studies on detailed protocol implementation issues as well as the performance evaluation of the protocols are needed. VIII. REFERENCES [ [2] A. Acharya, E Griffoul, and E Ansari. IP multicast support in MPLS networks, IETF draft, draft-acharyaipsofacto-mpls-mcast-0o.txt. February [3] A. Ballardie. Core based trees (CBT) multicast routing architecture, RFC September [4] A. Ballardie. Core based trees (CBT version 2) multicast routing - protocol specificatiop, RFC September [5] R. Callon, P. Doolan, N. Feldman, A. Fredette, G. Swallow, and A. Viswanathan. A framework for multiprotocol label switching, IETF draft, draft-ietf-mplsframework-02.txt. November [6] G. K. Chang. Optical label switching, dyncorp-is.com/darpa/meetings/ngi98oct/agenda.html. [7] S. Deering, D. Estrin, D. Farinacci, V. Jacobson, A. Helmy, D. Meyer, and L. Mei. Protocol independent multicast version 2 dense mode specification. November [8] D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. Deering, M. Handley, V. Jacobson, C. Liu, P. Sharma, and L. Wei. Protocol independent multicast - sparse mode (PIM-SM): Protocol specification, RFC June [9] D. Farinacci and Y. Rekhter. Multicast label binding and distribution using PIM, IETF draft, draft-farinaccimulticast-tggsw-01.txt. November [ 101 R. Malli, X. Zhang, and C. Qiao. Benefits of multicasting in all-optical networks: In SPIE Proceedings, All Optical Networking, pages , November [ 111 J. Moy. Multicast extensions to OSPF, RFC March [12] D. Ooms, W. Livens, and B. Sales. MPLS for PIM-SM, IETF draft, draft-ooms-mpls-pimsm-00.txt. November [13] D. Ooms, W. Livens, B. Sales, and M. Ramalho. Framework for IP multicast in MPLS, IETF draft, draftooms-mpls-multicast-01.txt. February [ 141 T. Pusateri. Distance vector routing protocol, IETF draft, draft-ietf-idmr-dvmrpp-v3-03.txt. September [I~I E. C. R ~ A. viswanathan, ~ ~ ~ and, R. callon. ~~ltiprotocol label switching architecture, IETF draft, draftietf-mpls-arch-02.txt. July L. H. SAasrabuddhe and B. ~ ~ h Light- ~ ~ j ~ ~ trees: Optical multicasting for improved performance in wavelength-routed networks. IEEE Communications Magazine, 37(2):67-73, February G. shin and M. ~ ~ i Multicast ~ ~ routing ~ l and ~. wavelength assignment in wide-area networks. In SPIE Proceedings, All Optical Networking, pages , November [18] M. Yo0 and C. Qiao. Optical burst switching (OBS) - a new paradigm for an optical Internet. Journal of High Speed Networks (JHSN), 8( 1):69-84,1999. [19] X. Zhang, J. Wei, and C. Qiao. Constrained multicast routing in WDM networks with sparse light splitting. Technical Report 99-07, CSE Dept., SUNY at Bufalo, July 90