Multiplex communications – Pathfinding or routing – Switching a message which includes an address header
Reexamination Certificate
1997-11-18
2003-12-30
Kizou, Hassan (Department: 2662)
Multiplex communications
Pathfinding or routing
Switching a message which includes an address header
C370S390000, C370S396000, C370S401000
Reexamination Certificate
active
06671276
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates to a method and a network architecture for mapping Internetworking Protocol (IP) multicast and Integrated Services (i.e. differing levels of quality of service) over an Asynchronous Transfer Mode (ATM) network. The method and architecture, which are based upon multicast switches, allow IP/Resource. Reservation Protocol (RSVP) applications running on ATM hosts to seamlessly participate in Internet-wide multicast sessions. The method and architecture make good use of ATM capabilities to support features such as receiver heterogeneity, shortcut routing and scalability.
2. Description of the Related Art
The current Internet services, including IP multicast, are based on best effort delivery of datagrams as the sole underlying mechanism. The best effort delivery mechanism however, is not suitable for transporting media streams such as audio and video over the Internet, since applications using such streams often require data delivery with delay and bandwidth guarantees for a successful replay of media streams at the receiving end. Furthermore, Internet traffic continues to grow faster than the speed at which additional capacity is being added to the Internet infrastructure. This means that data traffic traversing the Internet is subject to unpredictable delays and possibly packet loss due to the increased load on Internet routers.
While traditional Internet applications such as email, file transfer, remote login etc., based on transmission control protocol (TCP), can adapt their network usage to the prevailing conditions, emerging multimedia applications, such as video on demand and those based on streaming video, are less tolerant to changes in traffic parameters such as end-to-end delay and jitter. The only way to support these multimedia applications (other than over engineering the Internet capacity) is to provide multiple service classes and a capability of reserving resources in the Internet.
As a result of the efforts of the Internet Engineering Task Force (IETF) (See, e.g., Wroclawski, Specification of the Controlled-Load Network Element Service, Network Working Group, Request for Comments: 2211, Category: Standards Track, September, 1997; and Shenker et al., Specification of Guaranteed Quality of Service, Network Working Group, Request for Comments: 2212, Category: Standards Track, September, 1997), support for Quality of Service (QoS) based service classes, known as Integrated Services, is expected to become available in the Internet in the near future. In addition, Resource Reservation Protocol (RSVP) is also being standardized by the IETF as an internetworking protocol for resource reservation that will be used by applications in the multi-service Internet. See, R. Braden, et al., “Resource Reservation Protocol (RSVP)—Version 1 Functional Specification,” Internet Engineering Task Force, Network Working Group, Request for Comments: 2205, Category: Standards Track, September, 1997.
Asynchronous Transfer Mode (ATM) has been developed as an integrated link layer and network layer solution for providing QoS based services in local and wide area networks. Although the ATM technology supports its own version of QoS based services, it is unlikely that ATM networks will completely replace the existing IP based Internet infrastructure in the foreseeable future. Therefore, at least in the initial stages of ATM deployment, hosts connected to ATM networks will continue to run IP and RSVP applications in order to communicate with other hosts, most of which may still be connected to legacy networks, such as Ethernet.
Since the ATM technology readily provides the QoS support needed for IP Integrated Services, the problem of mapping these services over an ATM network appears to be simple. However, such a mapping is quite difficult due to the following reasons:
(1) Since IP is the network layer protocol of choice for use with RSVP, all the network technologies ranging from Ethernet to Token Ring to ATM will be treated as link layer technologies by RSVP/IP. Such an approach does not give rise to any conflicts with the use of conventional network technologies such as Ethernet, but with ATM networks this approach has an inherent problem in that it fails to make use of the network layer capabilities (addressing and routing) of ATM;
(2) IP multicasting, which is at the core of Integrated Services and RSVP, is being deployed widely in the existing IP networks. On the other hand, support for efficient multicasting in ATM is still inadequate. Point-to-multipoint virtual circuits (VCs), although supported in ATM, suffer from scalability problems; and
(3) Some of the RSVP features, namely receiver heterogeneity and dynamic QoS, do not have equivalent mechanisms in ATM.
One proposal to deal with the provision of IP Integrated Services over ATM is the Cell Switch Router (CSR) from Toshiba. See, Katsube, et al., “Toshiba's Router Architecture Extensions for ATM: Overview,” Network Working Group, Request for Comments: 2098, Category: Informational, February, 1997. A CSR is a traditional IP router attached to an ATM switch and is capable of “concatenating” incoming and outgoing VCs to provide shortcut paths through routers in an ATM cloud. Individual intra-logical IP subnet (LIS) VCs (host to router or router to router) are established using ATM signaling. Such VCs may be point to point for unicast, or point to multipoint for multicast. Different VCs may be established for different “flows” between the same set of endpoints to allow for a different QoS for each flow, e.g. using RSVP. The problem is that CSRs use IP based protocols to route data traffic and thus limit the use of ATM protocols to intra-LIS routing. Some of the disadvantages of this approach are:
(1) A true shortcut path between two endpoints may not go through a router (CSR) which is given as the next hop by IP routing. This is because IP routing needs to send all data crossing subnet boundaries through a router (CSR);
(2) Wide area addressing and routing capabilities of ATM are not utilized properly by this approach since ATM is used only as a link layer; and
(3) Currently there is no proposal to handle heterogeneous QoS receivers in a multicast session with CSRs.
Two other recent proposals dealing with IP switching, are IPSILON and IPSOFACTO. See, A. Acharya, et al., “IP switching over fast ATM cell transport (IPSOFACTO), Proc. Of IEEE Globecom '97, 1997; and P. Newman, et. al., “Transmission of Flow Labeled Ipv4 on ATM Data Links Ipsilon Version 1.0”, Network Working Group, Request for Comments 1954, Category: Informational, May, 1996. IP switching “identifies” long lived IP flows passing through a switch router (IP switch) and places such flows on a fast switched path so that subsequent data packets on these flows do not incur reassembly, routing and segmentation delays at the router. IPSILON uses a heuristic based on the number of packets with the same source and destination addresses to identify a long lived flow. IPSOFACTO relies on the control packets of higher layer protocols, e.g. SYN packets in TCP, to identify long lived flows. Once a long lived flow is identified, it is assigned a new Virtual Circuit Indicator/Virtual Path Indicator (VCI/VPI) by the IP switch. At the same time, an association between the incoming VCI/VPI and outgoing VCI/VPI is established in the switching fabric so that subsequent data packets are forwarded without any intervention by the routing software. IPSILON relies on a proprietary protocol for assigning VCI/VPI to IP flows between two IP switches. IPSOFACTO uses a technique based on partitioning of VCI/VPI space and chooses an unused VCI/VPI from this space for forwarding a flow through each IP switch. The only difference between the two IP switching techniques and the CSR technique described earlier is the way shortcut VCs are established by the switch/router. Apart from this difference, the two IP switching techniques and CSR rely on IP routing software to make routing decisions. As such, all the drawback
Bakre Ajay V.
Nishida Takeshi
Kizou Hassan
Sughrue & Mion, PLLC
Tsegaye Saba
LandOfFree
Switch based network architecture for IP multicast and... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Switch based network architecture for IP multicast and..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Switch based network architecture for IP multicast and... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3165975