GB2170079A - Method and apparatus for bridging local area networks - Google Patents
Method and apparatus for bridging local area networks Download PDFInfo
- Publication number
 - GB2170079A GB2170079A GB08530600A GB8530600A GB2170079A GB 2170079 A GB2170079 A GB 2170079A GB 08530600 A GB08530600 A GB 08530600A GB 8530600 A GB8530600 A GB 8530600A GB 2170079 A GB2170079 A GB 2170079A
 - Authority
 - GB
 - United Kingdom
 - Prior art keywords
 - network
 - frame
 - bridge
 - local area
 - lan
 - 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.)
 - Granted
 
Links
- 238000000034 method Methods 0.000 title claims description 161
 - 230000008569 process Effects 0.000 claims description 132
 - 230000006870 function Effects 0.000 claims description 95
 - 238000005538 encapsulation Methods 0.000 claims description 71
 - 108091006146 Channels Proteins 0.000 claims description 58
 - 238000004891 communication Methods 0.000 claims description 38
 - 230000006854 communication Effects 0.000 claims description 38
 - 230000005540 biological transmission Effects 0.000 claims description 6
 - 230000004044 response Effects 0.000 claims description 5
 - 229920000136 polysorbate Polymers 0.000 claims description 2
 - 238000009960 carding Methods 0.000 claims 1
 - 238000007726 management method Methods 0.000 description 59
 - 238000012545 processing Methods 0.000 description 23
 - 238000012423 maintenance Methods 0.000 description 12
 - 238000013519 translation Methods 0.000 description 10
 - 230000014616 translation Effects 0.000 description 10
 - 230000001419 dependent effect Effects 0.000 description 9
 - 238000013461 design Methods 0.000 description 9
 - 238000001914 filtration Methods 0.000 description 9
 - 239000008186 active pharmaceutical agent Substances 0.000 description 7
 - 230000000694 effects Effects 0.000 description 5
 - 101100110009 Caenorhabditis elegans asd-2 gene Proteins 0.000 description 4
 - 230000032683 aging Effects 0.000 description 4
 - 230000008859 change Effects 0.000 description 4
 - 238000001514 detection method Methods 0.000 description 4
 - 230000008093 supporting effect Effects 0.000 description 4
 - 241000220300 Eupsilia transversa Species 0.000 description 3
 - 230000001934 delay Effects 0.000 description 3
 - 230000003466 anti-cipated effect Effects 0.000 description 2
 - 150000001768 cations Chemical class 0.000 description 2
 - 230000009977 dual effect Effects 0.000 description 2
 - 238000005516 engineering process Methods 0.000 description 2
 - 239000003292 glue Substances 0.000 description 2
 - 238000009434 installation Methods 0.000 description 2
 - 230000007246 mechanism Effects 0.000 description 2
 - 241000905957 Channa melasoma Species 0.000 description 1
 - 235000008694 Humulus lupulus Nutrition 0.000 description 1
 - 101100172132 Mus musculus Eif3a gene Proteins 0.000 description 1
 - 241000220324 Pyrus Species 0.000 description 1
 - 230000009471 action Effects 0.000 description 1
 - 230000002730 additional effect Effects 0.000 description 1
 - 230000004075 alteration Effects 0.000 description 1
 - 238000010420 art technique Methods 0.000 description 1
 - 230000006399 behavior Effects 0.000 description 1
 - 238000011161 development Methods 0.000 description 1
 - 230000018109 developmental process Effects 0.000 description 1
 - 238000010586 diagram Methods 0.000 description 1
 - 239000000835 fiber Substances 0.000 description 1
 - 230000003455 independent Effects 0.000 description 1
 - 230000002452 interceptive effect Effects 0.000 description 1
 - 230000007775 late Effects 0.000 description 1
 - 230000004048 modification Effects 0.000 description 1
 - 238000012986 modification Methods 0.000 description 1
 - COCAUCFPFHUGAA-MGNBDDOMSA-N n-[3-[(1s,7s)-5-amino-4-thia-6-azabicyclo[5.1.0]oct-5-en-7-yl]-4-fluorophenyl]-5-chloropyridine-2-carboxamide Chemical compound C=1C=C(F)C([C@@]23N=C(SCC[C@@H]2C3)N)=CC=1NC(=O)C1=CC=C(Cl)C=N1 COCAUCFPFHUGAA-MGNBDDOMSA-N 0.000 description 1
 - 230000006855 networking Effects 0.000 description 1
 - 230000008520 organization Effects 0.000 description 1
 - 235000021017 pears Nutrition 0.000 description 1
 - 230000009467 reduction Effects 0.000 description 1
 - 230000009466 transformation Effects 0.000 description 1
 - XLYOFNOQVPJJNP-UHFFFAOYSA-N water Substances O XLYOFNOQVPJJNP-UHFFFAOYSA-N 0.000 description 1
 
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
 
 - 
        
- H—ELECTRICITY
 - H04—ELECTRIC COMMUNICATION TECHNIQUE
 - H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
 - H04L45/00—Routing or path finding of packets in data switching networks
 - H04L45/74—Address processing for routing
 - H04L45/745—Address table lookup; Address filtering
 
 
Landscapes
- Engineering & Computer Science (AREA)
 - Computer Networks & Wireless Communication (AREA)
 - Signal Processing (AREA)
 - Small-Scale Networks (AREA)
 - Data Exchanges In Wide-Area Networks (AREA)
 
