CA2105040C - Inter-domain multicast routing - Google Patents
Inter-domain multicast routingInfo
- Publication number
- CA2105040C CA2105040C CA002105040A CA2105040A CA2105040C CA 2105040 C CA2105040 C CA 2105040C CA 002105040 A CA002105040 A CA 002105040A CA 2105040 A CA2105040 A CA 2105040A CA 2105040 C CA2105040 C CA 2105040C
- Authority
- CA
- Canada
- Prior art keywords
- multicast
- gateway
- receiving stations
- group
- subnetworks
- 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.)
- Expired - Fee Related
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/1836—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast with heterogeneous network architecture
-
- 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/185—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast with management of multicast group membership
-
- 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
Abstract
Disclosed are a method and a system for transmitting a message or data packet from a single sender to a plurality, i.e. a group of receivers, usually called multicasting, within a conventional unicast transmission network, i.e. a network basically not equipped to handle such multicast transmissions, consisting of a plurality of subnetworks. The nodes or gateways connecting the subnetworks maintain tables of multicast receiving stations (or groups of such) and the header of each message includes information defining the groups of the addressed multicast receiving stations.
Description
SZ9-92-009 2 1 ~ 5 ~ ~ ~
INTER-DOMAIN MUL~I~AST ROUTING
Description Field of the Invention In computer networks, routing protocols are ~sed to distribute information that allows to determine how to send a data packet or a message from any point in that network to its intended destination. In many cases, a data packet or message is sent from a single source, the sender, to a single receiver; this is usually called unicasting. Today's computer networks have elaborate routing protocols to support or assure safe, fast, and reliable execution of such unicast transmissions. If a data packet or message must, however, be sent from a single sending source to a group of receiving stations within a network - usually called multicasting - it is very inefficient, if at all possible, to rely on traditional unicast routing protocols for this purpose. For this, the present invention provides a solution; it relates to multicasting, in particular to a method of multicasting messages in a complex network that is originally equipped only for unicas-t transmission.
Background and Objects of the Invention Existing state-of-the-art routing protocols, such as the Inter-Domain Routing Protocol (IDRP), as disclosed e.g. in ISO "Information Processing Systems - Telecommunications and Information Exchange between Systems - Protocol for the Exchange Inter-Domain Routing Information Among Intermediate Systems to Support Forwarding of ISO 8473 PDUs", ISO/DIS CD
10747, 1991, being standardized by the International Standards Organization, ISO, provide a framework for routing unicast packets, that is, packets sent to a single destination.
Often, a key requirement of computer networks in general, and of applicant's Multi-Protocol Transport Network (abbre~Jiated MPTN in the following) specifically, is to allow to multicast data packets, which are sent from a 21050~
particular source to a group of destinations. Generally speaking, this invention gives a solution to this requirement by teaching a method of and a system for multicasting using a set of new protocols in combination with existing routing protocols (e.g. IDRP) to support multicasting in a computer network of arbitrary size and topology. It has characteristics which maXe it suitable for such an environment that are not found in any existing multicasting protocols.
Brief Description of the Drawings Figure 1 is a multi-protocol transport network (MPTN) comprised of three subnetworks (already discussed with the prior art above);
Figure 2 is an example for another MPTN (also already discussed above);
Figure 3 is an example of the information learned by gateways from attached subnetworks;
Figure 4 is a detail in a subnetworlc, namely all nodes with a common address prefix in such a subnetwork;
(Figures 2 and 3 show essentially the same arrangement, the reference numbers are chosen such that the last digit of each number identifies the same part in each figure, i.e.
"21" in Fig. 2 is the same part as "31" in Fig. 3);
Figure 5 shows various nodes with a given address prefix in different subnetworks;
Fi~ure 6 shows the so-called MPTN split net ID support.
~n the following, background and objects of the invention shall be described i.n more detai1. It should be understood, however, that the invention is not in any way restricted to be used within the type of network described hereinbelow.
Further examples can be found in other parts of the description.
_ SZ9-92-009 3 2 t ~ 0 A widely used protocol set such as the IBM~ Multi-Pro-tocol Transport Network provides connectivity to computer applications, regardless of the network to which they are attached. Thus, as illustrated in Fig. 1, two applications attached to different subnetworks in the same MPTN 11 can communicate. As shown in Fig. 1, a client application 12 attached to a first subnetwork 13, e.g. a NetBIOS subnetwork (a trademark of the applicant), can communicate with a compatible server application 14 attached to a second subnetwork 15, e.g. a System Network Architecture (SNA, which is also a trademark of the applicant) subnetwork. MPTN
gateways 16 and 17 are required to join the three different subnetworks 13, 15, and 18 into a single logical network (the MPTN); the gateways are connected via the third subnetwork 18, e.g. a Transmission Control Program/Internet Protocol (TCP/IP) network.
A key function of the MPTN gateways 16 and 17 is to route messages from their source (e.g., the client application 12) to the destination (e.g., the server application 14). This problem is difficult for the following reasons:
- A path between the source and destination must be found that satisfies the requirements of the application (e.g., security, speed, reliability).
- The MPTN may be very large, with many subnetworks and gateways. This can result in a very complex network topology, and therefore complex routing decisions need to be made at the gateways.
- Due to link and node failures, or the installation of new equipment, the topology, and thus the correct routing decisions, change in real time.
To solve these problems, MPTN gateways make use of the routing protocol mentioned above that was standardized by the International Standards Organization, called the Inter-Domain Rou-ting Protocol (IDRP). IDRP defines the formats and procedures of a protocol for routing from a single source to a single destination in a network of _ SZ9-92-009 2~aOl~
arbitrary topology and size. However, IDRP does not support multicasting, that is, delivery of a message from a single source to multiple destinations. On the other hand, multicasting is essential in MPTN for a number of reasons.
~irst, some subnetworks support multicasting and, therefore, applications running on those subnetworks -take advantage of this feature. In order to provicle connectivi-ty to such applications, mu]ticasting must be supported in the internetworking environment. Second, some MPTN control protocols are based on multicasting. For example, protocols for locating a resource require that a search for that resource be distribu-ted to all gateways attached to subnetworks in which it might be located.
Some examples of the problems associated with multicasting in an internetwork environment are now described making reference to the simple MPTN illustrated in Fig. 2. In this example, a multicast is initiated by an application in subnetwork W (21) that should be delivered to destinations in subnetworks X (22) and Z (24). There are no destinations in subnetwork Y (23). The problems associated wi-th such an operation include:
- It is no-t acceptable -to generate separate (unicas-t) messages to all destinations since this would create an unnecessary load on the MPTN resources. For example, in Fig.
2, such a unicast strategy would necessitate that one message for each destination be sent on the link between gateway A (25) and gateway B (26) instead of just a single multicast message.
- It is not accep-table to multicast the message to every subnetwork in the MPTN. In the example, subnetwork Y (23~
should not receive a multicast destined only to nodes in subnetworks X (22) and Z (24). Although not illustrated by -the example, it is clear that in a large MPTN with many subnetworks and many different multicast groups, such a flooding strategy would not be acceptable.
- A given packet should only be multicast once to a given subnetwork. In the example network, there are two paths from .
~ SZ9-92-009 5 21~ai)~0 gateway B (26) to subnetwork X (22), via gateway D (28) and via gateway C (29) direct. Subnetwork X (22) should, however, only receive a single copy oE the mul-ticast from the source in subnetwork W (21). This rule must hold regardless of the number o~ yateways attached to subnetwork X (22), or the number of paths between a source and a particular destination subnetwork. This is important to minimize the load placed on subnetworks due to multicast traffic, and to avoid duplication of packet delivery which may necessitate error recovery protocols for some applications.
Prior Art For a better understanding of the invention, solutions for multicasting messages in other environments, and existing solutions in internetworking environments will be reviewed.
Local Area Networks (LANs) LANs are a very special type of subnetworks since they naturally support a broadcast function, such -that a single message is easily delivered to all nodes. The most common LAN multicast strategy is thereEore to broadcast messages, and let each attached computer :Eilter those messages not required by local users. An e~ample is given by S.E.
Deering and D.R. Cheriton in "Multicast Rou-ting in Datagram Internetworks and Extended LANs", ACM Transactions on Computer Systems , Vol. 8, No. 2, pp. 85-110, ACM, May 1990.
However, such a strategy seems unsuitable for a large internetwork, as previously explained. It should also be mentioned that essentially the same observations hold for Metropolitan Area Networks IMANs).
When LAN segments are interconnected by bridges, these can selectively filter LAN messages so that they are only broadcast on segments where at least one node is a destination ~or a mul-ticast. These protocols work as follows (see Deering and Cheriton, cited above, for variations on this basic algorithm):
. :
,, ~ :::
, . : .. ~ . . . . ..
CA 02l0~040 l997-l2-22 1. Group members broadcast their existence on the LAN to which they are attached. These broadcasts are forwarded by bridges onto all LAN segments so that all bridges can learn the location of group members.
2. When a multicast packet for a group is received, only bridges on the path to one or more members of that group forward the packet. Thus, flooding of all LAN segments for each multicast is avoided.
A restriction of such LAN-based multicasting is that no loops are allowed in the topology, i.e. there cannot be multiple paths via bridges between any two LAN stations. This is required since otherwise the simple forwarding scheme used by the LAN bridges would result in packets being broadcast forever around any such loop. Such a scheme is unsuitable for multicasting in a large internetwork since all traffic would be forced to take the same path through the internetwork thereby creating an unacceptable load on the involved links.
Algorithms exists which allow loops to exist in the LAN
topology, but a single set of bridges is selected that form a loop-free spanning tree for forwarding multicasts. Thus, all multicast traffic is still forced to follow a single path along the branches of the spanning tree.
Ml]ltic~sting in the Internet Multicasting algorithms exist that work with routing protocols used in Internet Protocol (IP) networks. IP
networks provide routing and relaying of packets (called datagrams) over a general topology network consisting of LANs, point-to-point links, and even subnetworks such as X.25. An IP internetwork consists of a collection of such subnetworks interconnected by IP routers.
The following routing protocols used in IP networks are all based on a distance-vector (sometimes also called path-vector) routing scheme like that used in IDRP:
- Routing Information Protocol (RIP), as described by C.L.
Hedrik in "Routing Information Protocol", RFC 1058 S~9-92-009 7 2~0S0~0 (Request for Comments), NIC (Network Information Center), June 1988.
- Hello Routing Protocol, disclosed by D.L. Mills in "Experimental Multiple Path Routing Algorithm", RFC 981, NIC, March 1986.
- Border Gateway Protocol (BGP), described by K. Lougheed and Y. Rekhter in "Border Gateway Protocol (BGP)", RFC 1163, NIC, June 1990.
- Gateway-Gateway Protocol (GGP),as disclosed by R.M.
Hinden and A. Sheltzer in "DARPA In-ternet Gateway", RFC 823, NIC, September 1982.
As will be apparent later, the present invention provides a solution directly applicable to all networks based on the above (and equivalent) routing protocols.
IP multicast algorithms have been developed primarily for use with the Routing Information Protocol as disclosed by C.L. Hedrik, cited above, but are ~tsable with the other distance-vector routing algorithm.s as well. IP multicast algorithms (see, e.g. S.E. Deering and D.R. Cheriton, cited above; S.E. Deering: "Host Ex-tensions for IP Multicasting", RFC 1112, NIC, August 1988; L. Hughes and P. Thomlinson: "A
Multicast Internetwork Routing Algorithm", Proceedings of the IFIP WG 6.~ Conference on High Speed Networking, 18-22 March 1991, Berlin, pp. 183-200; D. Wait~man, C. Partridge, and S.E. Deerincl: "Distance Vector Multicast Protocol", RFC
1075, NIC, November 1988) are all variants of the Reverse Path Broadcasting algorithm described by Y.K. Dalal and R.M.
Metcalfe in "Reverse Path Forwarding of Broadcast Packets", Communications of the ACM, Vol. 21, No. 12, pp. 1040-1048, ACM, December 1978. This algorithm is similar to the LAN
multicast algorithm in -that a spanning tree is used to distribute the multicast packets, however it contains additional features to solve some of the problems associated w~th LAN multicasting. In brief, the algorithm works as follows (see S.E. Deering and D.R. Cheriton, cited above, for a more detailed description):
. . - , . . . , .. .
- : .
21~ 4~
1. Multicast packets are in:i-tially broadcast to all subnetworks in the internetwork. Packets are broadcast on a least-eost spanning tree. When a :router receives a multieast packet from some source "S", it knows that it is on the spanning tree for multicasts originating from S if its routing tables indicate tha-t it can reach node S with a lower cost than all other routers attached to a given subnetwork (this information is available in the normal IP
routing tables). If so, that router forwards the multieast paekets on the subnetwork in question. It was shown by S.E.
Deering and D.R. Cheriton, eited above, that this algorithm results in the multieast paeket being distributed to each subnetwork in the internetwork with minimum cost.
An obvious improvement of this seheme compared to the LAN
multieasting sehemes is that while here the multieast spanning tree is fixed for a given source, it is not the same for all sourees. Thus multieast traffie is distributed over many different paths in the network.
2. In order to avoid broadeas-ting multieast paekets to subnetworks that do not have members in the speeified group, a seheme is used whereby routers that receive a multicast for a partieular group that do not lie on a branch of the multieast tree that leads to ~ny members of that group diseard the multieast (there is obviously no need to forward it) and report to the predecessor in the multicast tree that this braneh of the tree may be prunecl. This proeess bagins with routers attached to "leaf subnetworksl' (subnetworks that are at the end of their respective branehes on the tree), and works its way up the branch as far as possible to restriet the distribution of multicast traffie to where it is recluired.
The IP multieas-t sehemes have the following drawbacks:
- Initially, multicasts from a given souree to a given group must be broadcas-t to the entire internet until the multieast tree for tha-t source-destination pair is pruned.
- The scheme requires that information used for pruning the multicast trees be discarded after some time so that new members that join the network on a previously pruned tree branch will eventually start receiving the multicasts. Thus, multicasts trees are continuously rebuilt and repruned, creating considerable overhead on the network links and processing nodes.
- Multicast trees exist for each source-multicast group pair~ That is, a separate logical multicast tree exists for each different source tha-t multicasts to a given group. Thus routing nodes may have to maintain an extremely large database for pruned mul-ticast trees.
For these reasons such protocols or algorithms seem unsuitable for use in the MPTN and similar architectures. A
useful algorithm should be able to utilize the routing capabilities of gateways which have no multicast intelligence.
In some more detail, the following goals or objects of the invention can be identified as requirements for providing multicast service:
1. Multicast packets mus-t not be broadcast to all subnetworks, and in fact should be restricted to being sent only to subnetworks that have a multicast group member.
2. Each multicast packet must be delivered exactly once to each destination subnetwork (i.e. duplicate multicast packets must not be created).
INTER-DOMAIN MUL~I~AST ROUTING
Description Field of the Invention In computer networks, routing protocols are ~sed to distribute information that allows to determine how to send a data packet or a message from any point in that network to its intended destination. In many cases, a data packet or message is sent from a single source, the sender, to a single receiver; this is usually called unicasting. Today's computer networks have elaborate routing protocols to support or assure safe, fast, and reliable execution of such unicast transmissions. If a data packet or message must, however, be sent from a single sending source to a group of receiving stations within a network - usually called multicasting - it is very inefficient, if at all possible, to rely on traditional unicast routing protocols for this purpose. For this, the present invention provides a solution; it relates to multicasting, in particular to a method of multicasting messages in a complex network that is originally equipped only for unicas-t transmission.
Background and Objects of the Invention Existing state-of-the-art routing protocols, such as the Inter-Domain Routing Protocol (IDRP), as disclosed e.g. in ISO "Information Processing Systems - Telecommunications and Information Exchange between Systems - Protocol for the Exchange Inter-Domain Routing Information Among Intermediate Systems to Support Forwarding of ISO 8473 PDUs", ISO/DIS CD
10747, 1991, being standardized by the International Standards Organization, ISO, provide a framework for routing unicast packets, that is, packets sent to a single destination.
Often, a key requirement of computer networks in general, and of applicant's Multi-Protocol Transport Network (abbre~Jiated MPTN in the following) specifically, is to allow to multicast data packets, which are sent from a 21050~
particular source to a group of destinations. Generally speaking, this invention gives a solution to this requirement by teaching a method of and a system for multicasting using a set of new protocols in combination with existing routing protocols (e.g. IDRP) to support multicasting in a computer network of arbitrary size and topology. It has characteristics which maXe it suitable for such an environment that are not found in any existing multicasting protocols.
Brief Description of the Drawings Figure 1 is a multi-protocol transport network (MPTN) comprised of three subnetworks (already discussed with the prior art above);
Figure 2 is an example for another MPTN (also already discussed above);
Figure 3 is an example of the information learned by gateways from attached subnetworks;
Figure 4 is a detail in a subnetworlc, namely all nodes with a common address prefix in such a subnetwork;
(Figures 2 and 3 show essentially the same arrangement, the reference numbers are chosen such that the last digit of each number identifies the same part in each figure, i.e.
"21" in Fig. 2 is the same part as "31" in Fig. 3);
Figure 5 shows various nodes with a given address prefix in different subnetworks;
Fi~ure 6 shows the so-called MPTN split net ID support.
~n the following, background and objects of the invention shall be described i.n more detai1. It should be understood, however, that the invention is not in any way restricted to be used within the type of network described hereinbelow.
Further examples can be found in other parts of the description.
_ SZ9-92-009 3 2 t ~ 0 A widely used protocol set such as the IBM~ Multi-Pro-tocol Transport Network provides connectivity to computer applications, regardless of the network to which they are attached. Thus, as illustrated in Fig. 1, two applications attached to different subnetworks in the same MPTN 11 can communicate. As shown in Fig. 1, a client application 12 attached to a first subnetwork 13, e.g. a NetBIOS subnetwork (a trademark of the applicant), can communicate with a compatible server application 14 attached to a second subnetwork 15, e.g. a System Network Architecture (SNA, which is also a trademark of the applicant) subnetwork. MPTN
gateways 16 and 17 are required to join the three different subnetworks 13, 15, and 18 into a single logical network (the MPTN); the gateways are connected via the third subnetwork 18, e.g. a Transmission Control Program/Internet Protocol (TCP/IP) network.
A key function of the MPTN gateways 16 and 17 is to route messages from their source (e.g., the client application 12) to the destination (e.g., the server application 14). This problem is difficult for the following reasons:
- A path between the source and destination must be found that satisfies the requirements of the application (e.g., security, speed, reliability).
- The MPTN may be very large, with many subnetworks and gateways. This can result in a very complex network topology, and therefore complex routing decisions need to be made at the gateways.
- Due to link and node failures, or the installation of new equipment, the topology, and thus the correct routing decisions, change in real time.
To solve these problems, MPTN gateways make use of the routing protocol mentioned above that was standardized by the International Standards Organization, called the Inter-Domain Rou-ting Protocol (IDRP). IDRP defines the formats and procedures of a protocol for routing from a single source to a single destination in a network of _ SZ9-92-009 2~aOl~
arbitrary topology and size. However, IDRP does not support multicasting, that is, delivery of a message from a single source to multiple destinations. On the other hand, multicasting is essential in MPTN for a number of reasons.
~irst, some subnetworks support multicasting and, therefore, applications running on those subnetworks -take advantage of this feature. In order to provicle connectivi-ty to such applications, mu]ticasting must be supported in the internetworking environment. Second, some MPTN control protocols are based on multicasting. For example, protocols for locating a resource require that a search for that resource be distribu-ted to all gateways attached to subnetworks in which it might be located.
Some examples of the problems associated with multicasting in an internetwork environment are now described making reference to the simple MPTN illustrated in Fig. 2. In this example, a multicast is initiated by an application in subnetwork W (21) that should be delivered to destinations in subnetworks X (22) and Z (24). There are no destinations in subnetwork Y (23). The problems associated wi-th such an operation include:
- It is no-t acceptable -to generate separate (unicas-t) messages to all destinations since this would create an unnecessary load on the MPTN resources. For example, in Fig.
2, such a unicast strategy would necessitate that one message for each destination be sent on the link between gateway A (25) and gateway B (26) instead of just a single multicast message.
- It is not accep-table to multicast the message to every subnetwork in the MPTN. In the example, subnetwork Y (23~
should not receive a multicast destined only to nodes in subnetworks X (22) and Z (24). Although not illustrated by -the example, it is clear that in a large MPTN with many subnetworks and many different multicast groups, such a flooding strategy would not be acceptable.
- A given packet should only be multicast once to a given subnetwork. In the example network, there are two paths from .
~ SZ9-92-009 5 21~ai)~0 gateway B (26) to subnetwork X (22), via gateway D (28) and via gateway C (29) direct. Subnetwork X (22) should, however, only receive a single copy oE the mul-ticast from the source in subnetwork W (21). This rule must hold regardless of the number o~ yateways attached to subnetwork X (22), or the number of paths between a source and a particular destination subnetwork. This is important to minimize the load placed on subnetworks due to multicast traffic, and to avoid duplication of packet delivery which may necessitate error recovery protocols for some applications.
Prior Art For a better understanding of the invention, solutions for multicasting messages in other environments, and existing solutions in internetworking environments will be reviewed.
Local Area Networks (LANs) LANs are a very special type of subnetworks since they naturally support a broadcast function, such -that a single message is easily delivered to all nodes. The most common LAN multicast strategy is thereEore to broadcast messages, and let each attached computer :Eilter those messages not required by local users. An e~ample is given by S.E.
Deering and D.R. Cheriton in "Multicast Rou-ting in Datagram Internetworks and Extended LANs", ACM Transactions on Computer Systems , Vol. 8, No. 2, pp. 85-110, ACM, May 1990.
However, such a strategy seems unsuitable for a large internetwork, as previously explained. It should also be mentioned that essentially the same observations hold for Metropolitan Area Networks IMANs).
When LAN segments are interconnected by bridges, these can selectively filter LAN messages so that they are only broadcast on segments where at least one node is a destination ~or a mul-ticast. These protocols work as follows (see Deering and Cheriton, cited above, for variations on this basic algorithm):
. :
,, ~ :::
, . : .. ~ . . . . ..
CA 02l0~040 l997-l2-22 1. Group members broadcast their existence on the LAN to which they are attached. These broadcasts are forwarded by bridges onto all LAN segments so that all bridges can learn the location of group members.
2. When a multicast packet for a group is received, only bridges on the path to one or more members of that group forward the packet. Thus, flooding of all LAN segments for each multicast is avoided.
A restriction of such LAN-based multicasting is that no loops are allowed in the topology, i.e. there cannot be multiple paths via bridges between any two LAN stations. This is required since otherwise the simple forwarding scheme used by the LAN bridges would result in packets being broadcast forever around any such loop. Such a scheme is unsuitable for multicasting in a large internetwork since all traffic would be forced to take the same path through the internetwork thereby creating an unacceptable load on the involved links.
Algorithms exists which allow loops to exist in the LAN
topology, but a single set of bridges is selected that form a loop-free spanning tree for forwarding multicasts. Thus, all multicast traffic is still forced to follow a single path along the branches of the spanning tree.
Ml]ltic~sting in the Internet Multicasting algorithms exist that work with routing protocols used in Internet Protocol (IP) networks. IP
networks provide routing and relaying of packets (called datagrams) over a general topology network consisting of LANs, point-to-point links, and even subnetworks such as X.25. An IP internetwork consists of a collection of such subnetworks interconnected by IP routers.
The following routing protocols used in IP networks are all based on a distance-vector (sometimes also called path-vector) routing scheme like that used in IDRP:
- Routing Information Protocol (RIP), as described by C.L.
Hedrik in "Routing Information Protocol", RFC 1058 S~9-92-009 7 2~0S0~0 (Request for Comments), NIC (Network Information Center), June 1988.
- Hello Routing Protocol, disclosed by D.L. Mills in "Experimental Multiple Path Routing Algorithm", RFC 981, NIC, March 1986.
- Border Gateway Protocol (BGP), described by K. Lougheed and Y. Rekhter in "Border Gateway Protocol (BGP)", RFC 1163, NIC, June 1990.
- Gateway-Gateway Protocol (GGP),as disclosed by R.M.
Hinden and A. Sheltzer in "DARPA In-ternet Gateway", RFC 823, NIC, September 1982.
As will be apparent later, the present invention provides a solution directly applicable to all networks based on the above (and equivalent) routing protocols.
IP multicast algorithms have been developed primarily for use with the Routing Information Protocol as disclosed by C.L. Hedrik, cited above, but are ~tsable with the other distance-vector routing algorithm.s as well. IP multicast algorithms (see, e.g. S.E. Deering and D.R. Cheriton, cited above; S.E. Deering: "Host Ex-tensions for IP Multicasting", RFC 1112, NIC, August 1988; L. Hughes and P. Thomlinson: "A
Multicast Internetwork Routing Algorithm", Proceedings of the IFIP WG 6.~ Conference on High Speed Networking, 18-22 March 1991, Berlin, pp. 183-200; D. Wait~man, C. Partridge, and S.E. Deerincl: "Distance Vector Multicast Protocol", RFC
1075, NIC, November 1988) are all variants of the Reverse Path Broadcasting algorithm described by Y.K. Dalal and R.M.
Metcalfe in "Reverse Path Forwarding of Broadcast Packets", Communications of the ACM, Vol. 21, No. 12, pp. 1040-1048, ACM, December 1978. This algorithm is similar to the LAN
multicast algorithm in -that a spanning tree is used to distribute the multicast packets, however it contains additional features to solve some of the problems associated w~th LAN multicasting. In brief, the algorithm works as follows (see S.E. Deering and D.R. Cheriton, cited above, for a more detailed description):
. . - , . . . , .. .
- : .
21~ 4~
1. Multicast packets are in:i-tially broadcast to all subnetworks in the internetwork. Packets are broadcast on a least-eost spanning tree. When a :router receives a multieast packet from some source "S", it knows that it is on the spanning tree for multicasts originating from S if its routing tables indicate tha-t it can reach node S with a lower cost than all other routers attached to a given subnetwork (this information is available in the normal IP
routing tables). If so, that router forwards the multieast paekets on the subnetwork in question. It was shown by S.E.
Deering and D.R. Cheriton, eited above, that this algorithm results in the multieast paeket being distributed to each subnetwork in the internetwork with minimum cost.
An obvious improvement of this seheme compared to the LAN
multieasting sehemes is that while here the multieast spanning tree is fixed for a given source, it is not the same for all sourees. Thus multieast traffie is distributed over many different paths in the network.
2. In order to avoid broadeas-ting multieast paekets to subnetworks that do not have members in the speeified group, a seheme is used whereby routers that receive a multicast for a partieular group that do not lie on a branch of the multieast tree that leads to ~ny members of that group diseard the multieast (there is obviously no need to forward it) and report to the predecessor in the multicast tree that this braneh of the tree may be prunecl. This proeess bagins with routers attached to "leaf subnetworksl' (subnetworks that are at the end of their respective branehes on the tree), and works its way up the branch as far as possible to restriet the distribution of multicast traffie to where it is recluired.
The IP multieas-t sehemes have the following drawbacks:
- Initially, multicasts from a given souree to a given group must be broadcas-t to the entire internet until the multieast tree for tha-t source-destination pair is pruned.
- The scheme requires that information used for pruning the multicast trees be discarded after some time so that new members that join the network on a previously pruned tree branch will eventually start receiving the multicasts. Thus, multicasts trees are continuously rebuilt and repruned, creating considerable overhead on the network links and processing nodes.
- Multicast trees exist for each source-multicast group pair~ That is, a separate logical multicast tree exists for each different source tha-t multicasts to a given group. Thus routing nodes may have to maintain an extremely large database for pruned mul-ticast trees.
For these reasons such protocols or algorithms seem unsuitable for use in the MPTN and similar architectures. A
useful algorithm should be able to utilize the routing capabilities of gateways which have no multicast intelligence.
In some more detail, the following goals or objects of the invention can be identified as requirements for providing multicast service:
1. Multicast packets mus-t not be broadcast to all subnetworks, and in fact should be restricted to being sent only to subnetworks that have a multicast group member.
2. Each multicast packet must be delivered exactly once to each destination subnetwork (i.e. duplicate multicast packets must not be created).
3. The protocols should no-t re~uire any centralized elements. They should be completely distributed.
4. The protocols should not require computation of a spanning tree from a centralized database.
5. Routing decisions for multicast packets must be flexible. Distribution of all multicasts over a fixed spanning tree for example is not acceptable.
~:~05~
~:~05~
6. The number of packets distributed must be minimi~ed. In particular, it is not acceptable to generate a separate unicast packet for each destination.
7. The cost of distributing the multicast packets must be minimized. Thus, a good path must be taken from the multicast source to each destination.
Summary of the Invention In brief, the present invention achieves the above objects by a method and a system for multicasting a message from a sending station to a plurality of receiving stations within a conventional unicast message transmission network using existing protocols by, at least in certain nodes within the network, maintaining tables of subnetworks with multicast receiving stations or tables of multicast receiving stations and by including appropriate routing information in the header of multica~t messages, as further defined in the claims.
With this invention, a solution is presen-ted that, when used in combination with distance-vector routing protocols such as the standard OSI IDRP routing protocol, disclosed in ISO
"Information Technology - Telecommunications and Information Exchange between Systems - Intermediate System to Intermediate System Intra-Domain Rou-ting Protocol for Use in Conjunction with the Protocol for Providing the Connection", ISO/DIS 10589, 1990, or any other similar protocol, such as those used in IP networks referenced above, supports multicasting in large internetworks. This solution is also usable with link-state routing protocols, such as OSPF
developed for IP networks (described by J. Moy in "OSPF
Versicn 2", RFC 1247, NIC, July 1991) and the OSI IS-IS
protocol (described in ISO/DIS 10589, cited above) and are thus applicab~e to a wide range of internetworking environments. Within the invention, three new types of protocols are presented:
1. for the distribution of routing information based on network topology and the location of multicas-t group 210~0~
members, and for the creation of routing tables using this information;
2. for efficiently forwarding multicast packets to all members of a multicast group given tha routing information from the first step; and 3. for enabling the multicast protocols to be used in the MPTN environment.
Detailed Description The following section is divided into four parts. The first part, entitled "Routing Information", describes the routing information that is distributed and the tables that are created for routing multicast packets. The second part, entitled "Multicast Packet Forwarding", describes the procedures for using the created tables to route multicast packets. Then, in the third part, entitled "Multicast with Reduced Routing Information", a description i~ given of how the amount of routing information required for the multicasting protocols can be reduced. ~inally, in part four, entitled "MPTN Use of Multicast", an example is given of how MPTN uses the protocols described in this invention.
Routing Information A brief description of the Inter-Domain Routing Protocol (IDRP) protocol is provided so that the invention may be better understood. Further details can be found in IS0/DIS
10589, referred to above.
IDRP distributes routing information between gateways in so-called Update PDUs, i.e. Update Protocol Data Units.
Update PDUs contain the following fields that are relevant to the invention.
1. Reachability Information: this field specifies the resources that can be reached along the path specified in this Update PDU. It can be the address of a specific end system, or it can be the prefix common to the addresses used by a set of end systems. A11 systems whose address contains 21~0~0 a given prefix reside in the same subnetwork, and therefore this prefix uniquely identifies this subnetwork. A type field is defined in the reachability information which indicates that the reachability information is an address prefix (type=O). Thus, different types of reachability information could be distributed in Update PDUs by defining a new type code.
Z. Quality of service: -this specifies properties like cost, delay, and security implications of using the routing information ln this update PDU.
3. Path: the routing information that specifies how to reach the end systems identified by the prefix(es) in the reachability information.
Based on received Update PDUs, gateways build routing tables, called Forwarding Information Bases (FIBs) in IDRP.
For each destination (a destination is identified by a prefix received in an Update PDU, and may thus be a single node or a set of nodes), the next gateway on the path to that destination is stored (this ~s determined from the path field in the update PDU). Exac-t]y one path for each prefix is stored for each unique se-t of quality of service parameters. This path is the one that can best provide the specified quality of service.
In the invention, a new type of xeachability information is defined, called a group identifier (groupid). A groupid is used to address a group of end systems that are to receive a particular set of multicasts. The groupid, which is chosen from the normal subnetwork address space, is therefore included as the des-tination address of a multicast packet so that the proper group of end systems is identified. The end systems addressed by a particular groupid are not necessarily located in a common subnetwork. Selecting groupids from the standard address space guarantees that they represent valid reachability information even for gateways which do not imp].ement the multicast extensions described below.
r SZ9-92-009 13 2 ~ 0 To support unicast inter-domain routin~, subnetworks report the address prefix(es) shared by its nodes to gateways.
These prefixes are used to create the Update PDUs as described above. In the invention, subnetworks also report all groupids reachable in that subnetwork.
An example is illustrated in Fig. 3. In that figure, the subnetworks with prefixes X (32) and Z (34) also have end systems in group G. They therefore report both the prefix and the groupid to the local gateways C (39) and E (37).
Subnetworks W (31) and Y (33) do not have any groupids to report, so they report only their prefixes. Note that a given subnetwork may report multiple groupids and prefixes (not illustrated).
IDRP Update PDUs are constructed as follows. Update PDUs not containing groupids are constructed as specified in IS0/DIS
CD 10747, mentioned above. Update PDUs used to advertise reachability to groupids must contain the following information:
- An address prefix of the subnetwork, and - one or more groupids for that subnetwork.
The reachability information in an Update PDU containing groupids consists of only the groupids and (one of) the address prefix(es) unique to the end systems in the subnetwork reporting the groupids, so that all gateways will be able to build an association between the subnetwork prefix and the groupids reachable in that subnetwork.
The Update PDU constructed in this manner is delivered with the reachability information field unchanged to all gateways according to t:he existing IDRP protocols. Note that this Update PDU construction is allowed by the IDRP standard, and that no other chanyes to the Update PDU construction or distribution are required.
In the example shown in Fig. 3, gateway C (39) would create an Update PDU with the following reachability information:
prefix=X, groupid=G. Similarly, gateway E (37) would create SZ9~92-009 14 , ~ ~, O ~ o an Update PDU with prefix=Z and groupid=G. Both of these Update PDUs would be distributed to all other gateways according to the IDRP protocol to allow all of them to learn the association between group G and subnetworks X and Z.
As reachability information changes (e.g., the prefix changes, or groupids are added or deleted), the changes are reported to the local gateways which use the normal IDRP
routing protoco].s to update all r~PTN gateways with the new information.
Construction of Update PDUs as specified above allows gateways to build an additional routing table which will be referred to as the Multicast Routing Table or MURT. The MURT
contains for each groupid the list of prefixes ~or subnetworks containing members of that group, as learned from Update PDUs containing groupids. How the MURT is used for routing is explained in the next section.
In the system of Fig. 3, following the distribution of the Update PDUs as described above, each gateway would have a MURT entry for groupid G, identifying X and Z as the prefixes of subnetworks in which group members are located. ~ -The remaining IDRP routing tables (e.g., the FIB as described above) are constructed according to existing IDRP
specifications. In particular the path information associated with all reachability information (including groupids) is stored in the FIB.
Thus far in this section, the procedure for constructing a MURT using the OSI IDRP routing protocol has been described.
This same procedure can be used with any distance-vector routing protocol, as e.g. described in the following references: C.L Hedrick, "Routing Information Protocol", RFC
1058, NIC, Jun~e 1988; R.M. Hinden and A Shelt~er, cited above; K. Lougheed and Y. Rekhter, cited above; D.L. ~ills, cited above. In all such protocols, Update PDUs are di~tributed to advertise reachability to a given address or address prefix. By associating groupids with each address prefix, a MURT can be constructed as described above.
,~ SZ9-92-009 15 2 1 ~ 0 A MURT can also be constructed using link-state routing protocols such as those described in IS0/DIS 10589, 1990 or in J. Moy, cited above. In those protocols, each gateway distributes reachability information in link-state PDUs, which provide information on the state of each link adjacent to that gateway, as well as all address prefixes directly reachable from that gateway. Th~se link state PDUs are forwarded unmodified to all other gateways in the system.
Therefore, by also including a list of groupids in the link state PDUs, a MURT can be constructed associating the group with a lisi of address prefixes of subnetworks in which group members reside. Both distance-vector and link-s-tate routing protocols create an FIB which is essentially eq~ivalent to that created by IDRP. Due to this, the multicast forwarding algorithm described in the next section is also applicable to these environments.
Multicast Packet Forwardinq Conceptually, once the MURT is constructed as described in the previous section, routing of multicast packets is very simple. The MURT allows the subnetworks in wh.ich members of the multicast group are located to be identified.
Furthermore, the IDRP FIB can be ~Ised to route packets to each of these subnetworks. A copy of each multicast packet could simply be routed to each of these subnetworks.
However, due to the MPTN requirements specified in the section entitled Summary of the Invention, above, regarding restrictions on the number of distributed packets, the methods and algorithms specified in this section are an essential part of this invention.
The invention also defines a Multicast Spanning-Tree Algorithm (MSTA) for routing multicast packets in an MPTN.
The MSTA is also usable in other networks that provide routing information similar to that specified in the previous section.
To assist the reader in understanding, MSTA is presented in an example before the detailed algorithms are given.
,~ SZ9-92-009 16 210aO40 The topology ~f the network u~ed in this example is illustrated in Fig. 3. Using the protocol~ of th~ p~evious section, the following routing table~ are constructed at the respective MPTN gateways: -At gateway A (35) FIB (prefix: next hop on shortest path) address prefix W: addresses wlth this prefix are located in the local subnet (31) X: the next gateway on the path to the subnet containing addresses with this prefix is Gateway B.
Y: gateway B
Z: gateway B
G: gateway B :
MURT (groupid: associated prefixes) groupid G: the prefixes associated w:ith this groupid are X,Z
At gateway B (36) FIB (preflx: next hop on shortest path) W: the next gateway on the path to the subnet containing addresses with this prefix ~s Gateway A.
X: gateway C
Y: gateway D
Z: gateway E
G: gateway r.
MURT (groupid: associated prefi.xes) groupid G: the prefixes associflted w:Lth this groupid sre X,Z
At gateway C (39) FIB (prefix: next hop on shortest path) address prefix X: addresses with this prefix are located in the local subnet (32) W: the next gateway on the path to the subnet containing addresses wlth this prefix is Gateway B.
Y: gateway D
Z: gatewfly B
G: local ~ubnet (32) MURT (groupicl: associflted pref:ixes) groupid G: the prefixes associflted with this groupid are X,Z
At ~tew~y D (38) FIB (pr~fix: next hop on shortest path) ~ddress preflx Y: addresses with this pr~flx ~re loc~ted in the local ~ubnet (33) W: the n~xt g~-t~way on the path to the subnet containing addresses with this pr~fix is G~-teway B.
X: g~tew~y C
Z: gateway B
G: gatew~y C
MURT (group~d: a~sociated prefixes) groupid G: the prefixes associated with this groupid are X,Z
At gat~way E (37) FIB (prefix: next hop on shortest path) address prefix Z: ~ddresses with this preflx ~re located in the loc~l subnet (34) W: th~ next gateway on the p~th to the subnet containing ~ddress~s with this prefix is G~t~way B.
X: gat~way B
Y: g~tew~y B
G: local subnet (34) MURT (groupid: associatad prefix~s) groupid G: the prefixes ns~ocinted l~ith this gro~lpid are X,Z
The basic layout is shown in Fig. 3. In this example, G is the groupid of a multicast group which has members in subnetworks X (32) and Z (34). A source node in subnetwork W
l31) sends a multicast to groupid G.
MPTN gateway A (35) receives the multicast packet addressed to groupid G from subnetwork W (31). Its MURT entry indicates that the multicast i 5 to be sent to the subnetworks with prefixes X (32) and Z (34). From its FIB, gateway A (35) determines that the next hop for both X and Z
is gateway B (36). It therefore sends an MPTN multicast packet to gateway B (36) with the following fields:
destination = G
target subnetworks = X, Z
data as specified in the original multicast packet Nota that the target subnetworks field specifies all unique destination subnetworks for this multicast on a given path.
Since both subnetworks X (323 and Z (34) are reached through gateway B (36), only a single packet is sent from ~ateway A
(35) to gateway B 536) to accompli.sh the multicast.
Gateway B (36) receives the multicast packet specified above. Since the target subnetworks are specified, it does not need to make use of the MURT. Mote that this implies that only gateways that are attached to possible sources of multicast traffic need to maintain a MURT. All other gateways do not need to create this table. Gateway B uses its FIB to determine that the next hop for ~ubnetwork X is gateway C (39) and ~or subnetwork Z ~34) gateway E (37). It therefore sends an MPTN multicast packet to gateway C with the following fields:
de~tination = G
target subnetworks = X
data as specified in the original multicast packet Note that the target subnetworks field only includes those subnetworks on this path. Subnetwork Z (34) is reached via a different path and is therefore not included in the multicast to gateway C (39).
Similarly, gateway B (36) sends an MPTN multicast packet to gateway E (37) with the following fields:
destination = G
target subnetworks = Z
data as specified in the original multicast packet Gateway C (39) receives the multicast destined for subnetwork X (32~ to which it is attached. It therefore rnultic~sts the packet to groupid G in subnetwork X.
Similarly, gateway E (37) multicasts the packet in subnetwork Z (34~ to all members of groupid G. Thus the multicast is delivered to all members of groupid G. The algorithms above meet all MPTN requirements for efficient multicast:
CA 0210~040 1997-12-22 1. The packet was only multicast in subnetworks that have a multicast group member (e.g., X and Z, but not Y). The MURT
identifies the destination subnetworks.
2. Each multicast packet was delivered exactly once to each subnetwork. The target subnetworks field of the MPTN multicast is used to ensure that each subnetwork receives exactly one copy of the multicast.
3. There are no centralized elements. The creation of the MURT, and the routing of multicast packets is completely distributed.
4. The algorithms do not require computation of a spanning tree from a topology database.
5. The multicast routing has all the flexibility of normal MPTN routing. As shown in the example, the normal IDRP FIBs are used to route multicast packets. This implies that different routes may be used for different multicast packets due to different quality of service requirements and/or changing network conditions (topology or load).
6. The number of packets distributed is minimized. A
multicast packet to several destinations (e.g., X and Z) is only sent as separate packets when the best routes to the different destinations are not the same. In the example, only a single packet was sent from gateway A to gateway B, but gateway B sent individual packets to gateways C and E.
7. The multicast packets are sent on the best route to each destination according to the IDRP FIB. A unicast packet to one of the given destinations would follow the same path as the multicast packet to that destination.
It is also important that only a single MURT entry is created per multicast group. The multicast algorithms for the Internet Protocol described in the Prior Art section of this disclosure require nodes to create multicast tables with entries for each source-group pair (thus the number of ~1~3~
entries is multiplied by the -total number of sources compared to the MPTN scheme).
Having given the ahove informal description of the MPTN
multicast packet forwarding algorithm, the procedures for multicasting are now specified in detail. One procedure is specified for the MPTN gateway that initially receives the multicast packet from a subnetwork (List A), and one for intermediate MPTN gateways that forward multicasts received from other gateways (List B).
SZ9~92-009 21 2~3~
List A - Procedure: Initiate MPTN Multicast This procedure is used by an MPTN gateway that receives a multicast packet from a subnetwork.
~nput: The subnetwork multicast packet which specifies a destination groupid, quality of service, and the data to be multicast.~utput: MPTN multicast packets to the next gateways on the path to the target, or a multicast directly to target subnetworks that are directly attached to the gateway.
Using the specified groupid as a key into the MURT obtain the list of prefixes for subnetworks containing members of the group.
For each prefix in the list Use the prefix and the specified quality of service as a key into the IDRP FIB to determine the next hop gateway on the path to that subnetwork.
Add this prefix to a list for the particular next hop.
For each next hop list crea~ed above Set target_subnetworks to the list of prefixes associated with that next hop.
Send the MPTN multicast including the groupid, target_subnetworks, q~lality of service, and data to that next hop.
Note that in some cases the target subnetwork is directly attached to this gateway and that the multicast is for~arded directly to that subnetwork in those cases.
~ SZ9-92~009 22 2 ~ 4 ~
List B - Procedure: Forward MPTN Multicast This procedure is used by an MPTN gateway to forward a multicast packet received from another MPTN gateway.
Input: The MPTN multicast including the groupid, target_subnetworks, quality of service, and data as created in procedure Initiate_MPTN_Multicast.
Output: MPTN multicast packets to the next gateways on the path to the target, or a multicast directly to target subnetworks that are directly attached to the gateway.
For each prefix in the received target_subnetworks list Use the prefix and the specified quality of service as a key into the IDRP FIB to cletermine -the next hop gateway on the path to that subnetwork.
Add this prefix to a list for the particular ne~t hop.
For each next hop list created above Set target_subnetworks to the list of prefixes associated with that next hop.
Send the MPTN mul-ticast including the groupid, target_subnetworks, quality of service, and data to that next hop.
Note that in some cases the target subnetwork is directly attached to this gateway and that the multicast is forwarded directly to that subnetwork in those cases.
Multicast with Reduced Routinq Information In the multicasting scheme described in the previous sections, a MURT entry for a group is reguired at every gateway that is attached to a potential source of multicast traffic to that group. In large MPTNs with many groups, this may be undesirable. Therefore in this section, an alternative scheme is described in which MURT entries for a particular multicast group need only be maintained at gateways attached to subnetworks with members in that group (other gateways may optionally maintain these MURT entries).
This scheme can potentially reduce the amount of storage required to support multicasting at the e~pense of optimal routing, as will be shown. The scheme described in this section is an integral part of this invention, and can be used in combination with, or in place of the previous scheme.
With this scheme, subnetworks report groupids and address prefixes to adjacent gateways as was described in the section entitled Routing Information. These gateways must create MURT entries for the specified groupids. They must also create IDRP update PDUs as described in the addressed section. However, gateways not attached to a subnetwork containing members of a particular groupid are not forced to maintain MURT entries for that groupid.
Forwarding of packets addressed to a groupid is done as follows:
~ If a packet to be forwarded has the target subnetworks field set by a previous MPTN gateway, it is forwarded according the the algorithm in List B. This can be done by all yateways since a MURT is not re~uired for this algorithm (the destination prefixes are specified in the target subnetworks field).
- If a packet to be forwarded does not have the target subnetworks field set, and the destination address is a groupid for which a MURT entry is maintained at this gateway, the procedure for initlating an MPTN multicast in List A is followed. -- If a packet to be forwarded does not have the target subnetworks field set, and no MURT entry exists for the destination address, the packet is forwarded point to-point based on the IDRP FIB entry for that address.
If only the gateways attached to the subnetworks with members of a group have a MURT entry for that groupid, the packet will be routed point-to-point to one of those ;.,: , .
~ SZ9-92-009 2~
2~050~
gateways, which will then cause it to be multicast to the ~emainder of the gateways.
The above algorithm for ro~lting with reduced information is illustrated with an example, again referring to the network depicted in Fig. 3. Using the protocols specified in this section, the following routing tables are constructecl at the ~espective MPTN gateways:
At gateway A (35) FIB (prefix: next hop on shortest pflth) address prefix W: addressss with this prefix are located in the local subnet (31) X: the next gateway on the path to the subnet containing flddresses with this prefix is Gatewny B.
Y: gateway B
Z: gflteway B
G: gatewfly B
At gatew~y B (36) FIB (prefix: next hop on shortest p~th) W: the next gateway on the pat:h to the subnet containing flddresses with thls preElx :Is Gatewfly A.
X: gatewfly C
Y: gateway D
Z: gatewQy E
G: gflteway F.
At gatewfly C (39) FIB (prefix: nex-t hop on shortest path) address prefix X: flddresses with this prefix are located .Ln the 1OCA1 subnet (32) W: the next gfltewfly on the pflth to the subnet contflining flddresses with this prefix is Gfltewfly B.
Y: gateway D
Z: gflteway B
G: local subnet (32) MURT (groupid: associated pref:Lxes) groupid G: the preflxes flssociflted with this groupid are X,Z
At gateway D (38) 21~ a ~ ~ O
FIB tprefix: next h~p on shortest pflth) flddres~ prefix Y: flddresses wlth this pr~fix ~re locat~d in the loc~ bnet ~33) W: the next g~teway on th~ pflth to th~ subnet cont~ining addre~ses wlth this prefix t~ G~tew~y B.
X: ~a-tew~y C
Z: g~teway B
G: g~t~way C
At g~teway E (37) FIB ~preflx: next hop on sho~test path) address prefix Z: addresses with this prefix are located in the loc~l subnet (34) W: the next gateway on the path to the subnet contflining addresses with this prefix is Gateway B.
X: gatew~y B :
Y: gat~w~y B
G: local subn~t (34) MURT (groupld: associated prefixes) gr~upid G: the prefixes associnted w:L-th this groupid ar~ X,Z
In this example, "G" is the yro~lpid of a multicast group which has members in subnetworks X (32) and Z (34), and it is assumed that only gateways C (3g) and E (37) maintain MURT entries for groupid G. Hence, all other gateways treat G like a unicast address (i.e., according to the existing IDRP procedures), and therefore maintain a single entry for G in their FIBs. The fact that multiple gateways advertise a path to G (gateways C and E in the example) is not a problem, since IDRP allows for this. However, gateways only store routing information (in -the FIB) for the best path for a given prefix. For example, gateway B (36) has a FIB entry of gateway E ~37) associated with G rather than gateway C
(39). This could have been reversed, but in any event only one of the paths is stored in the FIB.
MPTN gat~way A (35) receives a multicast packet addressed to G from subnetwo:rk W (31). I-t does not have a MURT entry for G, so it routes the packet based on the FIB entry for G (to gateway B) with the following fields:
, SZ9-92-009 26 2 ~ 4 ~
destination = G
target subnetworks = not set data as specified in the original multicast packet Note that the target subnetworks field is not set since the MURT entry for G is not available.
Gateway B (36) receives the packet, and since it also does not have a MURT entry for G, routes the packet based on its FIB to gateway E (37) with the following fields:
destination = G
target subnetworks = not set data as specified in the original multicast packet Gateway E (37) is attached to subnetwork Z which has members in group G, and therefore it has a MURT entry for G. The MURT indicates that the packet is to be multicast in subnetworks with prefixes X and Z. Since subnetwork Z (34) is attached, it multicasts the packet into that subnetwork.
Since the FIB entry for subnetwork X (32) is gateway B (36), an MPTN multicast packet is sent to gateway B with the following fields:
destination = G
target subnetworks = X
data as specified in the original multicast packet Since the target subnetworks fields is now set, gateway B
(36) forwards the packet based on that field (contrast the routing decision made here to that made at gateway B above~.
Thus, since the FIB entry for subnetwork X (32) is gateway C
(39), it forwards the MPTN m~lticast packet to gateway C
with the following fields:
destination = G
target subnetworks = X
data as specified in the original multicast packet Finally, gateway C (39) multicasts the packet to groupid G
in subnetwork X (32) to which it is attached.
21~ ~ O ~ O
Note that in this example the packet was routed through gateway B (36) twice; once with the target subnetworks field not set, and once with it set. Thus, the savings in storage for not maintaining the MURT entries at gateways A, B, and D
(35, 36, and 3~) come at the expense of suboptimal routing behavior for multicast packets.
MPTN Use of Multica~t As noted previously, MPTN relies on multicasting to support multicasts by applications using MPTN, and to support MPTN
control algorithms. These problems and the manner in which they are solved are described in this section.
Existing routing protocols require that all nodes whose addresses have a common prefix be located in a single subnetwork. In that way, the prefix uniquely identifies the subnetwork, and operations involving nodes with the given prefix can be entirely performed within that subnetwork.
This is illustrated in Fig. 4.
MPTN allows nodes in different subnetwork to have the same address prefix. Thus, such a prefix does not uniquely identify a particular subnetwork, and operations involving nodes with this prefix may have to be distributed over multiple subnetworks. This is illustrated in Fig. 5. This is referred to as a "split netid", since "netid" is a synonym for address prefix, and "split" implies that the nodes with the given netid are split up among different subnetworks.
The subnetworks containing nodes in the split netid are called "islands" of that split netid. Thus, Fig. 5 illustrates a split netid with 3 islands. Support of such split netids has implications on the following MPTN
operations:
1. Packets multicast by MPTN users to nodes in a split netid must be delivered to all subnetworks containing such nodes.
2. In order to route connections and unicast datagrams to a node in a split netid, MPTN gateways must first determine in which island of the spllt netid the destination is located.
3. Subnetwork protocols that ensure that all addresses in use in that subnetwork are unique must be extended to all islands of a split netid, since nodes with the same address could exist there due to the use of the same address prefix.
In order to support split netids, the multicast protocols described in this invention are used. In particular the address prefix common to -the nodes in the split netid is treated like a groupid, and this groupid i8 registered with all MPTN gateways adjacent to all islands of the split netid. Thus, the groupid identifies the group of all islands of the split netid. User datagrams and connection requests will be received that specify a destination address that begins with the split netid prefix (i.e., the groupid), since users will want to communicate with resources in that split netid. MPTN control packets will be addressed to the groupid in order to communicate with one gateway attached to each island of the split netid, as explained below. As with other groups, each group member (i.e., each island) also requires a unique prefix -that will be associa-ted with the groupid in the MURT. This is obtained as follows.
~ach gateway attached to a split netid has an address in that subnetwork which is globally unique (this global uniqueness is yuaranteed by the subnetwork protocols). If this gateway is the only gateway attached to a particular island of the split netid, it may use its own address in that subnetwork as the unique prefix for the island. Since all routing protocols in the class relevant to this invention (e.g., IDRP, IP, OSPF, OSI IS-IS) require that gateways communicate to exchange routing information, gateways will automatically have contact with all other gateways attached to the same island of the split netid ~i.e., all of those gataways with which it exchanges routing information through tha-t subnetwork~. Thus, gateways are aware when multiple gateways are attached to the same island of a split netid, and also when gateways are added or removed from the set attached to a split netid island.
~ ~ ~3~
The method for selecting a unique prefix to associate with an island of a split netid is as follows:
1. When a gateway is initially activated, it assumes that its own address will be used as the unique prefix for the split netid island to which it is attached.
2. Whenever a gateway becomes aware of the existence of other gateways attached to the same island (which it must in order to implement the existing routing protocols), it examines the addresses of all such gateways and uses the smallest such address (which might be its own) as the unique prefix for the split netid. Since all gateways will execute this algorithm, they will converge to using the same address as the prefix to uniquely identify this island.
This step must be repeated whenever a gateway is added or dropped from the set of gateways attached to the local split netid island.
This method provides valid unique prefixes for split netid islands in the case where two or more disjoint islands are joined into one island, or when a single island is dynamically split into several islands. The algorithm is completely distributed and is guaranteed to result in a correct assignment of unique prefixes to gateways attached to split netid islands.
l'he unique address prefixes associated with a split netid is called a "derived netid". This is illustrated in Fig. 6.
In that Fig. 6, we see that nodes with address prefix X are located in two different subnetworks. Therefore X, a split netid, is registered as a groupid with the MPTN gateways attached to those subnetworks. Gateway G (62) is the only gateway attached to the top island of split netid X. It therefore uses its local address X.7 as the unique prefix to be associated with groupid X. Gateways H (63) and I (64) are attached to the lower island of the split netid. Since gateway H's adclress is less that gateway I's (X.8 is less than X.9), they both use X.8 as the unique prefix to be , .
~ 2i ~:~Q~
associated with groupid X. Using -the protocols of this invention, Gateway F (61~ builds the illustrated FIB and MU~T table entries associated wit:h the address prefix X.
Using the multicast protocols from the previous sections, and the procedure for mapping split netids to groupids and derived netids in this section, lt is possible to support split netids in MPTN.
If an MPTN user's packet is to be multicast to all nodes with prefix X, the packet can be distributed to all islands of the split netid using the procedures of the previous sections since X is an entry in the MURT. In the same way, flows which are part of subnetwork name management protocols can be multicast to all parts of a split netid.
If a connection or unicast datagram is to be sent to a node with prefix X (say X.3 in the example in Fig. 6), an additional protocol is required, which forms another part of this invention. An MPTN gateway that is required to route a ~nicast packet or connection based on an address prefix which appears in the MURT uses this procedure.
1. Using the multicast method described in this invention, a LOCATE request is distributed to one MPTN gateway attached to each island of the split netid. A parameter of the LOCATE
is the specific address which is the target of the original unicast packet (i.e., the resource that is to be located).
Thus in the example, gateway F (61) multicasts a LOCATE to gateways G (62) and H (63) to determine the location of the resource X.3.
2. Each gateway that receives such a LOCATE request searches the attached subnetwork (using the native protocols of that subnetwork, or MPTN protocols) to determine if the target resource is actually located in that island of the split netid. In the example, gateway G (62) discovers that X.3 is located in the attached subnetwork, while gateway H
(63) is not able to locate X.3.
2 ~
3. All gateways that received the LOCATE return a response to the MPTN gateway that initiated the search that includes the unique prefix of the responder, and a flag which indicates if the resource was found or not. In the example, gateway G (62) returns a response to gateway F (61) that includes its unique address prefix X.7, and a flag that indicates that the resource was found. Gateway H (63) returns a result indicating that the resource was not found.
4. As soon as a positive response to the search is obtained, gateway F (61) is able to route the unicast message or connection to -the proper destination. The header of that request must indicate to which gateway the request is being routed (X.7 in the example) so that all gateways can forward the request. The header must further include the address to which the request is destined (X.3) so that the final gateway will be able to route it through the subnetwork containing the destination.
It is important for gateways that cannot locate a particular resource to send a ne~ative response to a LOCATE request.
Otherwise, in the case where -the targe-t resource does not exist (e.g., a user attempts to send a message to X.5 which does not exist), the gateway that needs to route the request would wait forever for a response. Instead, if a negative response is received from each gateway, it knows that the resource in question is unreachable and it can therefore reject the original request.
This terminates the description of the preferred embodiments. Of course, numerous variations of the given examples are possible, still within the scope of the invention as claimed.
Summary of the Invention In brief, the present invention achieves the above objects by a method and a system for multicasting a message from a sending station to a plurality of receiving stations within a conventional unicast message transmission network using existing protocols by, at least in certain nodes within the network, maintaining tables of subnetworks with multicast receiving stations or tables of multicast receiving stations and by including appropriate routing information in the header of multica~t messages, as further defined in the claims.
With this invention, a solution is presen-ted that, when used in combination with distance-vector routing protocols such as the standard OSI IDRP routing protocol, disclosed in ISO
"Information Technology - Telecommunications and Information Exchange between Systems - Intermediate System to Intermediate System Intra-Domain Rou-ting Protocol for Use in Conjunction with the Protocol for Providing the Connection", ISO/DIS 10589, 1990, or any other similar protocol, such as those used in IP networks referenced above, supports multicasting in large internetworks. This solution is also usable with link-state routing protocols, such as OSPF
developed for IP networks (described by J. Moy in "OSPF
Versicn 2", RFC 1247, NIC, July 1991) and the OSI IS-IS
protocol (described in ISO/DIS 10589, cited above) and are thus applicab~e to a wide range of internetworking environments. Within the invention, three new types of protocols are presented:
1. for the distribution of routing information based on network topology and the location of multicas-t group 210~0~
members, and for the creation of routing tables using this information;
2. for efficiently forwarding multicast packets to all members of a multicast group given tha routing information from the first step; and 3. for enabling the multicast protocols to be used in the MPTN environment.
Detailed Description The following section is divided into four parts. The first part, entitled "Routing Information", describes the routing information that is distributed and the tables that are created for routing multicast packets. The second part, entitled "Multicast Packet Forwarding", describes the procedures for using the created tables to route multicast packets. Then, in the third part, entitled "Multicast with Reduced Routing Information", a description i~ given of how the amount of routing information required for the multicasting protocols can be reduced. ~inally, in part four, entitled "MPTN Use of Multicast", an example is given of how MPTN uses the protocols described in this invention.
Routing Information A brief description of the Inter-Domain Routing Protocol (IDRP) protocol is provided so that the invention may be better understood. Further details can be found in IS0/DIS
10589, referred to above.
IDRP distributes routing information between gateways in so-called Update PDUs, i.e. Update Protocol Data Units.
Update PDUs contain the following fields that are relevant to the invention.
1. Reachability Information: this field specifies the resources that can be reached along the path specified in this Update PDU. It can be the address of a specific end system, or it can be the prefix common to the addresses used by a set of end systems. A11 systems whose address contains 21~0~0 a given prefix reside in the same subnetwork, and therefore this prefix uniquely identifies this subnetwork. A type field is defined in the reachability information which indicates that the reachability information is an address prefix (type=O). Thus, different types of reachability information could be distributed in Update PDUs by defining a new type code.
Z. Quality of service: -this specifies properties like cost, delay, and security implications of using the routing information ln this update PDU.
3. Path: the routing information that specifies how to reach the end systems identified by the prefix(es) in the reachability information.
Based on received Update PDUs, gateways build routing tables, called Forwarding Information Bases (FIBs) in IDRP.
For each destination (a destination is identified by a prefix received in an Update PDU, and may thus be a single node or a set of nodes), the next gateway on the path to that destination is stored (this ~s determined from the path field in the update PDU). Exac-t]y one path for each prefix is stored for each unique se-t of quality of service parameters. This path is the one that can best provide the specified quality of service.
In the invention, a new type of xeachability information is defined, called a group identifier (groupid). A groupid is used to address a group of end systems that are to receive a particular set of multicasts. The groupid, which is chosen from the normal subnetwork address space, is therefore included as the des-tination address of a multicast packet so that the proper group of end systems is identified. The end systems addressed by a particular groupid are not necessarily located in a common subnetwork. Selecting groupids from the standard address space guarantees that they represent valid reachability information even for gateways which do not imp].ement the multicast extensions described below.
r SZ9-92-009 13 2 ~ 0 To support unicast inter-domain routin~, subnetworks report the address prefix(es) shared by its nodes to gateways.
These prefixes are used to create the Update PDUs as described above. In the invention, subnetworks also report all groupids reachable in that subnetwork.
An example is illustrated in Fig. 3. In that figure, the subnetworks with prefixes X (32) and Z (34) also have end systems in group G. They therefore report both the prefix and the groupid to the local gateways C (39) and E (37).
Subnetworks W (31) and Y (33) do not have any groupids to report, so they report only their prefixes. Note that a given subnetwork may report multiple groupids and prefixes (not illustrated).
IDRP Update PDUs are constructed as follows. Update PDUs not containing groupids are constructed as specified in IS0/DIS
CD 10747, mentioned above. Update PDUs used to advertise reachability to groupids must contain the following information:
- An address prefix of the subnetwork, and - one or more groupids for that subnetwork.
The reachability information in an Update PDU containing groupids consists of only the groupids and (one of) the address prefix(es) unique to the end systems in the subnetwork reporting the groupids, so that all gateways will be able to build an association between the subnetwork prefix and the groupids reachable in that subnetwork.
The Update PDU constructed in this manner is delivered with the reachability information field unchanged to all gateways according to t:he existing IDRP protocols. Note that this Update PDU construction is allowed by the IDRP standard, and that no other chanyes to the Update PDU construction or distribution are required.
In the example shown in Fig. 3, gateway C (39) would create an Update PDU with the following reachability information:
prefix=X, groupid=G. Similarly, gateway E (37) would create SZ9~92-009 14 , ~ ~, O ~ o an Update PDU with prefix=Z and groupid=G. Both of these Update PDUs would be distributed to all other gateways according to the IDRP protocol to allow all of them to learn the association between group G and subnetworks X and Z.
As reachability information changes (e.g., the prefix changes, or groupids are added or deleted), the changes are reported to the local gateways which use the normal IDRP
routing protoco].s to update all r~PTN gateways with the new information.
Construction of Update PDUs as specified above allows gateways to build an additional routing table which will be referred to as the Multicast Routing Table or MURT. The MURT
contains for each groupid the list of prefixes ~or subnetworks containing members of that group, as learned from Update PDUs containing groupids. How the MURT is used for routing is explained in the next section.
In the system of Fig. 3, following the distribution of the Update PDUs as described above, each gateway would have a MURT entry for groupid G, identifying X and Z as the prefixes of subnetworks in which group members are located. ~ -The remaining IDRP routing tables (e.g., the FIB as described above) are constructed according to existing IDRP
specifications. In particular the path information associated with all reachability information (including groupids) is stored in the FIB.
Thus far in this section, the procedure for constructing a MURT using the OSI IDRP routing protocol has been described.
This same procedure can be used with any distance-vector routing protocol, as e.g. described in the following references: C.L Hedrick, "Routing Information Protocol", RFC
1058, NIC, Jun~e 1988; R.M. Hinden and A Shelt~er, cited above; K. Lougheed and Y. Rekhter, cited above; D.L. ~ills, cited above. In all such protocols, Update PDUs are di~tributed to advertise reachability to a given address or address prefix. By associating groupids with each address prefix, a MURT can be constructed as described above.
,~ SZ9-92-009 15 2 1 ~ 0 A MURT can also be constructed using link-state routing protocols such as those described in IS0/DIS 10589, 1990 or in J. Moy, cited above. In those protocols, each gateway distributes reachability information in link-state PDUs, which provide information on the state of each link adjacent to that gateway, as well as all address prefixes directly reachable from that gateway. Th~se link state PDUs are forwarded unmodified to all other gateways in the system.
Therefore, by also including a list of groupids in the link state PDUs, a MURT can be constructed associating the group with a lisi of address prefixes of subnetworks in which group members reside. Both distance-vector and link-s-tate routing protocols create an FIB which is essentially eq~ivalent to that created by IDRP. Due to this, the multicast forwarding algorithm described in the next section is also applicable to these environments.
Multicast Packet Forwardinq Conceptually, once the MURT is constructed as described in the previous section, routing of multicast packets is very simple. The MURT allows the subnetworks in wh.ich members of the multicast group are located to be identified.
Furthermore, the IDRP FIB can be ~Ised to route packets to each of these subnetworks. A copy of each multicast packet could simply be routed to each of these subnetworks.
However, due to the MPTN requirements specified in the section entitled Summary of the Invention, above, regarding restrictions on the number of distributed packets, the methods and algorithms specified in this section are an essential part of this invention.
The invention also defines a Multicast Spanning-Tree Algorithm (MSTA) for routing multicast packets in an MPTN.
The MSTA is also usable in other networks that provide routing information similar to that specified in the previous section.
To assist the reader in understanding, MSTA is presented in an example before the detailed algorithms are given.
,~ SZ9-92-009 16 210aO40 The topology ~f the network u~ed in this example is illustrated in Fig. 3. Using the protocol~ of th~ p~evious section, the following routing table~ are constructed at the respective MPTN gateways: -At gateway A (35) FIB (prefix: next hop on shortest path) address prefix W: addresses wlth this prefix are located in the local subnet (31) X: the next gateway on the path to the subnet containing addresses with this prefix is Gateway B.
Y: gateway B
Z: gateway B
G: gateway B :
MURT (groupid: associated prefixes) groupid G: the prefixes associated w:ith this groupid are X,Z
At gateway B (36) FIB (preflx: next hop on shortest path) W: the next gateway on the path to the subnet containing addresses with this prefix ~s Gateway A.
X: gateway C
Y: gateway D
Z: gateway E
G: gateway r.
MURT (groupid: associated prefi.xes) groupid G: the prefixes associflted w:Lth this groupid sre X,Z
At gateway C (39) FIB (prefix: next hop on shortest path) address prefix X: addresses with this prefix are located in the local subnet (32) W: the next gateway on the path to the subnet containing addresses wlth this prefix is Gateway B.
Y: gateway D
Z: gatewfly B
G: local ~ubnet (32) MURT (groupicl: associflted pref:ixes) groupid G: the prefixes associflted with this groupid are X,Z
At ~tew~y D (38) FIB (pr~fix: next hop on shortest path) ~ddress preflx Y: addresses with this pr~flx ~re loc~ted in the local ~ubnet (33) W: the n~xt g~-t~way on the path to the subnet containing addresses with this pr~fix is G~-teway B.
X: g~tew~y C
Z: gateway B
G: gatew~y C
MURT (group~d: a~sociated prefixes) groupid G: the prefixes associated with this groupid are X,Z
At gat~way E (37) FIB (prefix: next hop on shortest path) address prefix Z: ~ddresses with this preflx ~re located in the loc~l subnet (34) W: th~ next gateway on the p~th to the subnet containing ~ddress~s with this prefix is G~t~way B.
X: gat~way B
Y: g~tew~y B
G: local subnet (34) MURT (groupid: associatad prefix~s) groupid G: the prefixes ns~ocinted l~ith this gro~lpid are X,Z
The basic layout is shown in Fig. 3. In this example, G is the groupid of a multicast group which has members in subnetworks X (32) and Z (34). A source node in subnetwork W
l31) sends a multicast to groupid G.
MPTN gateway A (35) receives the multicast packet addressed to groupid G from subnetwork W (31). Its MURT entry indicates that the multicast i 5 to be sent to the subnetworks with prefixes X (32) and Z (34). From its FIB, gateway A (35) determines that the next hop for both X and Z
is gateway B (36). It therefore sends an MPTN multicast packet to gateway B (36) with the following fields:
destination = G
target subnetworks = X, Z
data as specified in the original multicast packet Nota that the target subnetworks field specifies all unique destination subnetworks for this multicast on a given path.
Since both subnetworks X (323 and Z (34) are reached through gateway B (36), only a single packet is sent from ~ateway A
(35) to gateway B 536) to accompli.sh the multicast.
Gateway B (36) receives the multicast packet specified above. Since the target subnetworks are specified, it does not need to make use of the MURT. Mote that this implies that only gateways that are attached to possible sources of multicast traffic need to maintain a MURT. All other gateways do not need to create this table. Gateway B uses its FIB to determine that the next hop for ~ubnetwork X is gateway C (39) and ~or subnetwork Z ~34) gateway E (37). It therefore sends an MPTN multicast packet to gateway C with the following fields:
de~tination = G
target subnetworks = X
data as specified in the original multicast packet Note that the target subnetworks field only includes those subnetworks on this path. Subnetwork Z (34) is reached via a different path and is therefore not included in the multicast to gateway C (39).
Similarly, gateway B (36) sends an MPTN multicast packet to gateway E (37) with the following fields:
destination = G
target subnetworks = Z
data as specified in the original multicast packet Gateway C (39) receives the multicast destined for subnetwork X (32~ to which it is attached. It therefore rnultic~sts the packet to groupid G in subnetwork X.
Similarly, gateway E (37) multicasts the packet in subnetwork Z (34~ to all members of groupid G. Thus the multicast is delivered to all members of groupid G. The algorithms above meet all MPTN requirements for efficient multicast:
CA 0210~040 1997-12-22 1. The packet was only multicast in subnetworks that have a multicast group member (e.g., X and Z, but not Y). The MURT
identifies the destination subnetworks.
2. Each multicast packet was delivered exactly once to each subnetwork. The target subnetworks field of the MPTN multicast is used to ensure that each subnetwork receives exactly one copy of the multicast.
3. There are no centralized elements. The creation of the MURT, and the routing of multicast packets is completely distributed.
4. The algorithms do not require computation of a spanning tree from a topology database.
5. The multicast routing has all the flexibility of normal MPTN routing. As shown in the example, the normal IDRP FIBs are used to route multicast packets. This implies that different routes may be used for different multicast packets due to different quality of service requirements and/or changing network conditions (topology or load).
6. The number of packets distributed is minimized. A
multicast packet to several destinations (e.g., X and Z) is only sent as separate packets when the best routes to the different destinations are not the same. In the example, only a single packet was sent from gateway A to gateway B, but gateway B sent individual packets to gateways C and E.
7. The multicast packets are sent on the best route to each destination according to the IDRP FIB. A unicast packet to one of the given destinations would follow the same path as the multicast packet to that destination.
It is also important that only a single MURT entry is created per multicast group. The multicast algorithms for the Internet Protocol described in the Prior Art section of this disclosure require nodes to create multicast tables with entries for each source-group pair (thus the number of ~1~3~
entries is multiplied by the -total number of sources compared to the MPTN scheme).
Having given the ahove informal description of the MPTN
multicast packet forwarding algorithm, the procedures for multicasting are now specified in detail. One procedure is specified for the MPTN gateway that initially receives the multicast packet from a subnetwork (List A), and one for intermediate MPTN gateways that forward multicasts received from other gateways (List B).
SZ9~92-009 21 2~3~
List A - Procedure: Initiate MPTN Multicast This procedure is used by an MPTN gateway that receives a multicast packet from a subnetwork.
~nput: The subnetwork multicast packet which specifies a destination groupid, quality of service, and the data to be multicast.~utput: MPTN multicast packets to the next gateways on the path to the target, or a multicast directly to target subnetworks that are directly attached to the gateway.
Using the specified groupid as a key into the MURT obtain the list of prefixes for subnetworks containing members of the group.
For each prefix in the list Use the prefix and the specified quality of service as a key into the IDRP FIB to determine the next hop gateway on the path to that subnetwork.
Add this prefix to a list for the particular next hop.
For each next hop list crea~ed above Set target_subnetworks to the list of prefixes associated with that next hop.
Send the MPTN multicast including the groupid, target_subnetworks, q~lality of service, and data to that next hop.
Note that in some cases the target subnetwork is directly attached to this gateway and that the multicast is for~arded directly to that subnetwork in those cases.
~ SZ9-92~009 22 2 ~ 4 ~
List B - Procedure: Forward MPTN Multicast This procedure is used by an MPTN gateway to forward a multicast packet received from another MPTN gateway.
Input: The MPTN multicast including the groupid, target_subnetworks, quality of service, and data as created in procedure Initiate_MPTN_Multicast.
Output: MPTN multicast packets to the next gateways on the path to the target, or a multicast directly to target subnetworks that are directly attached to the gateway.
For each prefix in the received target_subnetworks list Use the prefix and the specified quality of service as a key into the IDRP FIB to cletermine -the next hop gateway on the path to that subnetwork.
Add this prefix to a list for the particular ne~t hop.
For each next hop list created above Set target_subnetworks to the list of prefixes associated with that next hop.
Send the MPTN mul-ticast including the groupid, target_subnetworks, quality of service, and data to that next hop.
Note that in some cases the target subnetwork is directly attached to this gateway and that the multicast is forwarded directly to that subnetwork in those cases.
Multicast with Reduced Routinq Information In the multicasting scheme described in the previous sections, a MURT entry for a group is reguired at every gateway that is attached to a potential source of multicast traffic to that group. In large MPTNs with many groups, this may be undesirable. Therefore in this section, an alternative scheme is described in which MURT entries for a particular multicast group need only be maintained at gateways attached to subnetworks with members in that group (other gateways may optionally maintain these MURT entries).
This scheme can potentially reduce the amount of storage required to support multicasting at the e~pense of optimal routing, as will be shown. The scheme described in this section is an integral part of this invention, and can be used in combination with, or in place of the previous scheme.
With this scheme, subnetworks report groupids and address prefixes to adjacent gateways as was described in the section entitled Routing Information. These gateways must create MURT entries for the specified groupids. They must also create IDRP update PDUs as described in the addressed section. However, gateways not attached to a subnetwork containing members of a particular groupid are not forced to maintain MURT entries for that groupid.
Forwarding of packets addressed to a groupid is done as follows:
~ If a packet to be forwarded has the target subnetworks field set by a previous MPTN gateway, it is forwarded according the the algorithm in List B. This can be done by all yateways since a MURT is not re~uired for this algorithm (the destination prefixes are specified in the target subnetworks field).
- If a packet to be forwarded does not have the target subnetworks field set, and the destination address is a groupid for which a MURT entry is maintained at this gateway, the procedure for initlating an MPTN multicast in List A is followed. -- If a packet to be forwarded does not have the target subnetworks field set, and no MURT entry exists for the destination address, the packet is forwarded point to-point based on the IDRP FIB entry for that address.
If only the gateways attached to the subnetworks with members of a group have a MURT entry for that groupid, the packet will be routed point-to-point to one of those ;.,: , .
~ SZ9-92-009 2~
2~050~
gateways, which will then cause it to be multicast to the ~emainder of the gateways.
The above algorithm for ro~lting with reduced information is illustrated with an example, again referring to the network depicted in Fig. 3. Using the protocols specified in this section, the following routing tables are constructecl at the ~espective MPTN gateways:
At gateway A (35) FIB (prefix: next hop on shortest pflth) address prefix W: addressss with this prefix are located in the local subnet (31) X: the next gateway on the path to the subnet containing flddresses with this prefix is Gatewny B.
Y: gateway B
Z: gflteway B
G: gatewfly B
At gatew~y B (36) FIB (prefix: next hop on shortest p~th) W: the next gateway on the pat:h to the subnet containing flddresses with thls preElx :Is Gatewfly A.
X: gatewfly C
Y: gateway D
Z: gatewQy E
G: gflteway F.
At gatewfly C (39) FIB (prefix: nex-t hop on shortest path) address prefix X: flddresses with this prefix are located .Ln the 1OCA1 subnet (32) W: the next gfltewfly on the pflth to the subnet contflining flddresses with this prefix is Gfltewfly B.
Y: gateway D
Z: gflteway B
G: local subnet (32) MURT (groupid: associated pref:Lxes) groupid G: the preflxes flssociflted with this groupid are X,Z
At gateway D (38) 21~ a ~ ~ O
FIB tprefix: next h~p on shortest pflth) flddres~ prefix Y: flddresses wlth this pr~fix ~re locat~d in the loc~ bnet ~33) W: the next g~teway on th~ pflth to th~ subnet cont~ining addre~ses wlth this prefix t~ G~tew~y B.
X: ~a-tew~y C
Z: g~teway B
G: g~t~way C
At g~teway E (37) FIB ~preflx: next hop on sho~test path) address prefix Z: addresses with this prefix are located in the loc~l subnet (34) W: the next gateway on the path to the subnet contflining addresses with this prefix is Gateway B.
X: gatew~y B :
Y: gat~w~y B
G: local subn~t (34) MURT (groupld: associated prefixes) gr~upid G: the prefixes associnted w:L-th this groupid ar~ X,Z
In this example, "G" is the yro~lpid of a multicast group which has members in subnetworks X (32) and Z (34), and it is assumed that only gateways C (3g) and E (37) maintain MURT entries for groupid G. Hence, all other gateways treat G like a unicast address (i.e., according to the existing IDRP procedures), and therefore maintain a single entry for G in their FIBs. The fact that multiple gateways advertise a path to G (gateways C and E in the example) is not a problem, since IDRP allows for this. However, gateways only store routing information (in -the FIB) for the best path for a given prefix. For example, gateway B (36) has a FIB entry of gateway E ~37) associated with G rather than gateway C
(39). This could have been reversed, but in any event only one of the paths is stored in the FIB.
MPTN gat~way A (35) receives a multicast packet addressed to G from subnetwo:rk W (31). I-t does not have a MURT entry for G, so it routes the packet based on the FIB entry for G (to gateway B) with the following fields:
, SZ9-92-009 26 2 ~ 4 ~
destination = G
target subnetworks = not set data as specified in the original multicast packet Note that the target subnetworks field is not set since the MURT entry for G is not available.
Gateway B (36) receives the packet, and since it also does not have a MURT entry for G, routes the packet based on its FIB to gateway E (37) with the following fields:
destination = G
target subnetworks = not set data as specified in the original multicast packet Gateway E (37) is attached to subnetwork Z which has members in group G, and therefore it has a MURT entry for G. The MURT indicates that the packet is to be multicast in subnetworks with prefixes X and Z. Since subnetwork Z (34) is attached, it multicasts the packet into that subnetwork.
Since the FIB entry for subnetwork X (32) is gateway B (36), an MPTN multicast packet is sent to gateway B with the following fields:
destination = G
target subnetworks = X
data as specified in the original multicast packet Since the target subnetworks fields is now set, gateway B
(36) forwards the packet based on that field (contrast the routing decision made here to that made at gateway B above~.
Thus, since the FIB entry for subnetwork X (32) is gateway C
(39), it forwards the MPTN m~lticast packet to gateway C
with the following fields:
destination = G
target subnetworks = X
data as specified in the original multicast packet Finally, gateway C (39) multicasts the packet to groupid G
in subnetwork X (32) to which it is attached.
21~ ~ O ~ O
Note that in this example the packet was routed through gateway B (36) twice; once with the target subnetworks field not set, and once with it set. Thus, the savings in storage for not maintaining the MURT entries at gateways A, B, and D
(35, 36, and 3~) come at the expense of suboptimal routing behavior for multicast packets.
MPTN Use of Multica~t As noted previously, MPTN relies on multicasting to support multicasts by applications using MPTN, and to support MPTN
control algorithms. These problems and the manner in which they are solved are described in this section.
Existing routing protocols require that all nodes whose addresses have a common prefix be located in a single subnetwork. In that way, the prefix uniquely identifies the subnetwork, and operations involving nodes with the given prefix can be entirely performed within that subnetwork.
This is illustrated in Fig. 4.
MPTN allows nodes in different subnetwork to have the same address prefix. Thus, such a prefix does not uniquely identify a particular subnetwork, and operations involving nodes with this prefix may have to be distributed over multiple subnetworks. This is illustrated in Fig. 5. This is referred to as a "split netid", since "netid" is a synonym for address prefix, and "split" implies that the nodes with the given netid are split up among different subnetworks.
The subnetworks containing nodes in the split netid are called "islands" of that split netid. Thus, Fig. 5 illustrates a split netid with 3 islands. Support of such split netids has implications on the following MPTN
operations:
1. Packets multicast by MPTN users to nodes in a split netid must be delivered to all subnetworks containing such nodes.
2. In order to route connections and unicast datagrams to a node in a split netid, MPTN gateways must first determine in which island of the spllt netid the destination is located.
3. Subnetwork protocols that ensure that all addresses in use in that subnetwork are unique must be extended to all islands of a split netid, since nodes with the same address could exist there due to the use of the same address prefix.
In order to support split netids, the multicast protocols described in this invention are used. In particular the address prefix common to -the nodes in the split netid is treated like a groupid, and this groupid i8 registered with all MPTN gateways adjacent to all islands of the split netid. Thus, the groupid identifies the group of all islands of the split netid. User datagrams and connection requests will be received that specify a destination address that begins with the split netid prefix (i.e., the groupid), since users will want to communicate with resources in that split netid. MPTN control packets will be addressed to the groupid in order to communicate with one gateway attached to each island of the split netid, as explained below. As with other groups, each group member (i.e., each island) also requires a unique prefix -that will be associa-ted with the groupid in the MURT. This is obtained as follows.
~ach gateway attached to a split netid has an address in that subnetwork which is globally unique (this global uniqueness is yuaranteed by the subnetwork protocols). If this gateway is the only gateway attached to a particular island of the split netid, it may use its own address in that subnetwork as the unique prefix for the island. Since all routing protocols in the class relevant to this invention (e.g., IDRP, IP, OSPF, OSI IS-IS) require that gateways communicate to exchange routing information, gateways will automatically have contact with all other gateways attached to the same island of the split netid ~i.e., all of those gataways with which it exchanges routing information through tha-t subnetwork~. Thus, gateways are aware when multiple gateways are attached to the same island of a split netid, and also when gateways are added or removed from the set attached to a split netid island.
~ ~ ~3~
The method for selecting a unique prefix to associate with an island of a split netid is as follows:
1. When a gateway is initially activated, it assumes that its own address will be used as the unique prefix for the split netid island to which it is attached.
2. Whenever a gateway becomes aware of the existence of other gateways attached to the same island (which it must in order to implement the existing routing protocols), it examines the addresses of all such gateways and uses the smallest such address (which might be its own) as the unique prefix for the split netid. Since all gateways will execute this algorithm, they will converge to using the same address as the prefix to uniquely identify this island.
This step must be repeated whenever a gateway is added or dropped from the set of gateways attached to the local split netid island.
This method provides valid unique prefixes for split netid islands in the case where two or more disjoint islands are joined into one island, or when a single island is dynamically split into several islands. The algorithm is completely distributed and is guaranteed to result in a correct assignment of unique prefixes to gateways attached to split netid islands.
l'he unique address prefixes associated with a split netid is called a "derived netid". This is illustrated in Fig. 6.
In that Fig. 6, we see that nodes with address prefix X are located in two different subnetworks. Therefore X, a split netid, is registered as a groupid with the MPTN gateways attached to those subnetworks. Gateway G (62) is the only gateway attached to the top island of split netid X. It therefore uses its local address X.7 as the unique prefix to be associated with groupid X. Gateways H (63) and I (64) are attached to the lower island of the split netid. Since gateway H's adclress is less that gateway I's (X.8 is less than X.9), they both use X.8 as the unique prefix to be , .
~ 2i ~:~Q~
associated with groupid X. Using -the protocols of this invention, Gateway F (61~ builds the illustrated FIB and MU~T table entries associated wit:h the address prefix X.
Using the multicast protocols from the previous sections, and the procedure for mapping split netids to groupids and derived netids in this section, lt is possible to support split netids in MPTN.
If an MPTN user's packet is to be multicast to all nodes with prefix X, the packet can be distributed to all islands of the split netid using the procedures of the previous sections since X is an entry in the MURT. In the same way, flows which are part of subnetwork name management protocols can be multicast to all parts of a split netid.
If a connection or unicast datagram is to be sent to a node with prefix X (say X.3 in the example in Fig. 6), an additional protocol is required, which forms another part of this invention. An MPTN gateway that is required to route a ~nicast packet or connection based on an address prefix which appears in the MURT uses this procedure.
1. Using the multicast method described in this invention, a LOCATE request is distributed to one MPTN gateway attached to each island of the split netid. A parameter of the LOCATE
is the specific address which is the target of the original unicast packet (i.e., the resource that is to be located).
Thus in the example, gateway F (61) multicasts a LOCATE to gateways G (62) and H (63) to determine the location of the resource X.3.
2. Each gateway that receives such a LOCATE request searches the attached subnetwork (using the native protocols of that subnetwork, or MPTN protocols) to determine if the target resource is actually located in that island of the split netid. In the example, gateway G (62) discovers that X.3 is located in the attached subnetwork, while gateway H
(63) is not able to locate X.3.
2 ~
3. All gateways that received the LOCATE return a response to the MPTN gateway that initiated the search that includes the unique prefix of the responder, and a flag which indicates if the resource was found or not. In the example, gateway G (62) returns a response to gateway F (61) that includes its unique address prefix X.7, and a flag that indicates that the resource was found. Gateway H (63) returns a result indicating that the resource was not found.
4. As soon as a positive response to the search is obtained, gateway F (61) is able to route the unicast message or connection to -the proper destination. The header of that request must indicate to which gateway the request is being routed (X.7 in the example) so that all gateways can forward the request. The header must further include the address to which the request is destined (X.3) so that the final gateway will be able to route it through the subnetwork containing the destination.
It is important for gateways that cannot locate a particular resource to send a ne~ative response to a LOCATE request.
Otherwise, in the case where -the targe-t resource does not exist (e.g., a user attempts to send a message to X.5 which does not exist), the gateway that needs to route the request would wait forever for a response. Instead, if a negative response is received from each gateway, it knows that the resource in question is unreachable and it can therefore reject the original request.
This terminates the description of the preferred embodiments. Of course, numerous variations of the given examples are possible, still within the scope of the invention as claimed.
Claims (16)
1. A method for multicasting a message from a sending station to a plurality of receiving stations within a conventional unicast message transmission network using existing protocols, said network containing a plurality of subnetworks and a plurality of gateway nodes connecting, and acting as entry ports to, said subnetworks, said method comprising:
distributing multicast group information by each subnetwork to each connected gateway node, said group information identifying each group of receiving stations reachable in said subnetwork;
building and maintaining a multicast routing table in each gateway node, said routing table containing said group information to enable the routing of multicast messages to each said group of receiving stations, said multicast routing table having a single entry for each said group;
transmitting said multicast message with a group identifier carried in a header part of said multicast message defining an addressed group of receiving stations;
and in each gateway node, reading and interpreting said group identifier transmitted in said multicast message to direct forwarding of said multicast message to said addressed group of receiving stations.
distributing multicast group information by each subnetwork to each connected gateway node, said group information identifying each group of receiving stations reachable in said subnetwork;
building and maintaining a multicast routing table in each gateway node, said routing table containing said group information to enable the routing of multicast messages to each said group of receiving stations, said multicast routing table having a single entry for each said group;
transmitting said multicast message with a group identifier carried in a header part of said multicast message defining an addressed group of receiving stations;
and in each gateway node, reading and interpreting said group identifier transmitted in said multicast message to direct forwarding of said multicast message to said addressed group of receiving stations.
2. The method of claim 1, wherein the group information in the multicast routing table at each gateway node contains at least one prefix corresponding to each group identifier identifying each subnetwork in which the addressed group of receiving station(s) is located, and wherein said header part of each said multicast message contains said corresponding prefix.
3. The method of claim 2, wherein the receiving stations defined by the group identifier are located in different subnetworks.
4. The method of claim 1, wherein the multicast routing table maintained in a particular gateway node includes information of only those receiving stations that can be reached via said gateway node.
5. The method of claim 2, wherein the multicast routing table (MURT) maintained in a particular gateway node includes information of those receiving stations that can be reached via said gateway node.
6. The method of claim 3, wherein the multicast routing table maintained in a particular gateway node includes information of those receiving stations that can be reached via said gateway node.
7. The method of claim 1, wherein only those gateway nodes which are connected to possible sources of multicast messages maintain a multicast routing table of the addressable receiving stations.
8. The method of claim 2, wherein only those gateway nodes which are connected to possible sources of multicast messages maintain a multicast routing table of the addressable receiving stations.
9. The method of claim 3, wherein only those gateway nodes which are connected to possible sources of multicast messages maintain a multicast routing table of the addressable receiving stations.
10. The method of claim 4, wherein only those gateway nodes which are connected to possible sources of multicast messages maintain a multicast routing table of the addressable receiving stations.
11. The method of claim 5, wherein only those gateway nodes which are connected to possible sources of multicast messages maintain a multicast routing table of the addressable receiving stations.
12. The method of claim 6, wherein only those gateway nodes which are connected to possible sources of multicast messages maintain a multicast routing table of the addressable receiving stations.
13. The method of any one of claims 2, 3, 5, 6, 8, 9, 11, or 12, wherein the group identifier and the corresponding prefixes are transmitted to the gateway nodes together with conventional routing information.
14. A system for multicasting a message from a sending station to a plurality of receiving stations within a conventional unicast message transmission network using existing protocols, said network consisting of a plurality of subnetworks connected by a plurality of gateway nodes, said system comprising:
means at each of said plurality of gateway nodes for routing multicast messages to a group of receiving stations, said routing means including a routing table having a single entry for each addressable group of receiving stations, wherein each multicast message to be transmitted carries a header that contains information defining the addressable group of receiving stations to receive said each multicast message, and, means in each gateway node for interpreting, comparing and modifying the header of said each multicast message.
means at each of said plurality of gateway nodes for routing multicast messages to a group of receiving stations, said routing means including a routing table having a single entry for each addressable group of receiving stations, wherein each multicast message to be transmitted carries a header that contains information defining the addressable group of receiving stations to receive said each multicast message, and, means in each gateway node for interpreting, comparing and modifying the header of said each multicast message.
15. The system of claim 14, wherein said plurality of subnetworks are of different types and use different message transmission protocols.
16. The system of claim 15, wherein only a subset of said plurality of subnetworks is equipped to support multicasting.
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
EP92810927.1 | 1992-11-27 | ||
EP92810927A EP0598969B1 (en) | 1992-11-27 | 1992-11-27 | Inter-domain multicast routing |
Publications (2)
Publication Number | Publication Date |
---|---|
CA2105040A1 CA2105040A1 (en) | 1994-05-28 |
CA2105040C true CA2105040C (en) | 1998-04-21 |
Family
ID=8212037
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CA002105040A Expired - Fee Related CA2105040C (en) | 1992-11-27 | 1993-08-27 | Inter-domain multicast routing |
Country Status (11)
Country | Link |
---|---|
US (1) | US5361256A (en) |
EP (1) | EP0598969B1 (en) |
JP (1) | JP2539167B2 (en) |
KR (1) | KR960014987B1 (en) |
CN (1) | CN1052358C (en) |
AT (1) | ATE176744T1 (en) |
BR (1) | BR9304798A (en) |
CA (1) | CA2105040C (en) |
DE (1) | DE69228423T2 (en) |
ES (1) | ES2129038T3 (en) |
TW (1) | TW265497B (en) |
Families Citing this family (286)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
GB9212655D0 (en) * | 1992-06-15 | 1992-07-29 | Digital Equipment Int | Communications system |
US5594872A (en) * | 1993-04-27 | 1997-01-14 | Hitachi, Ltd. | Method of communicating messages in a distributed processing system |
US5963556A (en) * | 1993-06-23 | 1999-10-05 | Digital Equipment Corporation | Device for partitioning ports of a bridge into groups of different virtual local area networks |
JP3361865B2 (en) * | 1993-12-13 | 2003-01-07 | 富士通株式会社 | Automatic setting method of static routing information and computer for automatically setting routing information |
US5509006A (en) * | 1994-04-18 | 1996-04-16 | Cisco Systems Incorporated | Apparatus and method for switching packets using tree memory |
US5519704A (en) * | 1994-04-21 | 1996-05-21 | Cisco Systems, Inc. | Reliable transport protocol for internetwork routing |
US5461611A (en) * | 1994-06-07 | 1995-10-24 | International Business Machines Corporation | Quality of service management for source routing multimedia packet networks |
US5526358A (en) * | 1994-08-19 | 1996-06-11 | Peerlogic, Inc. | Node management in scalable distributed computing enviroment |
US5530703A (en) * | 1994-09-23 | 1996-06-25 | 3Com Corporation | Remote communication server with automatic filtering |
US5793978A (en) * | 1994-12-29 | 1998-08-11 | Cisco Technology, Inc. | System for routing packets by separating packets in to broadcast packets and non-broadcast packets and allocating a selected communication bandwidth to the broadcast packets |
US5867666A (en) * | 1994-12-29 | 1999-02-02 | Cisco Systems, Inc. | Virtual interfaces with dynamic binding |
JP3121221B2 (en) * | 1995-02-07 | 2000-12-25 | 株式会社日立製作所 | Communication method of information processing system and information processing system |
US5608726A (en) * | 1995-04-25 | 1997-03-04 | Cabletron Systems, Inc. | Network bridge with multicast forwarding table |
US6370142B1 (en) * | 1995-07-12 | 2002-04-09 | Nortel Networks Limited | Method and apparatus for performing per-port IP multicast pruning |
US5613071A (en) * | 1995-07-14 | 1997-03-18 | Intel Corporation | Method and apparatus for providing remote memory access in a distributed memory multiprocessor system |
US6041166A (en) * | 1995-07-14 | 2000-03-21 | 3Com Corp. | Virtual network architecture for connectionless LAN backbone |
US6097718A (en) | 1996-01-02 | 2000-08-01 | Cisco Technology, Inc. | Snapshot routing with route aging |
US6147996A (en) | 1995-08-04 | 2000-11-14 | Cisco Technology, Inc. | Pipelined multiple issue packet switch |
US5930259A (en) * | 1995-08-25 | 1999-07-27 | Kabushiki Kaisha Toshiba | Packet transmission node device realizing packet transfer scheme and control information transfer scheme using multiple virtual connections |
US6182224B1 (en) | 1995-09-29 | 2001-01-30 | Cisco Systems, Inc. | Enhanced network services using a subnetwork of communicating processors |
US5818838A (en) * | 1995-10-12 | 1998-10-06 | 3Com Corporation | Method and apparatus for transparent intermediate system based filtering on a LAN of multicast packets |
US5923853A (en) * | 1995-10-24 | 1999-07-13 | Intel Corporation | Using different network addresses for different components of a network-based presentation |
JP3097525B2 (en) * | 1995-11-10 | 2000-10-10 | 株式会社日立製作所 | Data transmission method for performing information filtering |
GB9603582D0 (en) | 1996-02-20 | 1996-04-17 | Hewlett Packard Co | Method of accessing service resource items that are for use in a telecommunications system |
US6091725A (en) | 1995-12-29 | 2000-07-18 | Cisco Systems, Inc. | Method for traffic management, traffic prioritization, access control, and packet forwarding in a datagram computer network |
US6035105A (en) | 1996-01-02 | 2000-03-07 | Cisco Technology, Inc. | Multiple VLAN architecture system |
US5822523A (en) * | 1996-02-01 | 1998-10-13 | Mpath Interactive, Inc. | Server-group messaging system for interactive applications |
US5898830A (en) * | 1996-10-17 | 1999-04-27 | Network Engineering Software | Firewall providing enhanced network security and user transparency |
US5870550A (en) * | 1996-02-26 | 1999-02-09 | Network Engineering Software | Web server employing multi-homed, moldular framework |
US5826014A (en) | 1996-02-06 | 1998-10-20 | Network Engineering Software | Firewall system for protecting network elements connected to a public network |
US8117298B1 (en) | 1996-02-26 | 2012-02-14 | Graphon Corporation | Multi-homed web server |
US5812552A (en) * | 1996-03-19 | 1998-09-22 | At & T Corp | Method and apparatus for dynamically forming multimedia emulated local area networks |
US6069890A (en) | 1996-06-26 | 2000-05-30 | Bell Atlantic Network Services, Inc. | Internet telephone service |
US6154445A (en) | 1996-04-18 | 2000-11-28 | Bell Atlantic Network Services, Inc. | Telephony communication via varied redundant networks |
US5754790A (en) * | 1996-05-01 | 1998-05-19 | 3Com Corporation | Apparatus and method for selecting improved routing paths in an autonomous system of computer networks |
US5778187A (en) * | 1996-05-09 | 1998-07-07 | Netcast Communications Corp. | Multicasting method and apparatus |
US7266686B1 (en) | 1996-05-09 | 2007-09-04 | Two-Way Media Llc | Multicasting method and apparatus |
US6308148B1 (en) | 1996-05-28 | 2001-10-23 | Cisco Technology, Inc. | Network flow data export |
US6243667B1 (en) | 1996-05-28 | 2001-06-05 | Cisco Systems, Inc. | Network flow switching and flow data export |
JP2842524B2 (en) * | 1996-06-06 | 1999-01-06 | 日本電気株式会社 | Multicast group configuration method and multicast communication network |
US5850396A (en) * | 1996-06-24 | 1998-12-15 | Gateway 2000, Inc. | Multicast message distribution in a polynomial expansion manner |
US6212182B1 (en) | 1996-06-27 | 2001-04-03 | Cisco Technology, Inc. | Combined unicast and multicast scheduling |
US6434120B1 (en) | 1998-08-25 | 2002-08-13 | Cisco Technology, Inc. | Autosensing LMI protocols in frame relay networks |
US5913921A (en) * | 1996-07-12 | 1999-06-22 | Glenayre Electronics, Inc. | System for communicating information about nodes configuration by generating advertisements having era values for identifying time reference for which the configuration is operative |
US5940396A (en) * | 1996-08-21 | 1999-08-17 | 3Com Ltd. | Method of routing in an asynchronous transfer mode network |
US5805594A (en) * | 1996-08-23 | 1998-09-08 | International Business Machines Corporation | Activation sequence for a network router |
US5963547A (en) * | 1996-09-18 | 1999-10-05 | Videoserver, Inc. | Method and apparatus for centralized multipoint conferencing in a packet network |
US6321270B1 (en) * | 1996-09-27 | 2001-11-20 | Nortel Networks Limited | Method and apparatus for multicast routing in a network |
US5724412A (en) * | 1996-10-07 | 1998-03-03 | U S West, Inc. | Method and system for displaying internet identification on customer premises equipment |
US6157647A (en) * | 1996-11-06 | 2000-12-05 | 3Com Corporation | Direct addressing between VLAN subnets |
WO1998020647A1 (en) * | 1996-11-08 | 1998-05-14 | Integrated Telecom Technology | Method and apparatus to translate data streams among multiple parties |
US6078582A (en) | 1996-12-18 | 2000-06-20 | Bell Atlantic Network Services, Inc. | Internet long distance telephone service |
US6304546B1 (en) | 1996-12-19 | 2001-10-16 | Cisco Technology, Inc. | End-to-end bidirectional keep-alive using virtual circuits |
EP0854604A1 (en) * | 1997-01-21 | 1998-07-22 | International Business Machines Corporation | Multicast group addressing |
US6198747B1 (en) | 1997-01-30 | 2001-03-06 | International Business Machines Corporation | Method and system for enhancing communications efficiency in data communications networks wherein broadcast occurs |
US6683870B1 (en) * | 1997-02-10 | 2004-01-27 | Mci Communications Corporation | Method and system for multicasting call notifications |
US6215790B1 (en) | 1997-03-06 | 2001-04-10 | Bell Atlantic Network Services, Inc. | Automatic called party locator over internet with provisioning |
US6205139B1 (en) | 1997-03-06 | 2001-03-20 | Bell Atlantic Network Services, Inc. | Automatic called party locator over internet |
US6137869A (en) | 1997-09-16 | 2000-10-24 | Bell Atlantic Network Services, Inc. | Network session management |
US6574216B1 (en) | 1997-03-11 | 2003-06-03 | Verizon Services Corp. | Packet data network voice call quality monitoring |
US6870827B1 (en) | 1997-03-19 | 2005-03-22 | Verizon Services Corp. | Voice call alternative routing through PSTN and internet networks |
DE19711720C2 (en) * | 1997-03-20 | 2001-05-31 | Siemens Ag | Communication system for switching data packets between connected communication terminals and / or communication terminals from connected local area networks |
US6189039B1 (en) | 1997-04-10 | 2001-02-13 | International Business Machines Corporation | Selective tunneling of streaming data |
US6094708A (en) | 1997-05-06 | 2000-07-25 | Cisco Technology, Inc. | Secondary cache write-through blocking mechanism |
US6122272A (en) | 1997-05-23 | 2000-09-19 | Cisco Technology, Inc. | Call size feedback on PNNI operation |
US6356530B1 (en) | 1997-05-23 | 2002-03-12 | Cisco Technology, Inc. | Next hop selection in ATM networks |
US6862284B1 (en) | 1997-06-17 | 2005-03-01 | Cisco Technology, Inc. | Format for automatic generation of unique ATM addresses used for PNNI |
US5959989A (en) * | 1997-06-25 | 1999-09-28 | Cisco Technology, Inc. | System for efficient multicast distribution in a virtual local area network environment |
US6078590A (en) | 1997-07-14 | 2000-06-20 | Cisco Technology, Inc. | Hierarchical routing knowledge for multicast packet routing |
US6330599B1 (en) | 1997-08-05 | 2001-12-11 | Cisco Technology, Inc. | Virtual interfaces with dynamic binding |
US6512766B2 (en) | 1997-08-22 | 2003-01-28 | Cisco Systems, Inc. | Enhanced internet packet routing lookup |
US6212183B1 (en) | 1997-08-22 | 2001-04-03 | Cisco Technology, Inc. | Multiple parallel packet routing lookup |
US6157641A (en) | 1997-08-22 | 2000-12-05 | Cisco Technology, Inc. | Multiprotocol packet recognition and switching |
US6006254A (en) * | 1997-08-29 | 1999-12-21 | Mitsubishi Electric Information Technology Center America, Inc. | System for the reliable, fast, low-latency communication of object state updates over a computer network by combining lossy and lossless communications |
US6288739B1 (en) | 1997-09-05 | 2001-09-11 | Intelect Systems Corporation | Distributed video communications system |
US5949783A (en) * | 1997-09-08 | 1999-09-07 | 3Com Corporation | LAN emulation subsystems for supporting multiple virtual LANS |
NO326260B1 (en) | 1997-09-29 | 2008-10-27 | Ericsson Telefon Ab L M | Method of routing calls from a terminal in a first telecommunications network to a terminal in a second telecommunications network |
US6343072B1 (en) | 1997-10-01 | 2002-01-29 | Cisco Technology, Inc. | Single-chip architecture for shared-memory router |
US6147993A (en) | 1997-10-14 | 2000-11-14 | Cisco Technology, Inc. | Method and apparatus for implementing forwarding decision shortcuts at a network switch |
JP3493309B2 (en) * | 1997-10-31 | 2004-02-03 | 富士通株式会社 | Multicast transmission method |
US6185623B1 (en) | 1997-11-07 | 2001-02-06 | International Business Machines Corporation | Method and system for trivial file transfer protocol (TFTP) subnet broadcast |
NO325072B1 (en) * | 1997-11-11 | 2008-01-28 | Ericsson Telefon Ab L M | Procedure for manual routing of calls from a first telecommunication network to an external telecommunications network |
US6272134B1 (en) * | 1997-11-20 | 2001-08-07 | International Business Machines Corporation | Multicast frame support in hardware routing assist |
US7023967B1 (en) * | 1997-12-04 | 2006-04-04 | Cingular Wireless Ii, Llc | Method and apparatus for voice mail sharing between wired and wireless telephones |
US6131117A (en) * | 1997-12-29 | 2000-10-10 | Cisco Technology, Inc. | Technique for correlating logical names with IP addresses on internetworking platforms |
US6111877A (en) | 1997-12-31 | 2000-08-29 | Cisco Technology, Inc. | Load sharing across flows |
US6119171A (en) | 1998-01-29 | 2000-09-12 | Ip Dynamics, Inc. | Domain name routing |
US6208649B1 (en) | 1998-03-11 | 2001-03-27 | Cisco Technology, Inc. | Derived VLAN mapping technique |
US6115385A (en) | 1998-03-11 | 2000-09-05 | Cisco Technology, Inc. | Method and system for subnetting in a switched IP network |
US6477707B1 (en) | 1998-03-24 | 2002-11-05 | Fantastic Corporation | Method and system for broadcast transmission of media objects |
US6208623B1 (en) | 1998-04-13 | 2001-03-27 | 3Com Corporation | Method of combining PNNI and E-IISP in an asynchronous transfer mode network |
US6151633A (en) | 1998-04-20 | 2000-11-21 | Sun Microsystems, Inc. | Method and apparatus for routing and congestion control in multicast networks |
US6396842B1 (en) | 1998-04-30 | 2002-05-28 | 3Com Corporation | Method of searching using longest match based Randix Search Trie with variable length keys and having prefix capability |
US6212188B1 (en) | 1998-05-01 | 2001-04-03 | 3Com Corporation | Method of source routing in an asynchronous transfer mode network when a node is in an overload state |
US6192043B1 (en) | 1998-05-01 | 2001-02-20 | 3Com Corporation | Method of caching routes in asynchronous transfer mode PNNI networks |
US6133912A (en) * | 1998-05-04 | 2000-10-17 | Montero; Frank J. | Method of delivering information over a communication network |
US6262984B1 (en) | 1998-05-12 | 2001-07-17 | 3Com Corporation | Method of preventing overlapping branches in point to multipoint calls in PNNI networks |
US6223149B1 (en) | 1998-05-28 | 2001-04-24 | 3Com Corporation | Non-distributed LAN emulation server redundancy method |
US6205146B1 (en) | 1998-05-28 | 2001-03-20 | 3Com Corporation | Method of dynamically routing to a well known address in a network |
US6163810A (en) * | 1998-06-02 | 2000-12-19 | At&T Corp. | System and method for managing the exchange of information between multicast and unicast hosts |
US6754224B1 (en) * | 1998-06-24 | 2004-06-22 | Cisco Technology, Inc. | Method and apparatus for multicast call signaling in packet network |
JP2002519891A (en) * | 1998-06-25 | 2002-07-02 | エムシーアイ・ワールドコム・インコーポレーテッド | Method and system for broadcasting call notifications |
US6356548B1 (en) | 1998-06-29 | 2002-03-12 | Cisco Technology, Inc. | Pooled receive and transmit queues to access a shared bus in a multi-port switch asic |
US6370121B1 (en) | 1998-06-29 | 2002-04-09 | Cisco Technology, Inc. | Method and system for shortcut trunking of LAN bridges |
US6377577B1 (en) | 1998-06-30 | 2002-04-23 | Cisco Technology, Inc. | Access control list processing in hardware |
US6567914B1 (en) * | 1998-07-22 | 2003-05-20 | Entrust Technologies Limited | Apparatus and method for reducing transmission bandwidth and storage requirements in a cryptographic security system |
US6308219B1 (en) | 1998-07-31 | 2001-10-23 | Cisco Technology, Inc. | Routing table lookup implemented using M-trie having nodes duplicated in multiple memory banks |
US6182147B1 (en) | 1998-07-31 | 2001-01-30 | Cisco Technology, Inc. | Multicast group routing using unidirectional links |
US6389506B1 (en) | 1998-08-07 | 2002-05-14 | Cisco Technology, Inc. | Block mask ternary cam |
US6101115A (en) | 1998-08-07 | 2000-08-08 | Cisco Technology, Inc. | CAM match line precharge |
US6584093B1 (en) * | 1998-08-25 | 2003-06-24 | Cisco Technology, Inc. | Method and apparatus for automatic inter-domain routing of calls |
US6490285B2 (en) | 1998-08-25 | 2002-12-03 | International Business Machines Corporation | IP multicast interface |
US6389027B1 (en) | 1998-08-25 | 2002-05-14 | International Business Machines Corporation | IP multicast interface |
US6600743B1 (en) * | 1998-08-25 | 2003-07-29 | International Business Machines Corporation | IP multicast interface |
US6327621B1 (en) * | 1998-08-25 | 2001-12-04 | International Business Machines Corporation | Method for shared multicast interface in a multi-partition environment |
US6141347A (en) * | 1998-08-26 | 2000-10-31 | Motorola, Inc. | Wireless communication system incorporating multicast addressing and method for use |
US6445715B1 (en) | 1998-08-27 | 2002-09-03 | Cisco Technology, Inc. | Dynamic trunk protocol |
US6421732B1 (en) | 1998-08-27 | 2002-07-16 | Ip Dynamics, Inc. | Ipnet gateway |
US6266705B1 (en) | 1998-09-29 | 2001-07-24 | Cisco Systems, Inc. | Look up mechanism and associated hash table for a network switch |
US6785274B2 (en) | 1998-10-07 | 2004-08-31 | Cisco Technology, Inc. | Efficient network multicast switching apparatus and methods |
US6993034B1 (en) | 1998-10-15 | 2006-01-31 | International Business Machines Corporation | Cluster destination address table—IP routing for clusters |
US7246168B1 (en) | 1998-11-19 | 2007-07-17 | Cisco Technology, Inc. | Technique for improving the interaction between data link switch backup peer devices and ethernet switches |
JP2000183873A (en) * | 1998-12-11 | 2000-06-30 | Fujitsu Ltd | Data transfer method |
US6771642B1 (en) | 1999-01-08 | 2004-08-03 | Cisco Technology, Inc. | Method and apparatus for scheduling packets in a packet switch |
US6611872B1 (en) * | 1999-01-11 | 2003-08-26 | Fastforward Networks, Inc. | Performing multicast communication in computer networks by using overlay routing |
US6507863B2 (en) | 1999-01-27 | 2003-01-14 | International Business Machines Corporation | Dynamic multicast routing facility for a distributed computing environment |
US6631420B1 (en) * | 1999-02-25 | 2003-10-07 | Nortel Networks Limited | Reducing convergence time by a protocol independent multicast (PIM) router |
US6757791B1 (en) | 1999-03-30 | 2004-06-29 | Cisco Technology, Inc. | Method and apparatus for reordering packet data units in storage queues for reading and writing memory |
US6192417B1 (en) * | 1999-03-30 | 2001-02-20 | International Business Machines Corporation | Multicast cluster servicer for communicating amongst a plurality of nodes without a dedicated local area network |
US6603772B1 (en) | 1999-03-31 | 2003-08-05 | Cisco Technology, Inc. | Multicast routing with multicast virtual output queues and shortest queue first allocation |
US6760331B1 (en) | 1999-03-31 | 2004-07-06 | Cisco Technology, Inc. | Multicast routing with nearest queue first allocation and dynamic and static vector quantization |
US6393423B1 (en) | 1999-04-08 | 2002-05-21 | James Francis Goedken | Apparatus and methods for electronic information exchange |
US6725276B1 (en) * | 1999-04-13 | 2004-04-20 | Nortel Networks Limited | Apparatus and method for authenticating messages transmitted across different multicast domains |
US6654371B1 (en) * | 1999-04-15 | 2003-11-25 | Nortel Networks Limited | Method and apparatus for forwarding multicast data by relaying IGMP group membership |
US6577653B1 (en) | 1999-04-28 | 2003-06-10 | 3Com Corporation | Apparatus for and method of establishing a route utilizing multiple parallel segments in an asynchronous transfer mode network |
US6594235B1 (en) | 1999-04-28 | 2003-07-15 | 3Com Corporation | Method of triggering reroutes in an asynchronous transfer mode network |
US6456600B1 (en) | 1999-04-28 | 2002-09-24 | 3Com Corporation | Complex node representation in an asynchronous transfer mode PNNI network |
US6483808B1 (en) | 1999-04-28 | 2002-11-19 | 3Com Corporation | Method of optimizing routing decisions over multiple parameters utilizing fuzzy logic |
US6839348B2 (en) | 1999-04-30 | 2005-01-04 | Cisco Technology, Inc. | System and method for distributing multicasts in virtual local area networks |
US6553028B1 (en) | 1999-04-30 | 2003-04-22 | Cisco Technology, Inc. | Method and apparatus for multicast switching using a centralized switching engine |
US6473408B1 (en) | 1999-05-19 | 2002-10-29 | 3Com Corporation | Building a hierarchy in an asynchronous transfer mode PNNI network utilizing proxy SVCC-based RCC entities |
US6571272B1 (en) | 1999-05-20 | 2003-05-27 | Cisco Technology, Inc. | Method and apparatus for SNA/IP correlation with multiple DSW peer connections |
US6532241B1 (en) | 1999-05-20 | 2003-03-11 | Cisco Technology, Inc. | Method and apparatus for determining SNA sessions using various protocols for transport based on filter criteria |
US6430595B1 (en) | 1999-05-20 | 2002-08-06 | Cisco Technology, Inc. | Method and apparatus for establishing a database used for correlating information gathered via SNMP |
US6490618B1 (en) | 1999-05-20 | 2002-12-03 | Cisco Technology, Inc. | Method and apparatus for SNA/IP correlation in a mixed APPN and DLSW network |
US6553423B1 (en) * | 1999-05-27 | 2003-04-22 | Cisco Technology, Inc. | Method and apparatus for dynamic exchange of capabilities between adjacent/neighboring networks nodes |
US6614792B1 (en) | 1999-05-27 | 2003-09-02 | 3Com Corporation | Proxy MPC for providing MPOA services to legacy lane clients in an asynchronous transfer mode network |
EP1186142A4 (en) * | 1999-05-28 | 2003-04-16 | Motorola Inc | Dispatch service to dispatch clients via a packet-switched network |
EP1063814A1 (en) * | 1999-06-24 | 2000-12-27 | Alcatel | A method to forward a multicast packet |
US6684331B1 (en) | 1999-12-22 | 2004-01-27 | Cisco Technology, Inc. | Method and apparatus for distributing and updating group controllers over a wide area network using a tree structure |
US7181014B1 (en) | 1999-09-10 | 2007-02-20 | Cisco Technology, Inc. | Processing method for key exchange among broadcast or multicast groups that provides a more efficient substitute for Diffie-Hellman key exchange |
US6987855B1 (en) | 1999-09-10 | 2006-01-17 | Cisco Technology, Inc. | Operational optimization of a shared secret Diffie-Hellman key exchange among broadcast or multicast groups |
US7013389B1 (en) | 1999-09-29 | 2006-03-14 | Cisco Technology, Inc. | Method and apparatus for creating a secure communication channel among multiple event service nodes |
US7434046B1 (en) | 1999-09-10 | 2008-10-07 | Cisco Technology, Inc. | Method and apparatus providing secure multicast group communication |
US7260716B1 (en) * | 1999-09-29 | 2007-08-21 | Cisco Technology, Inc. | Method for overcoming the single point of failure of the central group controller in a binary tree group key exchange approach |
US7103185B1 (en) | 1999-12-22 | 2006-09-05 | Cisco Technology, Inc. | Method and apparatus for distributing and updating private keys of multicast group managers using directory replication |
US6952421B1 (en) | 1999-10-07 | 2005-10-04 | Cisco Technology, Inc. | Switched Ethernet path detection |
ATE382220T1 (en) * | 1999-10-12 | 2008-01-15 | Alcatel Lucent | APPARATUS AND METHOD FOR COMPRESSING MULTI-MESSAGE DESTINATION ADDRESSES |
US6529983B1 (en) | 1999-11-03 | 2003-03-04 | Cisco Technology, Inc. | Group and virtual locking mechanism for inter processor synchronization |
US6578087B1 (en) * | 1999-11-12 | 2003-06-10 | Cisco Technology, Inc. | Determining a path through a managed network |
FR2801454B1 (en) * | 1999-11-18 | 2004-04-30 | Cit Alcatel | X25 NETWORK AND DATA TRANSMISSION METHOD |
US6667976B1 (en) * | 1999-12-09 | 2003-12-23 | Lucent Technologies Inc. | Fuzzycast service in switches |
US6928483B1 (en) * | 1999-12-10 | 2005-08-09 | Nortel Networks Limited | Fast path forwarding of link state advertisements |
US6678279B1 (en) | 1999-12-13 | 2004-01-13 | Nortel Networks Limited | System and method to implement a packet switch buffer for unicast and multicast data |
WO2001052482A1 (en) * | 2000-01-10 | 2001-07-19 | British Telecommunications Public Limited Company | Communications network |
US7089211B1 (en) | 2000-01-12 | 2006-08-08 | Cisco Technology, Inc. | Directory enabled secure multicast group communications |
IL140504A0 (en) * | 2000-02-03 | 2002-02-10 | Bandwiz Inc | Broadcast system |
JP3774351B2 (en) * | 2000-02-17 | 2006-05-10 | 富士通株式会社 | Packet conversion apparatus and packet conversion method |
JP3667586B2 (en) | 2000-02-28 | 2005-07-06 | 日本電気株式会社 | Multicast packet transfer device, multicast packet transfer system, and storage medium |
JP3506092B2 (en) * | 2000-02-28 | 2004-03-15 | 日本電気株式会社 | Multicast packet transfer device, multicast packet transfer system and storage medium |
US7016351B1 (en) * | 2000-02-29 | 2006-03-21 | Cisco Technology, Inc. | Small group multicast in a computer network |
US6757294B1 (en) * | 2000-03-13 | 2004-06-29 | International Business Machines Corporation | System and method for amicable small group multicast in a packet-switched network |
US6785275B1 (en) | 2000-03-13 | 2004-08-31 | International Business Machines Corporation | Method and system for creating small group multicast over an existing unicast packet network |
US6732189B1 (en) | 2000-03-20 | 2004-05-04 | International Business Machines Corporation | Method and apparatus for fault tolerant tunneling of multicast datagrams |
US6791981B1 (en) | 2000-03-21 | 2004-09-14 | International Business Machines Corporation | Method and apparatus for building a medium cost, self similar, self organizing multicast routing tree |
US6735200B1 (en) | 2000-03-21 | 2004-05-11 | International Business Machines Corporation | Method and apparatus for monitoring the availability of nodes in a communications network |
US6892237B1 (en) | 2000-03-28 | 2005-05-10 | Cisco Technology, Inc. | Method and apparatus for high-speed parsing of network messages |
WO2001076266A1 (en) * | 2000-03-31 | 2001-10-11 | British Telecommunications Public Limited Company | Method of determining network paths |
US7123620B1 (en) | 2000-04-25 | 2006-10-17 | Cisco Technology, Inc. | Apparatus and method for scalable and dynamic traffic engineering in a data communication network |
US7065079B1 (en) | 2000-05-04 | 2006-06-20 | Cisco Technology, Inc. | VC sharing for multicast in a computer network |
US6505269B1 (en) | 2000-05-16 | 2003-01-07 | Cisco Technology, Inc. | Dynamic addressing mapping to eliminate memory resource contention in a symmetric multiprocessor system |
EP1158731A3 (en) * | 2000-05-25 | 2003-08-13 | Roke Manor Research Limited | Improvements in or relating to packet switches |
JP2001339431A (en) * | 2000-05-26 | 2001-12-07 | Fujitsu Ltd | Communication system, repeater, end system and communication method |
US7111058B1 (en) | 2000-06-28 | 2006-09-19 | Cisco Technology, Inc. | Server and method for transmitting streaming media to client through a congested network |
US6941457B1 (en) | 2000-06-30 | 2005-09-06 | Cisco Technology, Inc. | Establishing a new shared secret key over a broadcast channel for a multicast group based on an old shared secret key |
US8301137B1 (en) * | 2000-07-31 | 2012-10-30 | Interdigital Patent Corporation | Method and apparatus for wireless router multicast |
US6781959B1 (en) | 2000-07-31 | 2004-08-24 | Cisco Technology, Inc. | Method and apparatus for determining troubleshooting information for completed calls in a telecommunications network |
US7133404B1 (en) | 2000-08-11 | 2006-11-07 | Ip Dynamics, Inc. | Communication using two addresses for an entity |
ATE326097T1 (en) * | 2000-08-25 | 2006-06-15 | Cit Alcatel | METHOD FOR PROVIDING A BIDIRECTIONAL CONNECTION IN A NETWORK FOR THE MULTIPLE TRANSMISSION OF DATA STREAMS USING THE INTERNET PROTOCOL AND NETWORK FOR APPLYING THE METHOD |
US7720903B1 (en) | 2000-08-31 | 2010-05-18 | Intel Corporation | Client messaging in multicast networks |
US6839436B1 (en) * | 2000-10-16 | 2005-01-04 | Lucent Technologies Inc. | Method for providing long-lived broadcast encrypton |
US8023421B2 (en) | 2002-07-25 | 2011-09-20 | Avaya Inc. | Method and apparatus for the assessment and optimization of network traffic |
US7756032B2 (en) | 2000-10-17 | 2010-07-13 | Avaya Inc. | Method and apparatus for communicating data within measurement traffic |
US7363367B2 (en) | 2000-10-17 | 2008-04-22 | Avaya Technology Corp. | Systems and methods for robust, real-time measurement of network performance |
US7080161B2 (en) * | 2000-10-17 | 2006-07-18 | Avaya Technology Corp. | Routing information exchange |
US7349994B2 (en) | 2000-10-17 | 2008-03-25 | Avaya Technology Corp. | Method and apparatus for coordinating routing parameters via a back-channel communication medium |
US7720959B2 (en) | 2000-10-17 | 2010-05-18 | Avaya Inc. | Method and apparatus for characterizing the quality of a network path |
AU2002213287A1 (en) | 2000-10-17 | 2002-04-29 | Routescience Technologies Inc | Method and apparatus for performance and cost optimization in an internetwork |
US7406539B2 (en) | 2000-10-17 | 2008-07-29 | Avaya Technology Corp. | Method and apparatus for performance and cost optimization in an internetwork |
US20020150094A1 (en) * | 2000-10-27 | 2002-10-17 | Matthew Cheng | Hierarchical level-based internet protocol multicasting |
US6529481B2 (en) * | 2000-11-30 | 2003-03-04 | Pluris, Inc. | Scalable and fault-tolerant link state routing protocol for packet-switched networks |
US6785254B2 (en) * | 2000-12-01 | 2004-08-31 | Motorola, Inc. | Wireless communication system incorporating multicast addressing and method for use |
US6618388B2 (en) | 2001-01-05 | 2003-09-09 | Extreme Networks | Method and system for VMAN protocol |
US6760549B2 (en) * | 2001-01-30 | 2004-07-06 | The Regents Of The University Of California | Optical layer multicasting using a multiple sub-carrier header and multicasting switch |
US6766114B2 (en) * | 2001-01-30 | 2004-07-20 | The Regents Of The University Of California | Optical layer multicasting using a single sub-carrier header and a multicast switch with active header insertion via single sideband optical processing |
US6754449B2 (en) * | 2001-01-30 | 2004-06-22 | The Regents Of The University Of California | Optical layer multicasting switch |
US6934472B2 (en) * | 2001-01-30 | 2005-08-23 | The Regents Of The University Of California | Optical layer multicasting using a single sub-carrier header and a multicast switch with active header insertion |
US6757497B2 (en) * | 2001-01-30 | 2004-06-29 | The Regents Of The University Of California | Optical layer multicasting using a single sub-carrier header and a multicast switch with active header insertion via reflective single sideband optical processing |
US6757496B2 (en) * | 2001-01-30 | 2004-06-29 | The Regents Of The University Of California | Optical layer multicasting using a single sub-carrier header and an optical multicasting switch |
US6768871B2 (en) * | 2001-01-30 | 2004-07-27 | The Regents Of The University Of California | Optical layer multicasting using a multicast switch to effect survivability and security |
US6850707B1 (en) * | 2001-01-30 | 2005-02-01 | The Regents Of The University Of California | Secure optical layer multicasting to effect survivability |
US6757495B2 (en) * | 2001-01-30 | 2004-06-29 | The Regents Of The University Of California | Optical layer multicasting using a multiple sub-carrier header and a multicast switch with active header insertion via single sideband optical processing |
US7039316B2 (en) | 2001-01-30 | 2006-05-02 | The Regents Of The University Of California | Optical layer multicasting using a multiple sub-carrier header and a multicast switch with active header insertion via reflective single sideband optical processing |
US7054276B2 (en) * | 2001-02-07 | 2006-05-30 | International Business Machines Corporation | System and method for a multicast network messaging service |
US20020174172A1 (en) * | 2001-03-29 | 2002-11-21 | Hatalkar Atul N. | Mechanism to control compilation and communication of the client-device profile by using unidirectional messaging over a broadcast channel |
US7433957B2 (en) * | 2001-04-30 | 2008-10-07 | International Business Machines Corporation | Group access privatization in clustered computer system |
KR20020023100A (en) * | 2001-05-28 | 2002-03-28 | 박현제 | System for virtual multicast network depolyment |
KR100377852B1 (en) * | 2001-06-15 | 2003-03-29 | 주식회사 미라콤아이앤씨 | Message transmission method and system capable of balancing load |
KR100377853B1 (en) * | 2001-06-18 | 2003-03-29 | 주식회사 미라콤아이앤씨 | Message transmission method and system capable of transmitting differential data |
US6996103B1 (en) * | 2001-06-20 | 2006-02-07 | Cisco Technology, Inc. | Method and system for multicasting |
US7193974B2 (en) * | 2001-08-10 | 2007-03-20 | Intel Corporation | Method and apparatus for dynamically discovering alias domains |
CN100420192C (en) * | 2001-08-29 | 2008-09-17 | 艾利森电话股份有限公司 | Method and device for multicasting in a UMTS network |
US6697349B2 (en) * | 2001-08-30 | 2004-02-24 | Motorola, Inc. | System and methods for distributed connection and mobility processing in a multicast IP network incorporating multi-cell location areas |
US7110404B1 (en) * | 2001-09-04 | 2006-09-19 | Cisco Technology, Inc. | System and method for sending a packet to multiple destinations using a pipeline network processor |
US7039052B2 (en) * | 2001-09-19 | 2006-05-02 | International Business Machines Corporation | Selective routing of multi-recipient communications |
US7009972B2 (en) * | 2001-09-24 | 2006-03-07 | Motorola, Inc | Multicast IP zones for fast spanning tree convergence in wide-area packet network systems |
US7389359B2 (en) * | 2001-10-19 | 2008-06-17 | Foundry Networks, Inc. | Method and system for intelligently forwarding multicast packets |
US7647422B2 (en) | 2001-11-06 | 2010-01-12 | Enterasys Networks, Inc. | VPN failure recovery |
US7334125B1 (en) | 2001-11-27 | 2008-02-19 | Cisco Technology, Inc. | Facilitating secure communications among multicast nodes in a telecommunications network |
US8688853B2 (en) * | 2001-12-21 | 2014-04-01 | Agere Systems Llc | Method and apparatus for maintaining multicast lists in a data network |
EP1324560B1 (en) * | 2001-12-28 | 2008-01-16 | Motorola, Inc. | Communication over a selected part of a network |
GB2385499A (en) * | 2002-02-18 | 2003-08-20 | Venation Ltd | Network transport protocol |
EP2375689A3 (en) | 2002-03-01 | 2012-01-11 | Enterasys Networks, Inc. | Location discovery in a data network |
US7337234B2 (en) * | 2002-04-05 | 2008-02-26 | Oracle International Corporation | Retry technique for multi-tier network communication systems |
US7302691B2 (en) * | 2002-05-10 | 2007-11-27 | Sonics, Incorporated | Scalable low bandwidth multicast handling in mixed core systems |
US7937471B2 (en) * | 2002-06-03 | 2011-05-03 | Inpro Network Facility, Llc | Creating a public identity for an entity on a network |
TWI265697B (en) * | 2002-06-06 | 2006-11-01 | Ibm | Digital contents distribution system, digital contents distribution method, computer readable recording medium storing the program therein, and server and client therefor |
US7480256B2 (en) * | 2002-08-14 | 2009-01-20 | Pluris, Inc. | Scalable and fault-tolerant link state routing protocol for packet-switched networks |
US7139828B2 (en) * | 2002-08-30 | 2006-11-21 | Ip Dynamics, Inc. | Accessing an entity inside a private network |
US8234358B2 (en) | 2002-08-30 | 2012-07-31 | Inpro Network Facility, Llc | Communicating with an entity inside a private network using an existing connection to initiate communication |
US7613796B2 (en) | 2002-09-11 | 2009-11-03 | Microsoft Corporation | System and method for creating improved overlay network with an efficient distributed data structure |
US7949785B2 (en) * | 2003-03-31 | 2011-05-24 | Inpro Network Facility, Llc | Secure virtual community network system |
JP4547195B2 (en) * | 2003-06-20 | 2010-09-22 | 株式会社エヌ・ティ・ティ・ドコモ | Network system, control device, router device, access point and mobile terminal |
US20050010687A1 (en) * | 2003-06-26 | 2005-01-13 | Silicon Graphics, Inc. | Multiprocessor network multicasting and gathering |
JP4328283B2 (en) * | 2003-10-22 | 2009-09-09 | パナソニック株式会社 | Packet delivery control method |
US7580403B2 (en) | 2004-02-26 | 2009-08-25 | Enterasys Networks, Inc. | Status transmission system and method |
MXPA06015212A (en) * | 2004-07-09 | 2007-03-15 | Interdigital Tech Corp | Logical and physical mesh network separation. |
US7945945B2 (en) | 2004-08-06 | 2011-05-17 | Enterasys Networks, Inc. | System and method for address block enhanced dynamic network policy management |
US7693132B1 (en) | 2004-10-01 | 2010-04-06 | Avaya Canada Corp. | Multicast and unicast message re-direction system, method, message re-director, and network device |
TWI391018B (en) | 2004-11-05 | 2013-03-21 | Ruckus Wireless Inc | Throughput enhancement by acknowledgment suppression |
US7505447B2 (en) | 2004-11-05 | 2009-03-17 | Ruckus Wireless, Inc. | Systems and methods for improved data throughput in communications networks |
US8638708B2 (en) | 2004-11-05 | 2014-01-28 | Ruckus Wireless, Inc. | MAC based mapping in IP based communications |
US8619662B2 (en) | 2004-11-05 | 2013-12-31 | Ruckus Wireless, Inc. | Unicast to multicast conversion |
US7347628B2 (en) | 2004-11-08 | 2008-03-25 | Enterasys Networks, Inc. | Optical interface identification system |
US7729350B2 (en) * | 2004-12-30 | 2010-06-01 | Nokia, Inc. | Virtual multicast routing for a cluster having state synchronization |
US20060227772A1 (en) * | 2005-03-30 | 2006-10-12 | Fujitsu Limited | Method and system for packet data communication between networks |
US8086232B2 (en) | 2005-06-28 | 2011-12-27 | Enterasys Networks, Inc. | Time synchronized wireless method and operations |
US8259593B2 (en) * | 2005-06-29 | 2012-09-04 | Honeywell International Inc. | Apparatus and method for segmenting a communication network |
KR100664937B1 (en) * | 2005-07-09 | 2007-01-04 | 삼성전자주식회사 | Method for transmitting web services message to plurality of receiver and apparatus for processing web services message |
US7787361B2 (en) | 2005-07-29 | 2010-08-31 | Cisco Technology, Inc. | Hybrid distance vector protocol for wireless mesh networks |
US20070044130A1 (en) * | 2005-08-16 | 2007-02-22 | Alcatel | System and method for implementing channel change operations in internet protocol television systems |
US7660318B2 (en) * | 2005-09-20 | 2010-02-09 | Cisco Technology, Inc. | Internetworking support between a LAN and a wireless mesh network |
WO2007038856A1 (en) | 2005-10-05 | 2007-04-12 | Nortel Networks Limited | Provider link state bridging |
US8059647B2 (en) | 2005-10-05 | 2011-11-15 | Nortel Networks Limited | Multicast implementation in a link state protocol controlled ethernet network |
US20070110024A1 (en) * | 2005-11-14 | 2007-05-17 | Cisco Technology, Inc. | System and method for spanning tree cross routes |
US7860106B2 (en) * | 2006-02-13 | 2010-12-28 | Wind River Systems, Inc. | System and method for routing table computation and analysis |
CN100413275C (en) * | 2006-03-02 | 2008-08-20 | 华为技术有限公司 | Realizing method for automatic exchanging optic network multicast network interface service |
US7742475B2 (en) * | 2006-05-03 | 2010-06-22 | Cisco Technology, Inc. | Techniques for distributing replication points for traffic using point-to-point links |
US8547899B2 (en) | 2007-07-28 | 2013-10-01 | Ruckus Wireless, Inc. | Wireless network throughput enhancement through channel aware scheduling |
US7664880B2 (en) * | 2007-08-15 | 2010-02-16 | Microsoft Corporation | Lightweight address for widely-distributed ADHOC multicast groups |
US8355343B2 (en) | 2008-01-11 | 2013-01-15 | Ruckus Wireless, Inc. | Determining associations in a mesh network |
US8630228B2 (en) * | 2009-03-12 | 2014-01-14 | Qualcomm Incorporated | Method and apparatus for providing position related data |
US8238538B2 (en) | 2009-05-28 | 2012-08-07 | Comcast Cable Communications, Llc | Stateful home phone service |
CN102763378B (en) | 2009-11-16 | 2015-09-23 | 鲁库斯无线公司 | Set up and there is wired and mesh network that is wireless link |
US9979626B2 (en) | 2009-11-16 | 2018-05-22 | Ruckus Wireless, Inc. | Establishing a mesh network with wired and wireless links |
US20120094600A1 (en) | 2010-10-19 | 2012-04-19 | Welch Allyn, Inc. | Platform for patient monitoring |
WO2012136005A1 (en) * | 2011-04-08 | 2012-10-11 | Zte Corporation | A method for addressing a m2m terminal and a m2m platform device |
EP3157203B1 (en) * | 2014-06-16 | 2018-07-04 | Ricoh Company, Ltd. | Network system, communication control method, and storage medium |
US9450916B2 (en) | 2014-08-22 | 2016-09-20 | Honeywell International Inc. | Hardware assist for redundant ethernet network |
US9333538B1 (en) | 2015-02-26 | 2016-05-10 | American Biocarbon, LLC | Technologies for material separation |
US9973447B2 (en) | 2015-07-23 | 2018-05-15 | Honeywell International Inc. | Built-in ethernet switch design for RTU redundant system |
US10681417B2 (en) * | 2017-05-12 | 2020-06-09 | Google Llc | Enhanced multicast network communications |
CN110324263B (en) * | 2018-03-30 | 2021-06-29 | 华为技术有限公司 | Method, equipment and system for transmitting multicast message |
US11362954B2 (en) * | 2019-03-27 | 2022-06-14 | Nokia Solutions And Networks Oy | Tunneling inter-domain stateless internet protocol multicast packets |
US11855893B2 (en) | 2021-11-24 | 2023-12-26 | Amazon Technologies, Inc. | Tag-based cross-region segment management |
US11799755B2 (en) * | 2021-11-24 | 2023-10-24 | Amazon Technologies, Inc. | Metadata-based cross-region segment routing |
Family Cites Families (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPS61214859A (en) * | 1985-03-20 | 1986-09-24 | Fujitsu Ltd | Destination indicating control system |
FR2631760B1 (en) * | 1988-05-20 | 1993-11-05 | Lmt Radio Professionnelle | METHOD AND DEVICE FOR TRANSMITTING A DATA PACKET |
US5079767A (en) * | 1988-09-27 | 1992-01-07 | Digital Equipment Corporation | Method of multicast message distribution |
US5095480A (en) * | 1989-06-16 | 1992-03-10 | Fenner Peter R | Message routing system for shared communication media networks |
JPH03125537A (en) * | 1989-10-11 | 1991-05-28 | Mitsubishi Electric Corp | Packet repeating method in packet switching network |
US5138614A (en) * | 1990-04-12 | 1992-08-11 | At&T Bell Laboratories | Transformation method for network conference connections |
-
1992
- 1992-11-27 ES ES92810927T patent/ES2129038T3/en not_active Expired - Lifetime
- 1992-11-27 EP EP92810927A patent/EP0598969B1/en not_active Expired - Lifetime
- 1992-11-27 AT AT92810927T patent/ATE176744T1/en not_active IP Right Cessation
- 1992-11-27 DE DE69228423T patent/DE69228423T2/en not_active Expired - Lifetime
-
1993
- 1993-05-27 US US08/068,351 patent/US5361256A/en not_active Expired - Lifetime
- 1993-08-27 CA CA002105040A patent/CA2105040C/en not_active Expired - Fee Related
- 1993-10-18 TW TW082108622A patent/TW265497B/zh not_active IP Right Cessation
- 1993-10-20 JP JP26259193A patent/JP2539167B2/en not_active Expired - Fee Related
- 1993-10-27 KR KR1019930022462A patent/KR960014987B1/en not_active IP Right Cessation
- 1993-11-23 BR BR9304798A patent/BR9304798A/en not_active IP Right Cessation
- 1993-11-24 CN CN93121109A patent/CN1052358C/en not_active Expired - Lifetime
Also Published As
Publication number | Publication date |
---|---|
ATE176744T1 (en) | 1999-02-15 |
DE69228423D1 (en) | 1999-03-25 |
EP0598969B1 (en) | 1999-02-10 |
CA2105040A1 (en) | 1994-05-28 |
CN1091570A (en) | 1994-08-31 |
KR940012961A (en) | 1994-06-24 |
TW265497B (en) | 1995-12-11 |
CN1052358C (en) | 2000-05-10 |
EP0598969A1 (en) | 1994-06-01 |
KR960014987B1 (en) | 1996-10-23 |
JP2539167B2 (en) | 1996-10-02 |
DE69228423T2 (en) | 1999-09-30 |
BR9304798A (en) | 1994-05-31 |
US5361256A (en) | 1994-11-01 |
JPH06224912A (en) | 1994-08-12 |
ES2129038T3 (en) | 1999-06-01 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CA2105040C (en) | Inter-domain multicast routing | |
US6839348B2 (en) | System and method for distributing multicasts in virtual local area networks | |
US6611528B1 (en) | Hierarchical routing knowledge for multicast packet routing | |
US5600644A (en) | Method and apparatus for interconnecting LANs | |
US7860094B2 (en) | Multicast routing method and apparatus for routing multicast packet | |
US6631136B1 (en) | Methods and apparatus for data communication using a hybrid transport switching protocol | |
EP0937353B1 (en) | Routing in a multi-layer distributed network element | |
US7307990B2 (en) | Shared communications network employing virtual-private-network identifiers | |
US7835276B2 (en) | Admission control mechanism for multicast receivers | |
US7877508B1 (en) | Method and system for intelligently forwarding multicast packets | |
US5870386A (en) | Method and apparatus for transparently bridging traffic across wide area networks | |
JP2001036583A (en) | Method for transferring multi-cast packet, entrance node and router to realize such method and internet network including such entrance node and such router | |
US6731632B1 (en) | Internetworking system and method | |
US5943317A (en) | Sub-network route optimization over a shared access transport facility | |
Cisco | IP Routing Protocols Commands | |
Cisco | IP Routing Protocols Commands | |
Cisco | IP Routing Protocols Commands | |
Cisco | IP Routing Protocols Commands | |
Cisco | IP Routing Protocols Commands | |
Cisco | IP Routing Protocols Commands | |
Cisco | Configuring IP Multicast Routing | |
Cisco | IP Routing Protocols Commands | |
Cisco | IP Routing Protocols Commands | |
Cisco | IP Routing Protocols Commands | |
Cisco | IP Routing Protocols Commands |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
EEER | Examination request | ||
MKLA | Lapsed |