CA2044363A1 - Bridge-like internet protocol router - Google Patents
Bridge-like internet protocol routerInfo
- Publication number
- CA2044363A1 CA2044363A1 CA002044363A CA2044363A CA2044363A1 CA 2044363 A1 CA2044363 A1 CA 2044363A1 CA 002044363 A CA002044363 A CA 002044363A CA 2044363 A CA2044363 A CA 2044363A CA 2044363 A1 CA2044363 A1 CA 2044363A1
- Authority
- CA
- Canada
- Prior art keywords
- bridge
- packet
- lan
- extended
- message
- 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.)
- Abandoned
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/46—Interconnection of networks
- H04L12/4604—LAN interconnection over a backbone network, e.g. Internet, Frame Relay
- H04L12/462—LAN interconnection over a bridge based backbone
- H04L12/4625—Single bridge functionality, e.g. connection of two networks over a single bridge
Abstract
BRIDGE-LIKE INTERNET PROTOCOL ROUTER
ABSTRACT OF THE DISCLOSURE
A device and related method for coupling seg-ments of an extended local area network (LAN) in such a way that message traffic employing inter-network proto-cols such as TCP/IP will be handled without the diffi-culties usually associated with bridges, and without the complexity and expense of full IP router capabili-ty. The device operates like a bridge for non-TCP/IP
traffic. For TCP/IP traffic it operates in a bridge-like manner but maintains a database associating extend-ed LAN segment addresses with port numbers in the de-vice, so that packets can be automatically forwarded over a spanning tree connecting the network segments. A
host computer in any network segment can address others in different network segments of the extended LAN as though all were in a single LAN. The device of the invention functions to block the flow of ARP messages and to generate ARP replies that render the device of the invention transparent to hosts within the extended LAN. The device is also transparent to true IP routers, which may still be used to effect communication with points outside the extended LAN.
ABSTRACT OF THE DISCLOSURE
A device and related method for coupling seg-ments of an extended local area network (LAN) in such a way that message traffic employing inter-network proto-cols such as TCP/IP will be handled without the diffi-culties usually associated with bridges, and without the complexity and expense of full IP router capabili-ty. The device operates like a bridge for non-TCP/IP
traffic. For TCP/IP traffic it operates in a bridge-like manner but maintains a database associating extend-ed LAN segment addresses with port numbers in the de-vice, so that packets can be automatically forwarded over a spanning tree connecting the network segments. A
host computer in any network segment can address others in different network segments of the extended LAN as though all were in a single LAN. The device of the invention functions to block the flow of ARP messages and to generate ARP replies that render the device of the invention transparent to hosts within the extended LAN. The device is also transparent to true IP routers, which may still be used to effect communication with points outside the extended LAN.
Description
2~43~
BRIDGE-LIKE INTERNET' PROTOCOL ROUTER
BACKGROUND OF T~E INVENTION
This invention relates generally to local area networks (LANs) of computers and, more particularly, to multiple LANs that are interconnected by bridges and routers. More specifically, the invention is concerned with a problem that arises in interconnected networks using a set of protocols generally known as TCP/IP. TCP
stands for Transmission Control Protocol, and IP is Internet Protocol. The following background material in-troduces various computer network concepts and defini-tions. Those familiar with computer networks and TCP/IP
may wish to skip to the subsection headed "The Prob-lem."
Com~uter Network Backaround:
A computer network is simply a collection of autonomous computers connected together to permit sharing of hardware and software resources, and to increase overall reliability. The qualifying term "local area" is usually applied to computer networks in which the computers are located in a single building or in nearby buildings, such as on a college campus or at a single corporate site. When the computers are further apart, the terms "wide area network" or "long haul net-work" are used, but the distinction is one of degree and the definitions sometimes overlap.
A bridge is a device that is connected to at least two LANs and serves to pass message frames or packets between LANs, such that a source station on one LAN can transmit data to a destination station on another LAN, without concern for the location of the destination. Bridges are useful and necessary network -2- 2~k43~
com~onents, principally because the total number of stations on a single LAN is limited. Bridges can be implemented to operate at a selected layer of protocol of the network. A detailed knowledge of network archi-tecture is not needed for an understanding of thisinvention, but a brief description follows by way of further background.
As computer networks have developed, various approaches have been used in the choice of communica-tion medium, network topology, message format, proto-cols for channel access, and so forth. Some of these approaches have emerged as de facto standards, but there is still no single standard for network communica-tion. However, a model for network architectures has been proposed and widely accepted. It is known as the International Standards Organization (ISO) Open Systems Interconnection (OSI) reference model. The OSI refer-ence model is not itself a network architecture. Rather it specifies a hierarchy of protocol layers and defines the function of each layer in the network. Each layer in one computer of the network carries on a conversa-tion with the corresponding layer in another computer with which communication is taking place, in accordance with a protocol defining the rules of this communica-tion. In reality, information is transferred down fromlayer to layer in one computer, then through the chan-nel medium and back up the successive layers of the other computer. However, for purposes of design of the various layers and understanding their functions, it is easier to consider each of the layers as communicating with its counterpart at the same level, in a "horizon-tal" direction.
The lowest layer defined by the OSI model is called the physical layer, and is concerned with transmitting raw data bits over the communication 2~3~^~
channel. Design of the physical layer involves issues o~ &lectrical, mechanical or optical engineering, depen-ding on the medium used for the communication channel.
The layer next to the physical layer is called the data link layer. The main task of the data link layer is to transform the physical layer, which interfaces directly with the channel medium, into a communication link that appears error-free to the next layer above, known as the network layer. The data link layer performs such functions as structuring data into packets or frames, and attaching control information to the packets or frames, such as checksums for error detection, and packet numbers.
Although the data link layer is primarily inde-pendent of the nature of the physical transmission me-dium, certain aspects of the data link layer function are more dependent on the transmission medium. For this reason, the data link layer in some network architec-tures is divided into two sublayers: a logical link con-trol sublayer, which performs all medium-independent functions of the data link layer, and a media access control (MAC) sublayer. This sublayer determines which station should get access to the communication channel when there are conflicting requests for access. The functions of the MAC layer are more likely to be depen-dent on the nature of the transmission medium.
Bridges may be designed to operate in the MAC
sublayer. Further details may be found in "MAC Brid-ges," P802.1D/D6, Sept. 1988, a draft publication of IEEE Project 802 on Local and Metropolitan Area Network Standards, or in later drafts of this document.
The basic function of a bridge is to listen "promiscuously," i.e. to all message traffic on all LANs to which it is connected, and to forward each mes-sage it hears onto LANs other than the one from which 2~4~3 _4_ the message was heard. Bridges also maintain a databaseof tation locations, derived from the content of the messages being forwarded. Bridges are connected to LANs by paths known as "links." After a bridge has been in operation for some time, it can associate practically every station with a particular link connecting the bridge to a LAN, and can then forward messages in a more efficient manner, transmitting only over the appro-priate link. The bridge can also recognize a message that does not need to be forwarded, because the source and destination stations are both reached through the same link. Except for its function of "learning" sta-tion locations, or at least station directions, the bridge operates basically as a message repeater.
As network topologies become more complex, with large numbers of LANs, and multiple bridges inter-connecting them, operational difficulties can ensue if all possible LAN bridging connections are permitted. In particular, if several LANs are connected by bridges to form a closed loop, a message may be circulated back to the LAN from which it was originally transmitted, and multiple copies of the same message will be generated.
In the worst case, messages will be duplicated to such a degree that the networks will be effectively clogged with these messages and unable to operate at all.
To prevent the formation of closed loops in bridged networks, IEEE draft publication P802.lD, re-ferred to above, proposes a standard for a spanning tree algorithm that will connect the bridged network - 30 into a tree configuration, containing no closed loops, and spanning the entire network configuration. The spanning tree algorithm is executed periodically by the bridges on the interconnected network, to ensure that the tr~e structure is maintained, even if the physical configlration of the network changes. Basically, the _5_ 2~3~
bri~ges execute the spanning t:ree algorithm by sending spe-ial messages to each other to establish the identi-ty of a "root" bridge. The root bridge is selected, for convenience, as the one with the smallest numerical identification. The algorithm determines which links of the bridges are to be active and which are to be inac-tive, i.e. disabled, in configuring the tree structure.
One more piece of terminology is needed to understand how the algorithm operates. Each LAN has a "designated"
link, which means that one of the link~ connectable to the LAN is designated to carry traffic toward and away from the root bridge. The basis for this decision is similar to the basis for selecting the root bridge. The designated link is the one providing the least costly tshortest) path to the root bridge, with numerical bridge identification being used as a tie-breaker. Once the designated links are identified, the algorithm chooses two types of links to be activated or closed:
first, for each LAN its designated link is chosen, and second, for each bridge a link that forms the "bes~
path" to the root bridge is chosen, i.e. a link through which the bridge received a message giving the identity of the root bridge. All other links are inactivated.
Execution of the algorithm results in interconnection of the LANs and bridges in a tree structure, i.e. one having no closed loops.
Internet is a collection of networks, includ-ing Arpanet, NSFnet, regional networks such as NYser-net, local networks at a number of university and re-search institutions, and a number of military networks.The protocols generally referred to as TCP/IP were originally developed for use only through Arpanet and have subsequently become widely used in the industry.
The protocols provide a set of services that permit users to communicate with each other across the entire 2 ~ a~ L~ 3 ~ 3 Internet. The specific services that these protocols provide are not important to the present invention, but include file transfer, remote log-in, remote execution, remote printing, computer mail, and access to network file systems.
The basic function oE the Transmission Control Protocol (TCP) is to make sure that commands and mes-sages from an application protocol, such as computer mail, are sent to their desired destinations. TCP keeps track of what is sent, and retransmits anything that does not get to its destination correctly. If any mes-sage is too long to be sent as one "datagram," TCP will split it into multiple datagrams and makes sure that they all arrive correctly and are reassembled for the application program at the receiving end. Since these functions are needed for many applications, they are collected into a separate protocol (TCP) rather than being part of each application. TCP is implemented in the transport layer of the OSI reference model.
The Internet Protocol (IP) is implemented in the network layer of the OSI reference model, and provides a basic service to TCP: delivering datagrams to their destinations. TCP simply hands IP a datagram with an intended destination; IP is unaware of any relationship between successive datagrams, and merely handles routing of each datagram to its destination. If the destination is a station connected to a different LAN, the IP makes use of routers to forward the mes-sage.
A router, like a bridge, is a device connected to two or more LANs. Unlike a bridge, however, a router operates at the network layer level, instead of the data link layer level. Addressing at the network layer level makes use of a 32-bit address field for each host, and the address field includes a unique network 2~3~
identifier and a host identifier within the network.
Rou~ers make use of the destination network identifier in a message to determine an optimum path from the source network to the destination network. Various routing algorithms may be used by routers to determine the optimum paths. Typically, routers exchange informa-tion about the identities of the networks to which they are connected.
When a message reaches its destination net-work, a data link layer address is needed to complete forwarding to the destination host. Data link layer ad-dresses are 48 bits long and are globally unique, i.e.
no two hosts, wherever located, have the same data link layer address. There is a protocol called ARP (address resolution protocol), which obtains a data link layer address from the corresponding network layer address (the address that IP uses). Typically, each router main-tains a database table from which it can look up the data link layer address, but if a destination host is not in this ARP database, the router can transmit an ARP request. This message basically means: "will the host with the following network layer address please supply its data link layer address." Only the addressed destination host responds, and the router is then able to insert the correct data link layer address into the message being forwarded, and to transmit the message to its final destination.
The Problem:
As discussed above, bridges operate at the data link layer level and are effectively "transparent"
to user stations or "hosts" connected to the LANs. That is to say, a message directed to a destination on a different LAN from the one to which the source of the messa~e is connected, will reach the destination 2 ~ 4 ~ 3 '~ ~
through a bridge without the source's knowing that the des~ination is on a different LAN. Bridges work well for message traffic that is not using the TCP~IP proto-cols. However, for TCP/IP traffic a significant problem is sometimes caused by ARP messages, especially when bridges are used within an extended network of LANs.
For some network implementations, ARP packets can be duplicated by bridges and this can result in "flurries"
or even "storms" of ARP packets, which disrupt normal traffic flow. Ideally, ARP packets should be confinedto the LAN in which they originate, but bridges are designed to be transparent to all traffic. One possible solution is to use a combination of a bridge and a router in every situation in which a bridge might be used, but providing full router functionality is more complex and more expensive than using conventional bridges.
The need for an alternative to bridges and rou-ters is particularly critical in an "extended network"
administered by a single institution. For example, a corporation or a university may have the need to config-ure a number of "subnets" or "network segments" that are interconnected into one extended network. From out-side the extended network, there appears to be just a single network, i.e. there is one network identifier in the network layer address, and messages destined for a host computer within the extended network are addressed as if this were the case. Within the extended network, however, part of the host identifier field of the net-work layer address is used as a subnet address or net-work segment address. The network segments might be connected by bridges, but these would be subject to the ARP storm problem outlined above. Another problem with using ~ridges for TCP/IP traffic is that some IP data packets may be too large for a bridge to forward, and 2 ~ ~ ~ 3 b 3 J
_ 9 _ will then ~e discarded by the bridge.
It will be apparent from the foregoing that there i~
a need for an alternative to conventional bridges in interconnected networks handling TCP/IP traffic without the added complexity of a router, and without the problems inherent in the use of bridges. The present invention satisfie~ this need, as will become apparent from the following summary.
SUMMARY OF THE INVENTION
The present invention resides in a bridge-like IP
router (BLIP) that functions exactly like a bridge for non-TCP/IP traffic, and functions in a bridge-like manner for TCP/IP traffic, forwarding messages through a spanning tree and learning source and destination addresses, at a network layer level, by correlating the direction from which messages arrive with the source subnet addresses they contain. Thus the bridge-like IP router functions very much like a bridge, but at the network layer level of addressing.
The invention in its broad form resides in apparatus and a method of operation of extended interconnected local area networks (LANs) handling message traffic in accordance with a set of protocols known as TCP/IP, the method comprising the steps of: configuring an extended local area network (LAN) to include a plurality of extended LAN segments connected by bridge-like IP routers 2 ~
- 9a -(BLIPs); receiving a packet of data at a BLIP;
characteri~ed by: determining whether the packet has been transmitted under TCP/IP protocols; processing non-TCP/IP
packets in the manner of a convention bridge; and processing TCP/IP traffic in a manner analogous to a bridge, wherein a message packet received from an extended LAN segment attached to the BLIP is forwarded if necessary to at least one other extended LAN segment attached to the BLIP.
Although the invention addresses a problem that arises in the specific context of the TCP/IP protocols, in a more general sense the invention applies to any inter-network protocols that operate at the network layer level, using an addressing scheme of network addresses and host addresses within each network. Basically, the invention is embodied in a bridge-like device that functions at this network layer level, as well as at a lower level at which globally unique host addresses are used.
As it relates more specifically to the TCP/IP
protocols, the device of the invention comprises mul-tip~e ports for attaching the BLIP to multiple segments of ~n extended LAN, means for distinguishing received TCP/IP message traffic from non-TCP/IP message traffic, bridge means for processing non-TCP/IP message tra~fic exactly in the manner of a conventional bridge, and bridge-like means for processing TCP/IP traffic in a manner analogous to a bridge. A message packet received from an extended LAN segment attached to the BLIP is forwarded, if necessary, to at least one other extended LAN segment attached to the BLIP. Forwarding to another segment will not be necessary if the destination ad-dress is known to be reachable via the bridge port through which the message was received.
Further, the device of the invention includes means for processing address resolution (ARP) messages, including means for detecting and discarding ARP mes-sages requesting destination address information, and means for responding to ARP messages with a special address codc when the requested destination address is on a different segment of the same extended LAN as the BLIP. The bridge-like means includes means for possibly forwarding a message packet having the special address code to some subset of the attached extended LAN seg-ments except the one from which the message packet was received. A host device may, therefore, transmit to destinations on other extended LAN segments as though the destinations were on the same LAN. The source host first requests the data link level address of the desti-nation by sending an ARP message. A BLIP intercepts the ARP message and sends a special reply address. When the source host uses this special address in sending a data packet, the packet is received by the BLIP and forward-ed, along a spanning tree previously computed collec-tively by all of the bridges, to one or more other attached extended LAN segments. When a BLIP receives a 2~ 3~3 pac~t destined for an attached segment, the BLIP ob-tai~s the correct data link layer address by searching its ARP database and sending an ARP message if neces-sary.
The BLIP also includes an IP database asso-ciating each segment of the extended LAN with a port of the BLIP, and means for updating the IP database by observing each received message and correlating the segment address for each message source with a port through which the message is received. There is also an ARP database associating each network layer address in attached extended LAN segments with a corresponding data link layer address, and means for updating the ARP
database by sending ARP messages directed to specific network layer addresses and processing ARP replies that contain the corresponding data link layer addresses.
Further, each BLIP has a router database con-taining the data link layer addresses of all true IP
routers connected to the extended LAN. The router data-base is used to facilitate communication with hostdevices outside the extended LAN.
More specifically, the bridge-like means of the BLIP includes means for determining whether a re-ceived message packet is destined for an attached seg-ment of the extended LAN, means for forwarding a packetdestined for an attached segment other than the one from which the packet was transmitted, by obtaining a data link layer destination address from the ARP data-base, and means for forwarding a packet destined for a segment unattached to the BLIP, by transmitting the packet to at least one other segment through a port selected to reach the destination segment.
Another feature of the invention device is address checking means effective for processing a packet destined for the same extended LAN segment as 2~ ~3~3 the one from which the packet was transmitted. The address checking means takes various corrective ac-tions, depending on the data link layer destination address contained in the packet. The corrective action 5 may simply be to discard the packet, if the data link layer destination address matches an entry in the ARP
database corresponding to an IP destination address con-tained in the packet. Alternatively, if there is no match between these addresses, the corrective action may be to substitute the ARP database entrv for the data link layer destination address in the packet, and to send a redirect message to a source host from which the packet was transmitted.
In terms of a novel method, the invention com-prises the steps of configuring an extended local areanetwork (LAN) to include a plurality of extended LAN
segments connected by bridge-like IP routers (BLIPs), receiving a packet of data at a BLIP, determining wheth-er the packet has been transmitted under TCP/IP proto-cols, processing non-TCP/IP packets in the manner of a conventional bridge, and processing TCP/IP traffic in a manner analogous to a bridge.
Additional steps of the method include detect-ing and discarding ARP messages requesting destination address information, responding to ARP messages with a special address code when the requested destination address is on a different segment of- the same extended LAN as the BLIP, and forwarding a message packet having the special address code to some subset of the attached extended LAN segments except the one from which the message packet was received. These functions of the BLIP allow a host device to transmit to destinations on other extended LAN segments as though the destinations were on the same LAN.
Other steps of the method include maintaining 2 ~ 3 an IP database tha~ associates each segment of the ex-tenBed LAN with a port of the BLIP, maintaining an ARP
database that associates each network layer address in attached extended LAN segments with a corresponding data link layer address, and maintaining a router data-base con'aining the data link layer addresses of all true IP routers connected to the extended LAN.
More specifically, the method may include the steps of determining whether a received message packet is destined for an attached segment of the extended LAN, forwarding a packet destined for an attached seg-ment other than the one from which the packet was trans-mitted, by obtaining a data link layer destination address from the ARP database, and forwarding a packet lS destined for a segment unattached to the BLIP, by transmitting the packet to some subset of the attached extended LAN segments except the one from which the message packet was received.
It will be appreciated from this summary that the invention represents a significant advance in the field of interconnected local area networks using the TCP/IP protocols. In particular, the invention facili-tates communication between multiple LAN segments in an extended LAN, by means of bridge-like IP routers (BLIPs). The BLIPs of the invention are not much more complex than conventional bridges, but function to block propagation of ARP messages and permit communica-tion between network segments as though all hosts in the extended LAN were in a single LAN.
BRIDGE-LIKE INTERNET' PROTOCOL ROUTER
BACKGROUND OF T~E INVENTION
This invention relates generally to local area networks (LANs) of computers and, more particularly, to multiple LANs that are interconnected by bridges and routers. More specifically, the invention is concerned with a problem that arises in interconnected networks using a set of protocols generally known as TCP/IP. TCP
stands for Transmission Control Protocol, and IP is Internet Protocol. The following background material in-troduces various computer network concepts and defini-tions. Those familiar with computer networks and TCP/IP
may wish to skip to the subsection headed "The Prob-lem."
Com~uter Network Backaround:
A computer network is simply a collection of autonomous computers connected together to permit sharing of hardware and software resources, and to increase overall reliability. The qualifying term "local area" is usually applied to computer networks in which the computers are located in a single building or in nearby buildings, such as on a college campus or at a single corporate site. When the computers are further apart, the terms "wide area network" or "long haul net-work" are used, but the distinction is one of degree and the definitions sometimes overlap.
A bridge is a device that is connected to at least two LANs and serves to pass message frames or packets between LANs, such that a source station on one LAN can transmit data to a destination station on another LAN, without concern for the location of the destination. Bridges are useful and necessary network -2- 2~k43~
com~onents, principally because the total number of stations on a single LAN is limited. Bridges can be implemented to operate at a selected layer of protocol of the network. A detailed knowledge of network archi-tecture is not needed for an understanding of thisinvention, but a brief description follows by way of further background.
As computer networks have developed, various approaches have been used in the choice of communica-tion medium, network topology, message format, proto-cols for channel access, and so forth. Some of these approaches have emerged as de facto standards, but there is still no single standard for network communica-tion. However, a model for network architectures has been proposed and widely accepted. It is known as the International Standards Organization (ISO) Open Systems Interconnection (OSI) reference model. The OSI refer-ence model is not itself a network architecture. Rather it specifies a hierarchy of protocol layers and defines the function of each layer in the network. Each layer in one computer of the network carries on a conversa-tion with the corresponding layer in another computer with which communication is taking place, in accordance with a protocol defining the rules of this communica-tion. In reality, information is transferred down fromlayer to layer in one computer, then through the chan-nel medium and back up the successive layers of the other computer. However, for purposes of design of the various layers and understanding their functions, it is easier to consider each of the layers as communicating with its counterpart at the same level, in a "horizon-tal" direction.
The lowest layer defined by the OSI model is called the physical layer, and is concerned with transmitting raw data bits over the communication 2~3~^~
channel. Design of the physical layer involves issues o~ &lectrical, mechanical or optical engineering, depen-ding on the medium used for the communication channel.
The layer next to the physical layer is called the data link layer. The main task of the data link layer is to transform the physical layer, which interfaces directly with the channel medium, into a communication link that appears error-free to the next layer above, known as the network layer. The data link layer performs such functions as structuring data into packets or frames, and attaching control information to the packets or frames, such as checksums for error detection, and packet numbers.
Although the data link layer is primarily inde-pendent of the nature of the physical transmission me-dium, certain aspects of the data link layer function are more dependent on the transmission medium. For this reason, the data link layer in some network architec-tures is divided into two sublayers: a logical link con-trol sublayer, which performs all medium-independent functions of the data link layer, and a media access control (MAC) sublayer. This sublayer determines which station should get access to the communication channel when there are conflicting requests for access. The functions of the MAC layer are more likely to be depen-dent on the nature of the transmission medium.
Bridges may be designed to operate in the MAC
sublayer. Further details may be found in "MAC Brid-ges," P802.1D/D6, Sept. 1988, a draft publication of IEEE Project 802 on Local and Metropolitan Area Network Standards, or in later drafts of this document.
The basic function of a bridge is to listen "promiscuously," i.e. to all message traffic on all LANs to which it is connected, and to forward each mes-sage it hears onto LANs other than the one from which 2~4~3 _4_ the message was heard. Bridges also maintain a databaseof tation locations, derived from the content of the messages being forwarded. Bridges are connected to LANs by paths known as "links." After a bridge has been in operation for some time, it can associate practically every station with a particular link connecting the bridge to a LAN, and can then forward messages in a more efficient manner, transmitting only over the appro-priate link. The bridge can also recognize a message that does not need to be forwarded, because the source and destination stations are both reached through the same link. Except for its function of "learning" sta-tion locations, or at least station directions, the bridge operates basically as a message repeater.
As network topologies become more complex, with large numbers of LANs, and multiple bridges inter-connecting them, operational difficulties can ensue if all possible LAN bridging connections are permitted. In particular, if several LANs are connected by bridges to form a closed loop, a message may be circulated back to the LAN from which it was originally transmitted, and multiple copies of the same message will be generated.
In the worst case, messages will be duplicated to such a degree that the networks will be effectively clogged with these messages and unable to operate at all.
To prevent the formation of closed loops in bridged networks, IEEE draft publication P802.lD, re-ferred to above, proposes a standard for a spanning tree algorithm that will connect the bridged network - 30 into a tree configuration, containing no closed loops, and spanning the entire network configuration. The spanning tree algorithm is executed periodically by the bridges on the interconnected network, to ensure that the tr~e structure is maintained, even if the physical configlration of the network changes. Basically, the _5_ 2~3~
bri~ges execute the spanning t:ree algorithm by sending spe-ial messages to each other to establish the identi-ty of a "root" bridge. The root bridge is selected, for convenience, as the one with the smallest numerical identification. The algorithm determines which links of the bridges are to be active and which are to be inac-tive, i.e. disabled, in configuring the tree structure.
One more piece of terminology is needed to understand how the algorithm operates. Each LAN has a "designated"
link, which means that one of the link~ connectable to the LAN is designated to carry traffic toward and away from the root bridge. The basis for this decision is similar to the basis for selecting the root bridge. The designated link is the one providing the least costly tshortest) path to the root bridge, with numerical bridge identification being used as a tie-breaker. Once the designated links are identified, the algorithm chooses two types of links to be activated or closed:
first, for each LAN its designated link is chosen, and second, for each bridge a link that forms the "bes~
path" to the root bridge is chosen, i.e. a link through which the bridge received a message giving the identity of the root bridge. All other links are inactivated.
Execution of the algorithm results in interconnection of the LANs and bridges in a tree structure, i.e. one having no closed loops.
Internet is a collection of networks, includ-ing Arpanet, NSFnet, regional networks such as NYser-net, local networks at a number of university and re-search institutions, and a number of military networks.The protocols generally referred to as TCP/IP were originally developed for use only through Arpanet and have subsequently become widely used in the industry.
The protocols provide a set of services that permit users to communicate with each other across the entire 2 ~ a~ L~ 3 ~ 3 Internet. The specific services that these protocols provide are not important to the present invention, but include file transfer, remote log-in, remote execution, remote printing, computer mail, and access to network file systems.
The basic function oE the Transmission Control Protocol (TCP) is to make sure that commands and mes-sages from an application protocol, such as computer mail, are sent to their desired destinations. TCP keeps track of what is sent, and retransmits anything that does not get to its destination correctly. If any mes-sage is too long to be sent as one "datagram," TCP will split it into multiple datagrams and makes sure that they all arrive correctly and are reassembled for the application program at the receiving end. Since these functions are needed for many applications, they are collected into a separate protocol (TCP) rather than being part of each application. TCP is implemented in the transport layer of the OSI reference model.
The Internet Protocol (IP) is implemented in the network layer of the OSI reference model, and provides a basic service to TCP: delivering datagrams to their destinations. TCP simply hands IP a datagram with an intended destination; IP is unaware of any relationship between successive datagrams, and merely handles routing of each datagram to its destination. If the destination is a station connected to a different LAN, the IP makes use of routers to forward the mes-sage.
A router, like a bridge, is a device connected to two or more LANs. Unlike a bridge, however, a router operates at the network layer level, instead of the data link layer level. Addressing at the network layer level makes use of a 32-bit address field for each host, and the address field includes a unique network 2~3~
identifier and a host identifier within the network.
Rou~ers make use of the destination network identifier in a message to determine an optimum path from the source network to the destination network. Various routing algorithms may be used by routers to determine the optimum paths. Typically, routers exchange informa-tion about the identities of the networks to which they are connected.
When a message reaches its destination net-work, a data link layer address is needed to complete forwarding to the destination host. Data link layer ad-dresses are 48 bits long and are globally unique, i.e.
no two hosts, wherever located, have the same data link layer address. There is a protocol called ARP (address resolution protocol), which obtains a data link layer address from the corresponding network layer address (the address that IP uses). Typically, each router main-tains a database table from which it can look up the data link layer address, but if a destination host is not in this ARP database, the router can transmit an ARP request. This message basically means: "will the host with the following network layer address please supply its data link layer address." Only the addressed destination host responds, and the router is then able to insert the correct data link layer address into the message being forwarded, and to transmit the message to its final destination.
The Problem:
As discussed above, bridges operate at the data link layer level and are effectively "transparent"
to user stations or "hosts" connected to the LANs. That is to say, a message directed to a destination on a different LAN from the one to which the source of the messa~e is connected, will reach the destination 2 ~ 4 ~ 3 '~ ~
through a bridge without the source's knowing that the des~ination is on a different LAN. Bridges work well for message traffic that is not using the TCP~IP proto-cols. However, for TCP/IP traffic a significant problem is sometimes caused by ARP messages, especially when bridges are used within an extended network of LANs.
For some network implementations, ARP packets can be duplicated by bridges and this can result in "flurries"
or even "storms" of ARP packets, which disrupt normal traffic flow. Ideally, ARP packets should be confinedto the LAN in which they originate, but bridges are designed to be transparent to all traffic. One possible solution is to use a combination of a bridge and a router in every situation in which a bridge might be used, but providing full router functionality is more complex and more expensive than using conventional bridges.
The need for an alternative to bridges and rou-ters is particularly critical in an "extended network"
administered by a single institution. For example, a corporation or a university may have the need to config-ure a number of "subnets" or "network segments" that are interconnected into one extended network. From out-side the extended network, there appears to be just a single network, i.e. there is one network identifier in the network layer address, and messages destined for a host computer within the extended network are addressed as if this were the case. Within the extended network, however, part of the host identifier field of the net-work layer address is used as a subnet address or net-work segment address. The network segments might be connected by bridges, but these would be subject to the ARP storm problem outlined above. Another problem with using ~ridges for TCP/IP traffic is that some IP data packets may be too large for a bridge to forward, and 2 ~ ~ ~ 3 b 3 J
_ 9 _ will then ~e discarded by the bridge.
It will be apparent from the foregoing that there i~
a need for an alternative to conventional bridges in interconnected networks handling TCP/IP traffic without the added complexity of a router, and without the problems inherent in the use of bridges. The present invention satisfie~ this need, as will become apparent from the following summary.
SUMMARY OF THE INVENTION
The present invention resides in a bridge-like IP
router (BLIP) that functions exactly like a bridge for non-TCP/IP traffic, and functions in a bridge-like manner for TCP/IP traffic, forwarding messages through a spanning tree and learning source and destination addresses, at a network layer level, by correlating the direction from which messages arrive with the source subnet addresses they contain. Thus the bridge-like IP router functions very much like a bridge, but at the network layer level of addressing.
The invention in its broad form resides in apparatus and a method of operation of extended interconnected local area networks (LANs) handling message traffic in accordance with a set of protocols known as TCP/IP, the method comprising the steps of: configuring an extended local area network (LAN) to include a plurality of extended LAN segments connected by bridge-like IP routers 2 ~
- 9a -(BLIPs); receiving a packet of data at a BLIP;
characteri~ed by: determining whether the packet has been transmitted under TCP/IP protocols; processing non-TCP/IP
packets in the manner of a convention bridge; and processing TCP/IP traffic in a manner analogous to a bridge, wherein a message packet received from an extended LAN segment attached to the BLIP is forwarded if necessary to at least one other extended LAN segment attached to the BLIP.
Although the invention addresses a problem that arises in the specific context of the TCP/IP protocols, in a more general sense the invention applies to any inter-network protocols that operate at the network layer level, using an addressing scheme of network addresses and host addresses within each network. Basically, the invention is embodied in a bridge-like device that functions at this network layer level, as well as at a lower level at which globally unique host addresses are used.
As it relates more specifically to the TCP/IP
protocols, the device of the invention comprises mul-tip~e ports for attaching the BLIP to multiple segments of ~n extended LAN, means for distinguishing received TCP/IP message traffic from non-TCP/IP message traffic, bridge means for processing non-TCP/IP message tra~fic exactly in the manner of a conventional bridge, and bridge-like means for processing TCP/IP traffic in a manner analogous to a bridge. A message packet received from an extended LAN segment attached to the BLIP is forwarded, if necessary, to at least one other extended LAN segment attached to the BLIP. Forwarding to another segment will not be necessary if the destination ad-dress is known to be reachable via the bridge port through which the message was received.
Further, the device of the invention includes means for processing address resolution (ARP) messages, including means for detecting and discarding ARP mes-sages requesting destination address information, and means for responding to ARP messages with a special address codc when the requested destination address is on a different segment of the same extended LAN as the BLIP. The bridge-like means includes means for possibly forwarding a message packet having the special address code to some subset of the attached extended LAN seg-ments except the one from which the message packet was received. A host device may, therefore, transmit to destinations on other extended LAN segments as though the destinations were on the same LAN. The source host first requests the data link level address of the desti-nation by sending an ARP message. A BLIP intercepts the ARP message and sends a special reply address. When the source host uses this special address in sending a data packet, the packet is received by the BLIP and forward-ed, along a spanning tree previously computed collec-tively by all of the bridges, to one or more other attached extended LAN segments. When a BLIP receives a 2~ 3~3 pac~t destined for an attached segment, the BLIP ob-tai~s the correct data link layer address by searching its ARP database and sending an ARP message if neces-sary.
The BLIP also includes an IP database asso-ciating each segment of the extended LAN with a port of the BLIP, and means for updating the IP database by observing each received message and correlating the segment address for each message source with a port through which the message is received. There is also an ARP database associating each network layer address in attached extended LAN segments with a corresponding data link layer address, and means for updating the ARP
database by sending ARP messages directed to specific network layer addresses and processing ARP replies that contain the corresponding data link layer addresses.
Further, each BLIP has a router database con-taining the data link layer addresses of all true IP
routers connected to the extended LAN. The router data-base is used to facilitate communication with hostdevices outside the extended LAN.
More specifically, the bridge-like means of the BLIP includes means for determining whether a re-ceived message packet is destined for an attached seg-ment of the extended LAN, means for forwarding a packetdestined for an attached segment other than the one from which the packet was transmitted, by obtaining a data link layer destination address from the ARP data-base, and means for forwarding a packet destined for a segment unattached to the BLIP, by transmitting the packet to at least one other segment through a port selected to reach the destination segment.
Another feature of the invention device is address checking means effective for processing a packet destined for the same extended LAN segment as 2~ ~3~3 the one from which the packet was transmitted. The address checking means takes various corrective ac-tions, depending on the data link layer destination address contained in the packet. The corrective action 5 may simply be to discard the packet, if the data link layer destination address matches an entry in the ARP
database corresponding to an IP destination address con-tained in the packet. Alternatively, if there is no match between these addresses, the corrective action may be to substitute the ARP database entrv for the data link layer destination address in the packet, and to send a redirect message to a source host from which the packet was transmitted.
In terms of a novel method, the invention com-prises the steps of configuring an extended local areanetwork (LAN) to include a plurality of extended LAN
segments connected by bridge-like IP routers (BLIPs), receiving a packet of data at a BLIP, determining wheth-er the packet has been transmitted under TCP/IP proto-cols, processing non-TCP/IP packets in the manner of a conventional bridge, and processing TCP/IP traffic in a manner analogous to a bridge.
Additional steps of the method include detect-ing and discarding ARP messages requesting destination address information, responding to ARP messages with a special address code when the requested destination address is on a different segment of- the same extended LAN as the BLIP, and forwarding a message packet having the special address code to some subset of the attached extended LAN segments except the one from which the message packet was received. These functions of the BLIP allow a host device to transmit to destinations on other extended LAN segments as though the destinations were on the same LAN.
Other steps of the method include maintaining 2 ~ 3 an IP database tha~ associates each segment of the ex-tenBed LAN with a port of the BLIP, maintaining an ARP
database that associates each network layer address in attached extended LAN segments with a corresponding data link layer address, and maintaining a router data-base con'aining the data link layer addresses of all true IP routers connected to the extended LAN.
More specifically, the method may include the steps of determining whether a received message packet is destined for an attached segment of the extended LAN, forwarding a packet destined for an attached seg-ment other than the one from which the packet was trans-mitted, by obtaining a data link layer destination address from the ARP database, and forwarding a packet lS destined for a segment unattached to the BLIP, by transmitting the packet to some subset of the attached extended LAN segments except the one from which the message packet was received.
It will be appreciated from this summary that the invention represents a significant advance in the field of interconnected local area networks using the TCP/IP protocols. In particular, the invention facili-tates communication between multiple LAN segments in an extended LAN, by means of bridge-like IP routers (BLIPs). The BLIPs of the invention are not much more complex than conventional bridges, but function to block propagation of ARP messages and permit communica-tion between network segments as though all hosts in the extended LAN were in a single LAN.
3 ~ 3 BRIEF DESCRIPTION OF T~E DRAWINGS
A more detailed understanding of the invention may be had from the following description of a preferred embodiment, given by way of example and to be understood in conjunction with the accompanying drawingswherein:
FIGURE 1 is a simplified diagrammatic view showing an extended local area network (LAN) connected by IP routers to other networks;
FIGURES 2a and 2b together constitute a flowchart show-ing the functions performed by a bridge-like IP router (BLIP) in accordance with a preferred embodiment of the invention, upon receipt of a packet or ARP message;
FIGURE 3 is a flowchart showing the functions performed by a BLIP upon receipt of an ARP message; and FIGURE 4 is a flowchart showing in more detail the functions performed by the BLIP in forwarding an IP data packet.
DESCRIPTION OF THE PREFERRED EMBODIMENT
AS shown in the drawings by way of illustration, the present invention is concerned with interconnected local area computer networks (LA~S) that are used to handle message traffic in accordance with a set of protocols known as TCP/IP. As described in the foregoing background section of this specifi-cation, conventional bridges cannot handle TCP/IP traffic efficiently, principally because bridges may contribute to the generation of multiple ARP messages that propagate through the interconnected networks. The use of 2~'~4~3 - 14a -conventional routers overcomes this problem, but not without considerable complexity and expense.
As described herein, local area networks within an exten-ded network are interconnected by a new device referred to as a BLIP, for bridge-like IP router. As will be described in detail, each BLIP functions exactly like a bridge for non-TCP/
IP traffic, and functions in a manner alalogous to a bridge for 2~43~3 TCP/IP traffic, but using IP addresses, i.e. network lay~r addresses.
FIG. l depicts in simplified form an extended LAN, indicated by reference numeral 10. Within the extended LAN 10 are shown three extended LAN segments 12, 14, 16. By way of example, extended LAN segment 12 includes four LANs 18, which are interconnected by bridges 20. The other extended LAN segments 14, 16 are single LANs. The extended LAN segments 12, 14, 16 are interconnected by bridge-like IP routers (BLIPs), indicated at 22 and 24. By way of further illustration, the extended LAN 10 is shown as being connected by IP
routers 26, 28 to other networks 30, 32, respectively, which may also be extended LANs.
As viewed by routers, such as 26, 28, and by all host computers (not shown) connected to the various LANs in the configuration of FIG. 1, the extended LAN
10 has a single network address, e.g. network #5. With-in the extended LAN 10, the extended LAN segments 12, 14, 16 have subnet addresses, or extended LAN segment addresses, appended to the extended LAN address. For example, the extended LAN segments might have subnet addresses 5.1, 5.2 and 5.3. The subnet portions of these addresses (.1, .2, .3) are used by tAe BLIPs in one mode of their operation in a bridge-like manner, and are known to the BLIPs initially from a manual configuration procedure.
One of the functions of the BLIPs is to run a spanning tree algorithm within the extended LAN 10, to ensure that the extended LAN segments are connected in a tree structure, having no continuous loops. The tech-niques for doing this are well known in the computer networr. field and will not be further discussed here.
See, for example, the IEEE publication P802.1D referred to in the foregoing background section of this - 2~3~3 specification. In the simple example given in FIG. 1, there are only three extended LAN segments, connected in a serial string, so there is no possibility of a circular path. It will be understood, however, that the extended LAN segments could be interconnected in a more complex manner that would require the running of the spanning tree algorithm to reduce the configuration to a tree structure.
How the BLIPs 22, 24 function when they re-ceive a data packet or an ARP message is best under-stood from the flowchart of FIG. 2. There are three databases maintained in each BLIP and referred to in the flowchart. These are the bridge database, the IP
database and the ARP database. In addition there is a router database, which may be manually supplied to the BLIPs.
The bridge database is identical with one maintained in a conventional bridge. It consists of data link layer addresses associated with corresponding port numbers through which the BLIP communicates. There-fore, when the BLIP receives a message through one of its ports, i.e. from a particular direction in the extended LAN, it can associate the source data link layer address with the port through which the message was received.
The IP database is analogous to the bridge database except that it functions at the network layer or IP address level. When a message is received through a particu]ar port, the ~xtended LAN segment or subnet address o~ the message source is associated with that port. Thus, the BLIP "learns" the directions of the various subnets in the extended LAN.
The ARP database associates host identifying numbers, in the IP address, with data link layer ad-dresses. The database is used for forwarding an IP
2~.43~3 packet to its final destination on an attached extended LAN segment. The database is acquired by listening to ARP replies, generated as a result of ARP messages sent by this and other BLIPs, or by other host devices in attached extended LAN segments.
As indicated in block 40 of FIG. 2, when a packet or ARP message is received by a BLIP, it first determines whether the received packet or message uses ARP and IP protocols within the TCP/IP protocol. This can be determined from a protocol field in the packet header. If the TCP/IP protocol is not employed, the BLIP continues processing the received packet in exact-ly the manner of a conventional bridge, as indicated in block 42. If the received message or packet does employ the TCP/IP protocol, it is next determined, in block 44, whether an ARP message has been received. If so, processing continues, as will be described with refer-ence to FIG. 3. If not, then it is concluded that an IP
message packet has been received. The next inquiry is to determine, in block 44, whether the IP destination address (IPD in the figure) is within the extended LAN
in which the BLIP resides. If not, the destination address is in some other LAN or extended LAN, and the BLIP next examines the data link layer destination address (DLLD in the figure). If the DLLD is not a special address referred to as all-adjacent-BLIPs, as determined in block 48, the BLIP continues processing in the manner of a bridge, as indicated in block 42, using data link layer destination address. The signifi-cance of the all-adjacent-BLIPs address will become clear as this description proceeds. If this special address is found in the test of block 48, the BLIP
picks I router at random and forwards the message to it, a- indicated in block 50. Inherently, then, the BLIPs ~ave to have knowledge of the directional 3 ~ 3 locations of the IP routers.
If the test in block 46 determines that the IP
destination is in the extended LAN 10, the next test, in block 52, asks whether the IP source address (IPS in the figure) is also in the extended LAN. If so, the BLIP "learns" the IP source address, as indicated in block 54. This is the same type of learning as a conven-tional bridge, except that the IP address is learned and not the data link address. Whenever an IP source address is seen by the BLIP, it updates its IP data-base, so that a subsequent message destined for the extended LAN segment can be transmitted in the correct direction. If the IP source is not in the extended LAN, the learning step is bypassed.
The next processing step is to determine wheth-er the IP destination is on an attached segment of the extended LAN, as indicated in block 56. An attached seg-ment is one to which this particular BLIP is directly connected. Thus, for example, BLIP 22 is attached to segments 12 and 14, but not to segment 16. If the IP
destination is not in an attached segment, the data link layer destination address (DLLD) is examined, in block 58. If the DLLD is all-adjacent-BLIPs, the packet is forwarded through the spanning tree established by the BLIPs, as indicated at block 60, which is expanded in FIG. 4. If the all-adjacent-BLIPs address is not in the DLLD field of the packet, it should have been placed there by the source of the packet. The BLIP, as indicated in block 62, changes the DLLD field to all-adjacent-BLIPs and sends a "redirect" message back to the s~urce, instructing that the all-adjacent-BLIPs address is to be used.
The all-adjacent-BLIPs address is basically a specia code inserted in the data link layer destina-tion ~!dress field to direct the packet to BLIPs -19- 2~3J3 att~ched to the segment from which the packet is sent.
A ~ost computer sending the packet uses the special code when the intended destination is located on a dif-ferent segment of the extendecl LAN. A typical sequence of events is that the source host knows the IP address of its intended destination, but is unaware that the destination is located on a different subnet or extend-ed LAN segment. This is because all hosts and routers are unaware of the subnet level of addressing, and all of the subnets in the extended LAN are perceived to be in the same network. The source host issues an ARP
message to determine the data link level address of its intended destination. Because the destination is not in the same subnet, the destination host does not receive the ARP message, but at least one BLIP does. In processing the ARP message, the BLIP generates an ARP
reply if the requested destination is on the extended LAN and on a different extended LAN segment from the source. The ARP reply gives the requested data link layer address as all-adjacent-BLIPs. Then the source host sends its data packet to what it believes to be a true data link layer address. In fact, the packet is received by a BLIP, and is forwarded through the spanning tree to an adjacent extended network segment, as indicated in block 60.
If the IP destination address is on an at-tached segment of this BLIP, it is next determined, in block 6~, whether the packet was received from a dif-ferent attached segment of the extended LAN. If so, the data link layer destination address is retrieved from the ARP database, or an ARP message is transmitted if the address is not yet in the ARP database, all of which is indicated in block 66. Once the data link layer destination address is obtained, the packet is forwarded to its final destination, as indicated at 68.
2~3~ ~
If it is determined, in block 64, that the packet was received from the same attached segment as the one to which the destination host is connected, this would normally indicate that a source host was sending a packet to a destination host on the same extended network segment. The BLIP need do nothing, since the packet will be recognized and received by the intended destination host. One processing option for the BLIP is simply to ignore the received packet in all cases, as indicated in block 70. However, a more rigor-ous approach is to examine the data link layer destina-tion address (DLLD) to determine an appropriate course of action.
If the DLLD address in the packet corresponds with the ARP database entry for the IP destination address in the packet, the proper course is to discard the packet, as indicated in block 72, since it will reach its destination directly, without help of the BLIP. Another possibility is that the DLLD address is all-adjacent-BLIPs. This indicates an error on the part of the source host. A destination on the same extended LAN segment should be addressed to a real DLLD address and not to the special all-adjacent-BLIPs address. An appropriate action by the BLIP in this case is to obtain the ARP entry for the IP destination address, and to forward the packet there, as indicated in block 74, and to send a "redirect" message back to the source host to correct the problem.
A third possibility is that the DLLD address is not equal to the ARP database entry corresponding to the IP destination, and is not the special all-adja-cent-BLIPs address either. This situation could occur because either the BLIPs ARP database or the DLLD in the packet is incorrect. One possible corrective ac-tion, as indicated in block 76, is to use the ARP
--2 ~ L~
database DLLD address and to send a "redirect" message to ~he source host. Also the ARP database entry is confirmed by sending an ARP message. The error will rectify itself in subsequent transmissions.
A fourth possibility is that the DLLD address in the packet is all-adjacent-BLIPs, but there is no ARP database entry for the IP destination address. An ARP message is issued to update the database, as in block 78. The packet may be temporarily stored until the ARP reply is received, or may be discarded. Subse-quent retransmission of the packet will be received after the ARP database has been updated.
A final possibility is that the DLLD address is equal to the corresponding entry in the ARP data-base, but both are incorrect. Obviously, there is noway to detect this error, but its possible effects are minimized by periodically refreshing the ARP database, as indicated in block 80.
More details of ARP message processing by a BLIP are shown in FIG. 3. When an ARP message is re-ceived, it is first determined, in block 82, whether the message came from the same segment as the one on which the IP destination is located. If so, the ARP
message is ignored, as indicated in block 84, since the generation of a reply will presumably be handled by the destination host.
If it is determined in bloc~ 82 that the re-quested IP destination is not on the same segment as the one that the ARP message was received from, it is next determined, in block 86, whether the requested IP
destination is on a different LAN or extended LAN from the one in which the BLIP is located. If so, which should not be the case, an ARP reply will be sent to direct l?acket transmission to a router, as indicated in block O3. Finally, it is determined in block 90 whether ~Q~3~
the requested IP destination is that of an IP router.
If SP, an ARP reply will be sent to direct packet trans-mission to a router, as shown in block 88. If not, an ARP reply is generated, as shown in block 92, indica-ting that the~DLLD address is all-adjacent-BLIPs.
FIG. 4 shows in more detail how a packet is forwarded through the spanning tree (block 60). First, the IP destination subnet address is examined, in block 94, to determine if it is in the IP database, i.e. to determine whether its directional location is already known. If so, another question is posed, in block 96, to determine if the IP destination subnet directional location is the same as the direction from which the packet was received. If so, there is no point in for-warding the packet in the same direction as the onefrom which it was received, and the packet is ignored, as shown in block 98. If the subnet directional loca-tion is not the same as the directional location from which the packet was received, the packet is forwarded in the direction determined from the IP database, as indicated in block 100. If the IP destination subnet address is not in the IP database, as determined in block 94, the packet is forwarded over all spanning tree segments except the one over which it was re-ceived, as indicated in block 102.
There are a number of possible situations thatcan serve as examples of the manner in which the BLIPs operate, depending on the locations of the source and destination hosts. These will now be described, with occasional reference to the BLIP functions shown in the drawin.,s.
.. . . .
.
-3 ~ 3 A. Source and destination both within the same extended LAN segment. The source will issue an ARP mes-sage to obtain the correct data link layer destination address, and will obtain that address from the destina-tion itself. The BLIPs will play no direct part in thisoperation. On receiving the ARP message, a BLIP will determine that the message is from the same segment as the destination (block 82), and will ignore the message (block 84). On receiving the data packet, a BLIP will determine that the packet is from the same attached segment as the destination (block 64), and will ignore the packet if its data link layer destination address matches the one in the BLIPs ARP database corresponding to the IP destination address (block 72). However, each BLIP receiving the transmitted packet will perform additional functions if the data link layer destination address does not match the BLIP's ARP database. More specifically:
1) If the data link layer destination address in the packet is the special all-adjacent-BLIPs ad-dress, the BLIP will obtain its ARP database entry and forward the packet there, also sending a "redirect"
message back to the source (block 74). If the BLIP has no ARP database entry corresponding to the IP destina-tion address in the packet, it will attempt to obtainan entry by sending an ARP message (block 78).
2) If the BLIP has a correct ARP database entry, but the source host chose to send the packet to an incorrect data link layer address, then the BLIP
will overwrite the data link layer destination address, and will send a "redirect" message to the source (block 76). Fer example, the source might incorrectly choose to send a packet to an IP router, which is only optimal for de~inations outside the extended LAN.
3) If the BLIP has an incorrect entry in its ' ' , ~ , ARP database, but the packet has a correct data link lay~r destination address, unfortunately the procedure in paragraph 2) above will result in the packet's being forwarded to an incorrect destination. However, the BLIP will also refresh its database by issuing an ARP
message, and on the next packet transmission from the source the BLIP will correctly forward the packet.
A more detailed understanding of the invention may be had from the following description of a preferred embodiment, given by way of example and to be understood in conjunction with the accompanying drawingswherein:
FIGURE 1 is a simplified diagrammatic view showing an extended local area network (LAN) connected by IP routers to other networks;
FIGURES 2a and 2b together constitute a flowchart show-ing the functions performed by a bridge-like IP router (BLIP) in accordance with a preferred embodiment of the invention, upon receipt of a packet or ARP message;
FIGURE 3 is a flowchart showing the functions performed by a BLIP upon receipt of an ARP message; and FIGURE 4 is a flowchart showing in more detail the functions performed by the BLIP in forwarding an IP data packet.
DESCRIPTION OF THE PREFERRED EMBODIMENT
AS shown in the drawings by way of illustration, the present invention is concerned with interconnected local area computer networks (LA~S) that are used to handle message traffic in accordance with a set of protocols known as TCP/IP. As described in the foregoing background section of this specifi-cation, conventional bridges cannot handle TCP/IP traffic efficiently, principally because bridges may contribute to the generation of multiple ARP messages that propagate through the interconnected networks. The use of 2~'~4~3 - 14a -conventional routers overcomes this problem, but not without considerable complexity and expense.
As described herein, local area networks within an exten-ded network are interconnected by a new device referred to as a BLIP, for bridge-like IP router. As will be described in detail, each BLIP functions exactly like a bridge for non-TCP/
IP traffic, and functions in a manner alalogous to a bridge for 2~43~3 TCP/IP traffic, but using IP addresses, i.e. network lay~r addresses.
FIG. l depicts in simplified form an extended LAN, indicated by reference numeral 10. Within the extended LAN 10 are shown three extended LAN segments 12, 14, 16. By way of example, extended LAN segment 12 includes four LANs 18, which are interconnected by bridges 20. The other extended LAN segments 14, 16 are single LANs. The extended LAN segments 12, 14, 16 are interconnected by bridge-like IP routers (BLIPs), indicated at 22 and 24. By way of further illustration, the extended LAN 10 is shown as being connected by IP
routers 26, 28 to other networks 30, 32, respectively, which may also be extended LANs.
As viewed by routers, such as 26, 28, and by all host computers (not shown) connected to the various LANs in the configuration of FIG. 1, the extended LAN
10 has a single network address, e.g. network #5. With-in the extended LAN 10, the extended LAN segments 12, 14, 16 have subnet addresses, or extended LAN segment addresses, appended to the extended LAN address. For example, the extended LAN segments might have subnet addresses 5.1, 5.2 and 5.3. The subnet portions of these addresses (.1, .2, .3) are used by tAe BLIPs in one mode of their operation in a bridge-like manner, and are known to the BLIPs initially from a manual configuration procedure.
One of the functions of the BLIPs is to run a spanning tree algorithm within the extended LAN 10, to ensure that the extended LAN segments are connected in a tree structure, having no continuous loops. The tech-niques for doing this are well known in the computer networr. field and will not be further discussed here.
See, for example, the IEEE publication P802.1D referred to in the foregoing background section of this - 2~3~3 specification. In the simple example given in FIG. 1, there are only three extended LAN segments, connected in a serial string, so there is no possibility of a circular path. It will be understood, however, that the extended LAN segments could be interconnected in a more complex manner that would require the running of the spanning tree algorithm to reduce the configuration to a tree structure.
How the BLIPs 22, 24 function when they re-ceive a data packet or an ARP message is best under-stood from the flowchart of FIG. 2. There are three databases maintained in each BLIP and referred to in the flowchart. These are the bridge database, the IP
database and the ARP database. In addition there is a router database, which may be manually supplied to the BLIPs.
The bridge database is identical with one maintained in a conventional bridge. It consists of data link layer addresses associated with corresponding port numbers through which the BLIP communicates. There-fore, when the BLIP receives a message through one of its ports, i.e. from a particular direction in the extended LAN, it can associate the source data link layer address with the port through which the message was received.
The IP database is analogous to the bridge database except that it functions at the network layer or IP address level. When a message is received through a particu]ar port, the ~xtended LAN segment or subnet address o~ the message source is associated with that port. Thus, the BLIP "learns" the directions of the various subnets in the extended LAN.
The ARP database associates host identifying numbers, in the IP address, with data link layer ad-dresses. The database is used for forwarding an IP
2~.43~3 packet to its final destination on an attached extended LAN segment. The database is acquired by listening to ARP replies, generated as a result of ARP messages sent by this and other BLIPs, or by other host devices in attached extended LAN segments.
As indicated in block 40 of FIG. 2, when a packet or ARP message is received by a BLIP, it first determines whether the received packet or message uses ARP and IP protocols within the TCP/IP protocol. This can be determined from a protocol field in the packet header. If the TCP/IP protocol is not employed, the BLIP continues processing the received packet in exact-ly the manner of a conventional bridge, as indicated in block 42. If the received message or packet does employ the TCP/IP protocol, it is next determined, in block 44, whether an ARP message has been received. If so, processing continues, as will be described with refer-ence to FIG. 3. If not, then it is concluded that an IP
message packet has been received. The next inquiry is to determine, in block 44, whether the IP destination address (IPD in the figure) is within the extended LAN
in which the BLIP resides. If not, the destination address is in some other LAN or extended LAN, and the BLIP next examines the data link layer destination address (DLLD in the figure). If the DLLD is not a special address referred to as all-adjacent-BLIPs, as determined in block 48, the BLIP continues processing in the manner of a bridge, as indicated in block 42, using data link layer destination address. The signifi-cance of the all-adjacent-BLIPs address will become clear as this description proceeds. If this special address is found in the test of block 48, the BLIP
picks I router at random and forwards the message to it, a- indicated in block 50. Inherently, then, the BLIPs ~ave to have knowledge of the directional 3 ~ 3 locations of the IP routers.
If the test in block 46 determines that the IP
destination is in the extended LAN 10, the next test, in block 52, asks whether the IP source address (IPS in the figure) is also in the extended LAN. If so, the BLIP "learns" the IP source address, as indicated in block 54. This is the same type of learning as a conven-tional bridge, except that the IP address is learned and not the data link address. Whenever an IP source address is seen by the BLIP, it updates its IP data-base, so that a subsequent message destined for the extended LAN segment can be transmitted in the correct direction. If the IP source is not in the extended LAN, the learning step is bypassed.
The next processing step is to determine wheth-er the IP destination is on an attached segment of the extended LAN, as indicated in block 56. An attached seg-ment is one to which this particular BLIP is directly connected. Thus, for example, BLIP 22 is attached to segments 12 and 14, but not to segment 16. If the IP
destination is not in an attached segment, the data link layer destination address (DLLD) is examined, in block 58. If the DLLD is all-adjacent-BLIPs, the packet is forwarded through the spanning tree established by the BLIPs, as indicated at block 60, which is expanded in FIG. 4. If the all-adjacent-BLIPs address is not in the DLLD field of the packet, it should have been placed there by the source of the packet. The BLIP, as indicated in block 62, changes the DLLD field to all-adjacent-BLIPs and sends a "redirect" message back to the s~urce, instructing that the all-adjacent-BLIPs address is to be used.
The all-adjacent-BLIPs address is basically a specia code inserted in the data link layer destina-tion ~!dress field to direct the packet to BLIPs -19- 2~3J3 att~ched to the segment from which the packet is sent.
A ~ost computer sending the packet uses the special code when the intended destination is located on a dif-ferent segment of the extendecl LAN. A typical sequence of events is that the source host knows the IP address of its intended destination, but is unaware that the destination is located on a different subnet or extend-ed LAN segment. This is because all hosts and routers are unaware of the subnet level of addressing, and all of the subnets in the extended LAN are perceived to be in the same network. The source host issues an ARP
message to determine the data link level address of its intended destination. Because the destination is not in the same subnet, the destination host does not receive the ARP message, but at least one BLIP does. In processing the ARP message, the BLIP generates an ARP
reply if the requested destination is on the extended LAN and on a different extended LAN segment from the source. The ARP reply gives the requested data link layer address as all-adjacent-BLIPs. Then the source host sends its data packet to what it believes to be a true data link layer address. In fact, the packet is received by a BLIP, and is forwarded through the spanning tree to an adjacent extended network segment, as indicated in block 60.
If the IP destination address is on an at-tached segment of this BLIP, it is next determined, in block 6~, whether the packet was received from a dif-ferent attached segment of the extended LAN. If so, the data link layer destination address is retrieved from the ARP database, or an ARP message is transmitted if the address is not yet in the ARP database, all of which is indicated in block 66. Once the data link layer destination address is obtained, the packet is forwarded to its final destination, as indicated at 68.
2~3~ ~
If it is determined, in block 64, that the packet was received from the same attached segment as the one to which the destination host is connected, this would normally indicate that a source host was sending a packet to a destination host on the same extended network segment. The BLIP need do nothing, since the packet will be recognized and received by the intended destination host. One processing option for the BLIP is simply to ignore the received packet in all cases, as indicated in block 70. However, a more rigor-ous approach is to examine the data link layer destina-tion address (DLLD) to determine an appropriate course of action.
If the DLLD address in the packet corresponds with the ARP database entry for the IP destination address in the packet, the proper course is to discard the packet, as indicated in block 72, since it will reach its destination directly, without help of the BLIP. Another possibility is that the DLLD address is all-adjacent-BLIPs. This indicates an error on the part of the source host. A destination on the same extended LAN segment should be addressed to a real DLLD address and not to the special all-adjacent-BLIPs address. An appropriate action by the BLIP in this case is to obtain the ARP entry for the IP destination address, and to forward the packet there, as indicated in block 74, and to send a "redirect" message back to the source host to correct the problem.
A third possibility is that the DLLD address is not equal to the ARP database entry corresponding to the IP destination, and is not the special all-adja-cent-BLIPs address either. This situation could occur because either the BLIPs ARP database or the DLLD in the packet is incorrect. One possible corrective ac-tion, as indicated in block 76, is to use the ARP
--2 ~ L~
database DLLD address and to send a "redirect" message to ~he source host. Also the ARP database entry is confirmed by sending an ARP message. The error will rectify itself in subsequent transmissions.
A fourth possibility is that the DLLD address in the packet is all-adjacent-BLIPs, but there is no ARP database entry for the IP destination address. An ARP message is issued to update the database, as in block 78. The packet may be temporarily stored until the ARP reply is received, or may be discarded. Subse-quent retransmission of the packet will be received after the ARP database has been updated.
A final possibility is that the DLLD address is equal to the corresponding entry in the ARP data-base, but both are incorrect. Obviously, there is noway to detect this error, but its possible effects are minimized by periodically refreshing the ARP database, as indicated in block 80.
More details of ARP message processing by a BLIP are shown in FIG. 3. When an ARP message is re-ceived, it is first determined, in block 82, whether the message came from the same segment as the one on which the IP destination is located. If so, the ARP
message is ignored, as indicated in block 84, since the generation of a reply will presumably be handled by the destination host.
If it is determined in bloc~ 82 that the re-quested IP destination is not on the same segment as the one that the ARP message was received from, it is next determined, in block 86, whether the requested IP
destination is on a different LAN or extended LAN from the one in which the BLIP is located. If so, which should not be the case, an ARP reply will be sent to direct l?acket transmission to a router, as indicated in block O3. Finally, it is determined in block 90 whether ~Q~3~
the requested IP destination is that of an IP router.
If SP, an ARP reply will be sent to direct packet trans-mission to a router, as shown in block 88. If not, an ARP reply is generated, as shown in block 92, indica-ting that the~DLLD address is all-adjacent-BLIPs.
FIG. 4 shows in more detail how a packet is forwarded through the spanning tree (block 60). First, the IP destination subnet address is examined, in block 94, to determine if it is in the IP database, i.e. to determine whether its directional location is already known. If so, another question is posed, in block 96, to determine if the IP destination subnet directional location is the same as the direction from which the packet was received. If so, there is no point in for-warding the packet in the same direction as the onefrom which it was received, and the packet is ignored, as shown in block 98. If the subnet directional loca-tion is not the same as the directional location from which the packet was received, the packet is forwarded in the direction determined from the IP database, as indicated in block 100. If the IP destination subnet address is not in the IP database, as determined in block 94, the packet is forwarded over all spanning tree segments except the one over which it was re-ceived, as indicated in block 102.
There are a number of possible situations thatcan serve as examples of the manner in which the BLIPs operate, depending on the locations of the source and destination hosts. These will now be described, with occasional reference to the BLIP functions shown in the drawin.,s.
.. . . .
.
-3 ~ 3 A. Source and destination both within the same extended LAN segment. The source will issue an ARP mes-sage to obtain the correct data link layer destination address, and will obtain that address from the destina-tion itself. The BLIPs will play no direct part in thisoperation. On receiving the ARP message, a BLIP will determine that the message is from the same segment as the destination (block 82), and will ignore the message (block 84). On receiving the data packet, a BLIP will determine that the packet is from the same attached segment as the destination (block 64), and will ignore the packet if its data link layer destination address matches the one in the BLIPs ARP database corresponding to the IP destination address (block 72). However, each BLIP receiving the transmitted packet will perform additional functions if the data link layer destination address does not match the BLIP's ARP database. More specifically:
1) If the data link layer destination address in the packet is the special all-adjacent-BLIPs ad-dress, the BLIP will obtain its ARP database entry and forward the packet there, also sending a "redirect"
message back to the source (block 74). If the BLIP has no ARP database entry corresponding to the IP destina-tion address in the packet, it will attempt to obtainan entry by sending an ARP message (block 78).
2) If the BLIP has a correct ARP database entry, but the source host chose to send the packet to an incorrect data link layer address, then the BLIP
will overwrite the data link layer destination address, and will send a "redirect" message to the source (block 76). Fer example, the source might incorrectly choose to send a packet to an IP router, which is only optimal for de~inations outside the extended LAN.
3) If the BLIP has an incorrect entry in its ' ' , ~ , ARP database, but the packet has a correct data link lay~r destination address, unfortunately the procedure in paragraph 2) above will result in the packet's being forwarded to an incorrect destination. However, the BLIP will also refresh its database by issuing an ARP
message, and on the next packet transmission from the source the BLIP will correctly forward the packet.
4) If the BLIP has an incorrect database entry, but the source host agrees with that incorrect entry, perhaps because the BLIP sent a "redirect" mes-sage with the incorrect destination, this situation is the same as one encountered in conventional IP routers, and referred to as the ARP cache invalidation problem.
The problem is minimized in the BLIPs by periodic re-freshing of ARP database entries (block 80); e.g. everyten minutes.
B. Source and destination located on different segments of the same extended LAN. The source host will not be able to distinguish the destination from one in its own extended LAN segment, since each host is una-ware of the division of the extended LAN into segments.
The source host will issue an ARP message and will re-ceive an ARP reply from adjacent BLIPs (block 92), indi-cating the data link layer destination address as all-adjacent-BLIPs. Data packets directed to this address will be correctly forwarded by the BLIPs (blocks 66, 68).
C. Source within the extended LAN destination outside the extended LAN. A source host wishing to com-municate with a destination outside the extended LAN is aware t~at it must use an IP router for this purpose.
The source host chooses a router at random and the BLIPs ;;ill forward the packet toward the chosen router.
Subsequ-ntly, the addressed router might send a "redi-rect" -essage back to the source, if a more optimum ~ $ !~
router should be used. When the source host receives the. "redirect," it will issue an ARP to get the data link layer address of the optimum router. The BLIP will reply with the correct station address of the router, obtained from its manually configured database of router addresses. The router itself does not receive the ARP request. In this way the BLIP keeps the ARP
requests and replies local to a part LAN segment and thereby minimizes "storms" of ARP requests and replies.
D. Source outside the extended LAN destina-tion within the extended LAN. Once the packet is re-ceived by an IP router connected to the extended LAN, the router will send an ARP message to determine the data link layer address of the destination. If the destination is on the same extended LAN segment as the router, the destination will itself respond to the ARP
message, and the router will forward the packet to the destination. If the destination is on a different ex-tended LAN segment from the router, all BLIPs connectedto the same segment as the router will respond to the ARP message with the special all-adjacent-BLIPs address (block 92). The router will then forward the packet into the extended LA~, as desired, with a data link layer destination address of all-adjacent-BLIPs. The BLIPs wlll then process the packet in accordance with FIG. 2, forwarding it through the spanning tree (block 60) until the destination segment is reached, and then forwarding the packet to its ultimate destination with-in the segment (blocks 66, 68).
It will be appreciated from the foregoing thatthe present invention represents a significant advance in the r ield of local area networks that handle TCP/IP
traffic. In particular, the invention permits TCP/IP
traffic to be forwarded through an interconnected 2~3~ ~
extended LAN without the use of IP routers, and without the disadvantages of bridge~ used for the same purpose.
Each BLIP functions as a bridge for non-TCP/IP traffic and functions analogously to a bridge for TCP/IP traf-fic, using addresses at the IP or network layer level.
It will also be appreciated that, although an embodi-ment of the invention has been described in detail for purposes of illustration, various modifications may be made without departing from the spirit and scope of the invention. Accordingly, the invention is not to be limited except as by the appended claims.
The problem is minimized in the BLIPs by periodic re-freshing of ARP database entries (block 80); e.g. everyten minutes.
B. Source and destination located on different segments of the same extended LAN. The source host will not be able to distinguish the destination from one in its own extended LAN segment, since each host is una-ware of the division of the extended LAN into segments.
The source host will issue an ARP message and will re-ceive an ARP reply from adjacent BLIPs (block 92), indi-cating the data link layer destination address as all-adjacent-BLIPs. Data packets directed to this address will be correctly forwarded by the BLIPs (blocks 66, 68).
C. Source within the extended LAN destination outside the extended LAN. A source host wishing to com-municate with a destination outside the extended LAN is aware t~at it must use an IP router for this purpose.
The source host chooses a router at random and the BLIPs ;;ill forward the packet toward the chosen router.
Subsequ-ntly, the addressed router might send a "redi-rect" -essage back to the source, if a more optimum ~ $ !~
router should be used. When the source host receives the. "redirect," it will issue an ARP to get the data link layer address of the optimum router. The BLIP will reply with the correct station address of the router, obtained from its manually configured database of router addresses. The router itself does not receive the ARP request. In this way the BLIP keeps the ARP
requests and replies local to a part LAN segment and thereby minimizes "storms" of ARP requests and replies.
D. Source outside the extended LAN destina-tion within the extended LAN. Once the packet is re-ceived by an IP router connected to the extended LAN, the router will send an ARP message to determine the data link layer address of the destination. If the destination is on the same extended LAN segment as the router, the destination will itself respond to the ARP
message, and the router will forward the packet to the destination. If the destination is on a different ex-tended LAN segment from the router, all BLIPs connectedto the same segment as the router will respond to the ARP message with the special all-adjacent-BLIPs address (block 92). The router will then forward the packet into the extended LA~, as desired, with a data link layer destination address of all-adjacent-BLIPs. The BLIPs wlll then process the packet in accordance with FIG. 2, forwarding it through the spanning tree (block 60) until the destination segment is reached, and then forwarding the packet to its ultimate destination with-in the segment (blocks 66, 68).
It will be appreciated from the foregoing thatthe present invention represents a significant advance in the r ield of local area networks that handle TCP/IP
traffic. In particular, the invention permits TCP/IP
traffic to be forwarded through an interconnected 2~3~ ~
extended LAN without the use of IP routers, and without the disadvantages of bridge~ used for the same purpose.
Each BLIP functions as a bridge for non-TCP/IP traffic and functions analogously to a bridge for TCP/IP traf-fic, using addresses at the IP or network layer level.
It will also be appreciated that, although an embodi-ment of the invention has been described in detail for purposes of illustration, various modifications may be made without departing from the spirit and scope of the invention. Accordingly, the invention is not to be limited except as by the appended claims.
Claims (17)
1. For use in an extended interconnected local area net-work (LAN) handling message traffic in accordance with a set of inter-network protocols that use a network addressing scheme, a bridge-like Internet Protocol (IP) router (BLIP), characterized by:
multiple ports for attaching the BLIP to multiple segments of an extended LAN;
means for distinguishing received message traffic that uses the inter-network protocols from other message traffic that does not use the protocols;
bridge means for processing the other message traffic exactly in the manner of a conventional bridge, using unique station addresses to determine how to forward the message traffic; and bridge-like means for processing the inter-network protocol traffic in a manner analogous to a bridge, wherein a message pac-ket received from an extended LAN segment attached to the BLIP
is forwarded if necessary to at least one other extended LAN
segment attached to the BLIP, using network addresses and net-work segment addresses, instead of unique station addresses, to determine how to forward the message traffic.
multiple ports for attaching the BLIP to multiple segments of an extended LAN;
means for distinguishing received message traffic that uses the inter-network protocols from other message traffic that does not use the protocols;
bridge means for processing the other message traffic exactly in the manner of a conventional bridge, using unique station addresses to determine how to forward the message traffic; and bridge-like means for processing the inter-network protocol traffic in a manner analogous to a bridge, wherein a message pac-ket received from an extended LAN segment attached to the BLIP
is forwarded if necessary to at least one other extended LAN
segment attached to the BLIP, using network addresses and net-work segment addresses, instead of unique station addresses, to determine how to forward the message traffic.
2. A bridge-like IP router as defined in claim 1, and further comprising:
means for processing address resolution messages requesting destination address information.
means for processing address resolution messages requesting destination address information.
3. A bridge-like IP router as defined in claim 2, wherein;
the means for processing address resolution messages includes means for detecting and discarding address resolution messages requesting destination address information, and means for responding to the address resolution messages with a special address code when the requested destination address is on a different segment of the same extended LAN as the BLIP;
and the bridge-like means includes means for forwarding a message packet having the special address code, to some subset of the attached extended LAN segments except the one from which the message packet was received;
whereby a host device may transmit to destinations on other extended LAN segments as though the destinations were on the same LAN.
the means for processing address resolution messages includes means for detecting and discarding address resolution messages requesting destination address information, and means for responding to the address resolution messages with a special address code when the requested destination address is on a different segment of the same extended LAN as the BLIP;
and the bridge-like means includes means for forwarding a message packet having the special address code, to some subset of the attached extended LAN segments except the one from which the message packet was received;
whereby a host device may transmit to destinations on other extended LAN segments as though the destinations were on the same LAN.
4. A bridge-like IP router as defined in claim 3, wherein:
the means for processing address resolution messages includes means for detecting and discarding address resolution messages requesting destination address information, and means for responding to the address resolution messages with a special address code when the requested destination address is on a different segment of the same extended LAN as the BLIP;
and the bridge-like means includes means for forwarding a message packet having the special address code, to some subset of the attached extended LAN segments except the one from which the message packet was received;
whereby a host device may transmit to destinations on other extended LAN segments as though the destinations were on the same LAN.
the means for processing address resolution messages includes means for detecting and discarding address resolution messages requesting destination address information, and means for responding to the address resolution messages with a special address code when the requested destination address is on a different segment of the same extended LAN as the BLIP;
and the bridge-like means includes means for forwarding a message packet having the special address code, to some subset of the attached extended LAN segments except the one from which the message packet was received;
whereby a host device may transmit to destinations on other extended LAN segments as though the destinations were on the same LAN.
5. A bridge-like IP router as defined in claim 4, wherein the bridge-like means includes:
an IP database associating each segment of the extended LAN with a port of the BLIP; and means for updating the IP database by obsering each received message and correlating the segment address for each message source with a port through which the message is received.
an IP database associating each segment of the extended LAN with a port of the BLIP; and means for updating the IP database by obsering each received message and correlating the segment address for each message source with a port through which the message is received.
6. A bridge-like IP router as defined in claim 4, wherein the bridge-like means includes:
an ARP database associating each network layer address in attached exended LAN segments with a corresponding data link layer address; and means for updating the ARP database by sending ARP
messages directed to specific network layer addresses and processing ARP replies that contain the corresponding data link layer addresses.
an ARP database associating each network layer address in attached exended LAN segments with a corresponding data link layer address; and means for updating the ARP database by sending ARP
messages directed to specific network layer addresses and processing ARP replies that contain the corresponding data link layer addresses.
7. A bridge-like IP router as defined in claim 4, wherein the bridge-like means includes:
a router database containing the data link layer addresses of all true IP routers connected to the extended LAN.
a router database containing the data link layer addresses of all true IP routers connected to the extended LAN.
8. A method of operation of extended interconnected local area networks (LANs) handling message traffic in accordance with a set of protocols known as TCP/IP, the method comprising the steps of:
configuring an extended local area network (LAN) to include a plurality of extended LAN segments connected by bridge-like IP routers (BLIPs);
receiving a packet of data at a BLIP; characterized by:
determining whether the packet has been transmitted under TCP/IP protocols; processing non-TCP/IP packets in the manner of a convention bridge; and processing TCP/IP traffic in a manner analogous to a bridge, wherein a message packet received from an extended LAN
segment attached to the BLIP is forwarded if necessary to at least one other extended LAN segment attached to the BLIP.
configuring an extended local area network (LAN) to include a plurality of extended LAN segments connected by bridge-like IP routers (BLIPs);
receiving a packet of data at a BLIP; characterized by:
determining whether the packet has been transmitted under TCP/IP protocols; processing non-TCP/IP packets in the manner of a convention bridge; and processing TCP/IP traffic in a manner analogous to a bridge, wherein a message packet received from an extended LAN
segment attached to the BLIP is forwarded if necessary to at least one other extended LAN segment attached to the BLIP.
9. A method as defined in claim 8, and further comprising:
detecting and discarding ARP messages requesting destination address information;
responding to ARP messages with a special address code when the requested destination address is on a different segment of the same extended LAN as the BLIP; and forwarding a message packet having the special address code, to at least one other attached LAN segment;
whereby a host device may transmit to destinations on other extended LAN segments as though the destinations were on the same LAN.
detecting and discarding ARP messages requesting destination address information;
responding to ARP messages with a special address code when the requested destination address is on a different segment of the same extended LAN as the BLIP; and forwarding a message packet having the special address code, to at least one other attached LAN segment;
whereby a host device may transmit to destinations on other extended LAN segments as though the destinations were on the same LAN.
10. A method as defined in claim 8, and further comprising:
maintaining an IP data base that associates each setment of the extended LAN with a port of the BLIP;
wherein the maintaining step is performed by observing each received message and correlating the segment address for each message source with a port through which the message is received.
maintaining an IP data base that associates each setment of the extended LAN with a port of the BLIP;
wherein the maintaining step is performed by observing each received message and correlating the segment address for each message source with a port through which the message is received.
11. A method as defined in claim 8, and further comprising;
maintaining an ARP database that associates each network layer address in attached extended LAN segments with a corresponding data link layer address;
wherein the maintaining step is performed by sending ARP
messages directed to specific network layer addresses and processing ARP replies that contain the corresponding data link layer addresses.
maintaining an ARP database that associates each network layer address in attached extended LAN segments with a corresponding data link layer address;
wherein the maintaining step is performed by sending ARP
messages directed to specific network layer addresses and processing ARP replies that contain the corresponding data link layer addresses.
12. A method as defined in claim 8, and further comprising:
maintaining a router database containing the data link layer addresses of all true IP routers connected to the extended LAN.
maintaining a router database containing the data link layer addresses of all true IP routers connected to the extended LAN.
13. A method of operation of a configuration of interconnected local area networks (LANs) handling message traffic in accordance with a set of protocols known as TCP/IP, the method comprising the steps of:
configuring an extended local area network (LAN) to include a plurality of extended LAN segments connected by bridge-like IP routers (BLIPs);
receiving a packet of data at a BLIP;
determining whether the packet has been trasmitted under TCP/IP protocols;
processing non-TCP/IP packets in a manner of a conventional bridge;
processing non-TCP/IP traffic in a manner analogous to a bridge, wherein a message packet received from an extended LAN
segment attached to the BLIP is forwarded if necessary to at least one other extended LAN segment attached to the BLIP;
detecting and discarding ARP messages requesting destination address information;
configuring an extended local area network (LAN) to include a plurality of extended LAN segments connected by bridge-like IP routers (BLIPs);
receiving a packet of data at a BLIP;
determining whether the packet has been trans-mitted under the inter-network protocols;
processing packets that were not transmitted under the inter-network protocols in the manner of a conventional bridge, using unique station addresses to determine how to forward the packets; and processing inter-network protocol traffic in a manner analogous to a bridge, wherein a message packet received from an extended LAN segment attached to the BLIP is forwarded if necessary to at least one other extended LAN segment attached to the BLIP, using net-work addresses and network segment addresses, instead of unique station addresses, to determine how to for-ward the packets.
configuring an extended local area network (LAN) to include a plurality of extended LAN segments connected by bridge-like IP routers (BLIPs);
receiving a packet of data at a BLIP;
determining whether the packet has been trasmitted under TCP/IP protocols;
processing non-TCP/IP packets in a manner of a conventional bridge;
processing non-TCP/IP traffic in a manner analogous to a bridge, wherein a message packet received from an extended LAN
segment attached to the BLIP is forwarded if necessary to at least one other extended LAN segment attached to the BLIP;
detecting and discarding ARP messages requesting destination address information;
configuring an extended local area network (LAN) to include a plurality of extended LAN segments connected by bridge-like IP routers (BLIPs);
receiving a packet of data at a BLIP;
determining whether the packet has been trans-mitted under the inter-network protocols;
processing packets that were not transmitted under the inter-network protocols in the manner of a conventional bridge, using unique station addresses to determine how to forward the packets; and processing inter-network protocol traffic in a manner analogous to a bridge, wherein a message packet received from an extended LAN segment attached to the BLIP is forwarded if necessary to at least one other extended LAN segment attached to the BLIP, using net-work addresses and network segment addresses, instead of unique station addresses, to determine how to for-ward the packets.
14. A method as defined in claim 13, and furth-er comprising:
determining whether a received message packet is destined for an attached segment of the extended LAN;
forwarding a packet destined for an attached segment other than the one from which the packet was transmitted, by retaining a data link layer destination address from the ? database; and forwarding a packet destined for a segment un-attached to the BLIP, by transmitting the packet to at least one other segment through a port selected to reach the destination segment.
determining whether a received message packet is destined for an attached segment of the extended LAN;
forwarding a packet destined for an attached segment other than the one from which the packet was transmitted, by retaining a data link layer destination address from the ? database; and forwarding a packet destined for a segment un-attached to the BLIP, by transmitting the packet to at least one other segment through a port selected to reach the destination segment.
15. A method as defined in claim 14 and furth-er comprising:
checking the destination address of every pack-et destined for the same extended LAN segment as the one from which the packet was transmitted; and taking corrective action depending on the data link layer destination address contained in the packet.
checking the destination address of every pack-et destined for the same extended LAN segment as the one from which the packet was transmitted; and taking corrective action depending on the data link layer destination address contained in the packet.
16. A method as defined in claim 15, wherein the step of taking corrective action includes:
discarding the packet if the data link layer destination address matches an entry in the ARP data-base corresponding to an IP destination address con-tained in the packet.
discarding the packet if the data link layer destination address matches an entry in the ARP data-base corresponding to an IP destination address con-tained in the packet.
17. A method as defined in claim 15, wherein the step of taking corrective action includes, if there is no match between the data link layer destination address in the packet and an entry in the ARP database corresponding to an IP destination address contained in the packet:
substituting the ARP database entry for the data link layer destination address in the packet; and sending a redirect message to a source host from which the packet was transmitted.
substituting the ARP database entry for the data link layer destination address in the packet; and sending a redirect message to a source host from which the packet was transmitted.
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US07/546,619 US5309437A (en) | 1990-06-29 | 1990-06-29 | Bridge-like internet protocol router |
US07/546,619 | 1990-06-29 |
Publications (1)
Publication Number | Publication Date |
---|---|
CA2044363A1 true CA2044363A1 (en) | 1991-12-30 |
Family
ID=24181242
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CA002044363A Abandoned CA2044363A1 (en) | 1990-06-29 | 1991-06-11 | Bridge-like internet protocol router |
Country Status (4)
Country | Link |
---|---|
US (1) | US5309437A (en) |
EP (1) | EP0465201B1 (en) |
CA (1) | CA2044363A1 (en) |
DE (1) | DE69122439T2 (en) |
Families Citing this family (272)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5860136A (en) * | 1989-06-16 | 1999-01-12 | Fenner; Peter R. | Method and apparatus for use of associated memory with large key spaces |
GB9107031D0 (en) * | 1991-04-04 | 1991-05-22 | Bicc Plc | Repeaters for digital data networks |
US5420862A (en) * | 1991-06-14 | 1995-05-30 | Digital Equipment Corporation | Router using remote address resolution to enable bridge like data forwarding |
GB9112898D0 (en) * | 1991-06-14 | 1991-07-31 | Digital Equipment Int | Communication networks |
US5500860A (en) * | 1991-06-14 | 1996-03-19 | Digital Equipment Corporation | Router using multiple hop redirect messages to enable bridge like data forwarding |
US6400702B1 (en) * | 1991-10-01 | 2002-06-04 | Intermec Ip Corp. | Radio frequency local area network |
US7006881B1 (en) * | 1991-12-23 | 2006-02-28 | Steven Hoffberg | Media recording device with remote graphic user interface |
US8352400B2 (en) | 1991-12-23 | 2013-01-08 | Hoffberg Steven M | Adaptive pattern recognition based controller apparatus and method and human-factored interface therefore |
US5519858A (en) * | 1992-01-10 | 1996-05-21 | Digital Equipment Corporation | Address recognition engine with look-up database for storing network information |
FR2686755A1 (en) * | 1992-01-28 | 1993-07-30 | Electricite De France | METHOD FOR ENCRYPTING MESSAGES TRANSMITTED BETWEEN INTERCONNECTED NETWORKS, ENCRYPTION APPARATUS AND DEVICE FOR COMMUNICATING ENCRYPTED DATA USING SUCH A METHOD. |
JPH05268223A (en) * | 1992-03-23 | 1993-10-15 | Nec Corp | Router device |
US5742760A (en) * | 1992-05-12 | 1998-04-21 | Compaq Computer Corporation | Network packet switch using shared memory for repeating and bridging packets at media rate |
FI90710C (en) * | 1992-05-29 | 1994-03-10 | Icl Personal Systems Oy | Procedure for Adapting a TCP / IP Software to a Local Area Network to a Remote Connection |
US5490252A (en) * | 1992-09-30 | 1996-02-06 | Bay Networks Group, Inc. | System having central processor for transmitting generic packets to another processor to be altered and transmitting altered packets back to central processor for routing |
US5426637A (en) * | 1992-12-14 | 1995-06-20 | International Business Machines Corporation | Methods and apparatus for interconnecting local area networks with wide area backbone networks |
EP0674790B1 (en) * | 1992-12-21 | 2002-03-13 | Apple Computer, Inc. | Method and apparatus for transforming an arbitrary topology collection of nodes into an acyclic directed graph |
US5619650A (en) * | 1992-12-31 | 1997-04-08 | International Business Machines Corporation | Network processor for transforming a message transported from an I/O channel to a network by adding a message identifier and then converting the message |
US5379296A (en) * | 1992-12-31 | 1995-01-03 | Unisys Corporation | Method and apparatus for interfacing a workstation to a plurality of computer platforms |
EP0622739A1 (en) * | 1993-04-29 | 1994-11-02 | International Business Machines Corporation | System for cascading data switches in a communication node |
JP2520563B2 (en) * | 1993-05-19 | 1996-07-31 | 日本電気株式会社 | Packet switching network |
US5491693A (en) * | 1993-12-30 | 1996-02-13 | International Business Machines Corporation | General transport layer gateway for heterogeneous networks |
US6701370B1 (en) * | 1994-06-08 | 2004-03-02 | Hughes Electronics Corporation | Network system with TCP/IP protocol spoofing |
US5689550A (en) * | 1994-08-08 | 1997-11-18 | Voice-Tel Enterprises, Inc. | Interface enabling voice messaging systems to interact with communications networks |
US5598536A (en) * | 1994-08-09 | 1997-01-28 | Shiva Corporation | Apparatus and method for providing remote users with the same unique IP address upon each network access |
JP3224963B2 (en) * | 1994-08-31 | 2001-11-05 | 株式会社東芝 | Network connection device and packet transfer method |
US5535199A (en) * | 1994-09-06 | 1996-07-09 | Sun Microsystems, Inc. | TCP/IP header compression X.25 networks |
US7373322B1 (en) | 1994-09-20 | 2008-05-13 | Papyrus Technology Corporation | Two-way wireless communication system for financial industry transactions |
US6768981B2 (en) | 1994-09-20 | 2004-07-27 | Papyrus Corporation | Method for executing a cross-trade in a two-way wireless system |
US5797002A (en) | 1994-09-20 | 1998-08-18 | Papyrus Technology Corp. | Two-way wireless system for financial industry transactions |
US5774877A (en) * | 1994-09-20 | 1998-06-30 | Papyrus Technology Corp. | Two-way wireless system for financial industry transactions |
US5530703A (en) * | 1994-09-23 | 1996-06-25 | 3Com Corporation | Remote communication server with automatic filtering |
US6571279B1 (en) * | 1997-12-05 | 2003-05-27 | Pinpoint Incorporated | Location enhanced information delivery system |
US6460036B1 (en) * | 1994-11-29 | 2002-10-01 | Pinpoint Incorporated | System and method for providing customized electronic newspapers and target advertisements |
US5758257A (en) | 1994-11-29 | 1998-05-26 | Herz; Frederick | System and method for scheduling broadcast of and access to video programs and other data using customer profiles |
US5631948A (en) * | 1994-12-05 | 1997-05-20 | Bell Atlantic Network Services, Inc. | Voice mail communication with call blocking |
US6285745B1 (en) | 1994-12-05 | 2001-09-04 | Bell Atlantic Network Services, Inc. | Analog terminal internet access |
US6215858B1 (en) | 1994-12-05 | 2001-04-10 | Bell Atlantic Network Services, Inc. | Analog terminal internet access |
US5661782A (en) * | 1994-12-05 | 1997-08-26 | Bell Atlantic Network Services, Inc. | Voice mail communication with call blocking |
US5812639A (en) * | 1994-12-05 | 1998-09-22 | Bell Atlantic Network Services, Inc. | Message communication via common signaling channel |
US5850518A (en) * | 1994-12-12 | 1998-12-15 | Northrup; Charles J. | Access-method-independent exchange |
CA2139081C (en) * | 1994-12-23 | 1999-02-02 | Alastair Gordon | Unified messaging system and method |
US5544162A (en) * | 1995-01-10 | 1996-08-06 | International Business Machines Corporation | IP bridge for parallel machines |
US5682525A (en) * | 1995-01-11 | 1997-10-28 | Civix Corporation | System and methods for remotely accessing a selected group of items of interest from a database |
US5838683A (en) | 1995-03-13 | 1998-11-17 | Selsius Systems Inc. | Distributed interactive multimedia system architecture |
US5822324A (en) * | 1995-03-16 | 1998-10-13 | Bell Atlantic Network Services, Inc. | Simulcasting digital video programs for broadcast and interactive services |
US5651010A (en) * | 1995-03-16 | 1997-07-22 | Bell Atlantic Network Services, Inc. | Simultaneous overlapping broadcasting of digital programs |
US5867660A (en) * | 1995-05-11 | 1999-02-02 | Bay Networks, Inc. | Method and apparatus for communicating between a network workstation and an internet |
JP2666769B2 (en) * | 1995-05-16 | 1997-10-22 | 日本電気株式会社 | Internet protocol routing method and apparatus |
US5734865A (en) * | 1995-06-07 | 1998-03-31 | Bull Hn Information Systems Inc. | Virtual local area network well-known port routing mechanism for mult--emulators in an open system environment |
US7272639B1 (en) | 1995-06-07 | 2007-09-18 | Soverain Software Llc | Internet server access control and monitoring systems |
US5812776A (en) * | 1995-06-07 | 1998-09-22 | Open Market, Inc. | Method of providing internet pages by mapping telephone number provided by client to URL and returning the same in a redirect command by server |
US6094525A (en) * | 1995-07-06 | 2000-07-25 | Novell, Inc. | Network addressing arrangement for backward compatible routing of an expanded address space |
US6147996A (en) | 1995-08-04 | 2000-11-14 | Cisco Technology, Inc. | Pipelined multiple issue packet switch |
US5757924A (en) * | 1995-09-18 | 1998-05-26 | Digital Secured Networks Techolognies, Inc. | Network security device which performs MAC address translation without affecting the IP address |
US6108704A (en) * | 1995-09-25 | 2000-08-22 | Netspeak Corporation | Point-to-point internet protocol |
US6009469A (en) * | 1995-09-25 | 1999-12-28 | Netspeak Corporation | Graphic user interface for internet telephony application |
US6226678B1 (en) | 1995-09-25 | 2001-05-01 | Netspeak Corporation | Method and apparatus for dynamically defining data communication utilities |
US6185184B1 (en) | 1995-09-25 | 2001-02-06 | Netspeak Corporation | Directory server for providing dynamically assigned network protocol addresses |
US5774670A (en) * | 1995-10-06 | 1998-06-30 | Netscape Communications Corporation | Persistent client state in a hypertext transfer protocol based client-server system |
DK2315398T3 (en) * | 1995-10-11 | 2014-05-05 | Aip Acquisition Llc | Effective communication network |
US5717853A (en) * | 1995-10-23 | 1998-02-10 | International Business Machines Corporation | Information handling system having router including first mode for configuring itself, second mode for configuring its connected devices and third mode for system operation |
US5684800A (en) * | 1995-11-15 | 1997-11-04 | Cabletron Systems, Inc. | Method for establishing restricted broadcast groups in a switched network |
CA2186795A1 (en) * | 1995-11-17 | 1997-05-18 | Cormac John Sreenan | Resource management system for a broadband multipoint bridge |
US5802146A (en) * | 1995-11-22 | 1998-09-01 | Bell Atlantic Network Services, Inc. | Maintenance operations console for an advanced intelligent network |
JP3545858B2 (en) * | 1995-12-01 | 2004-07-21 | 株式会社東芝 | Network connection device and information search device |
US6058429A (en) * | 1995-12-08 | 2000-05-02 | Nortel Networks Corporation | Method and apparatus for forwarding traffic between locality attached networks using level 3 addressing information |
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 |
US5778367A (en) * | 1995-12-14 | 1998-07-07 | Network Engineering Software, Inc. | Automated on-line information service and directory, particularly for the world wide web |
US5884043A (en) * | 1995-12-21 | 1999-03-16 | Cisco Technology, Inc. | Conversion technique for routing frames in a source route bridge network |
JPH09186723A (en) | 1995-12-29 | 1997-07-15 | Hitachi Ltd | Network communication processing 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 |
US5799016A (en) * | 1996-01-11 | 1998-08-25 | U S West, Inc. | Network addressing scheme encoding communication channel information |
US5764756A (en) * | 1996-01-11 | 1998-06-09 | U S West, Inc. | Networked telephony central offices |
JP3684262B2 (en) * | 1996-01-17 | 2005-08-17 | 富士通株式会社 | Network system and line concentrator |
US5781726A (en) * | 1996-01-31 | 1998-07-14 | 3Com Corporation | Management of polling traffic in connection oriented protocol sessions |
US5822523A (en) | 1996-02-01 | 1998-10-13 | Mpath Interactive, Inc. | Server-group messaging system for interactive applications |
US5732213A (en) * | 1996-03-22 | 1998-03-24 | Ericsson Inc. | System and method of testing open systems interconnection (OSI) layers in telecommunication networks |
US9619841B2 (en) | 1996-03-28 | 2017-04-11 | Integrated Claims Systems, Llc | Systems to assist in the creation, transmission, and processing of health insurance claims |
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 |
US6125113A (en) * | 1996-04-18 | 2000-09-26 | Bell Atlantic Network Services, Inc. | Internet telephone service |
US5790548A (en) * | 1996-04-18 | 1998-08-04 | Bell Atlantic Network Services, Inc. | Universal access multimedia data network |
US6438218B1 (en) | 1996-04-18 | 2002-08-20 | Robert D. Farris | Internet telephone service |
EP0895684B1 (en) * | 1996-04-24 | 2001-11-14 | Nortel Networks Limited | Internet protocol filter |
US5917825A (en) * | 1996-05-07 | 1999-06-29 | Rad Network Devices, Ltd. | LAN message routing system |
US6243667B1 (en) | 1996-05-28 | 2001-06-05 | Cisco Systems, Inc. | Network flow switching and flow data export |
US5826023A (en) * | 1996-06-03 | 1998-10-20 | International Business Machines Corporation | Communications tunneling |
US7555458B1 (en) | 1996-06-05 | 2009-06-30 | Fraud Control System.Com Corporation | Method of billing a purchase made over a computer network |
US8229844B2 (en) | 1996-06-05 | 2012-07-24 | Fraud Control Systems.Com Corporation | Method of billing a purchase made over a computer network |
US20030195846A1 (en) | 1996-06-05 | 2003-10-16 | David Felger | Method of billing a purchase made over a computer network |
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 |
US5805820A (en) * | 1996-07-15 | 1998-09-08 | At&T Corp. | Method and apparatus for restricting access to private information in domain name systems by redirecting query requests |
CA2212121C (en) | 1996-08-02 | 2010-03-30 | Symbol Technologies, Inc. | Improvements in data retrieval |
US5909638A (en) * | 1996-08-06 | 1999-06-01 | Maximum Video Systems, Inc. | High speed video distribution and manufacturing system |
US6023563A (en) * | 1996-08-20 | 2000-02-08 | Shani; Ron | Networking switch having the network presence of a bridge |
US5958015A (en) * | 1996-10-29 | 1999-09-28 | Abirnet Ltd. | Network session wall passively listening to communication session, with use of access rules, stops further communication between network devices by emulating messages to the devices |
US5708654A (en) * | 1996-11-27 | 1998-01-13 | Arndt; Manfred R. | Method for detecting proxy ARP replies from devices in a local area network |
JP3638742B2 (en) * | 1996-11-29 | 2005-04-13 | アンリツ株式会社 | Router |
US6145004A (en) * | 1996-12-02 | 2000-11-07 | Walsh; Stephen Kelly | Intranet network system |
US6078582A (en) | 1996-12-18 | 2000-06-20 | Bell Atlantic Network Services, Inc. | Internet long distance telephone service |
US5878232A (en) * | 1996-12-27 | 1999-03-02 | Compaq Computer Corporation | Dynamic reconfiguration of network device's virtual LANs using the root identifiers and root ports determined by a spanning tree procedure |
US6240513B1 (en) * | 1997-01-03 | 2001-05-29 | Fortress Technologies, Inc. | Network security device |
US6064653A (en) * | 1997-01-07 | 2000-05-16 | Bell Atlantic Network Services, Inc. | Internetwork gateway to gateway alternative communication |
US7020700B1 (en) | 1997-02-28 | 2006-03-28 | International Business Machines Corporation | Client side socks server for an internet client |
JPH10242990A (en) | 1997-02-28 | 1998-09-11 | Nec Commun Syst Ltd | Communication system for lec bridge device |
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 |
US6097719A (en) * | 1997-03-11 | 2000-08-01 | Bell Atlantic Network Services, Inc. | Public IP transport network |
JP3579208B2 (en) * | 1997-03-11 | 2004-10-20 | 株式会社東芝 | Node device and message exchange method |
US6084892A (en) * | 1997-03-11 | 2000-07-04 | Bell Atlantic Networks Services, Inc. | Public IP transport network |
US6650631B1 (en) | 1997-03-11 | 2003-11-18 | Verizon Services Corp. | Public IP transport network |
US5933490A (en) * | 1997-03-12 | 1999-08-03 | Bell Atlantic Network Services, Inc. | Overload protection for on-demand access to the internet that redirects calls from overloaded internet service provider (ISP) to alternate internet access provider |
US6130892A (en) * | 1997-03-12 | 2000-10-10 | Nomadix, Inc. | Nomadic translator or router |
ATE367701T1 (en) | 1997-03-12 | 2007-08-15 | Nomadix Inc | NOMADIC TRANSLATOR OR PATH FINDER |
US6292479B1 (en) | 1997-03-19 | 2001-09-18 | Bell Atlantic Network Services, Inc. | Transport of caller identification information through diverse communication networks |
US6870827B1 (en) | 1997-03-19 | 2005-03-22 | Verizon Services Corp. | Voice call alternative routing through PSTN and internet networks |
US6657999B1 (en) * | 1997-03-31 | 2003-12-02 | Texas Instruments Incorporated | Link layer gateway computer for interconnecting ethernet and 1394 networks |
US6359882B1 (en) | 1997-04-01 | 2002-03-19 | Yipes Communications, Inc. | Method and apparatus for transmitting data |
US6282172B1 (en) | 1997-04-01 | 2001-08-28 | Yipes Communications, Inc. | Generating acknowledgement signals in a data communication system |
EP0974218A4 (en) * | 1997-04-09 | 2005-04-13 | Alcatel Australia | Internet closed user group |
US7251784B2 (en) * | 1997-04-25 | 2007-07-31 | Winslowhouse International, Inc. | Supplying supplementary information for printed books |
US6034680A (en) * | 1997-04-25 | 2000-03-07 | Foundation For Concepts In Education, Inc. | Supplying supplementary information for printed books |
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 |
US6118760A (en) * | 1997-06-30 | 2000-09-12 | Sun Microsystems, Inc. | Management of entries in a network element forwarding memory |
US5938736A (en) * | 1997-06-30 | 1999-08-17 | Sun Microsystems, Inc. | Search engine architecture for a high performance multi-layer switch element |
US6052738A (en) * | 1997-06-30 | 2000-04-18 | Sun Microsystems, Inc. | Method and apparatus in a packet routing switch for controlling access at different data rates to a shared memory |
US6016310A (en) * | 1997-06-30 | 2000-01-18 | Sun Microsystems, Inc. | Trunking support in a high performance network device |
US6014380A (en) * | 1997-06-30 | 2000-01-11 | Sun Microsystems, Inc. | Mechanism for packet field replacement in a multi-layer distributed network element |
US6081522A (en) * | 1997-06-30 | 2000-06-27 | Sun Microsystems, Inc. | System and method for a multi-layer network element |
US6049528A (en) * | 1997-06-30 | 2000-04-11 | Sun Microsystems, Inc. | Trunking ethernet-compatible networks |
US6115378A (en) * | 1997-06-30 | 2000-09-05 | Sun Microsystems, Inc. | Multi-layer distributed network element |
US6088356A (en) * | 1997-06-30 | 2000-07-11 | Sun Microsystems, Inc. | System and method for a multi-layer network element |
US6128666A (en) * | 1997-06-30 | 2000-10-03 | Sun Microsystems, Inc. | Distributed VLAN mechanism for packet field replacement in a multi-layered switched network element using a control field/signal for indicating modification of a packet with a database search engine |
US6081512A (en) * | 1997-06-30 | 2000-06-27 | Sun Microsystems, Inc. | Spanning tree support in a high performance network device |
US6021132A (en) * | 1997-06-30 | 2000-02-01 | Sun Microsystems, Inc. | Shared memory management in a switched network element |
US6044418A (en) * | 1997-06-30 | 2000-03-28 | Sun Microsystems, Inc. | Method and apparatus for dynamically resizing queues utilizing programmable partition pointers |
US6246680B1 (en) | 1997-06-30 | 2001-06-12 | Sun Microsystems, Inc. | Highly integrated multi-layer switch element architecture |
US5920566A (en) * | 1997-06-30 | 1999-07-06 | Sun Microsystems, Inc. | Routing in a multi-layer distributed network element |
US6119196A (en) * | 1997-06-30 | 2000-09-12 | Sun Microsystems, Inc. | System having multiple arbitrating levels for arbitrating access to a shared memory by network ports operating at different data rates |
US5909686A (en) * | 1997-06-30 | 1999-06-01 | Sun Microsystems, Inc. | Hardware-assisted central processing unit access to a forwarding database |
US6044087A (en) * | 1997-06-30 | 2000-03-28 | Sun Microsystems, Inc. | Interface for a highly integrated ethernet network element |
US6094435A (en) * | 1997-06-30 | 2000-07-25 | Sun Microsystems, Inc. | System and method for a quality of service in a multi-layer network element |
US5958016A (en) * | 1997-07-13 | 1999-09-28 | Bell Atlantic Network Services, Inc. | Internet-web link for access to intelligent network service control |
US6078590A (en) * | 1997-07-14 | 2000-06-20 | Cisco Technology, Inc. | Hierarchical routing knowledge for multicast packet routing |
US6055364A (en) | 1997-07-31 | 2000-04-25 | Cisco Technology, Inc. | Content-based filtering of multicast information |
US6330599B1 (en) | 1997-08-05 | 2001-12-11 | Cisco Technology, Inc. | Virtual interfaces with dynamic binding |
US6157641A (en) | 1997-08-22 | 2000-12-05 | Cisco Technology, Inc. | Multiprotocol packet recognition and switching |
US6212183B1 (en) | 1997-08-22 | 2001-04-03 | Cisco Technology, Inc. | Multiple parallel packet routing lookup |
US6512766B2 (en) | 1997-08-22 | 2003-01-28 | Cisco Systems, Inc. | Enhanced internet packet routing lookup |
US6343072B1 (en) | 1997-10-01 | 2002-01-29 | Cisco Technology, Inc. | Single-chip architecture for shared-memory router |
US6026093A (en) * | 1997-10-02 | 2000-02-15 | Sun Microsystems, Inc. | Mechanism for dispatching data units via a telecommunications network |
US6473425B1 (en) | 1997-10-02 | 2002-10-29 | Sun Microsystems, Inc. | Mechanism for dispatching packets via a telecommunications network |
US6172981B1 (en) | 1997-10-30 | 2001-01-09 | International Business Machines Corporation | Method and system for distributing network routing functions to local area network stations |
US6252880B1 (en) * | 1997-11-10 | 2001-06-26 | Advanced Micro Devices, Inc. | Apparatus and method for selectively supplying a data packet to a selected network node in a buffered distributor |
US7570583B2 (en) * | 1997-12-05 | 2009-08-04 | Cisco Technology, Inc. | Extending SONET/SDH automatic protection switching |
US6249530B1 (en) | 1997-12-22 | 2001-06-19 | Sun Microsystems, Inc. | Network bandwidth control |
US6188694B1 (en) * | 1997-12-23 | 2001-02-13 | Cisco Technology, Inc. | Shared spanning tree protocol |
US6111877A (en) * | 1997-12-31 | 2000-08-29 | Cisco Technology, Inc. | Load sharing across flows |
US6424649B1 (en) | 1997-12-31 | 2002-07-23 | Cisco Technology, Inc. | Synchronous pipelined switch using serial transmission |
US9900305B2 (en) * | 1998-01-12 | 2018-02-20 | Soverain Ip, Llc | Internet server access control and monitoring systems |
US7411916B2 (en) * | 1998-02-26 | 2008-08-12 | Nortel Networks Limited | Data forwarding method and apparatus |
DE19809398A1 (en) * | 1998-03-05 | 1999-09-09 | Sel Verteidigungssysteme Gmbh | Common operation of a number of military communication systems |
US6853638B2 (en) * | 1998-04-01 | 2005-02-08 | Cisco Technology, Inc. | Route/service processor scalability via flow-based distribution of traffic |
US6876654B1 (en) | 1998-04-10 | 2005-04-05 | Intel Corporation | Method and apparatus for multiprotocol switching and routing |
US6049834A (en) * | 1998-05-08 | 2000-04-11 | Cisco Technology, Inc. | Layer 3 switch unicast protocol |
GB9810843D0 (en) | 1998-05-21 | 1998-07-22 | 3Com Technologies Ltd | Method for storing data in network devices |
US6603769B1 (en) | 1998-05-28 | 2003-08-05 | Cisco Technology, Inc. | Method and system for improving traffic operation in an internet environment |
US6445691B2 (en) * | 1998-06-08 | 2002-09-03 | Koninklijke Philips Electronics N. V. | Wireless coupling of standardized networks and non-standardized nodes |
US6445690B2 (en) * | 1998-06-08 | 2002-09-03 | Koninklijke Philips Electronics N.V. | Wireless coupling of incompatible nodes via a virtual network |
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 |
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 |
EP0978977A1 (en) | 1998-08-07 | 2000-02-09 | International Business Machines Corporation | A method and system for improving high speed internetwork data transfers |
US6389506B1 (en) | 1998-08-07 | 2002-05-14 | Cisco Technology, Inc. | Block mask ternary cam |
US6256314B1 (en) * | 1998-08-11 | 2001-07-03 | Avaya Technology Corp. | Apparatus and methods for routerless layer 3 forwarding in a network |
DE69934192T2 (en) | 1998-10-27 | 2007-08-30 | Hewlett-Packard Development Co., L.P., Houston | Method and device for network connection by means of bridges |
EP0998081B1 (en) * | 1998-10-27 | 2006-11-29 | Hewlett-Packard Company, A Delaware Corporation | Method and apparatus for bridging between networks |
US6330229B1 (en) * | 1998-11-09 | 2001-12-11 | 3Com Corporation | Spanning tree with rapid forwarding database updates |
GB9824594D0 (en) | 1998-11-11 | 1999-01-06 | 3Com Technologies Ltd | Modifying tag fields in ethernet data packets |
GB2344030B (en) | 1998-11-17 | 2003-06-04 | 3Com Technologies Ltd | Credit-based scheme for high performance communication between devices in a packet-based communication system |
US6657951B1 (en) | 1998-11-30 | 2003-12-02 | Cisco Technology, Inc. | Backup CRF VLAN |
US6674727B1 (en) | 1998-11-30 | 2004-01-06 | Cisco Technology, Inc. | Distributed ring protocol and database |
US6563832B1 (en) | 1998-11-30 | 2003-05-13 | Cisco Technology, Inc. | Token ring bridge distributed in a switched fabric |
US6704318B1 (en) | 1998-11-30 | 2004-03-09 | Cisco Technology, Inc. | Switched token ring over ISL (TR-ISL) network |
US7194554B1 (en) | 1998-12-08 | 2007-03-20 | Nomadix, Inc. | Systems and methods for providing dynamic network authorization authentication and accounting |
US8266266B2 (en) | 1998-12-08 | 2012-09-11 | Nomadix, Inc. | Systems and methods for providing dynamic network authorization, authentication and accounting |
US8713641B1 (en) | 1998-12-08 | 2014-04-29 | Nomadix, Inc. | Systems and methods for authorizing, authenticating and accounting users having transparent computer access to a network using a gateway device |
US6898189B1 (en) | 2000-08-23 | 2005-05-24 | Cisco Technology, Inc. | Restartable spanning tree for high availability network systems |
EP1142227A2 (en) * | 1998-12-23 | 2001-10-10 | Nokia Wireless Routers, Inc. | A unified routing scheme for ad-hoc internetworking |
US6609153B1 (en) * | 1998-12-24 | 2003-08-19 | Redback Networks Inc. | Domain isolation through virtual network machines |
US7216348B1 (en) | 1999-01-05 | 2007-05-08 | Net2Phone, Inc. | Method and apparatus for dynamically balancing call flow workloads in a telecommunications system |
US6771642B1 (en) | 1999-01-08 | 2004-08-03 | Cisco Technology, Inc. | Method and apparatus for scheduling packets in a packet switch |
US6611502B1 (en) | 1999-01-15 | 2003-08-26 | 3Com Corportion | Spanning tree with rapid propagation of topology changes |
US6771610B1 (en) | 1999-01-19 | 2004-08-03 | 3Com Corporation | Spanning tree with protocol for bypassing port state transition timers |
US7904187B2 (en) | 1999-02-01 | 2011-03-08 | Hoffberg Steven M | Internet appliance system and method |
JP3082760B1 (en) * | 1999-02-26 | 2000-08-28 | 日本電気株式会社 | MPOA packet transfer method |
US6535490B1 (en) * | 1999-03-04 | 2003-03-18 | 3Com Corporation | High availability spanning tree with rapid reconfiguration with alternate port selection |
US6850518B1 (en) | 1999-03-04 | 2005-02-01 | Cisco Technology, Inc. | DLSw RIF passthru technique for providing end-to-end source route information to end stations of a data link switching network |
US7065762B1 (en) | 1999-03-22 | 2006-06-20 | Cisco Technology, Inc. | Method, apparatus and computer program product for borrowed-virtual-time scheduling |
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 |
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 |
US6667967B1 (en) | 1999-05-14 | 2003-12-23 | Omninet Capital, Llc | High-speed network of independently linked nodes |
US6714541B1 (en) | 1999-08-10 | 2004-03-30 | Cisco Technology, Inc. | Method and apparatus for encoding bridging/switching information within a routing information filed in a token ring environment |
US6836463B2 (en) | 1999-10-15 | 2004-12-28 | Nokia Corporation | System for communicating labeled routing trees to establish preferred paths and source routes with local identifiers in wireless computer networks |
US6857009B1 (en) | 1999-10-22 | 2005-02-15 | Nomadix, Inc. | System and method for network access without reconfiguration |
US7630986B1 (en) * | 1999-10-27 | 2009-12-08 | Pinpoint, Incorporated | Secure data interchange |
US6771649B1 (en) * | 1999-12-06 | 2004-08-03 | At&T Corp. | Middle approach to asynchronous and backward-compatible detection and prevention of ARP cache poisoning |
US7007080B2 (en) | 1999-12-23 | 2006-02-28 | Solution Inc Limited | System for reconfiguring and registering a new IP address for a computer to access a different network without user intervention |
US6493341B1 (en) | 1999-12-31 | 2002-12-10 | Ragula Systems | Combining routers to increase concurrency and redundancy in external network access |
US6295276B1 (en) | 1999-12-31 | 2001-09-25 | Ragula Systems | Combining routers to increase concurrency and redundancy in external network access |
US6931003B2 (en) * | 2000-02-09 | 2005-08-16 | Bookline Flolmstead Llc | Packet prioritization protocol for a large-scale, high speed computer network |
US6922663B1 (en) | 2000-03-02 | 2005-07-26 | International Business Machines Corporation | Intelligent workstation simulation-client virtualization |
US6407341B1 (en) | 2000-04-25 | 2002-06-18 | International Business Machines Corporation | Conductive substructures of a multilayered laminate |
GB2362289B (en) | 2000-05-10 | 2002-04-03 | 3Com Corp | Distributed multicast routing in packet-based communication network devices |
JP3538119B2 (en) * | 2000-05-25 | 2004-06-14 | 日本電気株式会社 | Network connection device |
US6778540B1 (en) * | 2000-05-31 | 2004-08-17 | International Business Machines Corporation | Facility for forwarding data from a network adapter to a router partition without internet protocol (ip) processing |
US6807176B1 (en) * | 2000-07-13 | 2004-10-19 | Advanced Micro Devices, Inc. | Arrangement for switching data packets in a network switch based on subnet identifier |
US6920497B1 (en) | 2000-07-31 | 2005-07-19 | The Boeing Company | Contacting a broadcast channel |
US6732147B1 (en) | 2000-07-31 | 2004-05-04 | The Boeing Company | Leaving a broadcast channel |
US6829634B1 (en) | 2000-07-31 | 2004-12-07 | The Boeing Company | Broadcasting network |
US6910069B1 (en) | 2000-07-31 | 2005-06-21 | The Boeing Company | Joining a broadcast channel |
US6701344B1 (en) | 2000-07-31 | 2004-03-02 | The Boeing Company | Distributed game environment |
US6714966B1 (en) | 2000-07-31 | 2004-03-30 | The Boeing Company | Information delivery service |
EP1330721A4 (en) * | 2000-08-24 | 2009-08-19 | 2Wire Inc | System and method for selectively bridging and routing data packets between multiple networks |
US7149216B1 (en) | 2000-09-05 | 2006-12-12 | Cisco Technology, Inc. | M-trie based packet processing |
US6820120B1 (en) * | 2000-09-15 | 2004-11-16 | Nortel Networks Limited | Routing of data packets in heterogeneous networks |
FR2814883A1 (en) * | 2000-10-03 | 2002-04-05 | Canon Kk | METHOD AND DEVICE FOR DECLARING AND MODIFYING THE FUNCTIONALITY OF A NODE IN A COMMUNICATION NETWORK |
US7218632B1 (en) | 2000-12-06 | 2007-05-15 | Cisco Technology, Inc. | Packet processing engine architecture |
US6615221B2 (en) * | 2001-03-09 | 2003-09-02 | Hewlett-Packard Development Company, Lp. | Scalable transport layer protocol for multiprocessor interconnection networks that tolerates interconnection component failure |
JP4647825B2 (en) * | 2001-04-27 | 2011-03-09 | 富士通セミコンダクター株式会社 | Packet transmission / reception system, host, and program |
US7155537B1 (en) * | 2001-09-27 | 2006-12-26 | Lsi Logic Corporation | Infiniband isolation bridge merged with architecture of an infiniband translation bridge |
US7013347B1 (en) * | 2001-10-16 | 2006-03-14 | Cisco Technology, Inc. | Distance vector extension to the address resolution protocol |
US7389359B2 (en) * | 2001-10-19 | 2008-06-17 | Foundry Networks, Inc. | Method and system for intelligently forwarding multicast packets |
US7065047B2 (en) * | 2001-10-22 | 2006-06-20 | Pctel, Inc. | System and method of providing computer networking |
US8045565B1 (en) | 2001-11-20 | 2011-10-25 | Brookline Flolmstead Llc | Method and apparatus for an environmentally hardened ethernet network system |
US7403475B1 (en) * | 2002-02-11 | 2008-07-22 | Utstarcom, Inc. | Method and apparatus for allocating data packet pathways |
US8780770B2 (en) | 2002-05-13 | 2014-07-15 | Misonimo Chi Acquisition L.L.C. | Systems and methods for voice and video communication over a wireless network |
US7957356B2 (en) * | 2002-05-13 | 2011-06-07 | Misomino Chi Acquisitions L.L.C. | Scalable media access control for multi-hop high bandwidth communications |
US7941149B2 (en) | 2002-05-13 | 2011-05-10 | Misonimo Chi Acquistion L.L.C. | Multi-hop ultra wide band wireless network communication |
US7835372B2 (en) * | 2002-05-13 | 2010-11-16 | Weilin Wang | System and method for transparent wireless bridging of communication channel segments |
US7386605B2 (en) * | 2002-11-05 | 2008-06-10 | Enterasys Networks, Inc. | Methods and apparatus for automated edge device configuration in a heterogeneous network |
US7778999B1 (en) | 2003-01-24 | 2010-08-17 | Bsecure Technologies, Inc. | Systems and methods for multi-layered packet filtering and remote management of network devices |
US7415028B1 (en) * | 2003-02-11 | 2008-08-19 | Network Equipment Technologies, Inc. | Method and system for optimizing routing table changes due to ARP cache invalidation in routers with split plane architecture |
FR2852176B1 (en) * | 2003-03-04 | 2005-05-27 | DEVICE AND METHOD FOR INTERCONNECTING BETWEEN COMPUTER STATIONS COMMUNICATING THROUGH A SHARED MEDIUM | |
US7564842B2 (en) | 2003-07-02 | 2009-07-21 | Mitsubishi Electric Research Laboratories, Inc. | Methods and apparatuses for routing data in a personal area network |
US20050013261A1 (en) * | 2003-07-18 | 2005-01-20 | Seaman Michael John | Reducing address learning in virtual bridged local area networks |
US7339900B2 (en) * | 2003-09-26 | 2008-03-04 | Sun Microsystem, Inc. | Method and apparatus for preventing spanning tree loops during traffic overload conditions |
US20050197860A1 (en) * | 2004-02-23 | 2005-09-08 | Rademr, Inc. | Data management system |
US7697545B1 (en) * | 2004-07-14 | 2010-04-13 | Computer Associates Think, Inc. | Discovery of component relationships in distributed data processing networks |
US7450527B2 (en) | 2004-11-23 | 2008-11-11 | Nortel Networks Limited | Method and apparatus for implementing multiple portals into an Rbridge network |
US7460542B2 (en) * | 2004-12-13 | 2008-12-02 | Alcatel Lucent | Tagging rules for hybrid ports |
US7716472B2 (en) | 2005-12-29 | 2010-05-11 | Bsecure Technologies, Inc. | Method and system for transparent bridging and bi-directional management of network data |
US8175613B2 (en) * | 2006-08-04 | 2012-05-08 | Misonimo Chi Acquisitions L.L.C. | Systems and methods for determining location of devices within a wireless network |
US7636352B2 (en) * | 2006-08-22 | 2009-12-22 | Vitesse Semiconductor Corporation | Maintaining filtering database consistency |
US7971054B1 (en) * | 2006-09-19 | 2011-06-28 | Bsecure Technologies, Inc. | Method of and system for real-time form and content classification of data streams for filtering applications |
KR101102719B1 (en) * | 2006-12-07 | 2012-01-05 | 미소니모 카이 액퀴지션 엘엘씨 | System and method for timeslot and channel allocation |
JP5012553B2 (en) * | 2008-02-15 | 2012-08-29 | 富士通株式会社 | Frame relay apparatus, route learning program, and route learning method |
US8238538B2 (en) | 2009-05-28 | 2012-08-07 | Comcast Cable Communications, Llc | Stateful home phone service |
US8625427B1 (en) | 2009-09-03 | 2014-01-07 | Brocade Communications Systems, Inc. | Multi-path switching with edge-to-edge flow control |
US8650495B2 (en) | 2011-03-21 | 2014-02-11 | Guest Tek Interactive Entertainment Ltd. | Captive portal that modifies content retrieved from designated web page to specify base domain for relative link and sends to client in response to request from client for unauthorized web page |
US9137281B2 (en) | 2012-06-22 | 2015-09-15 | Guest Tek Interactive Entertainment Ltd. | Dynamically enabling guest device supporting network-based media sharing protocol to share media content over local area computer network of lodging establishment with subset of in-room media devices connected thereto |
US9455948B2 (en) * | 2012-06-29 | 2016-09-27 | Cisco Technology, Inc. | Reducing proliferation of network-to-link-layer address resolution messages |
US9065677B2 (en) * | 2012-07-25 | 2015-06-23 | Qualcomm Incorporated | Forwarding tables for hybrid communication networks |
US8862772B2 (en) * | 2012-10-09 | 2014-10-14 | Cisco Technology, Inc. | System and method for implementing a multilevel data center fabric in a network environment |
US9178861B2 (en) | 2012-10-16 | 2015-11-03 | Guest Tek Interactive Entertainment Ltd. | Off-site user access control |
CA2851709A1 (en) | 2013-05-16 | 2014-11-16 | Peter S. Warrick | Dns-based captive portal with integrated transparent proxy to protect against user device caching incorrect ip address |
Family Cites Families (15)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP0097351A3 (en) * | 1982-06-21 | 1986-02-26 | Nec Corporation | Router unit and routing network for determining an output port by detecting a part of an input packet |
US4597078A (en) * | 1983-10-19 | 1986-06-24 | Digital Equipment Corporation | Bridge circuit for interconnecting networks |
GB8407102D0 (en) * | 1984-03-19 | 1984-04-26 | Int Computers Ltd | Interconnection of communications networks |
US4706081A (en) * | 1984-12-14 | 1987-11-10 | Vitalink Communications Corporation | Method and apparatus for bridging local area networks |
US4706080A (en) * | 1985-08-26 | 1987-11-10 | Bell Communications Research, Inc. | Interconnection of broadcast networks |
US4707827A (en) * | 1986-03-21 | 1987-11-17 | Zenith Electronics Corporation | Bridging techniques for local area networks |
US4780873A (en) * | 1986-05-19 | 1988-10-25 | General Electric Company | Circuit switching network with routing nodes |
US4831620A (en) * | 1986-07-28 | 1989-05-16 | Bull Hn Information Systems Inc. | Controller for controlling multiple LAN types |
US4737953A (en) * | 1986-08-04 | 1988-04-12 | General Electric Company | Local area network bridge |
JPH0793634B2 (en) * | 1986-11-29 | 1995-10-09 | 株式会社東芝 | Bus adapter with address conversion function |
US4797881A (en) * | 1987-03-12 | 1989-01-10 | Sytek, Inc. | Bridge system for connecting networks |
US4811337A (en) * | 1988-01-15 | 1989-03-07 | Vitalink Communications Corporation | Distributed load sharing |
US5018137A (en) * | 1988-06-27 | 1991-05-21 | Digital Equipment Corporation | Transparent load sharing for parallel networks |
US5060228A (en) * | 1988-11-19 | 1991-10-22 | Fujitsu Limited | Bridge communication system |
US5058109A (en) * | 1989-06-28 | 1991-10-15 | Digital Equipment Corporation | Exclusionary network adapter apparatus and related method |
-
1990
- 1990-06-29 US US07/546,619 patent/US5309437A/en not_active Expired - Lifetime
-
1991
- 1991-06-11 CA CA002044363A patent/CA2044363A1/en not_active Abandoned
- 1991-07-01 EP EP91305968A patent/EP0465201B1/en not_active Expired - Lifetime
- 1991-07-01 DE DE69122439T patent/DE69122439T2/en not_active Expired - Fee Related
Also Published As
Publication number | Publication date |
---|---|
US5309437A (en) | 1994-05-03 |
EP0465201A2 (en) | 1992-01-08 |
EP0465201B1 (en) | 1996-10-02 |
DE69122439D1 (en) | 1996-11-07 |
DE69122439T2 (en) | 1997-05-15 |
EP0465201A3 (en) | 1992-06-03 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
EP0465201B1 (en) | Bridge-like internet protocol router | |
US6023563A (en) | Networking switch having the network presence of a bridge | |
US5574860A (en) | Method of neighbor discovery over a multiaccess nonbroadcast medium | |
EP0663746B1 (en) | Method and system for routing path determination for mobile workstations in a multisegment local area network | |
US7359394B2 (en) | Method and apparatus for bridging between networks | |
US6157647A (en) | Direct addressing between VLAN subnets | |
JP3483561B2 (en) | Reverse address determination system for remote network equipment | |
US6212191B1 (en) | Method and system for providing security to asynchronous transfer mode emulated local-area networks | |
US7474660B1 (en) | MAC address extension to maintain router information in source routed computer networks | |
Cisco | Command Summary | |
Cisco | Command Summary | |
Cisco | Command Summary | |
Cisco | Command Summary | |
Cisco | Command Summary | |
Cisco | Command Summary | |
Cisco | Command Summary | |
Cisco | Command Summary | |
Cisco | Command Summary | |
Cisco | Command Summary | |
Cisco | Configuring Transparent Bridging | |
Cisco | Configuring Transparent Bridging | |
Cisco | Configuring Transparent Bridging | |
Cisco | Configuring Transparent Bridging | |
Cisco | Configuring Transparent Bridging | |
Cisco | Configuring Transparent Bridging |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
EEER | Examination request | ||
FZDE | Discontinued |