Description
1 GB 2 170 079 A 1 
    SPECIFICATION 
    Method and apparatus for bridging local area networks Background of the invention: 5 
    This invention relates to methods and apparatus for bridging together local area networks. 
    This invention relates particularly to a communication system for interconnecting multiple local area networks across broadcast simplex channels independently and transparently of protocols above the data link layer so that the system appears to a user at a station in a local area network as one large single network. 10 Ethernet networks and/or 802.3 Local Area Networks (LAN's) are being installed in conjunction with a wide variety of office automation and data communication products. The LAN's are used to interconnect a number of products which use various network architectures (e.g.TCP/IP, XNS, DeCnet, etc.). As addi tional LAN's are installed in other locations the need to link together the remote LAN's is often initially ignored. Then, when interconnect options for interconnecting the remote LAN's are investigated, it often 15 becomes apparent that the simple, multipurpose data highway environment (that exists within a building or a single LAN) has disappeared. 
    Connecting a number of remote LAN's can present problems in software and can also present prob lems in complex multi-vendor compatibility. The architecture for interconnection can also become an is sue. Redundant configurations for different internet protocols may be required, and some of the LAN 20 stations may not support an internet implementation. 
    Summary of the present invention: 
    It is a primary object of the present invention to interconnect multiple Local Area Networks by a com munications system which avoids problems presented by prior art techniques. 25 
    It is a specific object of the present invention to connect more than two Local Area Networks across simplex channels through a bridge and to provide communication between stations, It is a related object to communicate with one or more stations and one or more remote Local Area Networks independently and transparently of protocols above the data link layer so that the system ap pears to a user at a station in a Local Area Network as one large single network. 30 In accordance with the present invention a plurality of Local Area Networks are connected together by multiple bridges. Each Local Area Network has at least one station for sending or receiving communica tions to or from another station using data link frames containing at least a destination address and a source address. The bridge interconnects the Local Area Networks across simplexd channels and permits one or more stations in one Local Area Network to communicate with one or more stations in one or 35 more of the other Local Area Networks independently and transparently of protocols above the data link layer. 
    The bridge is constructed to permit more than two Local Area Networks to be interconnected across simplex channels through the bridge. 
    In the present invention there are four basic novel principles involved in the operation of the system. 40 First, a simplex channel is associated with one and only one network. 
    Secondly, at each bridge a network has one and only one output simplex channel and one or more input simplex channels. 
    Thirdly, from the standpoint of the bridge, all networks and LAN's can be defined in terms of simplex channels. 45 Fourthly, a bridge is capable of bridging between more than two networks and LAN's. 
    Communication system apparatus and methods which incorporate the structures and techniques de scribed above and which are effective to function as described above constitute further, specific objects of this invention. 
    Other and further objects of the present invention will be apparent from the following description and 50 claims and are illustrated in the accompanying drawings which, by way of illustration, show preferred embodiments of the present invention and the principles thereof and what are now considered to be the best modes contemplated for applying these principles. Other embodiments of the invention embodying the same or equivalent principles may be used and structural changes may be made as desired by those skilled in the art without departing from the present invention and the purview of the appended claims. 55 Brief description of the drawing views: 
    Figure 1 is a diagram illustrating a taxonomy for describing Local Area Network (LAN) interconnection. 
    Figure 2 is a view of four Ethernet networks bridged together across a satellite backbone network in accordance with one embodiment of the present invention. 60 Figure 2A is a view which corresponds to Figure 2 but which shows the actual simplex channel config uration for a four node network. 
    Figure 3 illustrates how the Figure 2 configuration can be expanded using a terrestrial line. 
    Figure 4 illustrates how two bridges can be interconnected in accordance with the present invention using either a broadcast medium or a point to point medium (e.g., a terrestrial data link). 65 2 GB 2 170 079 A 2 Figure 5 is a comparison view showing the use of simplex channels including a single broadcast sim plex channel for star communications contrasted with the use of multiple point to point duplex links for star communications. 
    Figure 5A is a view like Figure 5 showing a star topology. Figure 5A is a four node network and illus trates the simplex channel used for star configuration. 5 Figure 5B illustrates another topology. In Figure 5B a four node network is connected in what is re ferred to as multistar topology. Figure 5B illustrates the simplex channels required to support that topo logy. 
    Figure 6 shows how simplex channels are used in accordance with the present invention to support a fully connected topology. Figure 6 is a view like Figure 2 but emphasizing and illustrating the simplex 10 channels. 
    Figure 7 illustrates a configuration containing two star topologies connected to a LAN in the central site. 
    Figure 8 is a view of an expanded Figure 7 configuration. Figure 8 shows a communication system constructed in accordance with the present invention and embodying a fully connected network. Figure 8 15 illustrates how star configurations are connected through a Local Area Network, and how a number of those locations can be connected by a fully connected network. Figure 8 illustrates the actual configuration (as distinct from the user perspective). The user perspective is illustrated in Figure 9. 
    Figure 9 is a diagrammatic view showing the user perspective of a communication system incorporat- ing the present invention. As illustrated in Figure 9 the overall configuration is viewed by all LAN stations 20 as containing a single LAN. 
    Figure 10 illustrates the primary role of the bridge of the present invention. 
    Figure 11 illustrates secondary roles of the bridge of the present invention. 
    Figure 12 is a view of a bridge constructed in accordance with one embodiment of the present inven- tion. Figure 12 shows major component parts of the bridge. Subsequent figures of the drawings show 25 further details of these component parts. 
    Figure 13 illustrates features of the forwarding function of the bridge. 
    Figure 14 illustrates features of the management functions of the bridge. 
    Figure 15 shows the format of a forwarding data store incorporated in the bridge of the present inven tion. 30 Figure 16 shows details of a multicast array data store entry structure as used in the present invention. 
    Figure 17 illustrates the logical structure of a local or backbone network control component of the bridge shown in Figure 12. 
    Figure 18 illustrates how a frame is encapsulated in certain operations of the bridge illustrated in Fig ure 12. 35 Figure 19 illustrates how an encapsulated frame is decapsulated in the bridge illustrated in Figure 12. 
    Figure 20 is a pictorial view of a communications system for interconnecting Local Area Networks in accordance with one embodiment of the present invention. 
    Description of the preferred embodiments: 40 
    In the text of this description the following references will be referred to by the abbreviations in the brackets as indicated. 
    [DEC841 Digital Equipment Corporation, Network and Communications Catalog, Summer, 1984. 
    45 [DIX821 Digital, Intel, and Xerox, The Ethernet: A Local Area Network Data Link Layer and Physical Layer Specifications, Version 2.0, Nov. 1982. 
    [Hawe841 Bill Hawe, Alan Kirby, and Bob Stewart, "Local Area Network Connection", Telecommunica tions, April, 1984. 50 [IEEa83] IEEE Project 802 Local Area Network Standards, "IEEE Standard 802.3 CSMA/CO Access Method and Physical Layer Specifications", Approved Standard, July, 1983. 
    [IEEb831 IEEE Project 802 Local Area Network Standards, "Draft IEEE Standard 802.4 Token Bus Access 55 Method and Physical Layer Specifications", Working Draft E, July, 1983. 
    [IEEc831 IEEE Project 802 Local Area Network Standards, "Draft IEEE Standard 802.5 Token Ring Access Method and Physical Layer Specifications". Working Draft, July 1983. 
    60 [ISO331 ISO-3309, "HDLC, Frame Structure", available from Computer and Business Equipment Manu facturers Association, 1928 L St., N.W. Washington, DC, 20036. 
    [Orns751 Severo M. Ornstein and David C. Walden, "The Evolution of a High Performance Modular Packet Switch", 1975 Internat. Conf. on Comm., San Francisco, CA, June, 1975. 65 3 GB 2 170 079 A 3 [Stew84] Bob Stewart, Bill Hawe, and Alan Kirby, "Local Area Network Interconnection", Telecommuni cations, Mar. 1984 Currently, Ethernet networks and/or 802.3 Local Area Networks (LAN's) are being installed in conjunc tion with a wide variety of office automation and data communication products. Once installed, many of 5 these LAN's become the data highway for interconnecting multiple products which utilize various net work architectures (e.g. TCP/IP, XNS, DECnet, etc.). 
    After one successful LAN installation, many organizations repeat the installation in multiple other loca tions. In many cases the need to link remote LAN's together is initially ignored. Later as organizations begin to investigate their interconnect options, they discover that the simple multiple purpose data high- 10 way environment that exists within the building has disappeared. 
    The traditional Internet LAN interconnection techniques support a single architecture and consequently a subset of the current or potential LAN population. Also, since Internet processes in the LAN stations must assist in the interconnection, costly software upgrades may be required and complex multi-vendor compatibility problems can occur. Which architecture to interconnect becomes an issue. Redundant con- 15 figurations for the different Internet protocols may be required. Some of LAN stations may not support an Internet implementation. 
    In contrast the TransLAN configuration and method of the present invention provide a simple and ele gant LAN interconnect solution that transparently extends the public data highway paradigm to LAN in terconnection. From the perspective of all LAN stations, the present invention turns an arbitrary number 20 of Etherriet/802.3 LAN's into a single LAN. 
    Using the ISO Reference Model, this description briefly describes the relationship of the present inven tion to other LAN interconnect devices. Next the simple architecture and operational characteristics of the present invention are defined. This is followed by a description of the flexibility of the present invention relative to satellite, terrestrial, and mixed configuration support, as well as its extensibility to 802.4 and 25 ther LAN's. 
    Relationship of the present invention to other products An interconnection system and method constructed and operated in accordance with the present in vention uses a device termed the Vitalink Bridge. Before discussing how the Vitalink Bridge operates, it is 30 useful to understand its relationship to other LAN interconnect devices. 
    Figure 1 illustrates a taxonomy for describing LAN interconnection [Stew841. The taxonomy associates a LAN interconnection device with an ISO Reference Model layer. A device is associated with the layer in which it relays information from one network to another. The term network in this context ranges from LAN segments, satellite links, and terrestrial lines in the lower layers to network architectures (e.g. DEC- 35 net to SNA) in the higher layers. 
    In this taxonomy it is important to note that the layer performing the relay does not utilize information from the higher layers. In fact, differing higher layer protocols can (and do) concurrently utilize the same lower layer relay. Generally, the higher the relay layer, the more specialized are the set of products and protocols serviced by the relay. Also, factors such as overhead and complexity increase the higher the 40 layer number. 
    The layer relays of direct interest to the present invention are Repeaters, Bridges, and Routers, layers 1-3 respectively. The most common of the three, Repeaters and Routers are briefly described and then compared and contrasted with Bridges. 
    45 Repeaters: physical layer relays Repeaters relay physical layer protocol data units (bits) and control signals (e.g. collision detection). 
    They operate at LAN speed and add only a very small amount of addition delay (e.g. less than 1 micro second). 
    Repeaters are used to extend LAN configurations by connecting LAN channel segments together di- 50 rectly or across an internal point to point link. In general, the use of Repeaters in a LAN configuration is transparent to LAN station protocols. 
    However, the use of Repeaters as a general mechanism for interconnecting multiple LAN's is severely limited. The length of a single LAN (including any internal point to point links) is limited by Physical layer constraints such as maximum round trip propagation delay budget. This limits LAN expansion using Re- 55 peaters to a few kilometers. The maximum number of stations that can be effectively serviced by a single LAN is another limiting factor. 
    Since Repeaters relay bits, they are unable to selectively filter Data Link frames. Consequently, LAN expansion is restricted by maximum LAN capacity. Another consequence of the absence of filtering is that links used by repeaters to tie together two segments must operate at LAN speed. 60 An Ethernet Repeater [DIX 821 is an example of a Repeater device. 
    Routers: network layer relays Routers are the traditional LAN interconnect devices. When using these devices, LAN stations must be able to distinguish between communication with a station on the same LAN and a remote LAN. Remote 65 4 GB 2 170 079 A 4 communication requires LAN stations to transmit/receive Data Link frames to/from a Router on the same LAN. 
    The frames contain Internet protocol data units (packets) created by the LAN stations. Routers utilizes the Internet protocol control information in the packets and a local configuration topology table to deter mine how to relay the packets between the LAN and other networks. (e.g., point to point data links). 5 When compared to Repeaters, Routers are not transparent to LAN station protocols. They only work with LAN stations having a compatible Internet layer. Also, compared to Repeaters, Routers add signifi cant delays. They operate as a store and forward packet relay (not a bit relay). Their internal processing time usually ranges from 5 to 50 milliseconds but more significant are the internal queue delays and transmission time between Routers. 10 Since LAN stations perform the filtering function for a Router (by only sending it packets destined for a remote LAN), the Router to Router links do not need to operate at LAN speeds. Typical link speeds range from 9.6 Kbps to 56 Kbps. Also, the maximum number of stations that can be effectively serviced by a single LAN is no longer a limiting factor. Stations can be spread among multiple interconnected LAN's. 
    A DECnet Router Server [DEC841 is an example of a Router device. 15 Bridges: data link layer relays Bridges interconnect LAN's using the same media as Routers, but operate totally within the Data Link layer. LAN's connected together by Bridges logically appear to the LAN stations as a single LAN. 
    LAN stations simply address Data Link frames to other stations as if they were on the same LAN. 20 Broadcast and Multicast destination frames are handled properly. They are received by the addressed group of stations regardless of location. LAN stations do not address frames to Bridges as they must with Routers. 
    The Frame Check Sum value created by the source system is delivered to the destination station. 
    Bridged LAN's have the same level of protection against corrupted data as is present on a single LAN. 25 With Routers, the original FCS is removed by the first Router and recreated by the last. 
    Like Routers, Bridges store and forward frames. This means, that unlike Repeaters, they are able to selectively filter and discard frames addressed to local stations. Bridges keep local traffic on one LAN from interfering with local traffic on the other LAN's. As a result, Bridge to Bridge links can operate at less than LAN speeds. In fact, in almost all configurations the same link speeds used to interconnect 30 Routers can be used to interconnect Bridges. 
    Also, as with Routers, the maximum number of stations that can be effectively serviced by a single LAN is no longer a limiting factor. The stations can be spread amoung multiple bridged LAN's [Hawe841. 
    In contrast with Routers, since Bridges relay and filter for all LAN stations, they provide the more general solution for a congested LAN. 35 Since Bridges operate at a lower layer than Routers, they have less processing overhead and are capa ble of processing and relaying frames at higher rates (thousands of frames/second). Consequently, Bridges are capable of effectively utilizing high bandwidth links (1-10 megabits/see) between LAN's. 
    When bridging remote LAN's together with a link operating at LAN speed or two local LAN's together directly, Bridges add a very small amount of additional delay (at most a few milliseconds). In contrast, 40 when utilizing lower speed links, Bridges like Routers add significant delays due to transmission time. 
    However, for the same configuration, the delay associated with a Bridge should be less than with a Rou ter. This is due to the reduced processing overhead within a Bridge. 
    While conceptually a Data Link Bridge is not a new idea, recently the potential for these devices has greatly increased. Specifically, Digital Equipment Corporation was the first to recognize this new potential 45 [Stew84]. The use of 48 bit global addressing in Ethernet and the 802 LAN's for the first time places a unique world wide identifier in the Data Link layer. Also, Bridges are processing and memory intensive devices that are able to exploit medium to high speed broadcast and point to point technologies. Signifi cant cost reductions and technical advancements are occurring in all of these areas. 
    50 Operational characteristics To describe the operational characteristics of the present invention it is useful to first illustrate and discuss one configuration of the present invention. Figure 2 illustrates four Ethernet [DIX82] and/or 802.3 [IEEa831 LAN's bridged together across a satellite backbone network. 
    The backbone is operating in a fully connected broadcast mode such that any frame transmitted by 55 one Vitalink Bridge (VB1, VB2, VB3 or VB4) is received by all other Bridges. Each Vitalink Bridge can be configured to Transmit at the same or a different rate. 
    A fully connected Vitalink satellite network is very similar to an Ethernet or 802.3 LAN. Both are a broadcast transmission media, support a promiscuous (receive all frames) reception mode, and have a very low bit error rate. 60 Both Ethernet and 802.3 utilize an unacknowledge clatagram protocol. Likewise, the Vitalink Bridges uti lize an unacknowledged datagram protocol across satellite backbone. The forwarded Ethernet/802.3 frame are simply enveloped inside the HDLC frame structure PS0331. In order to allow for concurrent support of Ethernet and 802.3 stations, the Vitalink Bridge support the 48 bit 802.3 Address Field. 
    A single Vitalink Bridge can concurrently relay between 2-9 different networks. For clarity and brevity, 65 GB 2 170 079 A 5 the following discussion configures each Vitalink Bridge with only two networks. This allows a simplified operational model to be utilized. 
    Listen- only mode When Vitalink Bridge 1 in Figure 2 is powered on it enters into LISTEN- ONLY mode. It remains in LIS- 5 TEN-ONLY mode for 10-60 seconds. V131 operates in Promiscuous mode relative to LAN I and the satellite backbone. As a result it receives all frames being transmitted by LAN stations A-C or Vitalink Bridges 2-4. 
    No frames are relayed by V131 during LISTEN-ONLY mode. 
    During LISTEN-ONLY mode, VB1 automatically creates a local data base (termed the Forwarding data store). A Forwarding data store entry is created from each frame received with a unique Source Address 10 value. The entry contains the address and a local variable which identifies the source of the frame (LAN I or satellite backbone). A Vitalink Bridge can support a Forwarding data store of up to 8000 entries. 
    The following assumptions are made about the current activity within the Figure 2 configuration. Sta tions AB), (M,N), (Q,R), and (X,Y) are only communicating locally on LAN 1, 11, 111, and IV respectively. 
    Stations (N,S), (R,Z) are communicating with each other across the satellite backbone. Station C is turned 15 off. As a result, the initial VB1 Forwarding data store (in summary form) contains the following entries. 
    Entry 1 - address=A, source=LAN-1 Entry 2 - address=B, source=LAN-1 Entry 3 - address=N, source=SATELLITE-BACKBONE 20 Entry 4 - address=S, source=SATELLITE-BACKBONE Entry 5 - address=R, so u rce= SATE LLITE-BACKBO N E Entry 6 - address=Z, source=SATELLITE-BACKBONE The entry source values of LAN-1 or SATE LLITE-BACKBO N E are a locally assigned value. They are not 25 globally administered or used as a global identifier between Vitalink Bridges in any manner. 
    Forwarding mode After the LISTEN-ONLY time period, the Vitalink Bridge enters FORWARDING mode. In FORWARDING mode the maintenance of the Forwarding data store based on Source Address continues in the background as defined above. Determining whether to filter (discard) or relay frames becomes the major fore ground activity. 
    Relaying and filtering rules When a single destination frame is received, a hash is created from the Ethernet/802.3 destination ad- 35 dress. The hash is used to locate a matching Forwarding data store entry (in under 40 microseconds). If the matching entry's source value identifies the frames source network, the frame is discarded. Other wise, the frame is relayed to the identified network. If no matching entry is located, the frame is relayed to all networks other than the source. 
    Since multicast or broadcast address values never appear as Source Addresses, Forwarding data store 40 entries are not automatically created. As a result, multicast and broadcast frames are relayed like single destination frames with no matching entries. However, this can be changed by configuring broadcast and multicast entries into the Vitalink Bridges. When this is done, multicast and broadcast destination frames are selectively filtered in the same manner as single destination frames. 
    Upon entering FORWARDING mode, VB1 in Figure 2 begins relaying and filtering frames in the follow- 45 ing manner. 
    1) Frames received from LAN I destined for A or B are not relayed to the satellite network. (i.e., frames local to LAN I are filtered). 
    2) Frames received from the satellite network destined for N, S, R, or Z are not relayed to LAN 1. 
    Frames destined for M, N, Q, X, and Y are not received on the satellite network because they are filtered 50 locally by the associated Bridge. These stations are not communicating with remote LAN stations. 
    3) Frames received from LAN I destined for L-Z are relayed to the satellite network. 
    4) Frames received from the satellite network destined for A or B are relayed to LAN 1. 
    Maintaining the forwarding data store 55 In FORWARDING model Vitalink Bridges learn the location of new LAN stations very quickly. For exam ple, assume that when station C is initialized, it generates an initial multicast frame containing a "Hello" or "Help" message. This is normal behaviour for many just initialized LAN stations. V131 relays the frame from LAN I to the satellite backbone and creates the following Forwarding data store entry: 
    Entry - address=C, source=LAN-1 60 VB2-4 receive the "Hello or Help" frame on the satellite backbone and relay the frame to LAN's Il-IV respectively. In addition, they each create the following Forwarding data store entry: 
    Entry - address=C, source=SATELLITE-BACKBONE As a result, the "Hello" or "Help" message is received by all addressed LAN stations. Also, all Vitalink Bridges learn the relative location of station C and are able to appropriately filter and relay frames des- 65 6 GB 2 170 079 A 6 tined to it. 
    If a Vitalink Bridge does not receive a frame containing a particular destination or source address value for about 15 minutes, the associated Forwarding data store entry is considered stale. Stale entries are automatically deleted. If station A in Figure 2 moves to LAN 11, the Vitalink Bridges will forget A's associa tion with LAN I independent of any action by station A. 5 If station A in less than 15 minutes moves and generates, for example, a "Hello" or "Help" multicast frame on LAN 11, the V131 and V132 entries change as follows: 
    VB1 Entry - address=A, source=SATELLITE-BACKBONE (was LAN 1) VB2 Entry address=A, source=LAN-11 (was SATELLITE BACKBONE) The source value in the VB3 and VB4 entries remains equal to SATELLITE BACKBONE. Relative to V133 10 and VB4, station A did not change position. 
    Experience has shown that the "no matching entry" case for single destination frames is rare. When it does occur, it usually occurs for one frame and NEVER results in a Vitalink Bridge forwarding error. The frames always reach the addressed destination. 
    15 Expanding the configuration Expanding a TransLAN configuration of the present invention is extremely easy. For example, the Fig ure 2 configuration can be expanded as illustrated in Figure 3. The additon of V135 and VB6 results in V131-4 learning about more stations. For example, if station D generates a single destination frame to station Z, the following entries are created: 20 VB6 Entry - address=D, source=LAN-N VB5 Entry - address=D, source=TERRESTRIAL-LINK VB4 Entry - address=D, source=LAN-IV Since V134 does not relay the frame to the Satellite Backbone (the V134 Entry for station Z has a source value of LAN IV), V131-3 do not create entries. 25 Subsequently, if D generates a single destination frame to station A, V134 will relay the frame and VB1 3 will then create the following entries: 
    VB3 Entry - address=D, source=SATELLITE-BACKBONE V132 Entry - address=D, source=SATELLITE-BACKBONE VB1 Entry - address=D, source= SATE LLITE-BACKBO N E 30 If station E initializes and generates a "Hello" multicast frame, V131-6 create the following entries: 
    V136 Entry - address=E, source=LAN-V V135 Entry - address=E, source=TERRESTRIAL-LINK VB4 Entry - address=E, source=LAN-IV V133 Entry address=E, source SATELLITE-BACKBONE 35 V132 Entry - address=E, source SATELLITE-BACKBONE V131 Entry - address=E, source SATELLITE-BACKBONE The Vitalink Bridges automatically adapt to the new configuration. The addition of V135 and V136, a ter restrial link, and LAN V requires no configuration changes to existing Bridges. The new and existing Bridges simply learn the relative location of new stations. 40 Supported topologies The configuration illustrated above indicates that the Vitalink Bridge supports interfaces to both a broadcast satellite network and apoint to point data link. The present invention is also capable of sup porting other point to point and broadcast media such as terrestrial microwave. 45 Both broadcast and point to point interconnect media are supported by the system and method of the present invention in a number of ways. 
    Dual bridge topologies Two Vitalink Bridges can be interconnected using either a broadcast medium or a point to point me- 50 dium (e.g., terrestrial data link). A broadcast and point to point dual end point configuration is illustrated in Figure 4. In both configurations, VB1 and VB2 are connected to a LAN. 
    When utilizing a broadcast medium, VB1 or V132 relay frames destined to remote LAN stations onto a simplex broadcast channel. They each receive the other Bridges transmit channel. When utilizing the point to point medium, V131 and VB2 each transmit on one side of the duplex data link and receive from 55 the other. 
    Relative to both the broadcast and point to point configurations, frames transmitted by one Bridge are almost always relayed and not filtered by the other Bridge. This occurs because each Bridge normally filters frames received from its LAN that are destined for local stations. As a result, only frames destined for stations on the other LAN are transmitted. 60 Typically, a point to point medium (terrestrial line), provides the same transmit rate in both directions. 
    In contrast, the concept of broadcast simplex channels encourages the use of different transmit rates to cost effectively accommodate asymmetric data transmission requirements. For example, if most of the traffic is LAN I stations transferring files to LAN 11 stations, the present invention allows the transmit rate of the VB attached to LAN I to be much higher. 65 7 GB 2 170 079 A 7 Star topology The system and method of the present invention can interconnect more than two Vitalink Bridges us ing a star topology. The medium used to interconnect the star can be broadcast or point to point. See Figure 5. In both cases, the present invention automatically relays and filters frames as appropri-ate. Sup port of the broadcast and point to point medium is summarized below using the configurations illus- 5 trated in Figure 3. In both of the configurations, VB1 through VBN are each connected to LAN. 
    Broadcast star topology In broadcast star topology each Vitalink Bridge has a simplex transmit channel. VB1's simplex channel is received by all remote VB's. Each remote VB's transmit channel is only received by VB1. This allows 10 numerous remote LAN stations to statistically share a high speed VB1 transmit channel. The VB2-N transmit channels can be low speed in comparison. 
    In configurations where a large percentage of the data is transferred from a central site to remote loca tions, the broadcast star topology is particularly effective. In addition, TransLAN maintains full connectiv ity. (e.g., V132 LAN stations can send frames to both VB1 as well as VB3N LAN stations). 15 Point to point star topology The point to point star topology is interconnected by individual cluplexed data links. One end of each link is attached to VB1; the other end of each link is attached to one remote VB. Each link can have a different transmit rate; but, the VB1 and the remote VB transmit rates are always equal for a given line. 20 As with the broadcast star topology, TransLAN maintains full connectivity. VB2-N LAN stations can send frames to VB1 LAN stations and VB1 will appropriately switch frames between VB2-N LAN stations. 
    Fully connected topology Figure 2 illustrates a configuration of the present invention that interconnects Vitalink Bridges using a 25 fully connected broadcast topology. A fully connected topology is characterized by each VB being directly connected to all other VB's. 
    The use of simplex channels in accordance with the present invention to support a fully connected topology is illustrated in Figure 6. Each Vitalink Bridge has a transmit channel that is received by all other Bridges. To fully connect the set of N LAN's using a broadcast topology requires N simplex links. 30 To fully connect a set of N LAN's using point to point medium requires N(N-1)/2 links. If N equals 3, 4, 8, or 16, the number of links equals 3, 6, 28, or 120 respectively. The number of broadcast simplex chan nels required for the same N values is 3, 4, 8, or 16 respectively. 
    A fully connected broadcast topology is chosen over a star topology when the flow of information be tween the remote sites is balanced, not predominantly to and from a single central site. This does not 35 imply that the transmit rate of each Bridge must be the same. In fact, in a fully connected topology the present invention allows each Bridge to have the same or a different rate. 
    Mixed topologies The ease of mixing a fully connected topology and a point to point link has already been illustrated in 40 Figure 3 and discussed. The simple rule is that the present invention is capable of mixing any supported topology within a configuration. The only restriction is that the topologies cannot be configured together in such a way as to form a loop. 
    Figure 7 illustrates a configuration containing two star topologies connected to a LAN in the central site. The star topologies and the LAN are labeled in Figure 7 for the convenience of this discussion. There 45 are no corresponding global identifiers in the actual implementation of the present invention. 
    The topology of Star 1 and Star 2 can be both broadcast or point to point, or one broadcast and one point to point. The remote sites each have a -LAN and a Vitalink Bridge. Any remote site is directly con nected (one hop) to the central site and two hops away from any other remote site. 
    As discussed earlier, a frame transmitted between remote sites on the same star is relayed by the as- 50 sociated central site Bridge. The frame is not transferred to LAN 1. A frame transferred between a Star 1 remote site and a Star 2 remote site is relayed between VB1 and V132 across LAN 1. Normally, relaying a frame across LAN I will add only a few additional milliseconds. 
    It is interesting to note the extent to which each bridge understands the Figure 7 configuration. Both V61 and VB2 think they are relaying and filtering for LAN I and functioning as the center of Star 1 and 2 55 respectively. Each Star 1 and Star 2 remote VB in turn thinks that it is relaying and filtering for its local LAN and functioning as a remote Bridge in a single star. The point is that A VITALINK BRIDGE DOES NOT REQUIRE KNOWLEDGE OF THE ENTIRE CONFIGURATION. TO FUNC TION CORRECTLY, A VITALINK BRIDGE ONLY NEEDS TO UNDERSTAND ITS ROLE IN NETWORKS TO WHICH IT DIRECTLY INTERFACES. 60 It is this characteristic that allows configurations to be so easily expanded. For example, the Figure 7 configuration can be expanded as illustrated in Figure 8. In the expanded configuration, the following occurs: 
    1) the perspective of all Star 1 and Star 2 Vitalink Bridges does not change (stays the same as in the. 
    Figure 7 configuration). 65 8 GB 2 170 079 A 8 2) the VB3 and the Star 3 remote VB's have the same relative perspective as either of the respective Star 1 and 2 Bridges. 
    3) VB4 is only aware of relaying and filtering for LAN 11 and the fully connected broadcast network. 
    4) VB5 is only aware of relaying and filtering for a LAN 1, the fully connected broadcast network, and the point to point link. VB5 is another example of a Vitalink Bridge interfacing to more than two net- 5 works. 
    5) VB6 is only aware of relaying and filtering for LAN III and the point to point data link. 
    While the perspective of VB1-VB6 in the Figure 8 configuration is greatly simplified, the LAN stations have by far the simplest perspective. (see Figure 9). The overall configuration is viewed by all LAN sta- tions as containing a single LAN. When transmitting frames, stations always assume the destination is on 10 the same LAN. This is true for both single destination and multicast destination frames. 
    Network management Figure 9 illustrates the transparency of the configuration of the present invention. However, providing this transparency elevates the need for distributed network management visibility and control. 15 Fortunately, network management communication to and from Bridges can exploit the simplicity of the single LAN perspective. Each Vitalink Bridge automatically creates the following permanent Forwarding data store entry. 
    Entry - address= LOCAL-BRIDGE, source=SELF When a frame with the LOCAL-BRIDGE Destination address is received, it is passed to the local Bridge 20 management process and not relayed. Entries are also created for certain Bridge multicast address val ues. 
    Entry - address= BRIDGE-M U LTICAST-1, source=SELF Entry - address= BRIDGE-M ULTICAST-2, source=SELF When a frame with a BRIDGE-MULTICAST destination address is received, it is copied for the local 25 Bridge management process and then relayed. 
    To communicate with a Vitalink Bridge anywhere in a configuration of the present invention, a LAN station only needs to generate a frame with Bridge single destination or multicast destination address. 
    The frame will be received and processed by the Vitalink Bridge(s) with a matching entry. 
    A Bridge management process simply generates single destination and multicast frames. Except during 30 LISTEN-ONLY mode, a Vitalink Bridge treats the local Bridge management process like another network. A frame generated by the local bridge management process is relayed or filtered in the same manner as a frame received from a network. 
    During LISTEN-ONLY mode, Bridge management frames are relayed to and from the local Bridge man agement process. All other frames received during LISTEN-ONLY mode are filtered. 35 One use of this capability is for Loop detection. During LISTEN-ONLY mode a Bridge transmits LOOP-DETECTION multicast frames. If a LOOP-DETECTION frame is received with a source address equal to the LOCAL-BRIDGE address, the bridge does not enter FORWARDING mode. If it did, a loop would be created. 
    Each Vitalink Bridge maintains an extensive set of statistical and local configuration information. The 40 local Bridge management process provides an information access service. The service supports informa tion retrieval and online reconfig u ration. This service can be accessed by both network operators and peer management processes. 
    Network operator communication 45 Network operators can access a Vitalink Bridge from one or more remote locations using terminals attached to system Management stations. The Management station communication with a Bridge uses a Virtual terminal protocol. 
    An operator can establish up to 4 concurrent connections to different Bridges from the same terminal. 
    This allows an operator to concurrently view the perspective. 50 An operator can establish up to 4 concurrent connections to different Bridges from the same terminal. 
    This allows an operator to concurrently view the perspective of several Bridges. Optionally, an operator can access a Bridge through its local console. The operator interface from the console and terminal are the same. 
    Multiple Bridge consoles, and terminals (or printers) can be configured to receive alarms and statistical 55 messages. Each may receive all or a subset. 
    Peer process communication A Vitalink Bridge supports a simple request/response protocol layered directly on top of either Ethernet or 802.3. When a request is received within an Ethernet or 802.3 frame, a Bridge transmits the associated 60 response using the same type of frame. The destination address in the response frame equals the source address value received in the request frame. 
    The request/response protocol provides the mechanism through which both Ethernet and 802.3 sta tions can communicate with a Bridge. The protocol provides access to essentially the same information that is available to a network operator. 65 9 G13 2 170 079 A 9 Beyond Ethernet and 802.3 The system of the present invention expects the following from a LAN. A promiscuous receive mode is supported. All frames sent and received from a LAN contain a 48 bit destination and 48 bit source ad dress. Frames contain a 32 bit Frame Check Sequence and have a length between 64 and 1518 octets. A single class of service is provided to the LAN stations. LAN's which are compatible with these assump- 5 tions are termed compatible with the system of the present invention. 
    System compatible LANs The development effort to support a LAN compatible with the system of the present invention ranges from no effort to developing a new LAN interface. For example, changing the medium to broadband or 10 fiber optics, only requires a different transceiver. Depending upon the implementation, the impact of changing LAN speeds from 10 megabits to one megabit ranges from a configuration change to develop ing a new LAN interface. The list of "TransLAN system compatible" LAN's includes the other potential IEEE 802.3 standards, Cheapernet and AT &T's SLAN. 
    Adding a "TransLAN system compatible" LAN to a TransLAN configuration of the present invention is 15 no different than adding an Ethernet or 802.3 LAN to the configuration. Only the Vitalink Bridge interfac ing to the LAN is aware of the LAN's existence. The LAN stations still have a single LAN perspective. 
    Almost TransLAN system compatible A LAN is considered "almost TransLAN system compatible" when a simple protocol translation at the 20 LAN interface makes the LAN appear "TransLAN system compatible" to the rest of the configuration. The other Bridges are unaware of the LAN's true properties. 
    For example, IEEE 802.4 [IEEb83] is an "almost TransLAN system compatible" LAN. 802.4 supports a maximum frame size that is larger that 1518 octets and offers multiple classes of service. Concurrent system support of 802.3 and 802.4 can be accomplished by limiting the frames on the 802.4 LAN(s) to 25 1518 octets and providing a translation function directly on top of the 802.4 LAN interface. 
    In each Bridge interfacing to an 802.4 LAN, the translation function does the following: 
    I) removes the class of service in received 802.4 frames. 
    2) adds preconfigured class of service information to transmitted 802.4 frames. Bridges can be con figured to all insert the same class of service or to each insert different classes as appropriate. 30 Bridging together "TransLAN system compatible" LAN's with "almost TransLAN system compatible" LAN's has an interesting effect. The single LAN perspective by the LAN stations is preserved, but each LAN station thinks the single LAN is of the type to which it interfaces. For example, 802.3 stations view the configuration as an 802.3 LAN, and 802.4 stations view it as an 802.4 LAN. Also, 802.3 and 802.4 stations can exchange frames. 35 Not TransLAN system compatible A LAN is considered "not TransLAN system compatible" when a simple protocol translation at the LAN interface is not possible. In this case the LAN frames can be encapsulated inside a system compatible frame and sent across a system configuration to a destination Bridge. The destination Bridge decapsu- 40 lates the frame and relays the frame back to its native LAN environment. 
    This technique allows LAN's which are "not TransLAN system compatible" to share the interconnec tion capabilities of the present invention. Frames from the group of incompatible LAN's are essentially "tunneled" through the configuration and method of the present invention. 
    Support of a group of LAN's which are "not TransLAN system compatible", results in two separate 45 single LAN perspectives. As expected, all of the stations attached to LAN's within the configuration have the same single LAN perspective. Their perspective is unchanged by the presence of the "not TransLAN system compatible" LAN's. Concurrently, all of the stations attached to the "not TransLAN system com patible" LAN's have different, not overlapping, single LAN perspective. 
    50 Partial summary of the description above 
    Vitalink Bridges have the transparency of repeaters, but are able to selectively filter and relay by auto matically learning the relative location of stations. The Bridges are able to support a wide variety of point to point and broadcast topologies. Because Vitalink Bridges are essentially transparent to each otherr configurations of the present invention can be easily expanded to support a very large number of LAN's. 55 Bridges perform a Data Link layer relay. Consequently, they can interconnect all LAN stations inde pendent of their higher layer architecture. Interconnected LAN stations view any configuration of the present invention as a single logical LAN. 
    Due to the high degree of transparency, emphasis is placed by the system and method of the present invention on network management visibility and control. Fortunately, accessing Bridges is easy; they all 60 appear to be on the local LAN. 
    The present invention bridges together Ethernet and/or 802.3 LAN's. Supporting other LAN's is, in many cases, straight forward. This allows the free use of different LAN technologies, while preserving the ease of communication on a single LAN. 
    Bridges are simple and elegant devices that provide a new general purpose networking glue. While the 65 GB 2 170 079 A 10 work with glue is just beginning, its effect is expected to be significant. 
    FURTHER AND MORE SPECIFIC DESCRIPTION OF THE TECHNICAL BACKGROUND OF THE PREFERRED 
    EMBODIMENTS (AND IN PARTICULAR THE BRIDGE) In the following text the following references will be referred to by the numerical codes as indicated to 5 the left side of the references. 
    2.2- The Ethernet, A Local Area Network Data Link Layer and Physical Layer Specifications, Version 
    2.0, November 1982. 
    2.3- IEEE Project 802, Local Area Network Standards, IEEE Computer Society, July 1983. 
    2.4- Ethernet System Product Line Software Technical Reference Manual, Preliminary Draft, May 1983, 10 Bridge Communications Inc. 
    2.5- ESPL Software Technical Reference Manual, Volume One, July 1983, Bridge Communication Inc. 
    2.6- ESPL Software Technical Reference Manual, Volume Two, July 1983, Bridge Communication Inc. 
    2.7- ESPL Software Technical Reference Manual, Volume Three, July 1983, Bridge Communication Inc. 
    This description describes the high level design of the bridge of the present invention. Sometimes the 15 present invention is referred to as the Vitalink Bridge or the Bridge. 
    3.1 - Networks The reader should understand the following Vitalink Bridge concepts concerning networks: 
    a) Network IDs 20 Relative to a Vitalink Bridge, a Network contains a single Transmit (or output) access point and one or more Receive (or input) access points. In some cases the Transmit and Receive access points utilize a common 110 port (e.g. Ethernet) and in other cases they utilize different 1/0 ports (e.g. FDMA Transmit and Receive frequencies). 
    Each Transmit and Receive access point is assigned a local identifier termed a Network ID (NID). The 25 minimum number of NID's associated with a network is two (i.e., one for Transmit, a TNID and one for Receive, a RNID). However, in certain cases (defined later), a TNID or RNID will be associated with a PSEUDO (non existant) Transmit or Receive access point. 
    b) Local Network A network that contains a station that is either the source or destination for a frame that is transmitted 30 on the Extended Network. The network is considered a local network relative to that frame. 
    c) Backbone Network A network across which a frame on the Extended Network is transmitted but does not contain either the source or destination station for the frame. The network is considered a backbone network relative to that frame. 35 3.2 - Extended network (ENET) frame The Vitalink Bridge Design assumes that the "standard" Extended Network (ENET) frame that either all Local Networks utilize, or that their Bridge translates or encapsulates/decapsulates to/from before for warding. The Vitalink design requires an ENET frame to conform to the Ethernet/802.3 Frame Size Limita- 40 tions and contain the following Ethernet/802 Protocol Information. 
    a) 48 Bit Destination GLOBAL-ADDRESS b) 48 Bit Source GLOBAL-ADDRESS 3.3 Satellite backbone physical topologies 45 Vitalink Bridges collectively support the following Physical Satellite Backbone Topologies. 
    a) NON-ROOTED Network (also referred to as full mesh and fully connected) This is the simplest type of Backbone Network. A NON-ROOTED network has the same topology as an Ethernet or a point to point terrestrial link. In this topology, each Vitalink Bridge is classified as a BRANCH and is configured as follows: 50 1) has a single Transmit Frequency that is received by the other BRANCH(es). A BRANCH classifies its Transmit frequency as NON-ROOTED. 
    2) only receives Transmit frequencies from Vitalink Briges that receive its Transmit frequency. 
    b) SINGLE-ROOTED Network (also referred to as star) In this topology, a Vitalink Bridge is classified as either a BRANCH or a ROOT. 55 1) Each BRANCH has a single Transmit Frequency that is classified as ROOTED-BRANCH and is only received by the ROOT. 
    2) The ROOT has a single Transmit Frequency that is classified as ROOT and is received by all BRANCHes. 
    A SINGLE-ROOTED topology must contain multiple BRANCHes. (i.e., Otherwise, it is NON-ROOTED) 60 c) MULTI-ROOTED Network (also referred to as multi-star) This is the most complex topology a Vitalink Bridge supports. In this topology, a Vitalink Bridge is classified as a BRANCH, a ROOT, or a SECONDARY-ROOT. 
    1) Each BRANCH has a single Transmit Frequency that is classified as ROOTED-BRANCH and is re ceived by all ROOT's. 65 11 G13 2 170 079 A 11 2) Each ROOT has a single Transmit Frequency that is received by all BRANCHes and other ROOT(s). One ROOT classifies its Transmit frequency as ROOT. All other ROOT(s) classify their Transmit frequency as SECONDARY- ROOT. 
    A MULTI-ROOTED topology must contain one or more BRANCHes. (i.e., Otherwise, it is NON-ROOTED) d) Multiple topology support 5 A Vitalink Bridge can concurrently interface to multiple topologies with the following restrictions: 
    1) each topology has its own Transmit/Receive frequencies 2) a multi bridge configuration (defined later in the document) support only 1 Satellite Backbone. 
    Multiple Satellite Backbones of any topology can always be supported at a location by multiple Vitalink Bridges connected to a common LAN. 10 3.4 SINGLE-ROO TED EncapsulationlDecapsulation The Logical Topology of an ENET is defined to be a Branching Tree with no alternate paths that create loops. In order to preserve the ENET logical topology, Vitalink Bridges operate as follows when utilizing Transmit and Receive frequencies associated with a SINGLE-ROOTED Satellite Network. 15 a) A BRANCH always encapsulates frames to be transmitted on a ROOTED- BRANCH frequency. The frames are encapsulated within an ENET Frame with a maximum size of 1530. The GLOBAL-ADDRESS values of the encapsulated frame are 1) The Destination Address=BRANCH- ENCAPSULATION (BE) Vitalink multicast address. 
    2) The Source Address= GLOBAL-ADDRESS of the BRANCH 20 b) In order to allow BRANCHes to operate in the ENET, the ROOT decapsulates received BE frames. 
    The ROOT then forwards to the associated ROOTED Transmit frequency, the clecapsulated BE frames that are either 1) destined for a station known to be accessible through the Transmit frequency (from a Forwarding data store entry) 25 2) Have an unknown destination. 
    The forwarding of these frames back to the SINGLE-ROOTED Satellite backbone is termed DOUBLE-HOPPING. 
    c) The ROOT always encapsulates a DOUBLE-HOPPED frame within an ENET Frame with a maximum size of 1530. The GLOBAL-ADDRESS values of the encapsulated frame are 30 1) The Destination Address= ROOT-ENCAPSULATION (RE) Vitalink multicast address. 
    2) The Source Address =Source address of the BE frame (i.e. the GLOBAL-ADDRESS of the BRANCH that created the BE) d) each BRANCH processes received RE frames as follows: 
    1) All RE frames with a Source Address equal to the BRANCH GLOBAL-ADDRESS are discarded. 35 2) All other RE frames are decapsulated and processed like any other received ENET frame. 
    e) The ROOT does not encapsulate NON-DOUBLE-HOPPED frames forwarded to the satellite backbone. 
    f) BRANCHes process received non encapsulated ENET frames. 
    g) To preserve compatability with support of a MULTI-ROOTED topology, the ROOT also processes received non encapsulated ENET frames. 40 3.5 - MUL T1--RO0 TED encapsulation1decapsulation As in 3.5 above, in order to preserve the ENET logical topology, Vitalink bridges operate as follows when utilizing Transmit and Receive frequencies associated with a MULTI-ROOTED Satellite Network. 
    a) A BRANCH always encapsulates frames to be transmitted on a ROOTEDBRANCH frequency within 45 a BE frame (same as a SINGLE-ROOTED) b) In order to allow BRANCHes to operate in the ENET, all ROOTs decapsulate the received BE frames. SECONDARY-ROOT(s) clecapsulate received BE frames, and process as a normal ENET frame. The ROOT clecapsulates received BE frames and then forwards to the associated ROOT Transmit frequency, the decapsulated BE frames that are either 50 1) Destined for a station known to be accessible through the Transmit frequency (from a Forwarding data store entry) 2) Have an unknown destination. 
    The forwarding of these frames back to the MULTI-ROOTED Satellite Backbone is termed DOU BLE-HOPPING. 55 c) The ROOT always encapsulates a DOUBLE-HOPPED frame within an ENET Frame with a maximum size of 1530. The GLOBAL--ADDRESS values of the encapsulated frame are 1) The Destination Address=ROOT-ENCAPSULATION (RE) Vitalink multicast address. 
    2) The Source Address=Source address of the BE frame (i.e. the GLOBALADDRESS of the BRANCH that created the BE) 60 d) Each BRANCH processes received RE as in the SINGLE- ROOTED case above. The SECOND ARY-ROOT(s) discard received RE frames. 
    e) The ROOT does not encapsulate NON-DOUBLE-HOPPED frames forwarded to the Satellite Backbone. 
    SECONDARY-ROOT's never encapsulate frames forwarded to the Satellite Backbone. 
    f) BRANCHes, ROOTs and, SECONDARY-ROOT's process received non encapsulated ENET frames. 65 12 GB 2 170 079 A 12 3.6 - Ku Band Rain and NON-ROOTED Satellite Backbone A NON-ROOTED Ku Band Satellite Backbone can operate on a sunny day in its normal no DOUBLE-HOP mode. However, rain has a disruptive effect on Ku band transmissions. Therefore, when a NON-ROOTED BRANCH is in the rain, it and the other NON-ROOTED BRANCHes operate as follows: - a) The BRANCH in the rain is termed a RAIN-BRANCH. The RAIN-BRANCH reconfigures its Transmit access point to be RAIN-ROOTED (the Transmit power is also increased) b) A RAIN-BRANCH always encapsulates frames to be transmitted on a RAIN- ROOTED Transmit access point within a RAIN-BRANCH- ENCAPSULATION (RBE) Frame with a maximum size of 1530. The GLOBAL-ADDRESS values of the encapsulated frame are 1) The Destination Address= RAIN-BRANCH-ENCAPSULATION (RBE) Vitalink multicast address. 10 2) The Source Address= G LO BAL-ADDRESS of the BRANCH c) Another BRANCH with a large dish is always configured as a RAIN-ROOT and its Transmit access' point is configured as RAW-ROOT. 
    d) In order to allow the RAIN-BRANCH(es) to operate in the ENET, when the first RBE frame is re ceived, the RAIN-ROOT marks the Receive access point as RAIN. A RAIN-ROOT always decapsulates a 15 RBE frame. The RAIN-ROOT forwards to the associated RAIN-ROOT Transmit access point, a decapsulated RBE frame that is either: 
    1) Destined for a station known to be accessible through the RAIN-ROOT Transmit access point (from an F DSE) 2) Has an unknown destination. 20 The forwarding of these frames back to the RAIN-ROOT Transmit access point is termed DOU BLE-HOPPING. (The RAIN- ROOT Transmit power is also increased.) e) When a non encapsulated ENET frame is received from the RAIN-ROOTED Satellite Backbone, it is DOUBLE-HOPPED by the RAIN-ROOT when either:  1) It is destined for a station whose Receive RNID is marked RAIN and is 
    known to be accessible 25 through the RAIN-ROOT Transmit access point (from an F DSE) 2) Has an unknown or multicast/broadcast destination. 
    f) The RAIN-ROOT always encapsulates a DOUBLE-HOPPED frame within an ENET Frame with a maxi. 
    mum size of 1530. The GLOBAL-ADDRESS values of the encapsulated frame are 1) The Muiticast Address= RAIN-ROOT-ENCAPAULATION (RRE) when there is a matching F DSE or 30 RAIN-ROOT-DOUBLE HOPPED-UNKNOWN (RRDU). 
    2) The Source Address= Source Address of the decapsulated BE frame (i.e. the GLOBAL- ADDRESS of the BRANCH that created the BE) or the RAIN-ROOT GLOBAL-ADDRESS 9) When a non encapsulated ENET frame is received from a Receive access point associated with another network, it is encapsulated by the RAIN-ROOT and transmitted on the RAIN- ROOT Transmit ac- 35 cess point when either: 
    1) It is destined for a station whose Receive RNID is marked RAIN and is known to be accessible through the RAIN-- ROOT Transmit access point (from an F DSE) 2) Has an unknown or multicast/broadcast destination These frames are termed NON-DOUBLE-HOPPED encapsulated frames. 40 h) The RAIN-ROOT always encapsulates a NON-DOUBLE-HOPPED frame within an ENET Frame with a maximum size of 1530. The GLOBAL-ADDRESS values of the encapsulated frame are 1) The Multicast Address= RAI N-ROOT-ENCAPSULATION (RRE) when there is a matching F DSE or RA[ N-ROOT-U N KNOWN (RRU). 
    2) The Source Address=the RAIN-ROOT GLOBAL-ADDRESS 45 1) BRANCHes and RAIN-BRANCHes discard received RBE frames. 
    j) RAIN-BRANCHes discard received non-encapsulated frames. 
    k) RAIN-BRANCHes process received RRE frames as follows: 
    1) All RRE frames with a Source Address equal to the RAIN- BRANCH GLOBALADDRESS are dis carded. 50 2) All other RRE frames are decapsulated and processed. 
    1) RAIN-BRANCHes decapsulate and process received RRDU and RRU frames m) BRANCHes process received RRE frames as follows: 
    1) All RRE frames with a Source Address equal to the BRANCH GLOBALADDRESS are discarded. 
    (This is necessary because the BRANCH may have just transitioned from a RAIN-BRANCH.) 55 2) All other RRE frames are decapsulated and processed. 
    n) BRANCHes discard RRDU but decapsulate and process received RRU frames o) When the rain stops, reversing the above requires the following: 
    1) The RAIN-BRANCH to reconfigure its Transmit access point to NON-ROOTED and become a BRANCH. 60 2) When the first non encapsulated frame is received, the RAIN-ROOT changes the Receive access point to NO-RAIN. 
    3.7 - Ku Band Rain and ROOTED Satellite Backbones This design assumes that the ROOT in a SINGLE-ROOTED Ku band network has a large dish. It likewise 65 13 GB 2 170 079 A 13 assumes that the ROOT with the MULTI-ROOTED Transmit frequency in a MULTI- ROOTED Ku band network has a large dish. These large dish ROOTS are termed DOUBLE-HOP ROOTs. 
    Since a ROOTED Ku Band Satellite Backbone operates on a sunny day in DOUBLE-HOP mode, rain does not require reconf ig u ration. The BRANCH(es) and ROOT(s) operate as normal except that a) The RAIN-BRANCH increases its Transmit power. 5 b) The DOUBLE-HOP ROOT increases its Transmit power. 
    3.8 - Ku Band rain alternative As defined below an alternative method of dealing with Ku band Rain is to reconfigure the RAIN-BRANCH to and from a temporary SINGLE-ROOT network, This method requires extensive 10 coordination by BRANCH and ROOT Management Function processing and protocols. Consequently, this method will not be implemented initially (if ever?). 
    a) A temporary SINGLE-ROOTED network is configured from part of a NONROOTED network as follows: 
    1) The RAIN-BRANCH DISABLES its normal Receive frequencies, ENABLES a RAIN-ROOT Receive fre- 15 quency, and increases Transmit power. A network is configured from the ROOTED Transmit frequency and RAIN-ROOT Receive frequency. 
    2) The other BRANCH(es) DISABLE their RAIN-BRANCH Receive frequency and ENABLE a RAIN-ROOT Receive frequency. 
    3) The RAIN-ROOT enables a RAIN-ROOT Transmit frequency (with increased power) and 20 reconfigures the RAIN-BRANCH Receive frequency into the network associated with the RAIN-ROOT Transmit frequency. 
    b) A temporary SINGLE-ROOTED network is configured from part of a ROOTED network as follows: 
    1) The RAIN-BRANCH DISABLES its normal Receive frequency, ENABLES a RAINROOT Receive fre quency, and increases Transmit power. The Transmit frequency and RAIN- ROOT Receive frequency are 25 configured as a network and Transmit frequency remains ROOTED. 
    2) The other BRANCH(es) are not involved. 
    3) The DOUBLE-HOPPING ROOT enables a RAIN-ROOT Transmit frequency (with increased power) and reconfigures the RAIN-BRANCH Receive frequency into the network associated with the RAIN-ROOT Transmit frequency. 30 c) When the rain stops, the complex processing in A) and B) above is reversed. 
    3.9 - PROTECTED network The Vitalink Bridge supports a concept termed a PROTECTED Network. A PROTECTED Network has a Transmit access point which is configured as PROTECTED. 35 If a Transmit access point is PROTECTED the Forwarding Function will only forward frames to that access point which have an F DSE which matches the Destination GLOBAL- ADDRESS. (Single destination or multicast/broadcast.) All other Forwarding rules apply. 
    The PROTECTED Network concept allows the PROTECTED station to interface to the Vitalink Bridge utilizing ENET frames without having to filter superfluous frames. Consequently PROTECTED Networks 40 can have a lower bandwidth than NON-PROTECTED networks and the processing capacity of the PRO TECTED Station can be much less than a Bridge. 
    It is anticipated that a PROTECTED station will configure most of the F DSE's in the associated Bridge using standard Bridge Management commands. The known exception is the F DSE which matches the GLOBAL-ADDRESS of the Station. The F DSE can be built in the normal fashion from a source 45 GLOBAL-ADDRESS. 
    A Bridge cannot be a PROTECTED Station relative to any Network. 
    Section 4 - high level design overview 504.1 - Vitalink Bridge roles 50 The primary role of Vitalink's Bridge is to relay Extended Network (ENET) frames to/from Vitalink's Sat ellite Backbone Network. This role is illustrated in Figure 10. 
    Secondary roles the Vitalink Bridge will also support are illustrated in Figure 11. 
    From a design perspective, a vitalink bridge will be capable of supporting the following Bridge roles: 
    a) MULTL-END-POINT medium(s) to MULTI-END-POINT medium(s) (e.g. Satellite Backbones and/or 55 LANs to Satellite Backbones and/or LANs) b) DUAL-END-POINT medium(s) to MULTI-END-POINT medium(s) (e.g. Terrestrial Links to Satellite Backbones and/or LANs) c) DUAL-END-POINT medium(s) to DUAL-END-POINT medium(s) (e.g. Terrestrial Links to Terrestrial Links etc.) 60 4.2 - Functional areas Conceptually, the Vitalink Bridge design is divided into four functional areas: 
    a) Forwarding Function b) Local/Backbone Network Control 65 14 GB 2 170 079 A 14 c) Management Functions d) Executive functions The logical organization of these functional areas is illustrated in Figure 12. 
    The Vitalink Bridge design has one Forwarding Function, one set of Management Functions, and one set of Executive Functions. These functions are executed by a CPU on the Main CPU (MCPU) board. 5 When the Vitalink Bridge is supporting multiple local andlor backbone networks, the Bridge will respec tively contain multiple Local andlor Backbone Network Control Functions. The Local and Backbone Net work Control Functions execute on both the MCPU board and their respective interface boards. 
    1 () Section 5 - forwarding function 10 The Forwarding Function conditionally forwards Extended Network Packets between two of the follow ing.. 
    a) Local Network Control b) Backbone Network Control c) Management Functions 15 All Network Control processes which input packets to the Forwarding Function run as Interrupt han dlers. Management Functions which input ENET frames run as Tasks. A typical forwarding sequence for a ENET frame from a local network is illustrated in Figure 13. 
    The discard time of single destination ENET frames from some NON-ROOTED Local Networks can be reduced significantly by utilizing a simple cache. A Discard Cache is useful when on the average there 20 are only a few stations actively utilizing the local network to interact with other local stations. A discard cache should: 
    a) Contain the last n source GLOBAL-ADDRESSes received from the network (n should equal at least 2 x the interacting station average) b) Be accessable by a rudimentary Network Control Forwarding Function 25 c) Be used for discarding only, not forwarding d) Not interfere with the use and maintenance of the F DS. 
    A typical forwarding sequence for a ENET frame from Management Functions is illustrated in Figure 14. 
    30 5.1 - Data stores 5.1.1 - Forwarding data store (FDS) The F DS is used by the Forwarding Function to determine how to forward single or multicast destina tion frames. For single destination frames, the F DS has a single entry (F DSE) for each address that has been seen as a source address in a recently processed ENET frame. All multicast F DSE's and optionally 35 single destination F DSE's are created from Reconfiguration or Set Parameters commands. 
    An F DS may contain from 1 to 65,536 Non Collision F DSE's and 0 to 8192 Collision F DSE's (C17 DSE). 
    The F DSE's and CF DSE's may share the same contigious memory segment (up to 524,288 octets) or two different contigious segments. When the number of F DSE's and CF DSE's exceed 8192, the C17 DSE's must come from a contigious segment of up to 65,536. An F DS with one shared 65,536 octet segment 40 has the format shown in Figure 15. 
    The F DSE variables are defined below - a) The first 40 bits of GLOBAL-ADDRESS that was used to create this F DSE. In single destination F DSE's, if the SNID equals ZERO, the GLOBAL-ADDRESS identifies this Bridge. 
    b) SNIDIAID is defined as follows: 45 1) In single destination frames the field is a Source NID (SNID) and bits 40-47 contain the SNID value associated with the received ENET frame that was used to create this F DSE. 
    2) For multicast destination frames, bits 40-47 contain an Array [D (AID) value that identifies that Mul ticast Array Data Store Entry associated with the multicast GLOBAL- ADDRESS used to create this F DSE. 50 c) FFF, bits 48-50, which contain the following flags: 
    1) FORWARD/D0-NOT-FORWARD ENET frame with matching Destination GLOBALADDRESS (1 bit). This flag currently not used in a multicast F DSE. 
    2) Aging Value (2 bits), one of the following values a. RECENTLY-USED 55 b. NOT-RECENTLY-USED (at least 1 DELETE cycle) c. NOT-RECENTLY-USED (at least 2 DELETE cycles) d. FIXED (can not be removed due to aging). Multicast F DSE's always have this value. 
    d) The CF DSE-INDEX, bits 51-63, which contains either: 
    1) ZERO, if there is not a subsequent CF DSE or 60 2) The INDEX associated with the next CF DSE 5.1.2 - Receiveltransmit data store (RITDS) This data store contains the following: 
    a) Bridge State (IN IT/LISTE NIOPERATE/BRO KEN) 65 GB 2 170 079 A 15 b) Bridge F DSE Type (LEARN 1 NG/NOT-LEARNI NG), Default= LEARN] NG c) Multicast Monitor Mode (TRUE/FALSE), Default=FALSE d) Transmit Data Store Entries (T DSE's) exist for each Transmit access point. Each T DSE has a unique NID value, termed a TNiD. The TNID values range from 00(16) to 39(16). TNID 00(16) is associated with Management Functions. 5 The TDSE's are ordered such that the TNID can be used as an index to locate the associated TDSE. 
    Each TDSE contains the following: 
    1) State (OFF/INIT/ON/BROKEN) 2) BROKEN reason (LOOP-DETECTED) - 3) Type (NOT-PROTECTED/PROTECTED) 10 4) Topology (NON-ROOTED/RAIN-ROOTED/ROOTED-BRANCH/ ROOT/RAIN- ROOT/SECONDARY ROOT) 5) Network Type (SATE LLITE/TE R RESTR 1AUETH ERN ET- 802.3/MANAGEMENT) 6) Statistics a. Frames transmitted 15 1. Single Destination (matching F DSE) 2. Single Destination (no F DSE) 3. Multicast Destination (matching F DSE) b. Bytes Transmitted (optional) C. Frames Discarded (congestion) 20 e) Receive Data Store Entries (RDSE's) exist for each Receive access point. Each R DSE has a unique NID value, termed a RNID. The RNID values range from 40(16) to 79(16). RNID 40(16) is associated with Management Functions. 
    *  The R DSE's are ordered such that an RNID minus 40(16) can be used as an index to locate the associ- ated R DSE. Each R DSE contains the following: 25 1) State (OFF/INIT/ON/BROKEN) 2) BROKEN Reason (LOOP-DETECTED) 3) Type (TRANSMIT-RECEIVE/RECEIVE-ONLY) 4) TNID (The value of the Transmit access point associated with this Receive access point.) 5) RAIN (TRUE/FALSE) 30 6) Network Type (SATE LLITE/TER RESTR IAL/ETH ERN ET---_8020 MANAGEMENT) 7) NON-Encapsulated frames flat (CONTAIN/D0-NOT-CONTAIN an FCS). If associated T DSE Type equals PROTECTED, the DEFAULT value equals DO-NOT-CONTAIN. Otherwise, the DEFAULT equals CONTAIN. 
    8) Statistics 35 a. Frames Received b. Frames Discarded C. Bytes Received (optional) 9) The alarm Counters for each type of Backbone Encapsulation. (i.e. BE errors, RBE errors, RE errors, RRE errors, RRDU errors, RRU errors.) 40 5.1.3 - Multicast array data store (MADS) This data store contains a set of bit array entries (MA DSE) arranged in AID order such that the AID values in multicast F DSE's can be used as indexes to locate an associated MA DSE. Each MA DSE has the structure shown in Figure 16. 45 As illustrated in Figure 16, a MA DSE contains a set of bits associated with T DSE's and a set associ ated with R DSE's. Each bit is associated with one T DSE or RDSE NID value (including MANAGEMENT) and is defined as follows: 
    a) each TDSE Bbit is defined as follows: 
    0 = FORWARD to the associated T DSE network (DEFAULT) 50 1 = DO-NOT-FORWARD to the associated T DSE network b) each RDSE Bbit is defined as follows: 
    0 = FORWARD from the associated R DSE network (DEFAULT) 1 = DO-NOT-FORWARD from the associated R DSE network - 55 5.1.4 - No match array data store (NA DS) This data store contains a single bit array (NA DSE) which has the same structure as a MA DSE. A NA DSE contains a set of bits associated with TDSE's and a set associated with RDSE's. Each bit is associated with one TDSE or RDSE NID value (including MANAGEMENT) and is defined as follows: 
    a) each TDSE bit is defined as follows: 60 0 = FORWARD to the associated T DSE network (DEFAULT) 1 = DO-NOT---FORWARD to the associated T DSE network (These bits are used to support a PROTECTED TDSE type) b) each R DSE bit is defined as follows: 
    0 = FORWARD from the associated R DSE network (DEFAULT) 65 16 GB 2 170 079 A 16 1 = DO-NOT-FORWARD from the associated R DSE network (currently the R DSE bits are not used) 5.1.5 - Discard broadcast type data store (DBTDSj A descending list of 0 to 15 Ethernet type values. The last type value always equals ZERO. If the list is 5 empty, the first entry equals ZERO. A MATCHING-FRAME-COUNT is associated with each value. 
    5.1.6 - Circular input queue data store The circular input queue (CIQ) data store is used by the forwarding function to input ENET frame proc essing information to the forwarding data store maintenance process. The CIQ contains the following: 10 a) A fixed maximum number of entries (CIQE's). Each CIQE contains the following information: 
    1) GLOBAL-ADDRESS = the source address from the ENET frame 2) SNID = Source NID parameter from the OUTPUT-CALL b) A fixed maximum number of entries configuration CIQE's (CCIQE). Each CCIQE contains the fol lowing information: 15 1) USED/NOT-USED flag 2) GLOBAL-ADDRESS = the F DSE GLOBAL,_ADDRESS 3) SNID = the F DSE SNID value c) The data store also contains the following queue depth and threshold values to monitor CIQ processing: 20 1) CIQE-TOTAL - the total number of CIQE's 2) EMPTY_CIQE the number of empty CIQE's 3) THRESHOLD__2 - an acceptable EMPTY-CIQE queue value that indicates that CIQE maintenance can take place at a normal priority. 
    4) THRESHOLD-1 - an EMPTY-CIQE queue value that indicates that the number of non empty 25 CIQE's is excessive. 
    5) THRESHOLD-0 - an EMPTY-CIQE queue value that is used to limit the forwarding maintenance processing time when the EMPTY-CIQE value equals zero. 
    5.1.7 - FDSE maintenance data store (FMDS) 30 This data store contains a pointer to the FDS and the LIF 0 queue of EMPTY-COLLISION-F DSE's. The data store also contains the following: 
    a) the FDS HASH-INDEX-SIZE b) count of TOTAL-NUMBER of F DSE's C) count of CURRENTLY-DEQUEUED F DSE's 35 d) count of TOTAL-NUMBER of COLLISION-F DSE's e) count of CURRENTLY-DEQUEUED COLLISION-F DSE's d) and e) are only present when F DSE's and COLLISION-F DSE's come from different memory seg ment (this will not be supported in the initial release) f) count of MAXIMUM-NUMBER of F DSE's dequeued (high water mark) 40 g) the F DSE-SHORTAGE value. (i.e. CURRENTLY-DEQUELIED value which causes the invocation of the DELETE process) h) count of number of DISCARDED-CIOE's i) count of number of UPDATED F DSE's j) the following counts of COLLISION_FDSE index values with n-F DSE's 45 1) count of double collisions 2) count of triple collisions 3) count of quadruple collisions 4) count of 5 or more collisions h) count of number of RESET's received. 50 6. 1.8 - Priority 2 forwarding data store maintenance mailbox The forwarding data store maintenance mailbox is used by the management functions to forward net work management requests. 
    55 5.2 - ENET frame service interfaces The forwarding function interfaces to both network control and management functions. The input and output service interface between the forwarding function and network control is considered a network control service interface and consequently is defined in the network control section. 
    The input and output service interface between the forwarding function and management functions is 60 considered a forwarding function service interface and consiquently is defined below. 
    5.2.1 - Forwarding function input The forwarding function input interface is the service interface utilized to input an ENET frame to man agement functions. The forwarding function input interface utilizes a procedure call and return. The re- 65 17 GB 2 170 079 A 17 quired parameters for the call and return are: 
    INPUT---CALL (Forwarding function to management functions) INPUT-FRAME The address to the linked list of buffer descriptors which identifies the complete ENET frame. 
    FCS - Identifies whether the ENET frame contains/does not contain an FCS. 5 SOURCE-NETWORK-IDENTIFIER(SNID) - A two octet system specific identifier which identifies the source network. The two octet field is defined as follows: 
    bits 0-7 - These bits are reserved. They must have a value of 00(16) bits 8-15 - These bits contain the source NID value. INPUT- RETURN (Management functions to for- warding function) 10 RETURN-CODE - TBD. 
    5.2.2 - Forwarding function output The forwarding function output interface is the service interface utilized to output an ENET frame from management functions. The forwarding function output interface utilizes a procedure call and return. The 15 required parameters for the call and return are: 
    OUTPUT-CALL (Management functions to forwarding function) OUTPUT-FRAME The address of the linked list of buffer descriptors which identify the complete ENET frame FCS - Identifies whether the ENET frame contains/does not contain an FCS. 20 SOURCE-NETWORK-IDENTIFIER (SNID) - A two octet system specific identifier which identifies the ENET fr6me source. The two octet field is defined as follows: 
    bits 0-7 - These bits are reserved. They must have a value of 00(16). 
    bits 8-15 - These bits contain the NID value of 0006), which means the ENET frame is from manage- ment functions. 25 DESTI NATIO N-N ETWOR K-IDENTI FIER (DNID) - A two octet system specified identifier which is defined as follows: 
    bits 0-7 - are defined as OERRRRRR, where 0 = the FORWARD-ONLY flag and is defined as follows 0 = FORWARD-ONLY flag is off 30 1 = the ENET frame is to be forwarded only to the network associated with the NID in bits 8-15. 
    E = the FORWARD-EXCEPT flag and is defined as follows: 
    0 = FORWARD-EXCEPT flag is off 1 = the ENET frame is to be forwarded all networks except the network associated with the NID in bits 8-15. One used for multicast frames. 35 RRRRRR = RESERVED and have a value of 0000000. 
    bits 8-15 - if the 0 and E flags equal 00(2), these bits have value of 00(16). Otherwise, these bits contain a SNID value which is used by the forwarding function to locate the associated TNID value. 
    OUTPUT-RETURN (Forwarding function to management functions) RETURN-CODE TBD. 40 5.4 - Forwarding function process description 
    Upon receipt of a CALL containing an ENET frame, the forwarding function processes the frame as follows: 
    45 5.4. 1 - Pre-forwarding processing If bridge type equals LEARNING, and the frame was input from network control, the SNID value is used to locate the associated R DSE (termed the SNID_R DSE). If the SNID-R DSE state is not equal to OFF, the forwarding function creates an entry in the circular input queue (CIQ) and decrements the EMPTY_CIQE value. Normally, the forwarding function does not interact with the forwarding data store maintenance 50 process (F MP) running at PRIORITY-0. The exceptions are as follows; a) If the EMPTY_CIQE value equals THRESHOLD__11, the FMP is set dispatchable at its PRIORITY-1. 
    b) If the EMPTY-CIQE value equals zero, the F MP is called by the forwarding function. The F MP executes (as an interrupt handler) until the EMPTY_CIQE value equals THRESHOLD-0. 
    55 5.4.2 - Directed forwarding of an ENET frame The ENET frame is forwarded to the network identified in a DNID CALL parameter with the FOR WARD-ONLY flag set as follows: 
    a) If any of the following are true, the ENET frame will not be forwarded. 
    1) The ENET frame was input from network control. 60 2) The forwarding state is equal to OFF. 
    b) The DNID NID value is used to locate the associated T DSE. 
    c) If T DSE equals OFF, the ENET frame will not be forwarded. 
    d) Otherwise, it is forwarded to the network associated with the T DSE as follows: 
    1) If T DSE topology equals NON-ROOTED, ROOT, or SECONDARY- ROOT, the following occurs: 65 18 GB 2 170 079 A 18 a. If there is no FCS, the frame is passed to the network control encapsulation process associated with the T DSE network. The value of the ENCAPSULATION-ID equals NO-FCS and the ENCAPSULATION-SOURCE---ADDRESS value equals the GLOBAL-ADDRESS of this bridge b. Otherwise, the frame is passed to network control process. 
    2) IF T DSE topology equals ROOTED-BRANCH, the frame is passed to the network control encapsu- 5 lation process associated with the T DSE network. The value of the ENCAPSULATION-ID equals BE and the ENCAPSULATION-SOURCE-ADDRESS value equals the GLOBAL-ADDRESS of the bridge. 
    3) If T DSE topology equals RAIN-ROOTED, the frame is passed to the network control encapsulation process associated with the T DSE network. The value of the ENCAPSULATION-ID equals RBE and the ENCAPSULATION-SOURCE-ADDRESS value equals the GLOBAL-ADDRESS of the bridge. 10 4) If T DSE topology equals RAIN-ROOT processing is dependent, on the FDSE-RDSE RAIN value as follows: 
    a) If RAIN equals FALSE, the following occurs: 
    1) If there is no FCS, the frame is passed to the network control encapsulation process associated with the TDSE network. The value of the ENCAPSULATION-M equals NOT- ENCAPSULATED and the EN- 15 CAPS U LATI 0 N-SOU FICE---ADDRESS value equals the GLOBAL-ADDRESS of the bridge. 
    2) Otherwise, the frame is passed to the network control process. 
    b) Otherwise, the frame is passed to the network control encapsulation process associated with the TDSE network. The value of the ENCAPSULATION-ID equals FIRE and the ENCAPSULATION SOURCE-ADDRESS value equals the GLOBAL-ADDRESS of this bridge. 20 Otherwise, the forwarding of the ENET frame as defined below. 
    5.4.3 - Technique for locating a matching F DSE The forwarding function uses the destination GLOBAL-ADDRESS of a ENET frame to search the F DS to locate a matching F DSE. The technique for locating a matching FDSE is defined below: 25 a) The trailing n bits (n - MS-INDEX-SIZE) of the destination GLOBAL- ADDRESS are multiplied by 2 and used as an index to the F DSE index. 
    b) If the indexed FDS index value is 0000(16), there is no matching F DSE. 
    c) Otherwise, the first 40 bits of the ENET frame's destination GLOBALADDRESS is compared to the first 40 bits of the ' F DSE. If the two values are equal, a matching F DSE has been found. 30 d) Otherwise, the F DSE CF13SE-index is examined as follows: 
    1) If equal to ZERO, there is no matching F DSE. 
    2) Otherwise, the F DSE C17 DSE-INDEX is used to locate the COLLISION-F DSE and processing continues as in b. above. 
    e) If a matching F DSE or CF DSE is found it is referred to as the F DSE or the matching F DSE. 35 5.4.4 - Forwarding of a single destination ENET frame The forwarding of single destination ENET frames is dependent upon whether a matching F DSE was located. Both cases are defined below. 
    a) If a matching F DSE is found, the following occurs: 40 1) If the ageing value in the matched F DSE is not equal to FIXED, it is set to the value of RE CENTLY-USED. 
    2) If the GLOBAL---ADDRESS is a local address [i.e., the FDSE SNID equals 00(16fl, the ENET frame is forwarded to DIF (local address F DSE's have an Ageing value of FIXED). 
    3) Otherwise, if the F DSE FORWARD/D0-NOT-FORWARD flag has a value of DONOT-FOR- 45 WARD, the frame is discarded. 
    4) Otherwise, the R DSE associated with the SNID in the matched F DSE is located (this R DSE is termed the F DSE- R DSE). If the F DSE-R DSE state is not equal to ON, the frame is discarded. 
    5) Otherwise, the T DSE associated with the TNID in the F DSE-R DSE is located (this is the only T DSE that will need to be located). If the T DSE's state equals to OFF, the frame is discarded. 50 6) Otherwise, if the ENET frame was input from management functions, it is forwarded to the net work associated with the T DSE. (i.e. local management functions can forward during INIT/BROKEN) as follows: 
    a. If T DSE topology equals NON-ROOTED, ROOT or SECONDARY-ROOT, the following occurs: 
    1) If there is no FCS, the frame is passed to the network control encapsulation process associated 55 with the T DSE network. The value of the ENCAPSULATION-ID equals NO-FCS and the ENCAPSULA TION-SOURCE---ADDRESS value equals the GLOBAL-ADDRESS of the bridge. 
    2) Otherwise, the frame is passed to network control process b. If T DSE topology equals ROOTED-BRANCH, the frame is passed to the network control encapsu- lation process associated with the TDSE network. The value of the ENCAPSULATION-ID equals BE and the 60 ENCAPSULATION- SOURCE---ADDRESS value equals the GLOBAL-ADDRESS of this bridge c. If T DSE topology equals RAIN-ROOTED, the frame is passed to the network control encapsulation process associated with the T DSE network. The value of the ENCAPSULATION-ID equals RBE and the ENCAPSULATION- SOURCE---ADDRESS value equals the GLOBAL-ADDRESS of this bridge 65 d. If T DSE topology equals RAIN-ROOT processing is dependent on the F DSE-R DSE RAIN value 65 19 GB 2 170 079 A 19 as follows: 
    (a) If RAIN equals FALSE, the frame is passed to network and the following occurs: 
    (1) If there is no F CS, the frame is passed to the network control encapsulation process associated with the TDSE network. The value of the ENCAPSULATION-ID equals NO-F CS and the ENCAPSULA- TION-SOURCE- ADDRESS value equals the GLOBAL-ADDRESS of this bridge. 5 (2) Otherwise, the frame is passed to Network Control process (b) Otherwise, the frame is passed to the network control encapsulation process associated with the TDSE network. The value of the ENCAPSULATION- ID equals RRE and the ENCAPSULATION-SOURCE-ADDRESS value equals the GLOBAL-ADDRESS of this bridge 7)Otherwise, the frame is discarded, if either of the following is TRUE: 10 a. The RITDS bridge state is not equal to OPERATE b. The TDSE state is not equal to ON 8) Otherwise, the RDSE associated with the SNID INPUT- CALL parameter is located (this RDSE is termed the SNID--- RDSE). If the SNID-RDSE state is not equal to ON, the frame is discarded. Otherwise, the TNID value in the SNID- RDSE is compared against the TNID value in the FDSE-RDSE. 15 a. If equal, the following occurs: 
    1. If the TDSE topology equals NON-ROOTED, RAIN- ROOTED, ROOTED-BRANCH, or SECONDARY-ROOT, the ENET frame is discarded. 
    2. If the TDSE topology equals ROOT, the following occurs: 
    (a) If the INPUT-CALL EID parameter equals BE, the ENET frame is passed to the network control 20 encapsulation process associated with the TDSE network. The value of the ENCAPSULATION-ID equals RE. 
    (b) If the INPUT-CALL EID parameter equals NOT- ENCAPSULATED, the frame is discarded. 
    (c) If the INPUT-CALL EID parameter does not equal BE, the following occurs: 
    (1) An ALARM is generated. 25 (2) The frame is discarded. 
    3. Otherwise, the value of the TIDSE topology equals RAIN-ROOT and the processing of the ENET frame is based on the INPUT-CALL EID parameter as follows: 
    (a) If the EID equals NOT-ENCAPSULATED, the following occurs: 
    (1) The SNID-RDSE RAIN value is set to FALSE 30 (2) If the FDSE-RDSE RAIN value equals TRUE, the ENET frame is passed to the network control encapsulation process associated with the TDSE network. The value of the ENCAPSULATION-ID equals RRE (3) Otherwise, the ENET frame is discarded (b) If the ENCAPSULATION-ID equals RBE, the following occurs: 35 (1) The SNID-RDSE RAIN value is set to TRUE (2) The ENET frame is passed to the network control encapsulation process associated with the TDSE network. The value of the ENCAPSULATION-ID equals RRE. (The FDSE- RDSE RAIN value is not ex amined because the BRANCH may be changing to RAIN.) (c) Otherwise, the following occurs: 40 (1) An ALARM is generated. 
    (2) The frame is discarded. 
    b. Otherwise, if not equal, the ENET is forwarded to the TDSE network as follows (i.e., using the same logic as if the frame came from management functions) 1. If TDSE topology equals NON-ROOTED or ROOT, the following occurs: 45 (a) If there is no FCS, the frame is passed to the network control encapsulation process associ ated with the TDSE network. The value of the ENCAPSULATION-ID equals NO- FCS and the ENCAPSULA TION-SOURCE-ADDRESS value equals the GLOBAL_ ADDRESS of this bridge (b) Otherwise, the frame is passed to network control process 2. If TDSE topology equals ROOTED-BRANCH, the frame is passed to the network control encap- 50 sulation process associated with the TDSE network. The value of the ENCAPSULATION-[D equals BE. 
    3. If TIDSE topology equals RAIN-ROOTED, the frame is passed to the network control encapsula tion process associated with the TDSE network. The value of the ENCAPSULATION-[1) equals RRE. 
    4. If TIDSE topology equals RAIN-ROOT processing is dependent, on the FDSE-RDSE RAIN value as follows: 55 (a) If RAIN equals FALSE, the following occurs: 
    (1) If there is no FCS, the frame is passed to the network control encapsulation process associ ated with the TDSE network. The value of the ENCAPSULATION-ID equals NOT- ENCAPSULATED and the ENCAPSULATION-SOURCEADDRESS value equals the GLOBAL-ADDRESS of this bridge (2) Otherwise, the frame is passed to network control process 60 (b) Otherwise, the frame is passed to the network control encapsulation process associated with the TDSE network. The value of the ENCAPSULATION-ID equals RRE. 
    b) If no matching FDSE is found, the ENET frame is processed as follows: 
    1) If the frame was input from management functions, and the NADSE bit associated with the MANAGEMENT RDSE equals DO-NOT-FORWARD, the frame is discarded. Otherwise, the frame is for- 65 GB 2 170 079 A 20 warded as follows to all transmit access points with a TDSE for which the TDSE type is equal to TRANSMIT- RECEIVE and the TDSE state is not equal to OFF. 
    a. If TDSE topology equals SECONDARY-ROOT, NON- ROOTED, or ROOT, the following occurs: 
    1) If there is no FCS, the frame is passed to the network control encapsulation process associated with the TDSE network. The value of the ENCAPSULATION-ID equals NO-FCS and the ENCAPSULATION-SOURCE-ADDRESS value equals the GLOBAL-ADDRESS of this bridge 2) Otherwise the frame is passed to network control process b. If TDSE topology equals ROOTED-BRANCH, the frame is passed to the network control encapsulation process associated with the TDSE network. The value of the ENCAPSULATION-W equals BE and ENCAPSULATION-SOURCE- ADDRESS equals the GLOBAL-ADDRESS of this bridge 10 c. If TDSE topology equals RAIN-ROOTED, the frame is passed to the network control encapsulation process associated with the TDSE network. The value of the ENCAPSULATION-] D equals RBE and ENCAPSULATION- SOURCE- ADDRESS equals the GLOBAL-ADDRESS of this bridge d. If TDSE topology equals RAIN-ROOT, the frame is passed to the network control encapsulation process associated with the TDSE network. The value of the ENCAPSULATIONID equals RRU and EN- 15 CAPSULATION- SOURCE-ADDRESS equals the GLOBAL-ADDRESS of this bridge 2) If the frame was input from a locallbackbone network, it is processed as follows: 
    a. If RITDS bridge state is not equal to OPERATE, the frame is discarded. 
    b. Otherwise, the RDSE associated with the SNID INPUT- CALL parameter is located (the located RDSE is again termed the SNID-RDSE). If the SNID-RDSE state is not equal to ON, the frame is discarded.20 c. Otherwise, the ENET frame is forwarded to all transmit access points with a TDSE as follows: 
    1. The TDSE state equals ON 2. The NADSE bit associated with the TDSE equals FORWARD 3. If the TNID associated with the TDSE does not equal the SNID-RDSE TNID value the following occurs: 25 (a) If TDSE topology equals NON-ROOTED SECONDARY- ROOT, or ROOT, the following occurs: 
    (1) If there is no FCS, the frame is passed to the network control encapsulation process associ ated with the TDSE network. The value of the ENCAPSULATION-ID equals NO- 17CS and the ENCAPSULA TIOAN-SOURCE-ADDRESS value equals the GLOBAL-ADDRESS of this bridge (2) Otherwise, the frame is passed to network control process 30 (b) If TDSE topology equals ROOTED-BRANCH, the frame is passed to the network control encap sulation process associated with the TDSE network. The value of the ENCAPSULATION-ID equals BE. 
    (c) If TDSE topology equals RAIN-ROOTED, the frame is passed to the network control encapsula tion process associated with the TDSE network. The value of the ENCAPSULATION-ID equals RBE. 
    (d) If TDSE topology equals RAIN-ROOT, the frame is passed to the network control encapsulation 35 process associated with the TDSE network. The value of the ENCAPSULATION- ID equals RRU. 
    4. If the TNID associated with the TDSE equals the SNID-RDSE TNID value the following occurs: 
    (a) if TDSE topology equals NON-ROOTED, SECONDARY-ROOT, RAIN-ROOTED, or ROOTED-BRANCH, the frame is not forwarded. 
    (b) If TDSE topology equals ROOT, the processing is dependent upon the INPUT-CALL EID param- 40 eter value as follows: 
    (1) If the EID equals BE, the ENET frame is passed to the network control encapsulation process associated with the TDSE network. The value of the ENCAPSULATION-ID equals RE. 
    (2) If the EID equals NON-ENCAPSULATED, the ENET frame is not forwarded (3) Otherwise, the following occurs 45 (a) An ALARM is generated. 
    (b) The frame is not forwarded. 
    (c) If TDSE topology equals RAIN-ROOT, the following. occurs: 
    (1) If the EID equals (a) NOT-EN CAPS U LATED, the SNID-RDSE RAIN value ios set to FALSE and the frame is passed to 50 the network control encapsulation process associated with the TDSE network. The value of the ENCAP SULATION-ID equals RRDU. 
    (b) RBE, the SNID, RDSE, RAIN value is set to TRUE and the frame is passed to the network con trol encapsulation process associated with the TDSE network. The value of the ENCAPSULATION-ID equals RRDU. 55 (c) Otherwise, the following occurs (1) An ALARM is generated (2) The frame is discarded 605.4.5 - Forwarding of multicastibroadcast destination ENET frame 60 The forwarding of multicast/broadcast ENET frames is defined below: 
    a) If the ENET frame was input from a local/backbone network, the following occurs: 
    1) if matching FDSE is not found (as described in 5.4.3), the following occurs: 
    a. If the RITDS bridge state is not equal to OPERATE, the frame is discarded. 
    b. Otherwise, the RDSE associated with the SNID INPUT_ CALL parameter is located (the located 65 21 GB 2 170 079 A 21 RDSE is again termed the SNID-RDSE). If the SNID-RDSE state is not equal to ON, the frame is discarded. 
    c. Otherwise, if the NADSE bit associated the SNiD-RDSE SNID equals DONOT-FORWARD, the frame is discarded. 
    d. Otherwise, the forwarding of the ENET frame to each Transmit access point with a TDSE oc- curs as follows: 5 1. The TDSE state equals ON 2. The NADSE bit associated with the TDSE equals FORWARD 3. If the TNID associated with the TDSE does not equal the SNID-RDSE TNID value the following occurs: 
    (a) If TDSE topology equals NON-ROOTED SECONDARY- ROOT, or ROOT, the following occurs: 10 (1) if there is no FCS, the frame is passed to the network control encapsulation process associated with the TDSE network. The value of the ENCAPSULATION-ID equals NO-FCS, and the ENCAPSULATION-SOURCE-ADDRESS value equals the GLOBAL-ADDRESS of this bridge. 
    (2) Otherwise, the frame is passed to network control process. 
    (b) Otherwise, if TDSE topology equals ROOT-BRANCH, the frame is passed to the network control 15 encapsulation process associated with the TDSE network. The value of the ENCAPSULATION-ID equals BE. 
    (c) Otherwise, if TDSE topology equals RAIN-ROOTED, the frame is passed to the network control encapsulation process associated with the TDSE network. The value of the ENCAPSULATION-ID equals RBE. 20 (d) Otherwise, if TDSE topology equals RAIN-ROOT, the frame is passed to the network control encapsulation process associated with the TDSE network. The value of the ENCAPSULATION-ID equals RRU. 
    4. Otherwise, if the TNID associated with the TDSE equals the SNID-RDSE TNID value the follow ing occurs: 25 (a) if TDSE topology equals NON-ROOTED, SECONDARY- ROOT, RAIN-ROOTED, or ROOTED-BRANCH, the frame is not forwarded. 
    (b) Otherwise, if TDSE topology equals ROOT, the processing is dependent upon the INPUT-CALL EID parameter value as follows: 
    (1) If the EID equals BE, the ENET frame is passed to the network control encapsulation process 30 associated with the TDSE network. The value of the ENCAPSULATION-ID equals RE (2) If the EID equals NOT-ENCAPSULATED, the ENET frame is not forwarded (3) Otherwise, the following occurs (a) An ALARM is generated. 
    (b) The frame is discarded. 35 (c) Otherwise, if TDSE topology equals RAIN-ROOT, the following occurs: 
    (1) If the EID equals (a) NOT-ENCAPSULATED, the SNID-RDSE RAIN value is set to FALSE and the frame is passed to the network control encapsulation process associated with the TDSE network. The value of the ENCAP SULATION-ID equals RRDU. 40 (b) RBE, the SNIQ-RDSE RAIN value is set to TRUE and the frame is passed to the network control encapsulation process associated with the TDSE network. The value of the ENCAPSULATION-ID equals RRDU. 
    (c) Otherwise, the following occurs (1) An ALARM is generated. 45 (2) the frame is discarded. 
    2) If a matching FDSE is found (as described in 5.4.3), the following occurs: 
    a. The associated MADSE is located using the FDSE AID value. 
    b. If either the MADSE bit associated with the MANAGEMENT TDSE equals FORWARD or the R/ TDS multicast monitor mode flag equals TRUE, a copy of the ENET frame is forwarded to management 50 functions. 
    c. Otherwise, if the destination address value equals the broadcast value and the type field matches a value in the DBTDS, the frame is discarded and the associated MATCH 1 NG-FRAME-COU NT value is incremented. 
    d. Otherwise, if the R/TDS bridge state is not equal to OPERATE, the frame is discarded. 55 e. Otherwise, the RDSE associated with the SNID INPUT_ CALL parameter is located (the located RDSE is again termed the SNID-RDSE). If the SNID-RDSE state is not equal to ON, the frame is discarded, f. Otherwise, the MADSE bit associated with the SNID- RDSE parameter in the INPUT-CALL is lo cated. If the value of the located bit equals DO-NOT-FORWARD, the ENET frame is discarded. 
    g. The forwarding of the ENET frame to each transmit access points with a TDSE occurs as fol- 60 lows: 
    1. The TDSE state equals ON 2. The MADSE bit associated with the TDSE equals FORWARD 3. If the TNID associated with the TDSE does not equal the SNID-RDSE TNID value the following occurs: 65 22 GB 2 170 079 A 22 (a) if TDSE topology equals NON-ROOTED SECONDARY_ ROOT, or ROOT, the following occurs: 
    (1) if there is no FCS, the frame is passed to the network control encapsulation process associ ated with the TDSE network. The value of the ENCAPSULATION-ID equals NO- FCS and the ENCAPSULA TION-SOURCE-ADDRESS value equals the GLOBAL-ADDRESS of this bridge. 
    (2) Otherwise, the frame is passed to network control process. 5 (b) Otherwise, if TDSE topology equals or ROOTED- BRANCH, the frame is passed to the network control encapsulation process associated with the TDSE network. The value of the ENCAPSULATION-ID equals BE. 
    (c) Otherwise, if TDSE topology equals RAW-ROOTED, the frame is passed to the network control encapsulation process associated with the TDSE network. The value of the ENCAPSULATION-0 equals 10 RBE. 
    (d) Otherwise, if TDSE topology equals RAIN-ROOT, the frame is passed to the network control encapsulation process associated with the TDSE network. The value of the ENCAPSULATION-ID equals RRU. 
    4.Otherwise, if the TNID associated with the TDSE equals the SNID-RDSE TNID value the following 15 occurs: 
    (a) If TDSE topology equals NON-ROOTED, SECONDARY-ROOT, RAIN-ROOTED, or ROOTED-BRANCH, the frame is not forwarded. 
    (b) Otherwise, if TDSE topology equals ROOT, the processing is dependent upon the INPUT-CALL EID parameter value as follows: 20 (1) If the EID equals BE, the ENET frame is passed to the network control encapsulation process associated with the TDSE network. The value of the ENCAPSULATION-ID equals RE (2) If the EID equals NOT-ENCAPSULATED, the ENET frame is not forwarded (3) Otherwise, the following occurs (a) An ALARM is generated. 25 (b) The frame is discarded. 
    (c) Otherwise, if TDSE topology equals RAIN-ROOT, the following occurs: 
    (1) If the EID equals (a) NOT-ENCAPSULATED, the SNID-RDSE RAIN value is set to FALSE and the frame is passed to the network control encapsulation process associated with the TDSE network. The value of the ENCAPSULATION-113 equals RRDU. 
    (b) RBE, the SNID-RAIN value is set to TRUE and the frame is passed to the network control en capsulation process associated with the TDSE network. The value of the ENCAPSULATION-ID equals RRDU. 
    (c) Otherwise, the following occurs 35 (1) An ALARM is generated. 
    (2) The frame is not forwarded. 
    b) Otherwise, the ENET frame was input from management functions and the following occurs: 
    1) If the frame was input from management functions, and the NADSE bit associated with the 40 MANAGEMENT RDSE equals DO-NOT- FORWARD, the frame is discarded. Otherwise, the frame is for warded as follows to all transmit access points for which the following is true: 
    a. The TDSE type is equal to TRANSMIT-RECEIVE b. The TDSE state is not equal to OFF c. If the OUTPUT-CALL contained a DNID with the FORWARD-EXCEPT flag, the NID associated 45 with the TDSE network does not equal the NID value in the DNID d. If TDSE topology equals SECONDARY-ROOT, NON- ROOTED, OR ROOT, the following occurs: 
    1. If there is no FCS, the frame is passed to the network control encapsulation process associated with the TDSE network. The value of the ENCAPSULATION-ID equals NOT- ENCAPSULATED and the EN CAPS U LATIO N-SOU RCE- ADDRESS value equals the GLOBAL-ADDRESS of this bridge 50 2. Otherwise, the frame is passed to network control process e. If TDSE topology equals ROOTED-BRANCH, the frame is passed to the network control encap sulation process associated with the TDSE network. The value of the ENCAPSULATION-0 equals BE and EN CAPS U LATI ON-SOU RCE-ADDRESS equals the GLOBAL---ADDRESS of this bridge. 
    f. If TDSE topology equals RAIN-ROOTED, the frame is passed to the network control encapsula- 55 tion process associated with the T13SE network. The value of the ENCAPSULATION-0 equals RBE and ENCAPSULATION-SOURCE-ADDRESS equals the GLOBAL-ADDRESS of this bridge 9. If TDSE topology equals RAIN-ROOT, the frame is passed to the network control encapsulation process associated with the TDSE network. The value of the ENCAPSULATIONID equals RRU and EN CAPSULATION-SOURCE--ADDRESS equals the GLOBALADDRESS of this bridge 60 2) Otherwise, a matching FDSE is found (as described in 5.4.3), and the associated MADSE is located using the FDSE AID value 3) If the MADSE bit associated with the MANAGEMENT RDSE equals DO-NOT- FORWARD, the frame is discarded 4) Otherwise, the ENET frame is forwarded to all transmit access points: 65 23 GB 2 170 079 A 23 a. The TDSE state is not equal to OFF b. If the OUTPUT-CALL contained a DNID with the FORWARD-EXCEPT flat, the Nil) associated with the TDSE network does not equal the NID value in the DNID c. The MADSE bit associated with the TDSE TNID equals FORWARD d. If TDSE topology equals NON-ROOTED, SECONDARYROOT or ROOT, the following occurs: 5 1. If there is not FCS, the frame is passed to the network control encapsulation process associated with the TDSE network. The value of the ENCAPSULATION-ID equals NOT- ENCAPSULATED and the EN CAPS U LATiO N-SOU RCE- ADDRESS value equals the GLOBAL-ADDRESS of this bridge 2. Otherwise, the frame is passed to network control process. 
    e. If TDSE topology equals RAIN-ROOTED, the frame is passed to the network control encapsulation 10 process associated with the TDSE network. The value of the ENCAPSULATION- ID equals RBE and ENCAP SULATION-SOURCEADDRESS equals the GLOBAL-ADDRESS of this bridge f. If TDSE topology equals ROOTEQ-13RANCH, the frame is passed to the network control encapsula tion process associated with the TDSE network. The value of the ENCAPSULATION-ID equals BE and EN CAPSULATION-SOURCE- ADDRESS equals the GLOBAL-ADDRESS of this bridge 15 9. If TDSE topology equals RAiN-ROOT, the frame is passed to the network control encapsulation process associated with the TDSE network. The value of the ENCAPSULATION- ID equals RRU and EN CAPSULATiON-SOURCE- ADDRESS equals the GLOBAL-ADDRESS of this bridge 5.5 - Forwarding data store maintenance process description 20 
    The forwarding data store maintenance processes (FMP's) are totally responsible for maintaining the forwarding data store. (The special TRB and ROB processing must still be added to this section.) Maintenance of the data store includes: 
    a) Creating new FDSE's. 
    b) Updating existing FIDSE's. 25 c) Deleting unused FDSE's. 
    The creating of new entries and updating existing entries is handled by a CREATE-UPDATE process that runs at 3 priorities: 
    PRiORITY-2 - a high background priority 
    PRIORITY-1 - a priority which is higher than all background tasks 30 
    PRIORiTY-O - a priority which interrupts the forwarding function processing When a request is received, the entire FDS must be purged. This is handled by a RESET process which runs at PRIORiTY-1 Deleting old entries is handled by a DELETE process that normally runs at PRIORITY-3 which is lower than PRIORITY-2. However, in some cases the DELETE process is CALLED by the CREATE-UPDATE proc- 35 ess. 
    SECTION 6 - Local/backbone network control The logical structure of a local or backbone network control is illustrated in Figure 17. 
    As Figure 17 illustrates, there are two external interfaces to a local/backbone network control. The in- 40 terface labeled 1. is the frame-related interface and is between the forwarding function and one of the following processes: 
    a) Network interface b) Translation c) Encapsulation/decapsulation 45 The interface labeled 2. is the management-related interface and is a queued interface. These interfaces are discussed later in this section. The above figure also identifies the following major processes within a local/backbone network control. 
    a) Translation or encapsulation/decapsulation b) Network interface 50 c) Local/backbone network management These processes are also discussed later in this section. 
    6. 1 - Data stores 6. 1. 1 - Locallbackbone network interface (NI) data store 55 An NI data store is defined for each local/backbone network. The data store contains the following: 
    a) The NID of local/backbone network b) The state of the locai/backbone network (OFF, INIT, ON, BROKEN). 
    c) The mode of the local/backbone network (NORMALIPROMISCUOUS) d) Pointers to the following: 60 1) Network interface output queue data store 2) Network interface input queue data store 3) Input filter data store 4) Management functions mailbox 5)]nit process mailbox 65 24 GB 2 170 079 A 24 6.1.2 - Network interface output queue (NIOQJ data store The NIOCI contains a FIFO queue for ENET frames to be transmitted to a local/backbone network. A network interface process in the MCPU inserts the ENET frames into the NIOQ. A network interface proc ess in the network interface board removes the ENET frames in a FIFO manner. The NIOQ also contains the following statistics: 5 1) Frames sent 2) Bytes sent 3) Current queue depth in bytes 4) Discard depth in bytes Each of the above statistical fields is a 32 bit unsigned integer. 10 
    6.1.3 - Network interface input queue (NIIQJ data store -. 
    The NIIQ contains a FIFO queue for ENET frames received from a local/backbone network. A network interface process on the network interface board inserts ENET frames into the NIIQ. A network interface process in the MCPU removes the ENET frames in a FIFO manner. The NIOG also contains a pointer to 15 the associated NI and the following statistics: 
    1) Frames received 2) Bytes received 3) Bridge frames received (frames sent to this system) 4) Bridge bytes received (bytes sent to this system) 20 Each of the above statistical fields is a 32 bit unsigned integer. 
    6.1.4 - Input filter data store The filter data store WILDS) contains the following address information that is utilized to filter received frames 25 a) If the network is in NORMAL mode, the data store contains the system's GLOBAL-ADDRESS. 
    b) The data store also contains the following: 
    1) A 40 bit VITAU N K-M U LTICAST-1 D field which is defined as follows: 
    a. The first 24 bits equals the assigned Vitalink company value plus the broadcast bit (bit 7 = 1). 
    30' b. The last 16 bits are set to zero 30 2) The following list of FILDS entries. Each FILDSE is associated with either: 
    a. A non encapsulated ENET frame with an FCS b. The last 8 bits of an assigned Vitalink multicast value FILDSE FLAGS ASSOCIATED VALUE 35 PASS/DISCARD/ERROR FCS (ENET frame with FCS) PASS/DISCARD/DECAPSULATE/ERROR NO-FCS 40 Two sets of the following FILDSE's are specified, one for ENET frames without FCS's and one for ENET frames with FCS's. 
    PASS/DISCARD/DECAPSULATE/ERROR BRANCH ENCAPSULATION(BE) PASS/DISCARD/DECAPSULATE/ERROR ROOT- 45 ENCAPSULATION (RE) PASS/DISCARD/DECAPSULATE/ERROR RAIN-ROOT ENCAPSULATION(RRE) PASS/DISCARD/DECAPSULATE/ERROR RAIN-ROOT-DOUBLE HOPPED- 50 UNKNOWN(RRDU) PASS/DISCARD/DECAPSULATE/ERROR RAIN-ROOT UNKNOWN(RRU) PASS/DISCARD/DECAPSULATE/ERROR RAIN-BRANCH ENCAPSULATION(RBE) 55 Each FILDSE also contains a count of the number of ERROR frames discarded. 
    The FILDSE flag values are set based on the value of the associated TDSE topology as defined below. 
    Other than FCS, the FILDSE flag value of PASS is only used in BMUX's and IMUX's where all multicast values are configured as PASS. 60 GB 2 170 079 A 25 TDSE TOPOL OG Y FIDLSEMULTICAST VALUES FILDSE FLA G VA L UE NON-ROOTED FCS PASS NO-FCS+RRE+RRDU+RRU DECAPSULATE 5 RBE DISCARD BE+RE ERROR RAIN-ROOTED RRE+RRDU+RRU DECAPSULATE FCS+NO-RCS+RBE DISCARD 10 BE+RE ERROR ROOTED-BRANCH FCS PASS NO-FCS+RE DECAPSULATE BE+RRE+RRDU+RRU+RBE ERROR 15 ROOT FCS PASS NO-FCS+BE DECAPSULATE RE+RRE+RRDU+RRU+RBE ERROR RAIN-ROOT FCS PASS 20 NO-FCS+RBE DECAPSULATE BE+RE+RRE+RRDU+RRU ERROR SECONDARY-ROOT FCS PASS 25 NO-FCS+BE DECAPSULATE - RE DISCARD RRE+RRDU+RRU+RBE ERROR 30 6.1.5 - Network control (NO mailbox A FIFO queue with two priorities, normal and urgent. An urgent message is inserted at the front of the queue, after other urgent messages. All data link management requests are inserted into the NC mailbox. 
    6.1.6 - Network dependent management mailboxes 35 FIFO queues with two priorities, normal and urgent. An urgent message is inserted at the front of the queue, after other urgent messages. All local/backbone network dependent management processes (e.g., initialization) receive network management requests from these queues. 
    6.2 - ENET frame-related interface 40 The network control interface to the forwarding function exchanges only ENET frames. The input and output network control service interfaces are defined below. 
    6.2. 1 - Network control input The network control input interface is the service interface utilized to input an ENET frame to forward- 45 ing function. The network control input interface utilizes a procedure call and return. The required param eters for the call and return are: 
    INPUT CALL (Network control to forwarding function) INPUT-FRAME - The address of the linked list of buffer descriptors which identifies the complete ENET frame. 60 FCS- TRUE/FALSE. Identifies whether the ENET frame contains/does not contain an FCS. If the frame was decapsulated the value of this field is set from the EID value. Otherwise, it is set from the value of the NON-encapsulated frames flag in the associated RDSE. 
    SNID- A two octet system specified identifier which identifies the source network. The two octet field is defined as follows: 55 bits 0-7- These bits are reserved. They must have a value of 00(16). 
    bits 8-15- These bits contain the source NID value associated with this ENET frame. 
    ENCAPSULATION-ID (EID) - If the frame was DECAPSULATED, this is the value of bits 40 - 47 of the DECAPSULATED destination multicast GLOBAL-ADDRESS. If the frame was not DECAPSULATED, this field equals ZERO. 60 
    ENCAPSULATION-SOURCE ADDRESS (ESA) - If the ENCAPSULATION-ID value is NON-ZERO, this is the DECAPSULATED source GLOBAL-ADDRESS. Otherwise, this field contains the GLOBAL- ADDRESS of the local bridge. 
    INPUT RETURN (Forwarding function to network control) RETURN CODE - TBD. 65 - 26 GB 2 170 079 A 26 6.2.2 - Network control output All output from the forwarding function utilizes a procedure call and return. Network control and the forwarding function run at the same priority. The required parameters for the call and return are: 
    OUTPUT-CALL (Forwarding function to network control) OUTPUT-FRAME - The address of the linked list of buffer descriptors which identify the input ENET 5 frame. 
    FCS - TRUE/FALSE - Identifies whether the ENET frame has an FCS or NO_FCS. The value of the FCS equals FCS value of the INPUT CALL. 
    SNID - A two octet system specified identifier which identifies the source network. The two octet field is defined as follows- 10 bits 0-7 - These bits are reserved. They currently are ignored by network control. 
    bits 8-15 - These bits contain the source NID value. If input from management functions this parame ter has a value of 00(16). 
    ENCAPSULATION-ID (EID) - If the frame is to be ENCAPSULATED, this is used in computing the value of bits 40 - 47 of the 15 ENCAPSULATION destination multicast GLOBAL-ADDRESS. 
    If the frame is not to be ENCAPSULATED, this field equals ZERO. 
    ENCAPSULATION-SOURCE ADDRESS (ESA) - If the ENCAPSULATION-ID value is NON-ZERO, this is the ENCAPSULATION source GLOBAL-ADDRESS. (e.g., the ESA parameter from INPUT-CALL). Otherwise, this field is ignored 20 by NC. 
    OUTPUT RETURN (Network control to forwarding function) RETURN CODE NOT-DISCARDED/DISCARDED 6.3 - Frame-related process description 25 
    As was stated earlier, the ENET frame-related interface is between the forwarding function and multiple network control processes. Logically, the forwarding function may directly interface with the network in terface process. In other cases, the forwarding function interfaces with a network specific translation process or with a network specific encapsulation/decapsulation process. These different cases are dis cussed below. 30 6,3. 1 - Network interface tolfrom forwarding function This mode of operation is possible when ENCAPSULATION/DECAPSULATION is not required by the underlining local/backbone network. In this case, input and output ENET frames flow through network control as follows: 35 a) Input frames When a ENET frame has been received and completely processed by the network interface board proc ess(es), it is placed in the associated network interface input queue. The ENET frame is subsequently removed (in a FIFO manner) by a network interface process on the MCPU. If the state of the network interface is "ON", the ENET frame is passed to the forwarding function in an input call. (EID = NOT_ 40 ENCAPSULATED, FCS = TRUE) b) Output frames When the network interface process receives an output cal[Ifrorn forwarding function, the following occurs: 
    1) It locates the network interface output queue data store with a NID equal to the NID in the output 45 call. 
    2) If the current queue depth is greater than the discard depth, the frame is discarded and a RE TURN-CODE of DISCARDED is generated. 
    3) Otherwise, the following occurs: 
    a. The ENET frame is then inserted on the queue. 50 b. The NIOQ statistics fields are incremented as appropriate. 
    c. A RETURN-CODE of NOT-DISCARDED is generated. 
    The process on the network interface board dequeues the ENET frames in FIFO manner and transmits them. 
    55 6.3.2 - Network translation tolfrom forwarding function This mode of operation is utilized when the underlining local/backbone network does not utilize the ENET frame, but a simple transformation is possible. In this case the input and output ENET frame flow changes as follows: 
    a) Input frames 60 The network interface process on MCPU passes input non-ENET frames to the network specific transla tion process instead of the forwarding function. The network specific non- ENET frame is then translated into an ENET frame and is then passed to the forwarding function in an input call. 
    b) Output frames The network specific translation process receives the output call from the forwarding function instead 65 27 GB 2 170 079 A 27 of the network interface process. The output ENET frame is translated into the network specific frame. 
    The network specific frame is then passed to the network interface process to be inserted on the network interface output queue. 
    It is anticipated that this mode of operation will be utilized to interface to other 802 LAN's. The high level design will be completed when the decision to interface to one or more of these LAN's is made. 5 6 3.3 Backbone encapsulationldecapsulation fromIto forwarding function As described in Section 3, this mode of operation is utilized for handling ROOTED configurations and Ku band rain. Certain input and output ENET frames from/to the forwarding function must be encapsu lated/decapsulated. (See Section 5.) ENET frames without an FCS are also encapsulated/decapsulated 10 when transmitted across a backbone network that does not utilize the ENET 32 bit FCS. 
    Backbone network encapsulation/decapsulation mode- of operation is discussed below. This section DOES NOT describe the local network encapsulation/decapsulation mode of operation identified in Refer ence 2.1. 
    15 6.3.3,1 - Encapsulation to a backbone network When present, the encapsulation process receives all OUTPUT_ CALL's from the forwarding function. 
    Only the forwarding function accesses the encapsulation process. The ENET frame in the OUTPUT-CALL is encapsulated as illustrated in Figure 18 and discussed below: 
    a) Upon receipt of an OUTPUT-CALL WITH A NON-ZERO ENCAPSULATION-ID or FCS = FALSE, 20 the encapasulation process encapsulates the ENET frame as illustrated above. The DA, SA, and DATA fields are defined as follows: 
    DA (DESTINATiON--ADDRESS)= VITALINK-MULTICAST-]D (40 bits)+4 bits 0000 + the following bit values computed from OUTPUT-CALL parameter values 1) 17CS(TRUE/FALSE) bit 25 2) ENCAPSULATION-0 bits 5-7 SA (SOURCE--ADDRESS)= ESA parameter from OUTPUT-CALL DATA = OUTPUT-FRAME parameter from OUTPUT-CALL b) After the above encapsulated frame is created, it is passed to the network interface process using the OUTPUT-CALL defined in Section 6.2.2. 30 6.3,3.2 - Decapsulation from a backbone network If a backbone network decapsulation process exists, the network interface process on the MCPU passes all input frames to the decapsulation process. An encapsulated frame is decapsulated as illustrated in Figure 19 and discussed below: 35 a) Upon receipt of an INPUT-CALL (as defined in Section 6.2.1 with ZERO EID and ESA parameters), the decapsulation process does the following: 
    1) Compares the first 40 bits of the frame's DESTINATION- ADDRESS to the VITALINK-MULTICAST ID value. If not equal, the frame is not a BACKBONE-ENCAPSULATED frame and is associated with the FILDSE labeled FCS. 40 2) Otherwise, the frame's SOURCE---ADDRESS is compared to this bridge's GLOBAL-ADDRESS. If equal, the frame is discarded. 
    3) Otherwise, the last 8 bits are used as an FILDSE index. 
    b) The processing of the frame is determined by the FILDSE flag values as follows: 
    1) If the flag equals DISCARD, the frame is discarded. 45 2) If the flag equals DECAPSULATE, SA and DA fields are removed. 
    3) if the flag equals PASS, the frame passes through the decapsulation process unchanged. 
    4) If the flag equals ERROR, the following occurs: 
    a. The associated FILDSE ERROR count is incremented by 1 b. If the count is less than 6, an ALARM is generated 50 c. The frame is discarded. 
    c) The decapsulation process then passes all frames that were not discarded to the forwarding func tion using the INPUT-CALL defined in Section 6.2.1. 
    Figure 20 is a pictorial view of a communications system for interconnected multiple local area net- 55works and constructed in accordance with one embodiment of the present invention. Figure 20 shows 55 how the present invention is associated with a satellite. Figure 20 also illustrates how the system of the present invention provides for modular expansion of extended networks. 
    The system shown in Figure 20 embodies the apparatus and methods described above in this specifi cation. 
    While we have illustrated and described the preferred embodiments of our invention, it is to be under- 60 stood that these are capable of variation and modification, and we therefore do not wish to be limited to the precice details set forth, but desire to avail ourselves of such changes and alterations as fall within the purview of the following claims. 
    28 GB 2 170 079 A 28 
  Claims (25)
