CA2258129A1 - Ip multicast over routed atm network using lane - Google Patents
Ip multicast over routed atm network using lane Download PDFInfo
- Publication number
- CA2258129A1 CA2258129A1 CA002258129A CA2258129A CA2258129A1 CA 2258129 A1 CA2258129 A1 CA 2258129A1 CA 002258129 A CA002258129 A CA 002258129A CA 2258129 A CA2258129 A CA 2258129A CA 2258129 A1 CA2258129 A1 CA 2258129A1
- Authority
- CA
- Canada
- Prior art keywords
- multicast
- data packet
- address
- router
- subnet
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/02—Details
- H04L12/16—Arrangements for providing special services to substations
- H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
- H04L12/1886—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast with traffic restrictions for efficiency improvement, e.g. involving subnets or subdomains
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/46—Interconnection of networks
- H04L12/4604—LAN interconnection over a backbone network, e.g. Internet, Frame Relay
- H04L12/4608—LAN interconnection over ATM networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/54—Store-and-forward switching systems
- H04L12/56—Packet switching systems
- H04L12/5601—Transfer mode dependent, e.g. ATM
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04Q—SELECTING
- H04Q11/00—Selecting arrangements for multiplex systems
- H04Q11/04—Selecting arrangements for multiplex systems for time-division multiplexing
- H04Q11/0428—Integrated services digital network, i.e. systems for transmission of different types of digitised signals, e.g. speech, data, telecentral, television signals
- H04Q11/0478—Provisions for broadband connections
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/54—Store-and-forward switching systems
- H04L12/56—Packet switching systems
- H04L12/5601—Transfer mode dependent, e.g. ATM
- H04L2012/5614—User Network Interface
- H04L2012/5615—Network termination, e.g. NT1, NT2, PBX
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/54—Store-and-forward switching systems
- H04L12/56—Packet switching systems
- H04L12/5601—Transfer mode dependent, e.g. ATM
- H04L2012/5614—User Network Interface
- H04L2012/5617—Virtual LANs; Emulation of LANs
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/54—Store-and-forward switching systems
- H04L12/56—Packet switching systems
- H04L12/5601—Transfer mode dependent, e.g. ATM
- H04L2012/5619—Network Node Interface, e.g. tandem connections, transit switching
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/54—Store-and-forward switching systems
- H04L12/56—Packet switching systems
- H04L12/5601—Transfer mode dependent, e.g. ATM
- H04L2012/5638—Services, e.g. multimedia, GOS, QOS
- H04L2012/564—Connection-oriented
- H04L2012/5642—Multicast/broadcast/point-multipoint, e.g. VOD
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/54—Store-and-forward switching systems
- H04L12/56—Packet switching systems
- H04L12/5601—Transfer mode dependent, e.g. ATM
- H04L2012/5638—Services, e.g. multimedia, GOS, QOS
- H04L2012/5645—Connectionless
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/54—Store-and-forward switching systems
- H04L12/56—Packet switching systems
- H04L12/5601—Transfer mode dependent, e.g. ATM
- H04L2012/5638—Services, e.g. multimedia, GOS, QOS
- H04L2012/5665—Interaction of ATM with other protocols
- H04L2012/5667—IP over ATM
Abstract
A method and a system for forwarding multicast data packets across a plurality of telecommunications subnets interconnected by routers in which a data packet is received within a subnet of the plurality of telecommunications subnets. When the data packet is a multicast data packet, a multicast IP address for the multicast data packet is determined. A multicast forwarding database is accessed for determining a LAN Emulation Client associated with the multicast IP address, and a Broadcast Unknown Server associated with the multicast IP address for the multicast data packet is determined. The multicast data packet is sent to the Broadcast Unknown Server associated with the multicast IP address for the multicast data packet through the LAN Emulation Client using a point-to-point connection. The Broadcast Unknown Server sends the multicast data packet inter-subnet to each router associated with the multicast IP address for the multicast data packet using a point-to-multipoint connection, with at least one multicast host being connected to a subnet that is different from the subnet in which the multicast data packet was received.
Description
IP MUI,TICAST OVER ROUTED ATM NETWORK USING LANE
BACKGROUND OF THE INVENTION
1. Field of the Invention The present invention relates to the field of telecommunications. More particularly, the present invention relates to a method and a system for routing S Internet Protocol (IP) multicast traffic over Asynchronous Transfer Mode (ATM) networks.
BACKGROUND OF THE INVENTION
1. Field of the Invention The present invention relates to the field of telecommunications. More particularly, the present invention relates to a method and a system for routing S Internet Protocol (IP) multicast traffic over Asynchronous Transfer Mode (ATM) networks.
2. D~ lion of the Related Art Many applications used on the Internet have multiple sources, or 10 senders, and hosts, or receivers, that participate, or interact, with each other.
Previously, conventional unicast techniques were used for sending the same data packet to each host of a multicast group over a circuit that was specifically established between a source and the host. A conventional unicast approach for multicasting traffic, however, is wasteful in terms of both bandwidth and circuit resources.
To overcome the drawbacks of using unicast techniques for multicast traffic, techniques and protocols have been developed so that a multicast data packet is sent along a predetermined route of routers, or switches, and replicated at a point _ _ .. .... .... ... ... .. .
CA 02258129 1998-12-lo closest to a dçstin~tion host, thereby reducing the amount of multicast traffic. For example, a number of routing protocols have been developed for creating distribution routes between a source and the hosts of a multicast group. Routers and end stations have become "multicast aware" by using multicast protocols such as the Distance S Vector Multicast Routing Protocol (DVMRP), the Multicast Open Shortest Path First (MOSPF) protocol and Protocol-Independent Multicast (PIM).
The DVMRP protocol is widely used in the Multicast Backbone (MBONE) and generates a separate distribution tree for each respective source and destination host group. The distribution tree, also referred to as a sp~nning tree, 10 provides the shortest path from a source to each host in a multicast group. A
sp~nning tree is constructed for a multicast group by the source initially bro~lc~cting, or sending, a message to an a~j~cent router that is prop~g~tPli to all other routers in the network so that the message reaches each participating host. The message effectively registers the multicast group with reach router receiving the message. If 15 no members for a registered multicast group are connected to a particular router, the router sends a pruning message to the previously adjacent router so that the router sPn-ling the pruning message is removed from the ~p~nning tree. As a result, the spanning tree that is eventually generated provides the shortest path between the source and every host in the net~,vork. Periodically, the broadcast and pruning 20 operations are pe,rc,lllled for updating the spanning tree. While the DVMRP protocol CA 022F,8129 1998- 12- lo works well for a densely-distributed multicast group, the overhead procescing ~ccori~t~d with message bro~dc~ctc and maintenance of state information can become expensive for a sparse distribution of hosts across a wide area network.
The MOSPF protocol is a multicast routing protocol that is built on top 5 of the OSPF protocol, thereby providing the ability to create multicast trees having an OSPF routing domain. Each MOSPF router receives information about hosts that are interested in a particular multicast group through an Internet Group Management Protocol (IGMP) registration process. Consequently, all routers in the OSPF domain contain information relating to the complete topology of the network and can construct 10 the optimum path between a source and any other host in the domain. Nevertheless, multicast trees generated using the MOSPF protocol cannot span OSPF domain boundaries. Further, the MOSPF protocol generates signific~nt amounts of overhead routing information that is continuously exchanged between routers in the network so multicast trees sp~nning large domains do not scale well.
The PIM protocol, developed by the Internet F.nginePring Task Force (IETF), addresses problems ~CcQCi~t~d with crossing domain boundaries, and is independent of any underlying unicast protocol. The PIM protocol includes a dense mode and a sparse mode. Dense-mode PIM (PIM-DM) is suitable for environments in which many of the different domains, or subnets, contain at least one host 20 partiCir~ting in a multicast group and in which network bandwidth is not critical.
CA 02258129 1998-12-lo W O 98/47309 PCT~US98/07317 Unlike the DVMRP protocol, the PIM-DM protocol uses a simple technique of sending a data packet arriving at a router to all adjacent downstream routers. The adjacent downstream routers, in turn, send the packet to their res~ecti~ely adjacent routers. The routing tree is pruned as each router determines whether there are any 5 hosts partici~tin~ in the multicast group that are connected to the router.
When the hosts in a network are sparsely distributed, the overhead associated with PIM-DM of flooding information through a network becomes too signifi~nt and the PIM-SM piotocol is used. In PIM-SM, a host that is interested in joining a particular multicast group is respon~ible for initi~fin~ a join operation to join 10 the multicast routing tree associated with the multicast group. A join request is sent from the interested host towards the source of the multicast tree. The join request is propag~ted toward the source until the request encounters a router that already has a host parti~ir~ting in the desired multicast group. The routing tree is then updated to include all of the routers between the host initi~ting the join operation and the router 15 where the propagation of the join request termin~tes.
Deployment of multicast pr~tocols on routers has procee~çd at a steady pace. Nevertheless, there are still so-called "islands" of routers that are multicast-aware that are se~a-d~ed from other islands of multicast-aware routers. Figure 1 is a sch~m~tic block diagram showing an exemplary conventional MBONE network 10 20 having a plurality of multicast-aware routers l l and unicast routers 12. A multicast-aware router or a group of multicast-aware routers that are separated from other multicast-aware routers 11 by one or more unicast routers 12 are referred to as islands. In order to transport multicast traffic between multicast-aware routers 11 across one or more unicast routers 12, a technique known as "multicast t~nneling" is 5 used. That is, a multicast-aware router 11 encapsulates multicast traffic inside a unicast packet. The encapsulated multicast traffic is then sent, or tunneled, across a portion of the network having unicast routers.
A number of other protocols are under development by the IETF that run on top of conven~ion~l routing yr~tocols and which provide the ability for an 10 application to reserve lesources in a network so that a specified Quality of Service (QoS) can be achieved. F~rnples of these particular protocols are the Resource Reservation Protocol (RSVP) and the Real Time Protocol (RTP).
The ATM Forum has developed a spe~ifi~tion, known as the LAN
Emulation spe~ifi~tion (LANE), that permits Legacy LANs- and ATM-connected 15 hosts to communicate across an ATM link without changes to existing applications or software. The LANE specification defines an Emulated Local Area Network (ELAN) environment in which, from the perspective of a legacy application, an ATM network looks ap~ to be a LAN se~ment There are three special entitles in a LANE
environment that are r~re.lcd to as a LAN Emulation Server (LES), a Broadcast 20 Unknown Server (BUS) and an LAN Emulation Configuration Server (LECS). The , . .. .... ~ .. ~ . . .. _ .. .
CA 022~8129 1998-12-10 LES registers and resolves ATM addressing by labeling each end station with a Medium Access Control (MAC) layer and an ATM address. The address mapping is used by an ingress LAN Emulation Client (LEC) for setting up a cut-through path to an egress LEC. The BUS is used for distributing broadcast and multicast traffic 5 within the LANE environment.
When a LEC sends a multicast or broadcast packet to other multicast group members within an ELAN, the packet is sent to a BUS. The BUS forwards the packet to all the other LECs within the ELAN environment on a point-to-multipoint virtual çh~nnPl connection (VCC). An alternative entity to a BUS is a Special 10 Multicast Server (SMS). A LEC wishing to receive data for a multicast address registers with an SMS and is added to the desired multicast group. Traffic received on the SMS for a particular multicast group is forwarded only on the point-to-multipoint circuit for the multicast group, thus preventing other LECs within the ELAN environment from receiving traffic in which they have no interest. While the 15 LANE specification operates with legacy LANs- and ATM-connect~ hosts, the LANE specification applies only to a single ELAN environment, which, by definition, is a single subnet of an ATM network. A multicast solution in which an ELAN spans different subnet boundaries is not defined under the LANE specification.
Multiprotocol over ATM (MPOA) is a standard that is built on top of 20 the LANE and the NHRP protocols. The MPOA plolocol uses LANE when traf~lc is CA 02258129 1998-12-lo confined within a single subnet, but uses the NHRP protocol when traffic crossessubnet boundaries. Figure 2 is a schematic block diagram showing a conventional MPOA implementation traversing a plurality of subnets 21. As data initially begins to flow from a source 22 to a destin~tion host 23, the data follows a default data path 24 through each subnet 21 using ELAN techniques. At each boundary router 25, thepacket is re~ccPrnbled and Level 3 processing occurs so that the packet can be successfully forwarded to the next subnet 21. While the data packet is traversing default data path 24, a NHRP request is generated for determining the ATM address of destin~tion host 23. Once the ATM destin~tion address information is available, source 22 can set up a direct unicast connection 26 to destin~tion host 23 using NHRP
protocol concepts, thereby bypassing all router hops and expensive Level 3 pro~escing.
For each of the conventional IP multicast routing protocols, such as DVMRP, MOSPF, PIM, LANE and MPOA, a considerable amount of state information must be exçh~nged between routers partiCir~ting in a multicast.
Consequently, overhead traffic, including "join" and "prune" messages, becomes asignific~nt portion of the multicast traffic as a multicast group grows in size. Further, for the DVMRP, MOSPF and PIM protocols, a multicast data packet flows hop-by-hop from one mllltjc~ct router to the next until the packet reaches its ~lestin~tion. At each hop, Level 3 proce~ing occurs, thereby causing considerable segmentation and CA 02258129 1998-12-lo W O 98/47309 PCT~US98/07317 reassembly overhead pr~ces~;ng. When the LANE and MPOA protocols are used, multicast traffic is confined to an ~AN. Consequently, a host desiring to join a multicast group, but not belonging to a particular ELAN is unable to participate in the multicast session without first becoming a member of the ELAN. This poses a S cignifiç~nt problem for dyn~mic~lly altering membership to a multicast group because a LAN Emulation client (host) can belong to only one ELAN at a time.
What is needed is a way to forward multicast traffic across an ATM
network that does not incur signifiç~nt overhead processing expenses, that scales well, that reduces the number of router hops experienced by a multicast packet when 10 forwarded across the ATM network, and makes efficient use of network resoulces and network bandwidth.
SUMMARY OF THE INVENTION
The present invention provides multicast traffic forwarding across an 15 ATM network that does not incur significant overhead p~uc~scing expenses, s~ales well, reduces the number of router hops experienced by a multicast packet when fo~ rded across an ATM network, and makes efficient use of network resources and network bandwidth. The advantages of the present invention are provided by a method and a system for forwarding multicast data packets across a plurality of 20 telecommllnic~ions subnets intercol n~ ed by routers in which a data packet is received within a subnet of the plurality of telecommunications subnets. When the data packet is a multicast data packet, a multicast IP address for the multicast data packet is determined. A multicast forwarding d~t~h~ is ~cces~ed for determining a LAN Emulation Client ~c~soci~t~ with the multicast IP address, and a Broadcast S Unknown Server Zlc~'toci~tp~ with the multicast ~P address for the multicast data packet is dt;ler,l,illed. The multicast data packet is sent to the Broadcast Unknown Server ~C~ci~te:d with the multicast IP address for the multicast data packet through the LAN
Emulation Client using a point-to-point connection. The Broadcast Unknown Server sends the multicast data packet inter-subnet to each router ~csoci~ted with the 10 multicast IP address for the multicast data packet using a point-to-multipoint connection, with at least one multicast host being cor-nected to a subnet that is different from the subnet in which the multicast data packet was received. When the data packet is not a multicast data packet, the data packet is sent to a ~estin~tion address for the data packet using intra-subnet techniques.
BRIEF DESCRIPI ION OF THE DRAWING
The present invention is illustrated by way of example and not limit~tion in the accom~)anying figures in which like reference numerals indicate similar elements and in which:
CA 02258129 1998-12-lo W O 98/47309 PCTrUS98/07317 Figure 1 shows a schem~tic block diagram of an exemplary conventional MBONE network having a plurality of multicast-aware routers and unicast routers;
Figure 2 is a schematic block diagram showing a conventional MPOA
5 implçmen~tion traversing a plurality of subnets;
Figure 3 is a schematic block diagram showing multicast traffic forwarded across subnets according to the present invention;
Figure 4 is a schematic block diagram of a multicast-forwarding system having according to the present invention that includes a static multicast ELAN;
Figure 5 is a schem~tic block diagram showing a multicast forwarding system according to the present invention having a static configuration of LECs and ELANs and their res~ /e LES/BUS entities;
Figure 6 is a schem~tic block diagram showing a multicast forwarding system according to the present invention that can be dyn~mi~lly reconfigured using 15 an LECS for creating LECs and LES/BUS entities within an ISELAN; and Figure 7 is a sr~eln~tic block diagram showing a multicast forwarding system according to the present invention that can be dynamically reconfigured using a Session Manager for creating LECs and LES/BUS entities within an ISELAN.
CA 02258129 1998-12-lo W O 98/47309 PCT~US98/07317 DETAILED DESCRIPI~ON
The present invention provides a multicast forwarding method and system that sends multicast data packets across subnets of an Internet-Protocol-routed (IP-routed) ATM network. The present invention only addresses the forwarding S aspect of mllltir~ting. A multicast routing protocol, such as the MOSPF, the DVMRP and the PIM protocols, and the Internet Group Management Protocol (IGMP) are required for distributing information relating to multicast group membership to routers connected to an ATM network. These particular protocols run across an ATM network or across other networks to hosts that are connected to a 10 multicast session. The multicast for varding aspects of these protocols, however, are replaced by multicast forwarding concepls of the present invention.
The present invention dr~ lly improves multicast forwarding o..llance over conventional multicast forwarding protocols and systems by re~ cing the number of router hops experienced by an IP multicast packet that is 15 forwarded across an ATM network to be a maximum of two hops. Thus, the present invention makes more efficient use of LANE-type resources and network bandwidth by only sen-ling multicast traffic for a particular multicast group to routers connected to sources and hosts that are members of the multicast group. A potential virtual circuit (VC) explosion caused by multicast traffic is elimin~t~d by the present 20 invention by using a single point-to-multipoint connection per multicast group, with CA 02258129 1998-12-lo the added capability of providing a specified Quality of Service (C!oS) in accordance with the LANE specification. Scalability is improved and large state tables contained within each router is not required by elimin~ting the flood-and-prune traffic techniques used by conventional multicast forwarding techniques.
S Figure 3 conceplually shows a multicast forwarding system (MFS) 300 according to the present invention connected to an IP-routed ATM network having a plurality of subnets 310, of which only three are shown. Subnets 310 are intel~;onne~ted by a plurality of boundary routers 320. According to the invention, a standards-compliant LAN Emulation Client (LEC) 330 resides on each boundary router 320 having a multicast source or host conn~ted to the router. Routers 320 are all conn~l to each other through the ATM network and, of course, can have non-ATM interfaces. At least one LES/BUS (not shown in Figure 3) is connected to each LEC 330 and forms an Inter-Subnet ELAN (ISELAN) 340 that forwards only multicast traffic to routers in the ATM network having members of the same multicast group. A LEC 330 can be dyn~mi~lly created when a router detects a host de~iringto join a multicast group for which no source or other member hosts are conn~.ted to the router.
Each router 320 includes a multicast-forwarding table that allows the router to delel.lline to which particular LEC 330 incoming IP multicast traffic should be forwarded to. IP multicast addresses are completely inclependent from subnet CA 02258129 1998-12-lo addresses so the sources and hosts of a multicast group can use the same IP multicast address, such as the address range of 224Ø0.0 through 239.255.2S5.255, across subnets regardless of where the source and the hosts are conne~ted in the ATM
network.
Unicast, broadca~st and multicast traffic received by a router 320 is segregated. When a received data packet is a multicast data packet, the packet is forwarded by the standards-compliant LEC 330 residing on the router to ISELAN
340. ISELAN 340 then forwards the multicast data packet to each ELAN subnet 310 having a member that is in~erei.led in receiving the multicast data packet. In contrast, a conventional ELAN is used only for intra-subnet comm~-ni~tions to forward ni~ct, bro~ct and multicast traffic all within a subnet. The unicast and broadcast traffic received by a router 320 are forwarded both intra-subnet and inter-subnet by the router using conventional default mec~ ~nisms specifically ~lesigne~ for unicast and broadcast traffic.
Figure 4 is a s~he-m~tic block diagram of an exemplary general configuration of an MFS 400 according to the present invention. In Figure 4, an ATM network 410 includes routers 421, 422 and 423, which are each preferably a C~ de. 9000 router, for example. Hosts 451, 452 and 453 are conne~ted to routers421, 422 and 423, ~ )eoti~ely. When router 423, for example, receives an IP packet from host 453, router 423 first i~ the IP address field of the packet for .. .. . , .. , , . _ ~
CA 02258129 1998-12-lo W O 98/47309 PCTrUS98/07317 det~ ining whether the packet is a unicast or a multicast data packet using well-known techniques. When router 423 determines that the packet is a unicast packet, that is, the packet is destin~l for a single IP ~lestinq~ion, router 423 sends the packet through ATM network 410 using conventional unicast routing procedures.
When router 423 dete~ es that the packet is a multicast packet, router 423 inepect~ the IP mul~ic~t address field, which is a class D IP address, and ~ccessPs a multicast-forwarding table contained within router 423 for determining whether a LEC entry for the particular class D address has already been created. If an entry exists in the multicast-forwarding table specifying a mapping from the class D address to a specific LEC 433 that resides on router 423, then router 423 encapsulates the packet into an LAN Emulation header using an ATM Forum compliant encapsulation and sends the encapsulated packet to the specified resident LEC 433, for example. If there is no LEC entry in the multicast-forwarding table for the spe~ife~ class D address, router 423 creates a new LEC and a co~ ,onding newtable entry in the multicast-forwarding table for mapping from the class D address to the newly created LEC.
LEC 433 first resolves the destination multicast MAC protocol address, which is gene,d~d by router 423 based on the IP multicast class D address contained in the data packet, into an ATM address by s~n(ling an address query LE_ARP Request message to a LES 460 that is resident on an ISELAN 440. LES
CA 02258129 1998-12-lO
W O 98/47309 PCT~US98/07317 460 responds to the address query message by sending a message to LEC 433 containing the address of a bro~c~ct and unknown server (BUS) 470 in accordance with the LANE c~ific~tion. Alternatively, LES 460 can specify the address of a Special Multicast Server (SMS) (not shown) instead of the address of BUS 470.
Next, LEC 433 sends the enc~rs~ t~d IP packet to BUS 470 (or SMS
480) over a connection 490. BUS 470 (or SMS 480), in turn, sends the packet to LECs that are :~C~ tÇd with the res~live destin~tions of the packet over a point-to-multipoint connection 491 using a well-known technique. The LECs receiving the packet reside on other routers in ATM network 410, such as routers 421 and 422.
Each receiving LEC de~rslllatec the packet, and the router on which the LEC resides ~cc~es a table for determining whether any of the destin~tion hosts, that is, members of the multicast group for the packet, are connçcted to the router. If there is a receiver for the multicast group of the packet connectçd to the router, the router sends the IP packet to the al)pr~,pliate outgoing port(s). Information relating to the hosts for a particular IP multicast group is obtained by a router through an IGMP
registration prvcess or a multicast routing protocol, such as the MOSPF protocol or the DVMRP protocol.
Figure S shows another çYernrl~ry emb~imçnt a multicast forwarding system 500 according to the present invention having a static configuration of LECs and LES/BUS entities associated with an ISELAN. In Figure 5, an ATM network .. ~. .
CA 02258129 1998-12-lo 510 includes a plurality of routers, of which only routers 521, 522, 523 and 524 are shown, and an ATM switch 525. ~ plurality of hosts, of which only hosts 551, 552and 553 are shown, can be conn~ted to ATM network 510 through a router via, for example, a dial-up line using the Point-to-Point Protocol (PPP), connected to a LAN
S (not shown) that is connected to a router, by a private line, or through a downstream router, such as router 524. Different host connection alternatives are viable.
ATM switch 525 includes ISELAN 540 having a predetermined number of preconfigured LES/BUS entities, with each BUS being design~t~d for a particular range of multicast IP addresses and is scalable within the expected traffic for the dçsign~P~l address range. For clarity, only three LES/BUS entities are shown.
ISELAN 541 includes an LES/BUS entity formed by an LES 561 and a BUS 571.
Similarly, ISELAN 542 includes a LES 562 and a BUS 572, and ISELAN 543 includes a LES 563 and a BUS 573. All LESs and BUSs can reside on the same physical device or can be distributed across multiple devices. Similarly, a prede~lnlined number of LECs coll~sponding to each BUS are preconfigured on eachrouter. The multicast IP address ranges and the correspondence QoS for each address range are made available in a well-known manner, such as an Internet web-page, so that sources can select from available mnlti~ct IP addresses.
A point-to-multipoint co~-n~ion 591 conne~ts BUS 571 to LECs 531, 534 and 537. Connection 591 is unidirectional in that BUS 571 is a source and each CA 02258129 1998-12-lo LEC is a leaf. Each of LECs 531, 534 and 527 also connect to BUS 571 with a point-to-point conn~!;on 590 so that packets can be forwarded to BUS 571.
Similarly, each of the LESs 561, 562 and 563 are connected to specific LECs using both point-to-multipoint and point-to-point conn~ctions that are not shown in Figure 5, 5 are well-defined by ATM Forum LAN Emulation specification.
Router 521, for example, receives an IP packet from host 551 that is ~estineJ to an IP multicast address, such as 225Ø1Ø Router 521 in~pect~ the packet in a well-known manner and determines that the destin~tion address is an IP
multicast address. Router 521 ~rce.sses the multicast-forwarding table con~ined within router 521 for determining which LEC residing on router 521 is design~ted for supporting the class D address of the multicast packet. An exemplary multicast-forwarding table contained in router 521 is shown in Table 1.
IP multicast address Destination address 15224Ø0.0 - 225Ø1.0 LEC 531 225Ø1.I - 230Ø8.0 LEC 532 230Ø8.1-239.255.255.255 LEC 533 Based on the exemplary entries in Table I, the IP packet is sent to LEC
- 20 531.Upon receipt of the packet, LEC 531 resolves the ATM address of the BUS by sPn(ling an address resolution query (LE_ARP_REQUEST) message to a LES 561 for the bro~dc~ct group address. In response, LES 561 returns the ATM address of the CA 02258129 1998-12-1o W O 98/47309 PCT~US98/07317 destin~tion LEC. LEC 531 forwards the multicast packet to BUS 571 on connection 590. BUS 571, in turn, forwards the packet using conne~tion 591 to LECs 531, 534and 537. LEC 531 discards the packet to prevent looping. LEC 534 residing on router 522 receives and forwards the packet to the Layer-3 plocessor residing onrouter 522. Router 522 deterrnines whether there is a host ~tt~.hed to any of the non-ATM ports connected to router 522 that should receive the packet. If so, router 522 fo~ ls the packet to port 593, for example, so that host 552 can receive the packet.
If there are no hosts connected to router 522 that should receive the packet, the packet is discarded.
In another implement~tion of a mnlti~st forwarding system according to the present invention, each router can dynamically create LECs dyn~rnic~lly when there are either new hosts explicitly joining a multicast group, or new sources sending multicast packets to a multicast group. Explicitly joining members become known to a router because a host that is intelesl~d in joining a multicast group sends an IGMP
packet to the router to which the host is directly conne~teA informing the router of the interest in receiving multicast packets addressed to a specific address. In response, the router informs lja~nt router(s) of the new ll,el.lber host by sentling multicast routing update messages using well-known protocols indicating that there is interest in receiving multicast packets at a particular multicast address. As previously mentionffl~ each router learns which multicast addresses are of interest using an IGMP registration process.
Figure 6 is a s~h~ tic block diagram showing a multicast forwarding system 600 according to the present invention that can be dynamically reconfigured 5 using an LECS for creating LECs and LES/BUS entities within an ISELAN. Figure 6 has b~ci~lly the same system topology as MFS 500 shown in Figure 5. For clarity, only three LES/BUS entities are shown. In Figure 6, an ATM network 610 includes a plurality of routers, of which only routers 621, 622, 623 and 624 are shown, and an ATM switch 625. A plurality of hosts, of which only hosts 651, 652 and 653 are shown, can be co~-ne~ to ATM network 610 through a router via, for exarnple, a dial-up line using the Point-to-Point Protocol using a varie~ of different techniques. ATM switch 625 includes ISELAN 640. For clarity, only three LES/BUS entities are shown. ISELAN 641 includes an LES/BUS entity formed by an LES 661 and a BUS 671. Similarly, ISELAN 642 includes a LES 662 and a BUS
672, and ISELAN 643 includes a LES 663 and a BUS 673.
A point-to-multipoint connection 691 connects BUS 671 to LECs 631, 634 and 637. Each of LECs 631, 634 and 627 also connect to BUS 671 with a point-to-point connection 690 so that packets can be forwarded to BUS 671. Similarly, each of the LESs 661, 662 and 663 are connected to specific LECs using both point-CA 02258129 1998-12-lo W O 98t47309 PCT~US98/07317 to-multipoint and point-to-point conneclions that are not shown in Figure 6, are well defined by ATM Forum LAN F.m~ tion specification.
In Figure 6, a router 621, for example, receives an IP packet from a host 651, for example, that is either directly conne~tP~l to router 621 or connected to 5 a downstream router (not shown) that is connected to router 621. Using well-known techniques, router 621 de~llllines whether the destin~tion address of the packet is an IP multicast address. Router 621 ~ccesses the multicast forwarding table contained in router 621 for detel,nining whether there is an LEC residing on router 621 that has already been created for forwarding the packet. When such an entry does not exist in 10 the multicast forwarding table, router 621 creates a new entry in the multicast forwarding table, such as line 1 of Table 2, that provides a new LEC ~ignment for the multicast address, such as 225Ø1.0, contained in the packet. Router 621 then creates a new LEC that is resident on router 621.
In most cases, an entry will have already been created by a LECS 601 15 or as a result of a previously-received IP packet having the same destin~tion address.
When an entry for the IP address exists, router 621 reads the destin~tion address from the table. An exemplary dyn~mi~lly-created multicast forwarding table contained in router 621 is shown in Table 2.
CA 02258129 1998-12-lo W O 98/47309 PCT~US98/07317 IP Multicast Address Destination Address 225Ø1.0 LEC 631 226.1Ø9 LEC 632 228.128Ø8 LEC 633 When LEC 631 is a newly-created LEC, LEC 631 connects to a LECS
601, via connection 692, for determining which LES/BUS to connect to. LECS 601 pelro-,-,s a table look-up to determine whether a LES/BUS entity has already been 10 created for the multicast address contained in the data packet. When there is a t~ble entry already created, LECS 601 returns the ATM address of the already-created LES, for e~mr~le, LES 661. Otherwise, LECS 601 creates a new table entry by sele~tin~ one of the available, but unused, LESs residing within ISELAN 640 for the new multicast group, activates the sele~tçd LES, and returns the ATM address for the sPle~ted LES, such as LES 661, to LEC 631. An exemplary LECS table contained in LECS 601 is shown in Table 3.
Multicast Address LES ATM Address 225Ø1.0 47.00.10.. 1 (LES 661) 226.1.3.4 47.00.10.. 2 (LES 662) 229.67Ø1 47.00.10.. 3 (LES 663) Subsequently, LEC 631 connects to LES 661 and BUS 671. LEC 631 resolves the MAC address of the dçstin~tion multicast address for the multicast ATM
,, ....... ... ~ .. ~ . ,............. ...... .. _ address by s~ntling an address resolution query (LE_ARP_REQUEST) message to LES 661. In response, LES 661 returns the ATM address for BUS 671. LEC 631 forwards the multicast packet to BUS 671 on connection 690. BUS 671, in turn, forwards the packet to LECs 631, 634 and 637 using connection 691. LEC 631 5 discards the packet to prevent looping.
LEC 634 on router 622 receives and forwards the packet to the Layer-3 processor residing on router 622. Router 622 determines whether there is a host ~ttzlrlled to any of its non-ATM ports that has an interest in receiving the packet. If there is no interested host, router 622 discards the packet. Otherwise, router 622 10 folw~ds the packet to those port to which interested hosts are connected.
The dynarnic approach of the present invention allows LECs and LES/BUS entity resoul~s to be allocated to each multicast group when a session manager builds an ISELAN or when data starts flowing. Thus, there are no dedicated ISELAN resources allocated, but unuse~, as with the static configuration of LECs and 15 LES/BUS entities of the present invention, as shown in Figure 5.
While "dynamic" multicast forwarding system 600 overcomes some of the drawbacks of the "static" multicast forwarding system, shown in Figure 5, system 600 does not provide any technique for tightly-controlled multicast groups, that is, an applic~ion triggered multicast group in which only eligible hosts can join a multicast 20 group. Figure 7 is a sCllem~ic block diagram showing a multicast forwarding system .
CA 02258l29 l998-l2-lO
700 according to the present invention that can be dyn~nlic~lly reconfigured using a .Sçssion Manager for creating LECs and LES/BUS entities within an ISELAN. Figure 7 has b~ir~lly the same system topology as MFS 600 shown in Figure 6.
In Figure 7, host 65 1, for example, initially 5/ccf c~es a web-based 5 multicast session manager 701 for joining a particular multicast group. Session manager 701 ~-lthP-n~ir~tes the user at host 651 and then provides a screen that permits existing and registered multicast sessions to be viewed, as well as the ability to create a new multicast session. A variety of additional filters or parameters, such as start time, bandwidth required, closed user groups, etc., can also be spe~-ified through 10 interface provided by the web-based multicast session manager. The values entered for parameters, such as bandwidth and cell delay variation, are used in setting up a circuit having a specified Quality of Service. Once the entries are complete, they are entered into a d~t~b2cr on session manager 701.
Session manager 701 is responsible for monitoring the start of a 15 multicast session and registration of participants. In order to build an ISELAN for a multicast session, the steps that have been previously outlined for dynamically creating an ISELAN must be ~Çurllled. When the session actually begins and the traffic begins to ~low through the routers, the entire ISELAN will be setup and engaged.
In addition to creating the Multicast ELANs, Session Manager 701 also has the responsibility of removing a LEC from a router when a host that was interested in a multicast session decides to drop out of the group, leaving no interested hosts conn~ct~ to the router or downstream from the router. Lastly, when S an entire multicast session is over, the LES/BUS entity and all the LECs that were a part of the session are removed and the resources made available for other multicast sessions.
While the present invention has been described in connection with the illustrated embo~iment~, it will be appreciated and understood that modifications may 10 be made without departing from the true spirit and scope of the invention.
Previously, conventional unicast techniques were used for sending the same data packet to each host of a multicast group over a circuit that was specifically established between a source and the host. A conventional unicast approach for multicasting traffic, however, is wasteful in terms of both bandwidth and circuit resources.
To overcome the drawbacks of using unicast techniques for multicast traffic, techniques and protocols have been developed so that a multicast data packet is sent along a predetermined route of routers, or switches, and replicated at a point _ _ .. .... .... ... ... .. .
CA 02258129 1998-12-lo closest to a dçstin~tion host, thereby reducing the amount of multicast traffic. For example, a number of routing protocols have been developed for creating distribution routes between a source and the hosts of a multicast group. Routers and end stations have become "multicast aware" by using multicast protocols such as the Distance S Vector Multicast Routing Protocol (DVMRP), the Multicast Open Shortest Path First (MOSPF) protocol and Protocol-Independent Multicast (PIM).
The DVMRP protocol is widely used in the Multicast Backbone (MBONE) and generates a separate distribution tree for each respective source and destination host group. The distribution tree, also referred to as a sp~nning tree, 10 provides the shortest path from a source to each host in a multicast group. A
sp~nning tree is constructed for a multicast group by the source initially bro~lc~cting, or sending, a message to an a~j~cent router that is prop~g~tPli to all other routers in the network so that the message reaches each participating host. The message effectively registers the multicast group with reach router receiving the message. If 15 no members for a registered multicast group are connected to a particular router, the router sends a pruning message to the previously adjacent router so that the router sPn-ling the pruning message is removed from the ~p~nning tree. As a result, the spanning tree that is eventually generated provides the shortest path between the source and every host in the net~,vork. Periodically, the broadcast and pruning 20 operations are pe,rc,lllled for updating the spanning tree. While the DVMRP protocol CA 022F,8129 1998- 12- lo works well for a densely-distributed multicast group, the overhead procescing ~ccori~t~d with message bro~dc~ctc and maintenance of state information can become expensive for a sparse distribution of hosts across a wide area network.
The MOSPF protocol is a multicast routing protocol that is built on top 5 of the OSPF protocol, thereby providing the ability to create multicast trees having an OSPF routing domain. Each MOSPF router receives information about hosts that are interested in a particular multicast group through an Internet Group Management Protocol (IGMP) registration process. Consequently, all routers in the OSPF domain contain information relating to the complete topology of the network and can construct 10 the optimum path between a source and any other host in the domain. Nevertheless, multicast trees generated using the MOSPF protocol cannot span OSPF domain boundaries. Further, the MOSPF protocol generates signific~nt amounts of overhead routing information that is continuously exchanged between routers in the network so multicast trees sp~nning large domains do not scale well.
The PIM protocol, developed by the Internet F.nginePring Task Force (IETF), addresses problems ~CcQCi~t~d with crossing domain boundaries, and is independent of any underlying unicast protocol. The PIM protocol includes a dense mode and a sparse mode. Dense-mode PIM (PIM-DM) is suitable for environments in which many of the different domains, or subnets, contain at least one host 20 partiCir~ting in a multicast group and in which network bandwidth is not critical.
CA 02258129 1998-12-lo W O 98/47309 PCT~US98/07317 Unlike the DVMRP protocol, the PIM-DM protocol uses a simple technique of sending a data packet arriving at a router to all adjacent downstream routers. The adjacent downstream routers, in turn, send the packet to their res~ecti~ely adjacent routers. The routing tree is pruned as each router determines whether there are any 5 hosts partici~tin~ in the multicast group that are connected to the router.
When the hosts in a network are sparsely distributed, the overhead associated with PIM-DM of flooding information through a network becomes too signifi~nt and the PIM-SM piotocol is used. In PIM-SM, a host that is interested in joining a particular multicast group is respon~ible for initi~fin~ a join operation to join 10 the multicast routing tree associated with the multicast group. A join request is sent from the interested host towards the source of the multicast tree. The join request is propag~ted toward the source until the request encounters a router that already has a host parti~ir~ting in the desired multicast group. The routing tree is then updated to include all of the routers between the host initi~ting the join operation and the router 15 where the propagation of the join request termin~tes.
Deployment of multicast pr~tocols on routers has procee~çd at a steady pace. Nevertheless, there are still so-called "islands" of routers that are multicast-aware that are se~a-d~ed from other islands of multicast-aware routers. Figure 1 is a sch~m~tic block diagram showing an exemplary conventional MBONE network 10 20 having a plurality of multicast-aware routers l l and unicast routers 12. A multicast-aware router or a group of multicast-aware routers that are separated from other multicast-aware routers 11 by one or more unicast routers 12 are referred to as islands. In order to transport multicast traffic between multicast-aware routers 11 across one or more unicast routers 12, a technique known as "multicast t~nneling" is 5 used. That is, a multicast-aware router 11 encapsulates multicast traffic inside a unicast packet. The encapsulated multicast traffic is then sent, or tunneled, across a portion of the network having unicast routers.
A number of other protocols are under development by the IETF that run on top of conven~ion~l routing yr~tocols and which provide the ability for an 10 application to reserve lesources in a network so that a specified Quality of Service (QoS) can be achieved. F~rnples of these particular protocols are the Resource Reservation Protocol (RSVP) and the Real Time Protocol (RTP).
The ATM Forum has developed a spe~ifi~tion, known as the LAN
Emulation spe~ifi~tion (LANE), that permits Legacy LANs- and ATM-connected 15 hosts to communicate across an ATM link without changes to existing applications or software. The LANE specification defines an Emulated Local Area Network (ELAN) environment in which, from the perspective of a legacy application, an ATM network looks ap~ to be a LAN se~ment There are three special entitles in a LANE
environment that are r~re.lcd to as a LAN Emulation Server (LES), a Broadcast 20 Unknown Server (BUS) and an LAN Emulation Configuration Server (LECS). The , . .. .... ~ .. ~ . . .. _ .. .
CA 022~8129 1998-12-10 LES registers and resolves ATM addressing by labeling each end station with a Medium Access Control (MAC) layer and an ATM address. The address mapping is used by an ingress LAN Emulation Client (LEC) for setting up a cut-through path to an egress LEC. The BUS is used for distributing broadcast and multicast traffic 5 within the LANE environment.
When a LEC sends a multicast or broadcast packet to other multicast group members within an ELAN, the packet is sent to a BUS. The BUS forwards the packet to all the other LECs within the ELAN environment on a point-to-multipoint virtual çh~nnPl connection (VCC). An alternative entity to a BUS is a Special 10 Multicast Server (SMS). A LEC wishing to receive data for a multicast address registers with an SMS and is added to the desired multicast group. Traffic received on the SMS for a particular multicast group is forwarded only on the point-to-multipoint circuit for the multicast group, thus preventing other LECs within the ELAN environment from receiving traffic in which they have no interest. While the 15 LANE specification operates with legacy LANs- and ATM-connect~ hosts, the LANE specification applies only to a single ELAN environment, which, by definition, is a single subnet of an ATM network. A multicast solution in which an ELAN spans different subnet boundaries is not defined under the LANE specification.
Multiprotocol over ATM (MPOA) is a standard that is built on top of 20 the LANE and the NHRP protocols. The MPOA plolocol uses LANE when traf~lc is CA 02258129 1998-12-lo confined within a single subnet, but uses the NHRP protocol when traffic crossessubnet boundaries. Figure 2 is a schematic block diagram showing a conventional MPOA implementation traversing a plurality of subnets 21. As data initially begins to flow from a source 22 to a destin~tion host 23, the data follows a default data path 24 through each subnet 21 using ELAN techniques. At each boundary router 25, thepacket is re~ccPrnbled and Level 3 processing occurs so that the packet can be successfully forwarded to the next subnet 21. While the data packet is traversing default data path 24, a NHRP request is generated for determining the ATM address of destin~tion host 23. Once the ATM destin~tion address information is available, source 22 can set up a direct unicast connection 26 to destin~tion host 23 using NHRP
protocol concepts, thereby bypassing all router hops and expensive Level 3 pro~escing.
For each of the conventional IP multicast routing protocols, such as DVMRP, MOSPF, PIM, LANE and MPOA, a considerable amount of state information must be exçh~nged between routers partiCir~ting in a multicast.
Consequently, overhead traffic, including "join" and "prune" messages, becomes asignific~nt portion of the multicast traffic as a multicast group grows in size. Further, for the DVMRP, MOSPF and PIM protocols, a multicast data packet flows hop-by-hop from one mllltjc~ct router to the next until the packet reaches its ~lestin~tion. At each hop, Level 3 proce~ing occurs, thereby causing considerable segmentation and CA 02258129 1998-12-lo W O 98/47309 PCT~US98/07317 reassembly overhead pr~ces~;ng. When the LANE and MPOA protocols are used, multicast traffic is confined to an ~AN. Consequently, a host desiring to join a multicast group, but not belonging to a particular ELAN is unable to participate in the multicast session without first becoming a member of the ELAN. This poses a S cignifiç~nt problem for dyn~mic~lly altering membership to a multicast group because a LAN Emulation client (host) can belong to only one ELAN at a time.
What is needed is a way to forward multicast traffic across an ATM
network that does not incur signifiç~nt overhead processing expenses, that scales well, that reduces the number of router hops experienced by a multicast packet when 10 forwarded across the ATM network, and makes efficient use of network resoulces and network bandwidth.
SUMMARY OF THE INVENTION
The present invention provides multicast traffic forwarding across an 15 ATM network that does not incur significant overhead p~uc~scing expenses, s~ales well, reduces the number of router hops experienced by a multicast packet when fo~ rded across an ATM network, and makes efficient use of network resources and network bandwidth. The advantages of the present invention are provided by a method and a system for forwarding multicast data packets across a plurality of 20 telecommllnic~ions subnets intercol n~ ed by routers in which a data packet is received within a subnet of the plurality of telecommunications subnets. When the data packet is a multicast data packet, a multicast IP address for the multicast data packet is determined. A multicast forwarding d~t~h~ is ~cces~ed for determining a LAN Emulation Client ~c~soci~t~ with the multicast IP address, and a Broadcast S Unknown Server Zlc~'toci~tp~ with the multicast ~P address for the multicast data packet is dt;ler,l,illed. The multicast data packet is sent to the Broadcast Unknown Server ~C~ci~te:d with the multicast IP address for the multicast data packet through the LAN
Emulation Client using a point-to-point connection. The Broadcast Unknown Server sends the multicast data packet inter-subnet to each router ~csoci~ted with the 10 multicast IP address for the multicast data packet using a point-to-multipoint connection, with at least one multicast host being cor-nected to a subnet that is different from the subnet in which the multicast data packet was received. When the data packet is not a multicast data packet, the data packet is sent to a ~estin~tion address for the data packet using intra-subnet techniques.
BRIEF DESCRIPI ION OF THE DRAWING
The present invention is illustrated by way of example and not limit~tion in the accom~)anying figures in which like reference numerals indicate similar elements and in which:
CA 02258129 1998-12-lo W O 98/47309 PCTrUS98/07317 Figure 1 shows a schem~tic block diagram of an exemplary conventional MBONE network having a plurality of multicast-aware routers and unicast routers;
Figure 2 is a schematic block diagram showing a conventional MPOA
5 implçmen~tion traversing a plurality of subnets;
Figure 3 is a schematic block diagram showing multicast traffic forwarded across subnets according to the present invention;
Figure 4 is a schematic block diagram of a multicast-forwarding system having according to the present invention that includes a static multicast ELAN;
Figure 5 is a schem~tic block diagram showing a multicast forwarding system according to the present invention having a static configuration of LECs and ELANs and their res~ /e LES/BUS entities;
Figure 6 is a schem~tic block diagram showing a multicast forwarding system according to the present invention that can be dyn~mi~lly reconfigured using 15 an LECS for creating LECs and LES/BUS entities within an ISELAN; and Figure 7 is a sr~eln~tic block diagram showing a multicast forwarding system according to the present invention that can be dynamically reconfigured using a Session Manager for creating LECs and LES/BUS entities within an ISELAN.
CA 02258129 1998-12-lo W O 98/47309 PCT~US98/07317 DETAILED DESCRIPI~ON
The present invention provides a multicast forwarding method and system that sends multicast data packets across subnets of an Internet-Protocol-routed (IP-routed) ATM network. The present invention only addresses the forwarding S aspect of mllltir~ting. A multicast routing protocol, such as the MOSPF, the DVMRP and the PIM protocols, and the Internet Group Management Protocol (IGMP) are required for distributing information relating to multicast group membership to routers connected to an ATM network. These particular protocols run across an ATM network or across other networks to hosts that are connected to a 10 multicast session. The multicast for varding aspects of these protocols, however, are replaced by multicast forwarding concepls of the present invention.
The present invention dr~ lly improves multicast forwarding o..llance over conventional multicast forwarding protocols and systems by re~ cing the number of router hops experienced by an IP multicast packet that is 15 forwarded across an ATM network to be a maximum of two hops. Thus, the present invention makes more efficient use of LANE-type resources and network bandwidth by only sen-ling multicast traffic for a particular multicast group to routers connected to sources and hosts that are members of the multicast group. A potential virtual circuit (VC) explosion caused by multicast traffic is elimin~t~d by the present 20 invention by using a single point-to-multipoint connection per multicast group, with CA 02258129 1998-12-lo the added capability of providing a specified Quality of Service (C!oS) in accordance with the LANE specification. Scalability is improved and large state tables contained within each router is not required by elimin~ting the flood-and-prune traffic techniques used by conventional multicast forwarding techniques.
S Figure 3 conceplually shows a multicast forwarding system (MFS) 300 according to the present invention connected to an IP-routed ATM network having a plurality of subnets 310, of which only three are shown. Subnets 310 are intel~;onne~ted by a plurality of boundary routers 320. According to the invention, a standards-compliant LAN Emulation Client (LEC) 330 resides on each boundary router 320 having a multicast source or host conn~ted to the router. Routers 320 are all conn~l to each other through the ATM network and, of course, can have non-ATM interfaces. At least one LES/BUS (not shown in Figure 3) is connected to each LEC 330 and forms an Inter-Subnet ELAN (ISELAN) 340 that forwards only multicast traffic to routers in the ATM network having members of the same multicast group. A LEC 330 can be dyn~mi~lly created when a router detects a host de~iringto join a multicast group for which no source or other member hosts are conn~.ted to the router.
Each router 320 includes a multicast-forwarding table that allows the router to delel.lline to which particular LEC 330 incoming IP multicast traffic should be forwarded to. IP multicast addresses are completely inclependent from subnet CA 02258129 1998-12-lo addresses so the sources and hosts of a multicast group can use the same IP multicast address, such as the address range of 224Ø0.0 through 239.255.2S5.255, across subnets regardless of where the source and the hosts are conne~ted in the ATM
network.
Unicast, broadca~st and multicast traffic received by a router 320 is segregated. When a received data packet is a multicast data packet, the packet is forwarded by the standards-compliant LEC 330 residing on the router to ISELAN
340. ISELAN 340 then forwards the multicast data packet to each ELAN subnet 310 having a member that is in~erei.led in receiving the multicast data packet. In contrast, a conventional ELAN is used only for intra-subnet comm~-ni~tions to forward ni~ct, bro~ct and multicast traffic all within a subnet. The unicast and broadcast traffic received by a router 320 are forwarded both intra-subnet and inter-subnet by the router using conventional default mec~ ~nisms specifically ~lesigne~ for unicast and broadcast traffic.
Figure 4 is a s~he-m~tic block diagram of an exemplary general configuration of an MFS 400 according to the present invention. In Figure 4, an ATM network 410 includes routers 421, 422 and 423, which are each preferably a C~ de. 9000 router, for example. Hosts 451, 452 and 453 are conne~ted to routers421, 422 and 423, ~ )eoti~ely. When router 423, for example, receives an IP packet from host 453, router 423 first i~ the IP address field of the packet for .. .. . , .. , , . _ ~
CA 02258129 1998-12-lo W O 98/47309 PCTrUS98/07317 det~ ining whether the packet is a unicast or a multicast data packet using well-known techniques. When router 423 determines that the packet is a unicast packet, that is, the packet is destin~l for a single IP ~lestinq~ion, router 423 sends the packet through ATM network 410 using conventional unicast routing procedures.
When router 423 dete~ es that the packet is a multicast packet, router 423 inepect~ the IP mul~ic~t address field, which is a class D IP address, and ~ccessPs a multicast-forwarding table contained within router 423 for determining whether a LEC entry for the particular class D address has already been created. If an entry exists in the multicast-forwarding table specifying a mapping from the class D address to a specific LEC 433 that resides on router 423, then router 423 encapsulates the packet into an LAN Emulation header using an ATM Forum compliant encapsulation and sends the encapsulated packet to the specified resident LEC 433, for example. If there is no LEC entry in the multicast-forwarding table for the spe~ife~ class D address, router 423 creates a new LEC and a co~ ,onding newtable entry in the multicast-forwarding table for mapping from the class D address to the newly created LEC.
LEC 433 first resolves the destination multicast MAC protocol address, which is gene,d~d by router 423 based on the IP multicast class D address contained in the data packet, into an ATM address by s~n(ling an address query LE_ARP Request message to a LES 460 that is resident on an ISELAN 440. LES
CA 02258129 1998-12-lO
W O 98/47309 PCT~US98/07317 460 responds to the address query message by sending a message to LEC 433 containing the address of a bro~c~ct and unknown server (BUS) 470 in accordance with the LANE c~ific~tion. Alternatively, LES 460 can specify the address of a Special Multicast Server (SMS) (not shown) instead of the address of BUS 470.
Next, LEC 433 sends the enc~rs~ t~d IP packet to BUS 470 (or SMS
480) over a connection 490. BUS 470 (or SMS 480), in turn, sends the packet to LECs that are :~C~ tÇd with the res~live destin~tions of the packet over a point-to-multipoint connection 491 using a well-known technique. The LECs receiving the packet reside on other routers in ATM network 410, such as routers 421 and 422.
Each receiving LEC de~rslllatec the packet, and the router on which the LEC resides ~cc~es a table for determining whether any of the destin~tion hosts, that is, members of the multicast group for the packet, are connçcted to the router. If there is a receiver for the multicast group of the packet connectçd to the router, the router sends the IP packet to the al)pr~,pliate outgoing port(s). Information relating to the hosts for a particular IP multicast group is obtained by a router through an IGMP
registration prvcess or a multicast routing protocol, such as the MOSPF protocol or the DVMRP protocol.
Figure S shows another çYernrl~ry emb~imçnt a multicast forwarding system 500 according to the present invention having a static configuration of LECs and LES/BUS entities associated with an ISELAN. In Figure 5, an ATM network .. ~. .
CA 02258129 1998-12-lo 510 includes a plurality of routers, of which only routers 521, 522, 523 and 524 are shown, and an ATM switch 525. ~ plurality of hosts, of which only hosts 551, 552and 553 are shown, can be conn~ted to ATM network 510 through a router via, for example, a dial-up line using the Point-to-Point Protocol (PPP), connected to a LAN
S (not shown) that is connected to a router, by a private line, or through a downstream router, such as router 524. Different host connection alternatives are viable.
ATM switch 525 includes ISELAN 540 having a predetermined number of preconfigured LES/BUS entities, with each BUS being design~t~d for a particular range of multicast IP addresses and is scalable within the expected traffic for the dçsign~P~l address range. For clarity, only three LES/BUS entities are shown.
ISELAN 541 includes an LES/BUS entity formed by an LES 561 and a BUS 571.
Similarly, ISELAN 542 includes a LES 562 and a BUS 572, and ISELAN 543 includes a LES 563 and a BUS 573. All LESs and BUSs can reside on the same physical device or can be distributed across multiple devices. Similarly, a prede~lnlined number of LECs coll~sponding to each BUS are preconfigured on eachrouter. The multicast IP address ranges and the correspondence QoS for each address range are made available in a well-known manner, such as an Internet web-page, so that sources can select from available mnlti~ct IP addresses.
A point-to-multipoint co~-n~ion 591 conne~ts BUS 571 to LECs 531, 534 and 537. Connection 591 is unidirectional in that BUS 571 is a source and each CA 02258129 1998-12-lo LEC is a leaf. Each of LECs 531, 534 and 527 also connect to BUS 571 with a point-to-point conn~!;on 590 so that packets can be forwarded to BUS 571.
Similarly, each of the LESs 561, 562 and 563 are connected to specific LECs using both point-to-multipoint and point-to-point conn~ctions that are not shown in Figure 5, 5 are well-defined by ATM Forum LAN Emulation specification.
Router 521, for example, receives an IP packet from host 551 that is ~estineJ to an IP multicast address, such as 225Ø1Ø Router 521 in~pect~ the packet in a well-known manner and determines that the destin~tion address is an IP
multicast address. Router 521 ~rce.sses the multicast-forwarding table con~ined within router 521 for determining which LEC residing on router 521 is design~ted for supporting the class D address of the multicast packet. An exemplary multicast-forwarding table contained in router 521 is shown in Table 1.
IP multicast address Destination address 15224Ø0.0 - 225Ø1.0 LEC 531 225Ø1.I - 230Ø8.0 LEC 532 230Ø8.1-239.255.255.255 LEC 533 Based on the exemplary entries in Table I, the IP packet is sent to LEC
- 20 531.Upon receipt of the packet, LEC 531 resolves the ATM address of the BUS by sPn(ling an address resolution query (LE_ARP_REQUEST) message to a LES 561 for the bro~dc~ct group address. In response, LES 561 returns the ATM address of the CA 02258129 1998-12-1o W O 98/47309 PCT~US98/07317 destin~tion LEC. LEC 531 forwards the multicast packet to BUS 571 on connection 590. BUS 571, in turn, forwards the packet using conne~tion 591 to LECs 531, 534and 537. LEC 531 discards the packet to prevent looping. LEC 534 residing on router 522 receives and forwards the packet to the Layer-3 plocessor residing onrouter 522. Router 522 deterrnines whether there is a host ~tt~.hed to any of the non-ATM ports connected to router 522 that should receive the packet. If so, router 522 fo~ ls the packet to port 593, for example, so that host 552 can receive the packet.
If there are no hosts connected to router 522 that should receive the packet, the packet is discarded.
In another implement~tion of a mnlti~st forwarding system according to the present invention, each router can dynamically create LECs dyn~rnic~lly when there are either new hosts explicitly joining a multicast group, or new sources sending multicast packets to a multicast group. Explicitly joining members become known to a router because a host that is intelesl~d in joining a multicast group sends an IGMP
packet to the router to which the host is directly conne~teA informing the router of the interest in receiving multicast packets addressed to a specific address. In response, the router informs lja~nt router(s) of the new ll,el.lber host by sentling multicast routing update messages using well-known protocols indicating that there is interest in receiving multicast packets at a particular multicast address. As previously mentionffl~ each router learns which multicast addresses are of interest using an IGMP registration process.
Figure 6 is a s~h~ tic block diagram showing a multicast forwarding system 600 according to the present invention that can be dynamically reconfigured 5 using an LECS for creating LECs and LES/BUS entities within an ISELAN. Figure 6 has b~ci~lly the same system topology as MFS 500 shown in Figure 5. For clarity, only three LES/BUS entities are shown. In Figure 6, an ATM network 610 includes a plurality of routers, of which only routers 621, 622, 623 and 624 are shown, and an ATM switch 625. A plurality of hosts, of which only hosts 651, 652 and 653 are shown, can be co~-ne~ to ATM network 610 through a router via, for exarnple, a dial-up line using the Point-to-Point Protocol using a varie~ of different techniques. ATM switch 625 includes ISELAN 640. For clarity, only three LES/BUS entities are shown. ISELAN 641 includes an LES/BUS entity formed by an LES 661 and a BUS 671. Similarly, ISELAN 642 includes a LES 662 and a BUS
672, and ISELAN 643 includes a LES 663 and a BUS 673.
A point-to-multipoint connection 691 connects BUS 671 to LECs 631, 634 and 637. Each of LECs 631, 634 and 627 also connect to BUS 671 with a point-to-point connection 690 so that packets can be forwarded to BUS 671. Similarly, each of the LESs 661, 662 and 663 are connected to specific LECs using both point-CA 02258129 1998-12-lo W O 98t47309 PCT~US98/07317 to-multipoint and point-to-point conneclions that are not shown in Figure 6, are well defined by ATM Forum LAN F.m~ tion specification.
In Figure 6, a router 621, for example, receives an IP packet from a host 651, for example, that is either directly conne~tP~l to router 621 or connected to 5 a downstream router (not shown) that is connected to router 621. Using well-known techniques, router 621 de~llllines whether the destin~tion address of the packet is an IP multicast address. Router 621 ~ccesses the multicast forwarding table contained in router 621 for detel,nining whether there is an LEC residing on router 621 that has already been created for forwarding the packet. When such an entry does not exist in 10 the multicast forwarding table, router 621 creates a new entry in the multicast forwarding table, such as line 1 of Table 2, that provides a new LEC ~ignment for the multicast address, such as 225Ø1.0, contained in the packet. Router 621 then creates a new LEC that is resident on router 621.
In most cases, an entry will have already been created by a LECS 601 15 or as a result of a previously-received IP packet having the same destin~tion address.
When an entry for the IP address exists, router 621 reads the destin~tion address from the table. An exemplary dyn~mi~lly-created multicast forwarding table contained in router 621 is shown in Table 2.
CA 02258129 1998-12-lo W O 98/47309 PCT~US98/07317 IP Multicast Address Destination Address 225Ø1.0 LEC 631 226.1Ø9 LEC 632 228.128Ø8 LEC 633 When LEC 631 is a newly-created LEC, LEC 631 connects to a LECS
601, via connection 692, for determining which LES/BUS to connect to. LECS 601 pelro-,-,s a table look-up to determine whether a LES/BUS entity has already been 10 created for the multicast address contained in the data packet. When there is a t~ble entry already created, LECS 601 returns the ATM address of the already-created LES, for e~mr~le, LES 661. Otherwise, LECS 601 creates a new table entry by sele~tin~ one of the available, but unused, LESs residing within ISELAN 640 for the new multicast group, activates the sele~tçd LES, and returns the ATM address for the sPle~ted LES, such as LES 661, to LEC 631. An exemplary LECS table contained in LECS 601 is shown in Table 3.
Multicast Address LES ATM Address 225Ø1.0 47.00.10.. 1 (LES 661) 226.1.3.4 47.00.10.. 2 (LES 662) 229.67Ø1 47.00.10.. 3 (LES 663) Subsequently, LEC 631 connects to LES 661 and BUS 671. LEC 631 resolves the MAC address of the dçstin~tion multicast address for the multicast ATM
,, ....... ... ~ .. ~ . ,............. ...... .. _ address by s~ntling an address resolution query (LE_ARP_REQUEST) message to LES 661. In response, LES 661 returns the ATM address for BUS 671. LEC 631 forwards the multicast packet to BUS 671 on connection 690. BUS 671, in turn, forwards the packet to LECs 631, 634 and 637 using connection 691. LEC 631 5 discards the packet to prevent looping.
LEC 634 on router 622 receives and forwards the packet to the Layer-3 processor residing on router 622. Router 622 determines whether there is a host ~ttzlrlled to any of its non-ATM ports that has an interest in receiving the packet. If there is no interested host, router 622 discards the packet. Otherwise, router 622 10 folw~ds the packet to those port to which interested hosts are connected.
The dynarnic approach of the present invention allows LECs and LES/BUS entity resoul~s to be allocated to each multicast group when a session manager builds an ISELAN or when data starts flowing. Thus, there are no dedicated ISELAN resources allocated, but unuse~, as with the static configuration of LECs and 15 LES/BUS entities of the present invention, as shown in Figure 5.
While "dynamic" multicast forwarding system 600 overcomes some of the drawbacks of the "static" multicast forwarding system, shown in Figure 5, system 600 does not provide any technique for tightly-controlled multicast groups, that is, an applic~ion triggered multicast group in which only eligible hosts can join a multicast 20 group. Figure 7 is a sCllem~ic block diagram showing a multicast forwarding system .
CA 02258l29 l998-l2-lO
700 according to the present invention that can be dyn~nlic~lly reconfigured using a .Sçssion Manager for creating LECs and LES/BUS entities within an ISELAN. Figure 7 has b~ir~lly the same system topology as MFS 600 shown in Figure 6.
In Figure 7, host 65 1, for example, initially 5/ccf c~es a web-based 5 multicast session manager 701 for joining a particular multicast group. Session manager 701 ~-lthP-n~ir~tes the user at host 651 and then provides a screen that permits existing and registered multicast sessions to be viewed, as well as the ability to create a new multicast session. A variety of additional filters or parameters, such as start time, bandwidth required, closed user groups, etc., can also be spe~-ified through 10 interface provided by the web-based multicast session manager. The values entered for parameters, such as bandwidth and cell delay variation, are used in setting up a circuit having a specified Quality of Service. Once the entries are complete, they are entered into a d~t~b2cr on session manager 701.
Session manager 701 is responsible for monitoring the start of a 15 multicast session and registration of participants. In order to build an ISELAN for a multicast session, the steps that have been previously outlined for dynamically creating an ISELAN must be ~Çurllled. When the session actually begins and the traffic begins to ~low through the routers, the entire ISELAN will be setup and engaged.
In addition to creating the Multicast ELANs, Session Manager 701 also has the responsibility of removing a LEC from a router when a host that was interested in a multicast session decides to drop out of the group, leaving no interested hosts conn~ct~ to the router or downstream from the router. Lastly, when S an entire multicast session is over, the LES/BUS entity and all the LECs that were a part of the session are removed and the resources made available for other multicast sessions.
While the present invention has been described in connection with the illustrated embo~iment~, it will be appreciated and understood that modifications may 10 be made without departing from the true spirit and scope of the invention.
Claims (12)
What is claimed is:
1. A method of forwarding multicast data packets across a plurality of telecommunications subnets interconnected by routers, the method comprising the steps of:
receiving a multicast data packet within a subnet of the plurality of telecommunications subnets;
determining a multicast IP address for the multicast data packet;
determining a Broadcast Unknown Server associated with the multicast IP address for the multicast data packet;
sending the multicast data packet to the Broadcast Unknown Server associated with the multicast IP address for the multicast data packet using a point-to-point connection;
sending the multicast data packet inter-subnet from the Broadcast Unknown Server to each router associated with the multicast IP address for the multicast data packet using a point-to-multipoint connection, at least one multicast host being connected to a subnet that is different from the subnet in which the multicast data packet was received.
receiving a multicast data packet within a subnet of the plurality of telecommunications subnets;
determining a multicast IP address for the multicast data packet;
determining a Broadcast Unknown Server associated with the multicast IP address for the multicast data packet;
sending the multicast data packet to the Broadcast Unknown Server associated with the multicast IP address for the multicast data packet using a point-to-point connection;
sending the multicast data packet inter-subnet from the Broadcast Unknown Server to each router associated with the multicast IP address for the multicast data packet using a point-to-multipoint connection, at least one multicast host being connected to a subnet that is different from the subnet in which the multicast data packet was received.
2. The method according to claim 1, wherein the step of receiving the multicast data packet includes the steps of:
receiving a data packet;
determining whether the data packet is a multicast data packet; and sending the data packet to a destination address for the data packet using an intra-subnet technique when the data packet is determined to not be a multicast data packet.
receiving a data packet;
determining whether the data packet is a multicast data packet; and sending the data packet to a destination address for the data packet using an intra-subnet technique when the data packet is determined to not be a multicast data packet.
3. The method according to claim 1, wherein the step of sending the multicast data packet to a Broadcast Unknown Server includes the steps of:
accessing a multicast forwarding database for determining a LAN
Emulation Client associated with the multicast IP address; and sending the multicast data packet to the Broadcast Unknown Server through the LAN Emulation Client when the multicast forwarding database includes information associating the multicast IP address with the LAN Emulation Client.
accessing a multicast forwarding database for determining a LAN
Emulation Client associated with the multicast IP address; and sending the multicast data packet to the Broadcast Unknown Server through the LAN Emulation Client when the multicast forwarding database includes information associating the multicast IP address with the LAN Emulation Client.
4. The method according to claim 3, wherein the multicast forwarding database associates a range of multicast IP addresses with the LAN Emulation Client.
5. The method according to claim 3, wherein when the multicast forwarding database does not include information associating the multicast IP address, the method further comprises the steps of:
creating a LAN Emulation Client for the multicast IP address; and associating the LAN Emulation Client with the multicast IP address in the multicast forwarding database.
creating a LAN Emulation Client for the multicast IP address; and associating the LAN Emulation Client with the multicast IP address in the multicast forwarding database.
6. The method according to claim 5, wherein when no Broadcast Unknown Server is associated with the multicast IP address of the multicast data packet, the method further includes the step of creating a Broadcast Unknown Server for the multicast IP address.
7. The method according to claim 5, further comprising the steps of:
creating a multicast group having the multicast IP address; and creating a LAN Emulation Server for the multicast IP address.
creating a multicast group having the multicast IP address; and creating a LAN Emulation Server for the multicast IP address.
8. A multicast forwarding system for forwarding multicast data packets across a plurality of telecommunications subnets, the system comprising:
a Broadcast Unknown Server associated with a multicast IP address;
and a router connected to a subnet of the plurality of telecommunications subnets, the router receiving a multicast data packet having a multicast IP address and sending the multicast data packet to the Broadcast Unknown Server, the Broadcast Unknown Server sending the multicast data packet inter-subnet to each router associated with the multicast IP address for the multicast data packet using a point-to-multipoint connection, at least one multicast host being connected to a subnet that is different from the subnet from which the multicast data packet was received.
a Broadcast Unknown Server associated with a multicast IP address;
and a router connected to a subnet of the plurality of telecommunications subnets, the router receiving a multicast data packet having a multicast IP address and sending the multicast data packet to the Broadcast Unknown Server, the Broadcast Unknown Server sending the multicast data packet inter-subnet to each router associated with the multicast IP address for the multicast data packet using a point-to-multipoint connection, at least one multicast host being connected to a subnet that is different from the subnet from which the multicast data packet was received.
9. The system according to claim 8, wherein the router receives a data packet and determines whether the data packet is a multicast data packet, the router sending the data packet to a destination address of the data packet using an intra-subnet technique when the data packet is determined to not be a multicast data packet.
10. The system according to claim 8, wherein the router includes a multicast forwarding database containing information relating to a LAN Emulation Client associated with the multicast IP address of the multicast data packet, the router accesses the multicast forwarding database in response to receiving the multicast data packet for determining the LAN Emulation Client associated with the multicast IP
address of the multicast data packet, and wherein the multicast data packet is sent to the Broadcast Unknown Server through the LAN Emulation Client when the multicast forwarding database includes information associating the multicast IP address with the LAN Emulation Client.
address of the multicast data packet, and wherein the multicast data packet is sent to the Broadcast Unknown Server through the LAN Emulation Client when the multicast forwarding database includes information associating the multicast IP address with the LAN Emulation Client.
11. The system according to claim 10, wherein the multicast forwarding database associates a range of multicast IP addresses with the LAN Emulation Client.
12. The system according to claim 10, wherein when the multicast forwarding database in the router does not include information associating the multicast IP address the router creates a LAN Emulation Client for the multicast IP
address, and associates the LAN Emulation Client with the multicast IP address in the multicast forwarding database.
address, and associates the LAN Emulation Client with the multicast IP address in the multicast forwarding database.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US4326797P | 1997-04-17 | 1997-04-17 | |
| US60/043,267 | 1997-04-17 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CA2258129A1 true CA2258129A1 (en) | 1998-10-22 |
Family
ID=21926307
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002258129A Abandoned CA2258129A1 (en) | 1997-04-17 | 1998-04-16 | Ip multicast over routed atm network using lane |
Country Status (5)
| Country | Link |
|---|---|
| US (1) | US6483832B1 (en) |
| EP (1) | EP0943223A1 (en) |
| JP (1) | JP2000505279A (en) |
| CA (1) | CA2258129A1 (en) |
| WO (1) | WO1998047309A1 (en) |
Families Citing this family (40)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6873627B1 (en) | 1995-01-19 | 2005-03-29 | The Fantastic Corporation | System and method for sending packets over a computer network |
| US6683870B1 (en) * | 1997-02-10 | 2004-01-27 | Mci Communications Corporation | Method and system for multicasting call notifications |
| JP2002519891A (en) * | 1998-06-25 | 2002-07-02 | エムシーアイ・ワールドコム・インコーポレーテッド | Method and system for broadcasting call notifications |
| US6628661B1 (en) * | 1998-08-27 | 2003-09-30 | Intel Corporation | Spanning tree recovery in computer networks |
| US6563793B1 (en) | 1998-11-25 | 2003-05-13 | Enron Warpspeed Services, Inc. | Method and apparatus for providing guaranteed quality/class of service within and across networks using existing reservation protocols and frame formats |
| US6611872B1 (en) * | 1999-01-11 | 2003-08-26 | Fastforward Networks, Inc. | Performing multicast communication in computer networks by using overlay routing |
| JP3418563B2 (en) * | 1999-01-20 | 2003-06-23 | 昇作 川合 | Network communication system |
| US6640251B1 (en) * | 1999-03-12 | 2003-10-28 | Nortel Networks Limited | Multicast-enabled address resolution protocol (ME-ARP) |
| DE19912547A1 (en) * | 1999-03-19 | 2000-09-28 | Bosch Gmbh Robert | Method, center and terminal for the transmission of messages to terminals in a telecommunications system |
| JP3662768B2 (en) * | 1999-05-10 | 2005-06-22 | 株式会社日立製作所 | Network connection method and apparatus |
| JP3788892B2 (en) * | 1999-07-16 | 2006-06-21 | 富士通株式会社 | Intercommunication system |
| US6721318B1 (en) * | 1999-07-29 | 2004-04-13 | Nortel Networks Limited | Extending router functionality to report static group membership |
| US7974192B2 (en) * | 1999-10-13 | 2011-07-05 | Avaya Inc. | Multicast switching in a distributed communication system |
| US6684253B1 (en) * | 1999-11-18 | 2004-01-27 | Wachovia Bank, N.A., As Administrative Agent | Secure segregation of data of two or more domains or trust realms transmitted through a common data channel |
| US6785294B1 (en) * | 1999-12-30 | 2004-08-31 | Intel Corporation | Methods and apparatuses for supporting IGMP and GMRP concurrently |
| US7065079B1 (en) * | 2000-05-04 | 2006-06-20 | Cisco Technology, Inc. | VC sharing for multicast in a computer network |
| US6732182B1 (en) * | 2000-05-17 | 2004-05-04 | Worldcom, Inc. | Method for generating packet loss report by a data coordinator in a multicast data transmission network utilizing a group shortest path tree |
| US8429296B2 (en) * | 2001-03-06 | 2013-04-23 | Pluris, Inc. | Method and apparatus for distributing routing instructions over multiple interfaces of a data router |
| JP2002290458A (en) * | 2001-03-26 | 2002-10-04 | Fujitsu Ltd | Multicast system |
| JP2002335281A (en) * | 2001-05-07 | 2002-11-22 | Ntt Docomo Inc | Multicast packet distribution method and system, address structure of packet, and mobile unit |
| US7103011B2 (en) | 2001-08-30 | 2006-09-05 | Motorola, Inc. | Use of IP-multicast technology for 2-party calls in mobile communication networks |
| ATE367026T1 (en) * | 2001-09-28 | 2007-08-15 | Motorola Inc | METHOD AND DEVICE FOR IP MULTIPLE TRANSMISSION OVER A BROADCAST CHANNEL |
| US7023813B2 (en) * | 2002-12-31 | 2006-04-04 | Motorola, Inc. | Methods for managing a pool of multicast addresses and allocating addresses in a communications system |
| US7366780B2 (en) * | 2002-12-31 | 2008-04-29 | Motorola, Inc. | System and method for controlling and managing sessions between endpoints in a communications system |
| JP3798754B2 (en) * | 2003-03-13 | 2006-07-19 | インターナショナル・ビジネス・マシーンズ・コーポレーション | Broadcast between subnetworks connected through a router |
| KR20050008081A (en) * | 2003-07-14 | 2005-01-21 | 삼성전자주식회사 | The Registration method in High Rate Packet Data System |
| US7925778B1 (en) * | 2004-02-13 | 2011-04-12 | Cisco Technology, Inc. | Method and apparatus for providing multicast messages across a data communication network |
| US7756033B2 (en) * | 2004-05-03 | 2010-07-13 | Verizon Business Global Llc | Systems and methods for managing multicast data transmissions |
| US8619774B2 (en) * | 2004-10-26 | 2013-12-31 | Cisco Technology, Inc. | Method and apparatus for providing multicast messages within a virtual private network across a data communication network |
| CN100393069C (en) * | 2004-12-29 | 2008-06-04 | 中兴通讯股份有限公司 | Method of differentiating multiple services for anti IP data stream in multicast to impact communication system |
| US8588210B2 (en) * | 2005-07-22 | 2013-11-19 | Motorola Solutions, Inc. | Method and apparatus for floor control in a communication system |
| US7822027B2 (en) | 2006-10-05 | 2010-10-26 | Cisco Technology, Inc. | Network routing to the socket |
| US8208463B2 (en) * | 2006-10-24 | 2012-06-26 | Cisco Technology, Inc. | Subnet scoped multicast / broadcast packet distribution mechanism over a routed network |
| US9787490B2 (en) * | 2011-01-04 | 2017-10-10 | Motorola Solutions, Inc. | Method of aggregating conventional resources upon losing connectivity to a master system site |
| US10025279B2 (en) * | 2013-06-18 | 2018-07-17 | NuLEDs, Inc. | Controlling loads and collecting building information via IP networks |
| US9438435B2 (en) * | 2014-01-31 | 2016-09-06 | Intenational Business Machines Corporation | Secure, multi-tenancy aware and bandwidth-efficient data center multicast |
| US9749221B2 (en) | 2015-06-08 | 2017-08-29 | International Business Machines Corporation | Multi-destination packet handling at overlay virtual network tunneling endpoints |
| US10177869B2 (en) * | 2016-09-26 | 2019-01-08 | Huawei Technologies Co., Ltd. | Systems and methods for reducing bandwidth overhead |
| CN109981534B (en) * | 2017-12-27 | 2021-03-05 | 华为技术有限公司 | Authentication method, equipment and system |
| KR101986099B1 (en) * | 2018-01-05 | 2019-06-05 | (주)에프씨아이 | Method and Apparatus for Filtering for Reducing Wake-UP Frequency |
Family Cites Families (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1078996C (en) | 1995-07-05 | 2002-02-06 | 西门子公司 | Process for determining a target ATM address |
| US6005864A (en) * | 1995-07-14 | 1999-12-21 | 3Com Corporation | Protocol for optimized multicast services for a connection oriented network providing lan emulation |
| US5752003A (en) * | 1995-07-14 | 1998-05-12 | 3 Com Corporation | Architecture for managing traffic in a virtual LAN environment |
| US5812552A (en) * | 1996-03-19 | 1998-09-22 | At & T Corp | Method and apparatus for dynamically forming multimedia emulated local area networks |
| US5909441A (en) * | 1997-04-11 | 1999-06-01 | International Business Machines Corporation | Apparatus and method for reducing frame loss in route switched networks |
-
1998
- 1998-04-14 US US09/060,292 patent/US6483832B1/en not_active Expired - Fee Related
- 1998-04-16 CA CA002258129A patent/CA2258129A1/en not_active Abandoned
- 1998-04-16 WO PCT/US1998/007317 patent/WO1998047309A1/en not_active Application Discontinuation
- 1998-04-16 EP EP98918121A patent/EP0943223A1/en not_active Withdrawn
- 1998-04-16 JP JP10544133A patent/JP2000505279A/en active Pending
Also Published As
| Publication number | Publication date |
|---|---|
| WO1998047309A1 (en) | 1998-10-22 |
| JP2000505279A (en) | 2000-04-25 |
| US6483832B1 (en) | 2002-11-19 |
| EP0943223A1 (en) | 1999-09-22 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US6483832B1 (en) | IP multicast over routed ATM network using lane | |
| US6563830B1 (en) | Multicast registration of all multicast flows in an asynchronous transfer mode based emulated LAN | |
| US5752003A (en) | Architecture for managing traffic in a virtual LAN environment | |
| US8559444B2 (en) | Controlling data link layer elements with network layer elements | |
| US6639901B1 (en) | Apparatus for and method for supporting 802.1Q VLAN tagging with independent VLAN learning in LAN emulation networks | |
| US7835276B2 (en) | Admission control mechanism for multicast receivers | |
| US6289017B1 (en) | Method of providing redundancy and load sharing among multiple LECs in an asynchronous mode network | |
| Cisco | Configuring Transparent Bridging | |
| Cisco | Configuring the ATM Router Module Interfaces | |
| Cisco | Configuring ATM Router Module Interfaces | |
| Cisco | Configuring ATM Router Module Interfaces | |
| Cisco | Configuring Transparent Bridging | |
| Cisco | Configuring Transparent Bridging | |
| Cisco | Configuring ATM Router Module Interfaces | |
| Cisco | Configuring Transparent Bridging | |
| Cisco | Configuring Transparent Bridging | |
| Cisco | Configuring IP Multicast Routing | |
| Cisco | Configuring ATM Router Module Interfaces | |
| Cisco | Configuring ATM Router Module Interfaces | |
| Cisco | Configuring IP Multicast Routing | |
| Cisco | Configuring IP Multicast Routing | |
| Cisco | Configuring the ATM Router Module Interfaces | |
| Cisco | Configuring Transparent Bridging | |
| Cisco | Network Connections | |
| Cisco | Network Connections |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| FZDE | Dead |