Multiplex communications – Pathfinding or routing – Switching a message which includes an address header
Reexamination Certificate
1998-04-14
2002-11-19
Nguyen, Chau (Department: 2663)
Multiplex communications
Pathfinding or routing
Switching a message which includes an address header
C370S432000
Reexamination Certificate
active
06483832
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates to the field of telecommunications. More particularly, the present invention relates to a method and a system for routing Internet Protocol (IP) multicast traffic over Asynchronous Transfer Mode (ATM) networks.
2. Description of the Related Art
Many applications used on the Internet have multiple sources, or senders, and hosts, or receivers, that participate, or interact, with each other. Previously, conventional unicast techniques were used for sending the same data packet to each host of a multicast group over a circuit that was specifically established between a source and the host. A conventional unicast approach for multicasting traffic, however, is wasteful in terms of both bandwidth and circuit resources.
To overcome the drawbacks of using unicast techniques for multicast traffic, techniques and protocols have been developed so that a multicast data packet is sent along a predetermined route of routers, or switches, and replicated at a point closest to a destination host, thereby reducing the amount of multicast traffic. For example, a number of routing protocols have been developed for creating distribution routes between a source and the hosts of a multicast group. Routers and end stations have become “multicast aware” by using multicast protocols such as the Distance Vector Multicast Routing Protocol (DVMRP), the Multicast Open Shortest Path First (MOSPF) protocol and Protocol-Independent Multicast (PIM).
The DVMRP protocol is widely used in the Multicast Backbone (MBONE) and generates a separate distribution tree for each respective source and destination host group. The distribution tree, also referred to as a spanning tree, provides the shortest path from a source to each host in a multicast group. A spanning tree is constructed for a multicast group by the source initially broadcasting, or sending, a message to an adjacent router that is propagated to all other routers in the network so that the message reaches each participating host. The message effectively registers the multicast group with reach router receiving the message. If no members for a registered multicast group are connected to a particular router, the router sends a pruning message to the previously adjacent router so that the router sending the pruning message is removed from the spanning tree. As a result, the spanning tree that is eventually generated provides the shortest path between the source and every host in the network. Periodically, the broadcast and pruning operations are performed for updating the spanning tree. While the DVMRP protocol works well for a densely-distributed multicast group, the overhead processing associated with message broadcasts and maintenance of state information can become expensive for a sparse distribution of hosts across a wide area network.
The MOSPF protocol is a multicast routing protocol that is built on top of the OSPF protocol, thereby providing the ability to create multicast trees having an OSPF routing domain. Each MOSPF router receives information about hosts that are interested in a particular multicast group through an Internet Group Management Protocol (IGMP) registration process. Consequently, all routers in the OSPF domain contain information relating to the complete topology of the network and can construct the optimum path between a source and any other host in the domain. Nevertheless, multicast trees generated using the MOSPF protocol cannot span OSPF domain boundaries. Further, the MOSPF protocol generates significant amounts of overhead routing information that is continuously exchanged between routers in the network so multicast trees spanning large domains do not scale well.
The PIM protocol, developed by the Internet Engineering Task Force (IETF), addresses problems associated with crossing domain boundaries, and is independent of any underlying unicast protocol. The PIM protocol includes a dense mode and a sparse mode. Dense-mode PIM (PIM-DM) is suitable for environments in which many of the different domains, or subnets, contain at least one host participating in a multicast group and in which network bandwidth is not critical. Unlike the DVMRP protocol, the PIM-DM protocol uses a simple technique of sending a data packet arriving at a router to all adjacent downstream routers. The adjacent downstream routers, in turn, send the packet to their respectively adjacent routers. The routing tree is pruned as each router determines whether there are any hosts participating in the multicast group that are connected to the router.
When the hosts in a network are sparsely distributed, the overhead associated with PIM-DM of flooding information through a network becomes too significant and the PIM-SM protocol is used. In PIM-SM, a host that is interested in joining a particular multicast group is responsible for initiating a join operation to join the multicast routing tree associated with the multicast group. A join request is sent from the interested host towards the source of the multicast tree. The join request is propagated toward the source until the request encounters a router that already has a host participating in the desired multicast group. The routing tree is then updated to include all of the routers between the host initiating the join operation and the router where the propagation of the join request terminates.
Deployment of multicast protocols on routers has proceeded at a steady pace. Nevertheless, there are still so-called “islands” of routers that are multicast-aware that are separated from other islands of multicast-aware routers.
FIG. 1
is a schematic block diagram showing an exemplary conventional MBONE network
10
having a plurality of multicast-aware routers
11
and unicast routers
12
. A multicast-aware router or a group of multicast-aware routers that are separated from other multicast-aware routers
11
by one or more unicast routers
12
are referred to as islands. In order to transport multicast traffic between multicast-aware routers
11
across one or more unicast routers
12
, a technique known as “multicast tunneling” is used. That is, a multicast-aware router
11
encapsulates multicast traffic inside a unicast packet. The encapsulated multicast traffic is then sent, or tunneled, across a portion of the network having unicast routers.
A number of other protocols are under development by the IETF that run on top of conventional routing protocols and which provide the ability for an application to reserve resources in a network so that a specified Quality of Service (QoS) can be achieved. Examples of these particular protocols are the Resource Reservation Protocol (RSVP) and the Real Time Protocol (RTP).
The ATM Forum has developed a specification, known as the LAN Emulation specification (LANE), that permits Legacy LANs- and ATM-connected hosts to communicate across an ATM link without changes to existing applications or software. The LANE specification defines an Emulated Local Area Network (ELAN) environment in which, from the perspective of a legacy application, an ATM network looks appears to be a LAN segment. There are three special entitles in a LANE environment that are referred to as a LAN Emulation Server (LES), a Broadcast Unknown Server (BUS) and an LAN Emulation Configuration Server (LECS). The LES registers and resolves ATM addressing by labeling each end station with a Medium Access Control (MAC) layer and an ATM address. The address mapping is used by an ingress LAN Emulation Client (LEC) for setting up a cut-through path to an egress LEC. The BUS is used for distributing broadcast and multicast traffic within the LANE environment.
When a LEC sends a multicast or broadcast packet to other multicast group members within an ELAN, the packet is sent to a BUS. The BUS forwards the packet to all the other LECs within the ELAN environment on a point-to-multipoint virtual channel connection (VCC). An alternative entity to a BUS is a Special Multicast Server (SMS). A LEC wishing to receive data for a multicast addre
Civanlar Seyhan
Coffield Don Richard
Leighton, III William J.
Masalawala Rustom K.
Saksena Vikram R.
AT&T Corp.
Lee Andy
Nguyen Chau
LandOfFree
IP multicast over routed ATM network using lane does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with IP multicast over routed ATM network using lane, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and IP multicast over routed ATM network using lane will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2964124