1. A communications system for interconnecting multiple local area networks across broadcast sim plex channels independently and transparently of protocols above the data link layer so that the system appears to a user at a station in a local area network as one large single network, said system compris- 5 ing, a plurality of local area networks with each local area network having at least one station for sending or receiving communications to or from another station using data link frames containing at least a desti nation address and a source address, bridge means for interconnecting across simplex channels the plurality of local area networks to permit 10 one or more stations in one local area network to communicate with one or more stations in one or more of the other local area networks independently and transparently of protocols above the data link layer, and wherein said bridge means are constructed to permit more than two local area networks to be inter connected across simplex channels through the bridge means and to provide communication between 15 stations.
    2. The invention defined in claim 1 wherein the bridge means include network interfacing means for interfacing the bridge means to one or more related local area networks and/or multiple input and output simplex channels for sending information in frame format onto and off a related network, and 20 forwarding means for forwarding frames.
    3. The invention defined in claim 2 wherein the forwarding means are operative to forward a frame received from (a) one station in one local area network attached to the bridge or (b) a process within the same bridge or 25 (c) simplex links attached to the bridge to and from one or more (1) local area networks attached to the bridge and (2) simplex channels attached to the bridge and finally to a designated station in another local area network or (3) to a local process in another bridge means. 30 
    4. The invention defined in claim 2 wherein there is a unique network interfacing means operatively associated with each input and output simplex channel connected to the bridge.
    5. The invention defined in claim 4 wherein the unique network interfacing means are constructed to accomplish total disassociation of input signals and output signals for the transmission and reception of data link frames. 35 
    6. The invention defined in claim 3 including data store and index means for associating an output simplex channel with one or more input simplex channels to form a non- rooted, rooted or multirooted network.
    7. The invention defined in claim 6 wherein the data store and index means include a forwarding data store which contains entries created from frames received with a unique source address value and a 40 local variable which identifies the input simplex channel of the frame.
    8. The invention defined in claim 7 wherein the data store and index means are effective, for each entry created in the forwarding data store, to insert the address value also into a source network cache such that a frame received from the network with a destination address value already in the cache is discarded quickly without accessing the forwarding data store. 45 
    9. The invention defined in claim 7 wherein the forwarding means for locating a matching forwarding data store entry uses the last 12-16 bits of a 48 bit destination address.
    10. The invention defined in claim 7 including discarding means for discarding a frame from an input simplex channel based upon the recognition that the frame's input simplex channel and the simplex channel identified in the matching forwarding data store entry are part of the same network so that dis- 50 carding that frame thereby avoids unnecessary propagation.
    11. The invention defined in claim 7 wherein the forwarding means for forwarding a frame to an out put simplex channel are based on associating the input simplex channel identified in the matching for warding data store entry to the output simplex channel of the network to which the frame is to be forwarded. 55 
    12. The invention defined in claim 6 including encapsulation, decapsulation, and discarding means to give rooted and multi-rooted networks the appearance of being non-rooted such that the retransmitted frames are appropriately filtered.
    13. The invention defined in claim 12 including reconfiguration means for permitting dynamic reconfi guration, through communication with a reconfiguration process in the bridge means, of part of a net- 60 work from a non-rooted to a rooted configuration and vice versa.
    14. The invention defined in claim 13 wherein the dynamic reconfiguration means are constructed for dynamically reconfiguring the communications system from a non-rooted to a rooted configuration and vice versa in response to a singnal indicating the desirability of such reconf ig u ration.
    15. The invention defined in claim 3 including configurable discarding means for allowing networks to 65 29 GB 2 170 079 A 29 be sheltered from frames with specific single destination addresses or multicast destination addresses such that those frames from remote local area networks are not forwarded onto specific simplex chan nels or input from specific input simplex channels to thereby preserve locality.
    16. The invention defined in claim 3 including configurable discarding means for allowing networks to be sheltered from all but frames with specific destinations addresses. 5 
    17. The invention defined in claim 3 wherein the forwarding means execute in an interrupt level mode and including processes that are within the bridge means and that execute in a non-interrupt mode such that the network management functions of the bridge means cannot interfere with the forwarding means.
    18. The invention defined in claim 6 wherein the data store and index means include a forwarding data store for receiving a frame and finding a matching forwarding data store entry for the single desti- 10 nation address, the forwarding data store also contains a source network ID, the source network ID is not a network in the sense of being a rooted network or a non-rooted net the source network ID identifies an input simplex channel, 15 the transmit network ID identifies an output simplex channel, the source network ID is used as an index into a receive data store the entry so located defines the input simplex channel, one of the values in the located entry is a transmit network ID, the transmit network ID is used as an index into the transmit data store, 20 said one value further locates an entry in the transmit data store, the entry so found in the transmit data store defines the output simplex channel associated with the forwarding data store entry that the frame was received on, and wherein when the bridge means receives a frame from the input simplex channel, the bridge means get with the frame from the network interface means the received network ID associated with that input 25 simplex channel and wherein the bridge means go through the same train of logic to find the output simplex channel asso ciated with that network.
    19. The invention defined in claim 2 wherein the forwarding means are effective to forward frames based on a determination of two questions: 30 (1) What simplex channel is the destination on? (2) What simplex channel did the frame come from? 
    20. A method of interconnecting in a communications system multiple local area networks independ ently and transparently of protocols above the data link layer so that the system appears to a user at a station in a local area network as one large single network, said method comprising, 35 connecting a plurality of local area networks together by simplex channels so that a station in one local area network can send or receive data link frames to or from another station in another local area net interassociating the simplex channels through a bridge that is effective to provide communication be tween stations in different local area networks independently and transparently of protocols above the 40 data link layer, and constructing the bridge to permit more that two local are networks to be interconnected across simplex channels through the bridge and to provide communication between stations.
    21. A bridge for a communications system of the kind in which multiple local area networks are inter connected independently and transparently of protocols above the data link layer and so that the system 45 appears to the user at a station in a local area network as one large single network, said bridge means comprising, network interface means for interfacing the bridge to related local area networks and simplex channels for sending information in frame format onto and off of a related local area network, forwarding means for forwarding a frame received from one station in one local area network to a 50 designated station in another local area network independently and transparently of protocols above the data link layer, wherein the bridge is constructed to permit more that two local area networks to be interconnected through the bridge and to provide communication between stations.
    22. A communications system for interconnecting multiple local area networks across broadcast sim- 55 plex channels independently and transparently of protocols above the data link layer so that the system appears to a user at a station in a local area network as one large single network, substantially as her einbefore described with reference to, and as illustrated in, the accompanying drawings.
    23. A method of interconnecting in a communications system multiple local area networks independ ently and transparently of protocols above the data link layer so that the system appears to a user at a 60 station in a local area network as one large single network, substantially as hereinbefore described with reference to the accompanying drawings.
      GB 2 170 079 A 30 
    24. A bridge for a communications system of the kind in which multiple local area networks are inter connected independently and transparently of protocols above the data link layer and so that the system appears to the user at a station in a local area network as one large single network, substantially as hereinbefore described with reference to, and as illustrated in, the accompanying drawings.
    25. Any novel feature or combination of features described herein. 5 Printed in the UK for HMSO, D8818935, 6/86, 7102. Published by The Patent Office, 25 Southampton Buildings, London, WC2A 1AY, from which copies may be obtained.
    Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title | 
