Flexible scheduling of network devices within redundant...

Details Flexible scheduling of network devices within redundant... Flexible scheduling of network devices within redundant...

1999-03-30

2003-09-09

Kizou, Hassan (Department: 2662)

Multiplex communications

Pathfinding or routing

Switching a message which includes an address header

C370S241100, C370S244000, C370S250000, C370S389000

Reexamination Certificate

active

06618377

ABSTRACT:

FIELD OF THE INVENTION
The present invention relates to systems and methods for maintaining network functionality when a critical network device fails. More specifically, the invention relates to groups of devices using a procedure for backing up an active device should that device become functionally unavailable.
BACKGROUND OF THE INVENTION
A computer network is a geographically distributed collection of interconnected communication links for transporting data between nodes, such as computers. By definition, a network is a group of computers and associated devices that are connected by communications facilities or links. Network connections can be of a permanent nature, such as cables, or can be of a temporary nature, such as connections made through telephone or other communication links. A plurality of computer networks may be further interconnected by intermediate nodes, or routers, to extend the effective “size” of the networks. A router is computer system that stores and forwards data packets from one local area network (LAN) or wide area network (WAN) to another. Routers see the network as network addresses and all the possible paths between them. They read the network address in a transmitted message and can make a decision on how to send it based on the most expedient route (traffic load, line costs, speed, bad lines, etc.). Routers typically communicate by exchanging discrete “packets” of data according to predefined protocols. In this context, a protocol comprises a set of rules defining how the nodes interact with each other.
The Asynchronous Transfer Mode (ATM) protocol establishes point-to-point connections over a virtual connection oriented media. A properly configured network device within an ATM system will include an ATM interface and a mechanism for establishing and supporting virtual connections or circuits. The appropriate hardware and/or software for providing ATM interfaces is generally known in the field. In 1991, an entity known as the ATM Forum was founded to standardize ATM technology. A substantial body of information regarding deployment of ATM technology is available from the ATM Forum. Cites to many references pertaining to ATM technology are available through the ATM Forum's World Wide Web site at www.ATMForum.com. Specific references include McDysan et al., “ATM Theory and Application,” McGraw Hill, 1995; Minoi et al., “ATM & Cell Relay Service for Corporate Environments,” McGraw Hill, 1994; and Prycker “Asynchronous Transfer Mode—Solution for Broadband ISDN, 2nd Edition, Ellis Horwood, 1993. Each of these references is incorporated herein by reference for all purposes.
Point-to-point connections between ATM nodes are made by “virtual circuits” or “virtual connections.” A virtual connection may be a permanent virtual circuit (PVC) (e.g., a fixed line) or by a switched virtual circuit (SVC) (a temporary virtual connection). Since an SVC is temporary, it is established between two network devices of the ATM network
100
upon demand and then released after a predetermined time period. Note that the connection may include temporarily combining two PVCs and on either side of a switch capable of connecting the two PVCs.
An ATM network device has an ATM address, such as a VPI address or a VCI address, which is required by a network device in order to establish the SVC with a second virtual device. The ATM address will sometimes be referred to herein as a Network Service Access Point (“NSAP”) Because PVCs dedicate network bandwidth to the two connected nodes (and preclude other nodes from using that bandwidth), PVC use is generally limited. Thus, to increase network applicability, many systems make use of SVCs. The process of establishing an SVC will be described broadly with respect to FIG.
1
A.
FIG. 1A
describes the process of establishing a virtual connection between a network device
104
and a network device
108
. The network devices
104
and
108
have NSAP addresses of NSAP
1
and NSAP
2
respectively. To initiate the connection, the network device
104
constructs a ‘SETUP’ message
136
which indicates a desire to establish a connection with device
108
, and sends it to the NSAP
2
address. Message
136
may require multiple hops to reach device
108
. To simplify the discussion, only a single hop is depicted here. As the SETUP message propagates toward its destination, the network acknowledges receipt of the message with CALL PROCEEDING messages at each hop. As shown, in
FIG. 1B
, network device
108
replies with a CALL PROCEEDING message
138
if it is merely a hop on the path to the ultimate destination or a CONNECT message
140
if it is the ultimate destination. In this case where NSAP
2
is not the destination, another SETUP message is propagated to the next network device (not shown) along the path to the destination and a CALL PROCEEDING message returns from that device. This procedure continues until connection is made with the destination having NSAP
2
.
As the setup message
138
propagates to the eventual destination IP address along a number of network devices and switches, a PNNI protocol may be found. The destination may specify a set of protocol parameters of message transmission and return them with the CONNECT message. For example, an AAL
5
platform with a 100 kBs bandwidth and a UBR service may be specified. If the network device
108
agrees to these parameters, the network device
108
will respond with a “CONNECT ACKNOWLEDGMENT” message
142
. In this case, an SVC is established between NSAP
1
and NSAP
2
as well as between any additional switches along the pathway from NSAP
2
to the destination. Once the virtual connections are established, data such as IP datagrams using ATM packets may be sent.
ATM can be used to run IP in a procedure referred to as IP over ATM. See Laubach, M. and Halpern, J., “Classical IP and ARP over ATM”, RFC 2225, April 1998 (http://www.ietf.cnri.reston.va.us/home.html), which is incorporated herein by reference for all purposes. In IP over ATM, each ATM host in a set of hosts is assigned its own IP address. The set of ATM hosts forms a logical IP subnet (“LIS”) which acts as a virtual LAN. All members of a LIS are directly connected to the ATM network and have the same IP network/subnet number and address mask. Hosts on the same LIS may exchange IP packets directly, but hosts on different ones are required to go through a router. A LIS may act as a bridge connecting existing LANs.
To move IP packets along a route from source to destination, in a conventional non-ATM IP network, an Address Resolution Protocol (“ARP”) is used. See Plummer, D., “An Ethernet Address Resolution Protocol—or—Converting Network Protocol Addresses to 48.bit Ethernet Addresses for Transmission on Ethernet Hardware,” STD 37, RFC 826, November 1982 (which is incorporated herein by reference). In such protocol, a network device holding a packet to be delivered asks its peers which one of them is responsible for handling packets having the IP destination address of the packet. The device makes this inquiry via an “ARP packet.” The correct device replies via the Address Resolution Protocol with its hardware address. The device holding the packet then encapsulates that packet with a header indicating the hardware address of the responding device and sends the packet to it.
In SVC cases, devices must learn the ATM addresses of their peers in order to forward IP packets to them. The ARP protocol immediately suggests itself for this purpose. ARP, as currently implemented and described in RFC 826, requires a broadcast medium (e.g., Ethernet) on which to transmit the ARP request. ATM, which is a point-to-point protocol, cannot support ARP as described in RFC 826.
One suitable method for transmitting IP datagrams over an ATM network where the destination lower level address is unknown uses ATM Address Resolution Protocol (“ATMARP”) as described in RFC 2225. ATMARP determines the lower level address of the next network device along a suitable path when given the destination IP address. An ATMARP system is typically co

Affiliated with

Also associated with

Rating

Flexible scheduling of network devices within redundant... does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Flexible scheduling of network devices within redundant..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Flexible scheduling of network devices within redundant... will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-3085420