Multiplex communications – Pathfinding or routing – Switching a message which includes an address header
Reexamination Certificate
1997-04-02
2002-04-09
Patel, Ajit (Department: 2662)
Multiplex communications
Pathfinding or routing
Switching a message which includes an address header
C370S401000, C370S432000
Reexamination Certificate
active
06370142
ABSTRACT:
FIELD OF THE INVENTION
The invention relates generally to the field of switched networks and Internet Protocol (IP) multicast forwarding. More specifically, the invention relates to pruning IP multicast traffic within an IP subnet and the determination of IP multicast group memberships in a switched network.
BACKGROUND OF THE INVENTION
Multicast is the transmission of information to a group of recipients (e.g., a multicast group) via a single transmission by the source. A protocol used to support membership registration for IP multicast traffic is Internet Group Management Protocol (IGMP). IGMP is used by end-stations in networks to communicate the addresses of IP multicast groups in which the end-stations would like to participate. Using this multicast group membership information from IGMP, routers carry out multicast pruning. Multicast packets are transmitted in such a way that only subnets with members (learned through IGMP) receive the appropriate multicast traffic. Further, multicast packets are forwarded in such a way that there is no “looping” of packets in the network. Loops are avoided within subnets by using a spanning tree algorithm and across subnets through the use of a multicast routing protocol. This prior method of multicast pruning performed by IGMP routers will be discussed further with reference to FIG.
2
.
Brief Overview of Internet Group Management Protocol (IGMP)
IGMP messages have an eight octet format including a type field and a group address field. IGMP messages are encapsulated in IP Datagrams using an IP protocol number of two. Three types of IGMP messages are exchanged between IP hosts and multicast routers: membership query messages, membership report messages, and leave group messages. As illustrated by
FIG. 1A
, membership query messages (represented with solid arrows) are used by multicast routers (e.g., router
110
) to learn which IP multicast groups have members on a particular attached network. The membership query messages are forwarded to each connected interface by intermediate switches
120
. IP hosts
130
respond to membership query messages with membership reports (represented with dashed arrows) which identify a multicast group in which the reporting IP host is participating. IP hosts
130
can also send unsolicited membership reports when they wish to join a multicast group. Further, leave group messages (not shown) may be sent by IP hosts when they no longer wish to participate in a particular multicast group.
As illustrated by
FIG. 1B
, the IGMP protocol
145
runs on router
110
. The IGMP protocol periodically generates IGMP membership queries using a set of timers
150
. Based upon the IGMP membership reports received from each attached network, multicast routers track IP multicast group membership represented on a given port by maintaining a multicast groups table
155
. Multicast routers maintain lists of multicast group memberships for each attached network and a timer for each group membership. When a multicast packet is received by a multicast router, the multicast group membership information is used to eliminate branches that do not lead to members of the multicast group to which the multicast packet is addressed.
With respect to a given attached network, a multicast router may assume the role of an IGMP querier or a non-querier. At start up, a multicast router assumes it is the IGMP querier for each attached network. However, if a multicast router hears a query message from another router with a lower IP address, it will become a non-querier for that network. This querier election mechanism prevents more than one multicast router from being a querier for a given network. Further details about this protocol are available in Fenner, W., “Internet Group Management Protocol, Version 2,” INTERNET-DRAFT, Xerox PARC, May 20, 1996 and also in S. Deering, Request for Comments 1112, “Host Extensions for IP Multicasting,” August 1989.
FIG. 2
illustrates the pruning of subnets for a multicast message in a routed network in which one or more end-stations reside on switched subnetworks. The routed network includes routers
201
through
205
, Layer
2
switches
250
through
254
, and endstations
231
through
244
. Routers
201
through
205
are multicast routers running IGMP or an equivalent group management protocol to discover the IP multicast group memberships of each attached network. Switches
250
through
254
represent switches employing current forwarding logic. Such a switch
120
is illustrated in FIG.
1
C. The switch
120
includes a forwarding engine
160
. The forwarding engine
160
has no forwarding rules (forwarding logic) for IP multicast traffic. Thus, when the switch
120
receives a packet with an IP multicast address, the address is mapped to a medium dependent broadcast address such as an Ethernet broadcast address and processed using the associated broadcast forwarding logic. Therefore, in the present example, since the forwarding engine
160
has no knowledge of which ports lead to end-stations participating in IP multicast groups, upon receiving an IP multicast packet, the forwarding engine
160
must forward the packet to each of its connected interfaces. This forwarding behavior is currently required to assure that all end-stations listening for the IP multicast group addressed by the packet will receive the packet.
In this example, end-stations
231
through
244
are all members of either the white multicast group or the black multicast group represented with hollow or solid circles, respectively. Assuming a multicast message addressed to the black multicast group is originated at end-station
240
, the thick lines represent the network segments upon which the multicast message will be forwarded. For example, the multicast message will be forwarded from router
203
to routers
202
and
205
. However, the multicast message will not be forwarded from router
203
to router
204
as no black multicast group members exist on this network segment. While this prior method of pruning is sufficient to eliminate multicast traffic on the network segment connecting router
203
and router
204
, it is limited to pruning at a network level.
A disadvantage of this prior approach is switches
120
forward IP multicast packets to all of their ports regardless of the IP multicast groups represented on a given port. Therefore, non-multicast group members residing on a network segment with one or more IP multicast group members wind up having to process and filter packets to destination addresses in which they have no interest. For example, this prior approach forces endstations
234
and
236
to process and filter IP multicast messages intended for end-stations
233
and
235
. Also, end-stations
237
,
239
,
240
,
241
, and
242
are interrupted by IP multicast messages intended for end-station
238
. Having to process these undesired packets takes up valuable resources at the end-station. In addition, bandwidth on the link is wasted.
Based on the foregoing, it is desirable to further confine IP multicast traffic such that multicast packets addressed to a particular multicast group address do not propagate into portions of a switched network in which no end-stations are listening for the particular multicast group address. Specifically, it is desirable to carry out IP multicast pruning on a per-port basis within a switch to eliminate the exposure of multicast traffic to end-stations not participating in a multicast group. Further, it is desirable to reduce the number of group membership reports that must be processed by a querying device by providing a group membership report proxy feature which allows a switch to act as a proxy device for group membership reports. In addition, it is desirable to provide the ability to perform multicast pruning on a per-port basis within a switch when no multicast routers are present on the network or when multicast is otherwise disabled on the router. Finally, rather than pursuing a proprietary solution for determining per-port multicast group membership within a swi
Pitcher Derek
Seshadri Kishore K.
Simone Daniel A.
Blakely , Sokoloff, Taylor & Zafman LLP
Nguyen Hanh
Nortel Networks Limited
Patel Ajit
LandOfFree
Method and apparatus for performing per-port IP multicast... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method and apparatus for performing per-port IP multicast..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and apparatus for performing per-port IP multicast... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2877857