|---|---|---|---|
| US06/682,061 US4706081A (en) | 1984-12-14 | 1984-12-14 | Method and apparatus for bridging local area networks | 
Publications (3)
| Publication Number | Publication Date | 
|---|---|
| GB8530600D0 GB8530600D0 (en) | 1986-01-22 | 
| GB2170079A true GB2170079A (en) | 1986-07-23 | 
| GB2170079B GB2170079B (en) | 1988-10-05 | 
Family
ID=24738037
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date | 
|---|---|---|---|
| GB08530600A Expired GB2170079B (en) | 1984-12-14 | 1985-12-12 | Method and apparatus for bridging local network | 
Country Status (7)
| Country | Link | 
|---|---|
| US (1) | US4706081A (en) | 
| JP (1) | JPH0691537B2 (en) | 
| AU (1) | AU583075B2 (en) | 
| BR (1) | BR8506261A (en) | 
| CA (1) | CA1239678A (en) | 
| GB (1) | GB2170079B (en) | 
| HK (1) | HK84490A (en) | 
Cited By (7)
| Publication number | Priority date | Publication date | Assignee | Title | 
|---|---|---|---|---|
| EP0269978A3 (en) * | 1986-11-29 | 1989-07-26 | Kabushiki Kaisha Toshiba | Network adapter for connecting local area network to backbone network | 
| US4901312A (en) * | 1988-05-05 | 1990-02-13 | Hui Man H | Remote interconnection of local area networks | 
| EP0255096A3 (en) * | 1986-07-28 | 1990-02-28 | Honeywell Bull Inc. | A controller for controlling multiple lan types | 
| EP0290189A3 (en) * | 1987-05-01 | 1990-09-19 | Vitalink Communications Corporation | Method and apparatus for interfacing to a local area network | 
| EP0353859A3 (en) * | 1988-08-02 | 1992-04-01 | Digital Equipment Corporation | Network transit prevention | 
| EP0388511A3 (en) * | 1989-03-22 | 1992-12-02 | Hewlett-Packard Company | Method for data transfer | 
| GB2284326A (en) * | 1993-11-24 | 1995-05-31 | Ericsson Ge Mobile Communicat | Interconnection of multisite switch controlled networks | 
Families Citing this family (122)
| Publication number | Priority date | Publication date | Assignee | Title | 
|---|---|---|---|---|
| US4882674A (en) * | 1985-03-05 | 1989-11-21 | Wang Laboratories, Inc. | Apparatus and method for control of one computer system by another computer system | 
| US4825435A (en) * | 1985-11-08 | 1989-04-25 | Digital Equipment Corp. | Multiport repeater | 
| JPH0648811B2 (en) * | 1986-04-04 | 1994-06-22 | 株式会社日立製作所 | Complex network data communication system | 
| US4797881A (en) * | 1987-03-12 | 1989-01-10 | Sytek, Inc. | Bridge system for connecting networks | 
| US4866421A (en) * | 1987-06-18 | 1989-09-12 | Texas Instruments Incorporated | Communications circuit having an interface for external address decoding | 
| DE3838945A1 (en) * | 1987-11-18 | 1989-06-08 | Hitachi Ltd | NETWORK SYSTEM WITH LOCAL NETWORKS AND WITH A HIERARCHICAL CHOICE OF PATH | 
| US4811337A (en) * | 1988-01-15 | 1989-03-07 | Vitalink Communications Corporation | Distributed load sharing | 
| US4893307A (en) * | 1988-02-29 | 1990-01-09 | International Business Machines Corporation | Method and apparatus for linking SNA terminals to an SNA host over a packet switched communications network | 
| DE3809129C2 (en) * | 1988-03-18 | 1994-06-09 | Broadcast Television Syst | Method and device for controlling video-technical devices | 
| JP2660422B2 (en) * | 1988-05-31 | 1997-10-08 | 株式会社日立製作所 | LAN mode coupling device with operation mode setting | 
| US5025491A (en) * | 1988-06-23 | 1991-06-18 | The Mitre Corporation | Dynamic address binding in communication networks | 
| US5032987A (en) * | 1988-08-04 | 1991-07-16 | Digital Equipment Corporation | System with a plurality of hash tables each using different adaptive hashing functions | 
| US4922503A (en) * | 1988-10-28 | 1990-05-01 | Infotron Systems Corporation | Local area network bridge | 
| US5109384A (en) * | 1988-11-02 | 1992-04-28 | Tseung Lawrence C N | Guaranteed reliable broadcast network | 
| US5036518A (en) * | 1988-11-02 | 1991-07-30 | Tseung Lawrence C N | Guaranteed reliable broadcast network | 
| US5073852A (en) * | 1988-12-16 | 1991-12-17 | Cayman Systems, Inc. | Network protocol translator including method and apparatus for reducing interprocess communication and data exchange overhead | 
| US5142622A (en) * | 1989-01-31 | 1992-08-25 | International Business Machines Corporation | System for interconnecting applications across different networks of data processing systems by mapping protocols across different network domains | 
| CA1335832C (en) * | 1989-04-21 | 1995-06-06 | Wing-Man Chan | Remote test access system for isdn testing | 
| US5860136A (en) * | 1989-06-16 | 1999-01-12 | Fenner; Peter R. | Method and apparatus for use of associated memory with large key spaces | 
| US5138615A (en) * | 1989-06-22 | 1992-08-11 | Digital Equipment Corporation | Reconfiguration system and method for high-speed mesh connected local area network | 
| AU620994B2 (en) * | 1989-07-12 | 1992-02-27 | Digital Equipment Corporation | Compressed prefix matching database searching | 
| JPH0728308B2 (en) * | 1990-04-23 | 1995-03-29 | 三菱電機株式会社 | Communication network interconnection device | 
| US5136580A (en) * | 1990-05-16 | 1992-08-04 | Microcom Systems, Inc. | Apparatus and method for learning and filtering destination and source addresses in a local area network system | 
| US5111453A (en) * | 1990-05-18 | 1992-05-05 | Nynex Corporation | Apparatus and method for recognizing addresses of information packets | 
| US5309437A (en) * | 1990-06-29 | 1994-05-03 | Digital Equipment Corporation | Bridge-like internet protocol router | 
| US5151895A (en) * | 1990-06-29 | 1992-09-29 | Digital Equipment Corporation | Terminal server architecture | 
| US5251205A (en) * | 1990-09-04 | 1993-10-05 | Digital Equipment Corporation | Multiple protocol routing | 
| US5159592A (en) * | 1990-10-29 | 1992-10-27 | International Business Machines Corporation | Network address management for a wired network supporting wireless communication to a plurality of mobile users | 
| JP2644624B2 (en) * | 1990-11-30 | 1997-08-25 | 株式会社日立製作所 | Inter-network routing control method | 
| US6847611B1 (en) | 1990-12-10 | 2005-01-25 | At&T Corp. | Traffic management for frame relay switched data service | 
| US5303238A (en) * | 1990-12-11 | 1994-04-12 | International Business Machines Corporation | Network communications intermediate interface | 
| GB9100389D0 (en) * | 1991-01-09 | 1991-02-20 | Digital Equipment Corp | Method and apparatus for transparently bridging traffic across wide area networks | 
| EP0521153B1 (en) * | 1991-01-23 | 2001-03-14 | Sun Microsystems, Inc. | Method and apparatus for scoped interprocess message switching | 
| US5434864A (en) * | 1991-01-25 | 1995-07-18 | Digital Equipment Corporation | Encapsulation of an address within a forwarded frame in a computer communications system | 
| US5956335A (en) * | 1991-01-25 | 1999-09-21 | Cabletron Systems, Inc. | Many to few group address translation through a network bridge | 
| US5280480A (en) * | 1991-02-21 | 1994-01-18 | International Business Machines Corporation | Source routing transparent bridge | 
| US5285449A (en) * | 1991-04-03 | 1994-02-08 | International Business Machines Corporation | Protocol for hybrid local area networks | 
| US5317568A (en) * | 1991-04-11 | 1994-05-31 | Galileo International Partnership | Method and apparatus for managing and facilitating communications in a distributed hetergeneous network | 
| US5442630A (en) * | 1991-05-24 | 1995-08-15 | Gagliardi; Ugo O. | ISDN interfacing of local area networks | 
| WO1992021189A1 (en) * | 1991-05-24 | 1992-11-26 | Bell Atlantic Network Services, Inc. | Isdn interfacing of local area networks | 
| US5404353A (en) * | 1991-06-28 | 1995-04-04 | Digital Equipment Corp. | Dynamic defer technique for traffic congestion control in a communication network bridge device | 
| US5339313A (en) * | 1991-06-28 | 1994-08-16 | Digital Equipment Corporation | Method and apparatus for traffic congestion control in a communication network bridge device | 
| US5296936A (en) * | 1991-07-22 | 1994-03-22 | International Business Machines Corporation | Communication apparatus and method for transferring image data from a source to one or more receivers | 
| JPH05327712A (en) * | 1991-08-09 | 1993-12-10 | Nec Corp | Terminal adaptor | 
| US6407991B1 (en) | 1993-05-06 | 2002-06-18 | Intermec Ip Corp. | Communication network providing wireless and hard-wired dynamic routing | 
| GB9127404D0 (en) * | 1991-12-24 | 1992-02-19 | Ncr Co | Local area network system | 
| US8352400B2 (en) | 1991-12-23 | 2013-01-08 | Hoffberg Steven M | Adaptive pattern recognition based controller apparatus and method and human-factored interface therefore | 
| US7006881B1 (en) * | 1991-12-23 | 2006-02-28 | Steven Hoffberg | Media recording device with remote graphic user interface | 
| US5398242A (en) * | 1992-04-07 | 1995-03-14 | Digital Equipment Corporation | Automatically configuring LAN numbers | 
| US5323394A (en) * | 1992-04-07 | 1994-06-21 | Digital Equipment Corporation | Selecting optimal routes in source routing bridging without exponential flooding of explorer packets | 
| US5844902A (en) * | 1992-04-07 | 1998-12-01 | Cabletron Systems, Inc. | Assigning multiple parallel bridge numbers to bridges | 
| US5400333A (en) * | 1992-04-07 | 1995-03-21 | Digital Equipment Corporation | Detecting LAN number misconfiguration | 
| US5327424A (en) * | 1992-04-07 | 1994-07-05 | Digital Equipment Corporation | Automatically configuring parallel bridge numbers | 
| ATE207679T1 (en) * | 1992-04-20 | 2001-11-15 | 3Com Corp | DEVICE FOR EXPANSION OF NETWORK MEANS TO REMOTE NETWORKS | 
| US5313465A (en) * | 1992-05-13 | 1994-05-17 | Digital Equipment Corporation | Method of merging networks across a common backbone network | 
| US5671355A (en) * | 1992-06-26 | 1997-09-23 | Predacomm, Inc. | Reconfigurable network interface apparatus and method | 
| US5442633A (en) * | 1992-07-08 | 1995-08-15 | International Business Machines Corporation | Shortcut network layer routing for mobile hosts | 
| FI91700C (en) * | 1992-08-14 | 1994-07-25 | Nokia Telecommunications Oy | Method for transmitting packet data as well as mobile station in a cellular radio system | 
| 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 | 
| US5390173A (en) * | 1992-10-22 | 1995-02-14 | Digital Equipment Corporation | Packet format in hub for packet data communications system | 
| JPH084273B2 (en) * | 1992-11-30 | 1996-01-17 | 日本電気株式会社 | Complex communication network | 
| US5379296A (en) * | 1992-12-31 | 1995-01-03 | Unisys Corporation | Method and apparatus for interfacing a workstation to a plurality of computer platforms | 
| US5434914A (en) * | 1992-12-31 | 1995-07-18 | At&T Corp. | Name translation in communications networks | 
| JP2793489B2 (en) * | 1993-01-13 | 1998-09-03 | インターナショナル・ビジネス・マシーンズ・コーポレイション | Common data link interface | 
| US5317565A (en) * | 1993-01-26 | 1994-05-31 | International Business Machines Corporation | Method of sequencing bus operations in a simplex switch | 
| US6771617B1 (en) | 1993-06-17 | 2004-08-03 | Gilat Satellite Networks, Ltd. | Frame relay protocol-based multiplex switching scheme for satellite mesh network | 
| US5434850A (en) | 1993-06-17 | 1995-07-18 | Skydata Corporation | Frame relay protocol-based multiplex switching scheme for satellite | 
| US5566203A (en) * | 1993-06-24 | 1996-10-15 | National Semiconductor Corp. | Intelligent repeater functionality | 
| US5875210A (en) * | 1993-06-24 | 1999-02-23 | National Semiconductor Corporation | Method and apparatus for repeating data | 
| AU677393B2 (en) * | 1993-07-08 | 1997-04-24 | E-Talk Corporation | Method and system for transferring calls and call-related data between a plurality of call centres | 
| US5937051A (en) * | 1993-07-08 | 1999-08-10 | Teknekron Infoswitch Corporation | Method and system for transferring calls and call-related data between a plurality of call centers | 
| US5617421A (en) * | 1994-06-17 | 1997-04-01 | Cisco Systems, Inc. | Extended domain computer network using standard links | 
| US5610906A (en) * | 1994-06-29 | 1997-03-11 | Interdigital Technology Corporation | Spread-spectrum changeable base station | 
| US5561669A (en) * | 1994-10-26 | 1996-10-01 | Cisco Systems, Inc. | Computer network switching system with expandable number of ports | 
| US5884040A (en) * | 1995-01-11 | 1999-03-16 | Sony Corporation | Per-packet jamming in a multi-port bridge for a local area network | 
| US5857075A (en) * | 1995-01-11 | 1999-01-05 | Sony Corporation | Method and integrated circuit for high-bandwidth network server interfacing to a local area network | 
| US6256313B1 (en) | 1995-01-11 | 2001-07-03 | Sony Corporation | Triplet architecture in a multi-port bridge for a local area network | 
| US5764895A (en) * | 1995-01-11 | 1998-06-09 | Sony Corporation | Method and apparatus for directing data packets in a local area network device having a plurality of ports interconnected by a high-speed communication bus | 
| US5940597A (en) * | 1995-01-11 | 1999-08-17 | Sony Corporation | Method and apparatus for periodically updating entries in a content addressable memory | 
| US5594732A (en) * | 1995-03-03 | 1997-01-14 | Intecom, Incorporated | Bridging and signalling subsystems and methods for private and hybrid communications systems including multimedia systems | 
| US5838683A (en) | 1995-03-13 | 1998-11-17 | Selsius Systems Inc. | Distributed interactive multimedia system architecture | 
| US7058067B1 (en) | 1995-03-13 | 2006-06-06 | Cisco Technology, Inc. | Distributed interactive multimedia system architecture | 
| BR9610882A (en) * | 1996-01-16 | 1999-07-13 | He Holding Inc Dba Hughes Elec | Security satellite addressable filter system for receiving only local surface network | 
| US6945457B1 (en) * | 1996-05-10 | 2005-09-20 | Transaction Holdings Ltd. L.L.C. | Automated transaction machine | 
| JP2000511662A (en) * | 1996-05-10 | 2000-09-05 | バルセロー,デビッド,エム. | Automated transaction machines | 
| US5915010A (en) | 1996-06-10 | 1999-06-22 | Teknekron Infoswitch | System, method and user interface for data announced call transfer | 
| US6567410B1 (en) | 1996-08-08 | 2003-05-20 | Enterasys Networks, Inc. | Assigning multiple parallel bridge numbers to bridges having three or more ports | 
| US5839088A (en) | 1996-08-22 | 1998-11-17 | Go2 Software, Inc. | Geographic location referencing system and method | 
| US6167389A (en) * | 1996-12-23 | 2000-12-26 | Comverge Technologies, Inc. | Method and apparatus using distributed intelligence for applying real time pricing and time of use rates in wide area network including a headend and subscriber | 
| US6643291B1 (en) * | 1997-06-18 | 2003-11-04 | Kabushiki Kaisha Toshiba | Multimedia information communication system | 
| US6081524A (en) | 1997-07-03 | 2000-06-27 | At&T Corp. | Frame relay switched data service | 
| US6363067B1 (en) | 1997-09-17 | 2002-03-26 | Sony Corporation | Staged partitioned communication bus for a multi-port bridge for a local area network | 
| US6157951A (en) * | 1997-09-17 | 2000-12-05 | Sony Corporation | Dual priority chains for data-communication ports in a multi-port bridge for a local area network | 
| US6744728B1 (en) | 1997-09-17 | 2004-06-01 | Sony Corporation & Sony Electronics, Inc. | Data pipeline timing optimization technique in a multi-port bridge for a local area network | 
| US6442168B1 (en) | 1997-09-17 | 2002-08-27 | Sony Corporation | High speed bus structure in a multi-port bridge for a local area network | 
| US6301256B1 (en) | 1997-09-17 | 2001-10-09 | Sony Corporation | Selection technique for preventing a source port from becoming a destination port in a multi-port bridge for a local area network | 
| US6308218B1 (en) | 1997-09-17 | 2001-10-23 | Sony Corporation | Address look-up mechanism in a multi-port bridge for a local area network | 
| US6617879B1 (en) | 1997-09-17 | 2003-09-09 | Sony Corporation | Transparently partitioned communication bus for multi-port bridge for a local area network | 
| US6473401B1 (en) | 1998-04-06 | 2002-10-29 | Iscale, Inc. | Self-scaling method for exploiting cached resources across organizational boundaries to enhance user response time and to reduce server and network load | 
| US6633562B1 (en) | 1998-07-31 | 2003-10-14 | Mci Communications Corporation | Method and apparatus using enhanced attachment for improved connectivity in telecommunications | 
| US6580720B1 (en) | 1998-09-18 | 2003-06-17 | The United States Of America As Represented By The Secretary Of The Navy | Latency verification system within a multi-interface point-to-point switching system (MIPPSS) | 
| US6678268B1 (en) | 1998-09-18 | 2004-01-13 | The United States Of America As Represented By The Secretary Of The Navy | Multi-interface point-to-point switching system (MIPPSS) with rapid fault recovery capability | 
| US6426952B1 (en) | 1998-09-18 | 2002-07-30 | The United States Of America As Represented By The Secretary Of The Navy | Multi-interface point-to-point switching system (MIPPSS) having an internal universal signal format | 
| US6628648B1 (en) | 1998-09-18 | 2003-09-30 | The United States Of America As Represented By The Secretary Of The Navy | Multi-interface point-to-point switching system (MIPPSS) with hot swappable boards | 
| US6580692B1 (en) | 1998-09-18 | 2003-06-17 | The United States Of America As Represented By The Secretary Of The Navy | Dynamic switch path verification system within a multi-interface point-to-point switching system (MIPPSS) | 
| US6526048B1 (en) | 1998-09-18 | 2003-02-25 | The United States Of America As Represented By The Secretary Of The Navy | Multi-interface point-to-point switching system (MIPPSS) under unified control | 
| DE19848342A1 (en) * | 1998-10-21 | 2000-04-27 | Philips Corp Intellectual Pty | Local network with a bridge terminal for the transmission of data between several sub-networks and for loop detection | 
| DE19848341A1 (en) * | 1998-10-21 | 2000-04-27 | Philips Corp Intellectual Pty | Automatic configuration of a bridge terminal for the transmission of data between several sub-networks in a local network | 
| US7904187B2 (en) | 1999-02-01 | 2011-03-08 | Hoffberg Steven M | Internet appliance system and method | 
| WO2000072469A1 (en) * | 1999-05-25 | 2000-11-30 | Comgates Communications, Ltd. | Packet based telephony over satellite links | 
| US6891823B1 (en) * | 1999-06-15 | 2005-05-10 | Pluris, Inc. | Apparatus and method for scaling a switching fabric in a network switching node | 
| US6973079B1 (en) * | 1999-06-15 | 2005-12-06 | Pluris, Inc. | Apparatus and method for scaling a switching fabric in a network switching node | 
| EP1148661A3 (en) * | 2000-04-21 | 2003-10-29 | Lockheed Martin Corporation | Geostationary satellite system with satellite clusters having intra-cluster local area networks and inter-cluster wide area network | 
| DE10145596A1 (en) | 2001-09-15 | 2003-04-03 | Philips Corp Intellectual Pty | Network with several sub-networks | 
| US7389359B2 (en) | 2001-10-19 | 2008-06-17 | Foundry Networks, Inc. | Method and system for intelligently forwarding multicast packets | 
| JP4148949B2 (en) * | 2003-02-12 | 2008-09-10 | 富士通株式会社 | RPR equipment | 
| JP4334534B2 (en) * | 2005-11-29 | 2009-09-30 | 株式会社東芝 | Bridge device and bridge system | 
| KR100754649B1 (en) * | 2006-07-24 | 2007-09-05 | 삼성전자주식회사 | Bridge-based wireless base station backbone network system and signal processing method | 
| US8346997B2 (en) * | 2008-12-11 | 2013-01-01 | International Business Machines Corporation | Use of peripheral component interconnect input/output virtualization devices to create redundant configurations | 
| US8625427B1 (en) | 2009-09-03 | 2014-01-07 | Brocade Communications Systems, Inc. | Multi-path switching with edge-to-edge flow control | 
| TWI428758B (en) * | 2011-01-13 | 2014-03-01 | Prolific Technology Inc | Operation method for a computer system | 
| CN111937354B (en) * | 2018-04-04 | 2022-04-01 | 三菱电机株式会社 | Data communication method, HUB station and earth station | 
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title | 
|---|---|---|---|---|
| GB1350800A (en) * | 1970-10-08 | 1974-04-24 | Western Electric Co | Data transmission | 
| GB2121651A (en) * | 1982-05-11 | 1983-12-21 | Tandem Computers Inc | Satellite communications system for computer networks | 
| EP0109964A1 (en) * | 1982-11-26 | 1984-06-13 | International Business Machines Corporation | Synchronization in a communication network of interconnected rings | 
| GB2138651A (en) * | 1983-04-21 | 1984-10-24 | Standard Telephones Cables Ltd | Local Area Networks Comprised of Interconnected Sub Networks | 
Family Cites Families (7)
| Publication number | Priority date | Publication date | Assignee | Title | 
|---|---|---|---|---|
| US4316283A (en) * | 1978-06-02 | 1982-02-16 | Texas Instruments Incorporated | Transparent intelligent network for data and voice | 
| US4375097A (en) * | 1978-06-02 | 1983-02-22 | Texas Instruments Incorporated | Transparent intelligent network for data and voice | 
| JPS58153442A (en) * | 1982-03-09 | 1983-09-12 | Toshiba Corp | data communication system | 
| JPS5962245A (en) * | 1982-10-01 | 1984-04-09 | Canon Inc | local area network | 
| JPS5963839A (en) * | 1982-10-05 | 1984-04-11 | Ricoh Co Ltd | Regenerative repeating device | 
| US4547880A (en) * | 1983-05-13 | 1985-10-15 | Able Computer | Communication control apparatus for digital devices | 
| US4509167A (en) * | 1983-08-05 | 1985-04-02 | At&T Bell Laboratories | Data conference arrangement | 
- 
        1984
        
- 1984-12-14 US US06/682,061 patent/US4706081A/en not_active Expired - Fee Related
 
 - 
        1985
        
- 1985-12-12 AU AU51170/85A patent/AU583075B2/en not_active Ceased
 - 1985-12-12 GB GB08530600A patent/GB2170079B/en not_active Expired
 - 1985-12-13 CA CA000497568A patent/CA1239678A/en not_active Expired
 - 1985-12-13 BR BR8506261A patent/BR8506261A/en not_active IP Right Cessation
 - 1985-12-13 JP JP60279406A patent/JPH0691537B2/en not_active Expired - Lifetime
 
 - 
        1990
        
- 1990-10-18 HK HK844/90A patent/HK84490A/en unknown
 
 
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title | 
|---|---|---|---|---|
| GB1350800A (en) * | 1970-10-08 | 1974-04-24 | Western Electric Co | Data transmission | 
| GB2121651A (en) * | 1982-05-11 | 1983-12-21 | Tandem Computers Inc | Satellite communications system for computer networks | 
| EP0109964A1 (en) * | 1982-11-26 | 1984-06-13 | International Business Machines Corporation | Synchronization in a communication network of interconnected rings | 
| GB2138651A (en) * | 1983-04-21 | 1984-10-24 | Standard Telephones Cables Ltd | Local Area Networks Comprised of Interconnected Sub Networks | 
Cited By (9)
| Publication number | Priority date | Publication date | Assignee | Title | 
|---|---|---|---|---|
| EP0255096A3 (en) * | 1986-07-28 | 1990-02-28 | Honeywell Bull Inc. | A controller for controlling multiple lan types | 
| EP0269978A3 (en) * | 1986-11-29 | 1989-07-26 | Kabushiki Kaisha Toshiba | Network adapter for connecting local area network to backbone network | 
| US4933937A (en) * | 1986-11-29 | 1990-06-12 | Kabushiki Kaisha Toshiba | Network adapter for connecting local area network to backbone network | 
| EP0290189A3 (en) * | 1987-05-01 | 1990-09-19 | Vitalink Communications Corporation | Method and apparatus for interfacing to a local area network | 
| US4901312A (en) * | 1988-05-05 | 1990-02-13 | Hui Man H | Remote interconnection of local area networks | 
| EP0353859A3 (en) * | 1988-08-02 | 1992-04-01 | Digital Equipment Corporation | Network transit prevention | 
| EP0388511A3 (en) * | 1989-03-22 | 1992-12-02 | Hewlett-Packard Company | Method for data transfer | 
| GB2284326A (en) * | 1993-11-24 | 1995-05-31 | Ericsson Ge Mobile Communicat | Interconnection of multisite switch controlled networks | 
| GB2284326B (en) * | 1993-11-24 | 1998-07-08 | Ericsson Ge Mobile Communicat | Extended trunked RF communications systems networking | 
Also Published As
| Publication number | Publication date | 
|---|---|
| JPS61144148A (en) | 1986-07-01 | 
| BR8506261A (en) | 1986-08-26 | 
| GB2170079B (en) | 1988-10-05 | 
| US4706081A (en) | 1987-11-10 | 
| AU5117085A (en) | 1986-06-19 | 
| CA1239678A (en) | 1988-07-26 | 
| HK84490A (en) | 1990-10-25 | 
| GB8530600D0 (en) | 1986-01-22 | 
| JPH0691537B2 (en) | 1994-11-14 | 
| AU583075B2 (en) | 1989-04-20 | 
Similar Documents
| Publication | Publication Date | Title | 
|---|---|---|
| GB2170079A (en) | Method and apparatus for bridging local area networks | |
| AU607571B2 (en) | Distributed load sharing | |
| EP1417586B1 (en) | Dense virtual router packet switching | |
| US20030112767A1 (en) | Communication network providing wireless and hard-wired dynamic routing | |
| EP0851634A2 (en) | Method and apparatus for dynamically reconfiguring virtual lans of a network device | |
| EP0567217A2 (en) | System of extending network resources to remote networks | |
| US10645009B2 (en) | Method and apparatus for programmable buffers in mobile networks | |
| CN105763385B (en) | Traffic scheduling method and device | |
| KR20190094463A (en) | DCN message processing methods, network devices, and network systems | |
| Cisco | Introduction to Cisco Router Configuration Cisco Internetwork Operating System Release 10.3 | |
| Cisco | Configuring DECnet | |
| Cisco | Configuring Interface Characteristics | |
| Cisco | Introduction to Cisco Router Configuration: Student Guide Cisco Internetwork Operating System Release 11.0 | |
| Cisco | Tunneling of Asynchronous Security Protocols | |
| Cisco | Tunneling of Asynchronous Security Protocols | |
| Cisco | Concepts | |
| Cisco | Concepts | |
| Cisco | Concepts | |
| Cisco | Concepts | |
| US20050102420A1 (en) | Link layer based network sharing | |
| EP1302030B1 (en) | In-band management of a stacked group of switches by a single cpu | |
| Ball et al. | Local area network bridges | |
| Gupta et al. | Performance modeling and optimization of networks of bridged LANs | |
| CN114938318B (en) | Cross-region peer-to-peer connection realization method based on elastic public network IP | |
| Chanson et al. | Performance of some Local Area Network Technologies | 
Legal Events
| Date | Code | Title | Description | 
|---|---|---|---|
| 732 | Registration of transactions, instruments or events in the register (sect. 32/1977) | ||
| PCNP | Patent ceased through non-payment of renewal fee | 
             Effective date: 19961212  |