CA2256698C - Connection aggregation in switched communications networks - Google Patents
Connection aggregation in switched communications networks Download PDFInfo
- Publication number
- CA2256698C CA2256698C CA002256698A CA2256698A CA2256698C CA 2256698 C CA2256698 C CA 2256698C CA 002256698 A CA002256698 A CA 002256698A CA 2256698 A CA2256698 A CA 2256698A CA 2256698 C CA2256698 C CA 2256698C
- Authority
- CA
- Canada
- Prior art keywords
- switch
- packet
- path
- virtual
- address
- 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.)
- Expired - Fee Related
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/46—Interconnection of networks
- H04L12/4604—LAN interconnection over a backbone network, e.g. Internet, Frame Relay
- H04L12/4608—LAN interconnection over ATM networks
Abstract
A method and apparatus are provided for connection-oriented switching in a communications network wherein a pre-established path is established between a select pair of an ingress switch and an egress switch. The use of pre-established paths enables a reduction in the total number of connections required inside the switch cloud, reduces the CPU load on trunk switches, and shortens the time for connection setup. In the embodiment described, the DA/SA
fields of a MAC frame data packet are replaced with a "virtual path", which identifies the pre-established path between the ingress and egress switches. A
"virtual circuit" is provided in another field of the modified packet which specifies the out-port and out-header on the egress switch for demultiplexing the modified packet upon receipt at the egress switch. The virtual circuit is exchanged between the ingress and egress switches at connection setup. The virtual path is assumed to already be in place, and known to both switches, prior to connection setup.
fields of a MAC frame data packet are replaced with a "virtual path", which identifies the pre-established path between the ingress and egress switches. A
"virtual circuit" is provided in another field of the modified packet which specifies the out-port and out-header on the egress switch for demultiplexing the modified packet upon receipt at the egress switch. The virtual circuit is exchanged between the ingress and egress switches at connection setup. The virtual path is assumed to already be in place, and known to both switches, prior to connection setup.
Description
CA 022~6698 1998-11-30 W O 97/47113 PCTrUS97/09552 I
.
CONNECTION AGGREGATION IN
SWITCHED COMMUNICATIONS NETWORKS
Field of the Invention This invention relates to a method and apparatus for providing connection aggregation within a switched communications network in which pre-established paths are provided in order to reduce the total number of connections required between switches.
Background of the Invention Most data communications networks today rely heavily on shared-media, packet-based LAN technologies for both access and backbone connections. These networks use bridges and routers to connect multiple LANs into global internets. However, such router-based 5 net~,vorks cannot provide the high bandwidth and quality of service required by the latest networking applications and new faster workstations.
Switched networking is a proposed solution intended to provide additional bandwidth and quality of service. In such networks, the physical routers and hubs are replaced by switches and a management system is optionally provided for monitoring the configuration of 20 the switches. The overall goal is to provide a scalable high-performance network where all links between switches can be used concurrently for connections.
One proposal is to establish a VLAN switch domain. A VLAN is a "virtual local area network" of users having full connectivity (sharing broadcast, multicast and unicast messages) independent of any particular physical or geographical location. In other words, users 25 that share a virtual LAN appear to be on a single LAN segment regardless of their actual location. Although the term "VLAN" is widely used as a new method of solving the increasing demand for bandwidth, the effectiveness of existing VLAN systems is wholly dependent on the particular implementation. For example, a VLAN implementation which allows VLAN
~ignments to end systems, as well as ports, provides a more effective means of VLAN
30 groupings. Other performance-determining characteristics include the manner of resolving unknown destination and broadcast traffic (which consume both network bandwidth and end system CPU bandwidth), the ability to allow tr~n~mi~ion out multiple ports, hop-by-hop switching determinations (as opposed to determination of a complete path at the call-origin~ting CA 022~6698 1998-11-30 -2- .~ ;~.' ;'';;' switch), and whether multi-protocol routers are required to enable transmission between separate VLANs.
Each of these may have an important effect on the total number of connections intrunk switches, the CPU load in the trunk switches, the speed of connection setup, and the 5 scalability of the system, i.e., ability to m~int ~in performance with increasing numbers of end stations and/or switches.
The journal article entitled "Providing MAC services on an ATM network with point-to-point links", in Internetworking in Broadband Networks, pp. 252-~60, IOS Press, 1993, by J.-Y. LeBoudec and H.L. Truong is directed to a method for providing MAC services to 0 terminal equipment (TE) attached to an ATM network. Specifically, TEs are connected to an ATM switch that provides connectionless service. This service relies on "partial connections"
that the terrninal equipment devices are not aware of. According to this service, TEs implement a single virtual connection for sending and receiving connectionless traffic. The TEs use an address resolution protocol to resolve destination MAC addresses to partial connections.
1~
Surnrnarv of the Invention In accordance with the present invention, a method and apparatus are provided for connection-oriented switching in a communications network. In a connection-oriented communication, a logical association is established between a source end station and a 20 destination end station, so that several separate groups of data ("a data flow") may be sent along the same path that is defined by the logical association. This is distinguished from connectionless communications, wherein each frame,of data is transmitted node-by-node independently of the previous frame.
In general, there are three phases which occur during a connection-oriented 25 communication: connection establishment; data transfer; and connection termination. In the connection establishment phase, the first time a source has data to be sent to a destination, a logical association, also called a connection or a path, is established between the source and the destin~tion. The connection defines nodes and connections between the nodes, for example, the switches between the source and destination, and the ports of the switches through which the 30 data will pass. The path set up at the establishment phase is the path on which the data will be transmitted for the duration of,the active connection. During the data transfer phase, data is transmitted from the source to the destination along the connection, which includes the port-to-A~E~IDED SHEEr CA 022~6698 1998-11-30 Q
-2~
. ~ , . . .
- port connections of the switches. Generally, after a certain amount of time, or at the occurrence of a certain event, the connection enters the termination phase, in which the connection is terminated, and the switches which made up the connection are freed to support other connections.
In accordance with the present invention, a technique referred to as "connectionaggregation" is provided in order to reduce the total number of connections required between the switches (i.e., inside the switch cloud). Connection aggregation entails providing a pre-established path between a select pair of an ingress switch (connected to the source end station) AME~IDED Sl IEE~
_ . .
CA 022~6698 1998-11-30 and an egress switch (connected to the destination end station). By establishing predetermined paths, only the ingress and egress switches need be involved in the connection setup phase, thereby reducing the connection setup time. In addition, providing predetermined paths reduces the number of connections required to be m~int,lined in the trunk switches, and reduces the CPU
load in each trunk switch.
In accordance with the invention, a "virtual path ID" is used to describe the path to be taken between an ingress device and egress device (i.e., switches). A "virtual circuit ID" is used to describe which two endpoints (i.e., source and destination end stations) are attached by the virtual path. In one embodiment described herein, the destination address (DA) and source 0 address (SA) fields in a MAC frame packet are replaced with the virtual path ID, the virtual circuit ID is inserted in a VLAN-ID field, and a packet identifier marking this as an aggregated packet is added to create a modified packet which is then sent on the pre-established path to the egress switch. In this embodiment, the 96-bit virtual path ID includes a 48-bit destination MAC
address of the in-port of the egress switch (to which the destination end station is connected).
The virtual path ID also includes a 24-bit path identifier (02:PP:PP) in which the local a-lmini~tered bit is set, and the rem~ining 16 bits (PP:PP) identify one of 65K unique paths to the egress switch. Because the virtual path ID must be unique not only to a particular switch, but also unique within the switch cloud, the last 24 bits (of the virtual path ID) contain the lower 24 bits of the ingress switch MAC address (XX:YY:ZZ). The ingress and egress switches exchange 20 their MAC addresses so each has the necessary information. Each switch on the predetermined virtual path has been set, prior to the connection setup phase, by for example entering a connection in its switching table (connection database) which maps an in-port and out-port to the virtual path ID.
The virtual circuit ID is assigned during the connection setup phase by the egress 25 switch and sent to the ingress switch in response to the connection request. When the modified packet is received by the egress switch, the virtual circuit is used to restore the original packet in order to send the restored packet to the destination end station. The other switches in the path, between the ingress and egress switches, do not need to use the virtual circuit field in the forwarding decision.
These and other aspects of the present invention will be more fully described inthe following detailed description and drawings.
CA 022~6698 1998-ll-30 W O 97/47113 PCTnUS97/09552 '4 ~ Brief Description of the Drawings Fig. 1 is a schematic logical representation of a pre-established path in a switch cloud between an ingress switch and egress switch, connecting a source end station and destination end station in accordance with this invention;
Fig. 2A is a portion of a MAC frame data packet sent by an end station, showing select fields, and Fig. 2B shows the corresponding fields of a modified packet as determined during connection setup by the ingress switch;
Fig. 3A is a schematic logical representation of a pre-established path between a source end station and destination end station, and Fig. 3B shows the corresponding portions of o the data packet as it is transmitted from the source, through the ingress switch, cloud switch and egress switch to the destination;
Fig. 4A, 4B, 4C, are flow charts illustrating steps performed at the ingress switch and data packet tr~nsmission;
Fig. 5 is a schematic logical representation of a VLAN switch domain, including multiple VLANs;
Fig. 6A-6B is an example of a local directory cache;
Figs. 7A-7C are examples of the following databases: link state, link state neighbor, and link state switching, respectively;
Fig. 8 is a schematic illustration of a portion of a switched network to illustrate an 20 exarnple of a path determination service;
Fig. 9 is a schematic illustration of a network topology built with FPS switches;
Fig. 10 is a schematic illustration of an FPS switch;
Fig. 11 is a logical view of an FPS switch;
Fig. 12 is a schematic illustration of a VLAN domain, illustrating the management 2~ of the VLAN switches;
Fig. 13 is a schematic illustration of a computer ~I,pal~lus.
Detailed Description Figs. 1-4 illustrate generally the connection aggregation scheme of the present 30 invention. Figs. 5-13 provide a more detailed description of a specific embodiment and implementation of the invention.
~UE~ll~l~ SEnEET ~RULE 91) ISAIEP
CA 02256698 1998-ll-30 W O97/47113 PCTrUS97/09552 Fig. 1 shows a switch cloud 10 Including a plurality of trunk switches 16, 17, 20 and 21. A pre-established path 12 is provided between an ingress switch 15, connected to a source end station 14, and an egress switch 18, connected to a destination end station 19. The RLE~ V SHEET ~RULE 91) ISAIEP
CA 022~6698 1998-11-30 Wo 97/47113 PCT/USg7109552 pre-established path includes trunk switches 16 and 17 between ingress switch 15 and egress switch 18.
Figs. 2-4 illustrate by way of example how a MAC frame data packet is modified to enable switching along the pre-established path. It is assumed, as will be described later, that s the virtual path 12 is already in place, and known to all switches 15, 16, 17, 18 on the path, prior to connection setup.
A MAC frame packet is sent from source end station 14, which is intended for destination end station 19. The packet includes a header portion 30 which includes the fields 31-34 shown in Fig. 2A. Field 31, labeled "DA", is the unique MAC (Media Access Control) o address of the destination end station 19. ~ield 32, labeled "SA", contains the MAC address of the source end station 14. Field 33, labeled "Ether Type", contains the IEEE defined VLAN
(Ll/L2) type field. Field 34, labeled "VLAN ID", is an optional field.
A "MAC frame" packet is a connectionless packet as described in IEEE
Publication 802.3. As described therein, a MAC frame generally contains the following fields:
5 preamble; start frame delimiter; destination address; source address; type/length field; payload (i.e., data and padding); and frame check sequence.
The data packet containing header 30, is transmitted to ingress switch 15, wherethe header portion 30 is modified to become header portion 40. As shown in Figs. 2A-2B, the header portion 40 includes three fields, which correspond to the ~lelds in header portion 30 20 connected by dashed lines. The combined fields 31 and 32 (DA and SA) become the virtual path field 41. The Ether Type field 33, which is modified to contain a packet type identifier which indicates that this is an aggregated packet, becomes the Ether Type field 45. The VLAN ID field 34 becomes the virtual circuit field 46.
In this disclosure, a field may be modified by inserting or overlaying the new data 25 in a field; thus, modifying a packet by "adding" information is meant to include inserting and/or overlaying. In addition, the specific fields which may be modified are not limited to those modified in the present embodiment; depending on the application, another field may be utilized.
The virtual path identifies the pre-established path to be taken between the ingress switch 15 and egress switch 18. As shown in Fig. 2B, the virtual path field 41 has three portions 30 42-44. The first portion 42 contains the 48-bit MAC address of the egress switch and its port instance which connects to the destination end station 19. The second portion 43 contains a 24-bit path identifier (02:PP:PP), in which the local ~-lmini~tered bit is set and PP:PP identifies one CA 022~6698 1998-ll-30 of 65K unique paths to the egress switch. The third portion 44 contains the lower three bytes (24 bits) of the MAC address of the ingress switch 15 (XX:YY:ZZ). This scheme guarantees that the g6-bit virtual path (in field 41) is unique within the switch cloud. Ether Type field 45 contains the packet identifier 48 and virtual circuit field 46 contains the out-port and out-header 47 on the 5 egress switch 18.
Fig. 4A is a flow chart illustrating the steps performed at the ingress switch. In step 49, a MAC frame data packet arrives at the ingress switch 15 from the source end station 14.
A look-up is performed on the DA-SA (and any other relevant fields) and the DA-SA fields 3 l -32 are replaced with the virtual path ID 41 (step 50). The look-up table provides mappings lO between the source and destination MAC addresses and the egress switch/port MAC address 42, the path identifier 43, and the lower three bytes of the ingress switch MAC 44. The Ether Type field is modified to include the packet identifier (step 51). In addition, the virtual circuit is inserted in the VLAN field 34 (step 52). To accomplish this, the DA/SA is sent by the ingress switch to the egress switch as part of a connection request; the egress switch then maps a new 5 connection in its lookup table (database) in which it assigns a virtual circuit ID number to the connection and stores the DA/SA in its table; the egress switch then sends the virtual circuit ID
back to the ingress switch (in response to the connection request). The packet thus modified (by the ingress switch) is forwarded to the next switch (step 53), which in this case is cloud switch 16.
As illustrated in the flow chart of Fig. 4B, the modifled packet arrives at cloud switch 16 (step 60). A look-up is performed based on the virtual path ID to determine the out-port (step 61). Then, the modified packet is forwarded from this out-port to the next switch (step 62).
After similar tr~n~mission through cloud switch 17, the modified packet arrives at 2s egress switch 18 (step 70 in Fig. 4C). A connection look-up is performed based on mapping the virtual path ID and virtual circuit ID to the out-port and out-header, to enable restoration of the original MAC frame packet and tr~nsmission to the destination end station (step 71). The virtual path in the modified packet is replaced with the DA/SA (step 72), the virtual circuit is removed - from the VLAN field (step 73), and the packet identifler in the Ether Type field is replaced with 30 the original information. The restored (re-assembled) original packet is then forwarded to the destin~tion end station (step 74). Thus the packet that came into the cloud is the same as the packet that comes out of the cloud.
RE(~ ;11 SHEET (RULE 91) ISA/EP
.
CA 022~6698 1998-11-30 There will next be described a specific embodiment for implementing the present invention. Various aspects of this embodiment may be more particularly described in copending and commonly owned U.S. Serial No. 08/626,596 entitled "Distributed Connection-Oriented Services For Switched Communications Networks," filed April 2, 1996 by K. Dobbins et al., and hereby incorporated by reference in its entirety.
FIG. 5 illustrates generally a logical view of an exemplary switched network with end systems (stations) on different VLANs. The representative network 110 has four switches 111 -114, all of the switches being connected in a meshed topology by physical links 115 between network ports forming, e.g., point-to-point connections. The plurality of end systems o 120- 131 extend from access ports on various switches. The end systems are grouped into different subsets which have different VLAN identifiers (VLAN-IDs): default VLAN (117), red VLAN (118), and blue VLAN (119), respectively. As shown in FIG. 5, red VLAN includes end systems 120, 122, 125, 128 and 130, and blue VLAN includes end systems 121, 123, 124, 126, 127, 129 and 131. Default VLAN is a special VLAN to which all ports and end systems are initially assigned; after being reassigned to another VLAN, they are removed from the default VLAN.
The operation of this exemplary VLAN network will be discussed under the following subsections:
~ Directory A~lmini.~tration ~ Link StateTopology Exchange ~ Path Determination.
Directory Administration During a discovery time, each switch discovers its local cormected end systems 25 (i.e., switch 111 in Fig. 5 discovers end systems 120-122) in order to provide a mapping of end system MAC addresses to access ports, as well as a mapping of end system MAC addresses (or access ports) to VLAN-IDs. In this particular embodiment, a local directory is provided (see Figs. 6A-6B) which contains all node-related information including:
~ the node (e.g., machine address of the end system) ~ any upper layer (alias) protocol addresses discovered with the node ~ the VLAN-IDs to which the node is mapped RE~ ;V SHEET (RULE 91) ISAIEP
CA 022~6698 1998-ll-30 W O 97/47113 PCT~US97/09552 ~ the local switch port(s) on which the node was discovered (plural for recllln(l~nt links) ~ the owner switch(es) hardware address (plural for redundant access switches).
As shown in Fig. 6A, the local directory of nodes includes in column order: the "Switch Port" (to which the end system is attached); the "Device MAC Address" (for the attached end system or switch); the "Node State" ("local" for an attached end system, "virtual node" for an attached switch); "Call Tag" (for the call associated within this entry); "Last Heard"
(the elapsed time since the attached device was last heard from); "Age" (the time since the node o was discovered), "Alias Count" (the number of alias' mapped to the MAC end system); and "VLAN Count" (the number of VLANs to which the entry belongs).
Fig. 6B includes a mapping of user MAC address to higher-layer protocol ("alias") addresses, such as network layer addresses, client addresses and server addresses. Use of these higher-layer protocol addresses enables a VLAN management application to verify or place users in the correct location. For example, if a red VLAN maps to IP subnet 42, then the network layer mappings for all red VLAN users should show an IP address that also maps to subnet 42. The Local Directory with alias address information as shown in Fig. 6B includes the fields: "Owner Switch" (the owner ofthe attached end system); "Switch Port"; "Device MAC
Address"; "Alias Type" (e.g., IP or IPX); "Alias Address"; "VLAN Policy" (discussed hereinafter); and "VLAN-ID" (e.g., red, blue, default).
The end system and/or VLAN mappings may be provided by an external application. Whether the mappings at each local access switch are done implicitly (e.g., by using a mapping criteria table or protocol-specific mappings) or explicitly (e.g., by using an external management application), the key point is that each access switch only m~int~in~ its locally 2s attached users. Taken as a group, this combination of local directories provides a "Virtual Directory" which can easily scale to fairly large numbers of users.
Assignment of VLANs to individual ports is the simplest embodiment to ~mini~ter and to engineer in a switch. A switch port can be assigned to more than one VLAN;
however, all users on a port with multiple VLANs will see all of the cross-VLAN traffic.
Alternatively, VLANs can be assigned based on lP subnets or end system MA(l addresses.
In order to provide connectivity "out of the box" (prior to any VLAN
a~mini~tration), by default all switch ports and end systems belong to a common VLAN (for tag-RE~ll~l~ SHEET(RULE 91) ISAIEP
CA 022~6698 1998-11-30 W O 97147113 PCTrUS97/09552 based flooding), known as the default VLANll9 (see Fig. S). Once a port or end system is assigned to a specific VLAN, it is automatically removed from the default VLAN.
It may also be desirable to have VLAN switches discover and automatically place end systems in one or more reserved VLANs. For example, as switches discover IPX servers, 5 they would be placed in the "IPX server" VLAN.
External services may communicate with the local directory via its application progr~mming interface (API). Information may be added to the directory by those applications that require node-related information to make switching decisions. The directory maintains the node information based on a set of rules, until the node is removed. External services may also 10 request for a node to be deleted via the API.
As implemented in an object-oriented progr~mming language, such as C~+7 the directory may comprise a class which provides the common API and manages the directory nodes and any tables used for queries. For example, the directory node table (Fig. 6a) and directory alias table (Fig. 6b) enable bi-directional queries, e.g., node-to-alias, or alias-to-node.
Link State Topology Exchange A path determination algorithm is used to determine the pre-established paths between switches. For example, a shortest path may be chosen based upon metrics such as summation of link cost, number of calls allocated on each link in the path, etc. Alternatively, 20 multiple equal-cost paths to a given destination may be chosen to provide load balancing (i.e., distribution of the traffic over the multiple paths equally). However, before a path to a destination can be chosen, the inter-switch topology must be determined.
In this embodiment, a specific link state protocol is defined for the deterrnining the inter-switch topology. For a general discussion of link state routing, see ~adia Perlman7 25 "Interconnections: Bridges and Routers" (Reading, Mass: Addison-Wesley, 1992), pages 221-222. Other link state protocols may be used in the present invention in order to enable path determination.
There are four basic components of a link state routing method. First7 each switch is responsible for meeting its neighbors and learning their names. Hello packets are sent 30 periodically on all switch interfaces in order to establish and maintain neighbor relationships. In addition7 hellos may be multicast on physical media having multicast or broadcast capability7 in order to enable dynamic discovery of a neighboring switch.
CA 022~6698 1998-11-30 All switches connected to a common network must agree on certain parameters, e.g., hello and dead intervals, etc. These parameters are included in the hello packets; differences in these parameters will inhibit the forming of neighbor relationships. For example, the hello interval designates the number of seconds between a switch's hello packets. The dead interval defines the number of seconds before declaring a silent (not heard from) switch down. The hello packet may fùrther include a list of neighbors, more specifically the switch IDs of each switch from whom valid hello packets have recently been seen on the network; recently means in the last dead interval.
A second basic component (of a link state method) is that each switch constructs a 0 packet known as a "link state packet" or "LSP" which contains a list of the names and costs to each of its neighbors. Thus, when an adjacency is being initi~li7~ t~b~ce description packets" are exchanged which describe the contents of a topological database. For this purpose, a poll-response procedure is used. One switch is designated a master, and the other a slave. The master sends database description packets (polls) which are acknowledged by database description packets sent by the slave (responses). The responses are linked to the polls via the packet's sequence numbers.
The main portion of the database description packet is a list of items, each item describing a piece of the topological database. Each piece is referred to as a "link state advertisement" and is uniquely identified by a "link state header" which contains all of the 20 information required to uniquely identify both the advertisement and the advertisement's current instance.
A third basic component (of a linlc state method) is that the LSPs are transmitted to all of the other switches, and each switch stores the most recently generated LSP from each other switch.
For example, after exch~nging database description packets with a neighboring switch, a switch may find that parts of its topological database are out of date. A "link state request packet" is used to request the pieces of the neighbor's database that are more up to date.
The sending of link state request packets is the last step in bringing up an adjacency.
A switch that sends a link state request packet has in mind the precise instance of the database pieces it is requesting (defined by LS sequence number, LS checksum, and LS age).
It may receive even more instances in response. Each advertisement requested is specified by its LS type, link state ID, and advertising switch. This uniquely identifies the advertisement, but not CA 022~6698 1998-11-30 W O 97/47113 PCTrUS97/09552 its instance. Link state request packets are understood to be requests for the most recent instance (whatever that might be).
"Link state update packets" carry a collection of link state advertisements one hop further from its origin, several link state advertisements may be included in a single packet. Link s state update packets are multicast on those physical networks that support multi-cast/broadcast.
In order to make the flooding procedure reliable, flooded advertisements are acknowledged in "link state acknowledgment packets." If retransmission of certain advertisements is necessary, the retransmitted advertisements are carried by unicast link state update packets.
In summary, there are five distinct types of link state advertisements, each of o which begins with the standard link state header:
hello ~ database description Iink state request ~ Iink state update 1S . link state acknowledgment.
Each link state advertisement describes a piece of the switch domain. All link state advertisements are flooded throughout the switch domain. The flooding algorithm is reliable, insuring that all switches have the same collection of link state advertisements. This 20 collection of advertisements is called the link state (or topological) database. From the link state database or table (see Fig. 7A), each switch constructs a shortest path tree with itself as the root.
This yields a link state switching table (see Fig. 7C), which is keyed by switch/port pair. Fig. 7B
is an example of a link state neighbor table.
The following fields may be used to describe each switch link.
2s A "type" field indicates the kind of link being described. It may be a link to a transit network, to another switch, or to a stub network.
A "link ID" field identifies the object that this switch link connects to. When connecting to an object that also originates a link state advertisement (i.e., another switch or a transit network), the link ID is equal to the other advertisement' s link state ID. The link ID
30 provides the key for looking up an advertisement in the link state database.
H~;~; l (RULE 91) ISA/EP
CA 022~6698 1998-ll-30 W O97/47113 PCTrUS97/09552.
A "link data" field contains information which depends on the link's type field.For example, it may specify a switch's associated port name, which is needed during building of the switching table, or when calculating the port name of the next hop.
A "metrics" field contains the number of different "types of service" (TOS) metrics for this link, not counting a required metric field TOS 0. For each link, separate metrics may be specified ~or each type of service. The metric is the cost of using an outbound switch link, for traff1c of the specified TOS.
Every switch originates a "switch links" advertisement. In addition, at any given time one of the switches has been elected to serve as the "Designated Switch." The Designated o Switch also originates a "network links" advertisement for each transit network (i.e., multi-access network that has more than one attached switch) in the area. The "network links" advertisement describes all switches attached to the network, including the designated switch itself. The advertisement's link state ID field lists the Switch ID of the de~ign~te-1 switch. The distance from the network to all attached switches is zero, for all types of service; thus the TOS and s metric fields need not be specified in the "network links" advertisement.
A fourth main component (of a link state method) is that each switch, now armed with a complete map of the topology (the information in the LSPs yields complete knowledge of the graph), computes a path to a given destination. Thus, once the LSPs have been distributed and proper protocol adjacencies formed, a Dijkstra algorithm (see R. Perlman, pp. 221-222, supra) may be run to compute routes to all known destinations in the network. This is discussed further in the following section entitled "Connection Management."
Some of the beneficial features of the link state protocol described herein are summarized below.
The link state protocol does not require configuration information. Instead, it employs the MAC address of a device for unique identification. Ports are also uniquely identified using the switch MAC address and a port number instance.
In addition, the link state protocol has no network layer service provider, as it operates at the MAC layer. As a result, the protocol incorporates the required features that are - typically provided by a network layer provider, such as fragmentation In order to provide network layer services, the link state protocol uses a well-known Cabletron Systems, Inc. multicast address (01001 D000000) for all packets sent and received. This enables all media to be treated as shared broadcasts, simplifying the protocol.
CA 022~6698 l998-ll-30 W O97/47113 PCTrUS97/09552 Due to the "flat" nature of switched fabrics, and the unrelated nature of MAC
address assignments, the present protocol does not provide for summarization of the address space (or classical IP subnet information), or level 2 routing (IS-IS Phase V DECNet). There exists a single area, and every switch within that area has a complete topology of the switch 5 fabric.
Because a single domain exists for the switch fabric, there is no need to provide for interdomain reachability.
Rather than calculating the best next hop as in other link state shortest path first algorithms, the present protocol method calculates the best next hops for the entire path. This is 0 significant in that the path is only determined once, instead of at each switch hop.
Path Deterrnination The following is a general example of applying metrics to the path deterrnin~tion.
s Example As illustrated in Fig. 8, a path may be determined from a call-origin~ling switch X1 (150), for a destination switch X5 (154). The protocol returns the best (meaning lowest aggregated metric) path to X5. This would be the path "e,d" (through switch X4 (153)), assuming like media and default metric assignments. Path l'e,d" has a value of 10. Path "a,b,c"
(through switches X2 (151) and X3 (152)) has value of 15 and would not be chosen. Should link "e" fail, the path "a,b,c" would take over and continue to provide connectivity. Should the value of the metric be manipulated such that path "a,b,c" and path "e,d" were of equal value, the protocol would return both as possible paths.
Once a path between an ingress switch and egress switch is determined (i.e., thepre-established or virtual path), the ingress switch sends a source-routed connect message (cont~ining an in-order list of switch nodes and links in the path) to set all switches on the path.
Each switch on the path maps a connection in its switching table (Fig. 7c) based on the virtual path identifier. The final (egress) switch on the path sends a path acknowledgment signal back to the ingress switch. Later, when the ingress switch receives a data packet intended for a destination attached to the egress switch, it forwards the data along the virtual path.
CA 022~6698 1998-11-30 W O97/47113 PCTrUS97/09552 -]4-~xemplar~ FPS Netvvork and Switches FIG. 9 shows a representative network topology built with six fast packet switches (FPS) labeled S1-S6 and connected by links L. Each switch has for example four ports;
s some ports are labeled A for access and some are labeled N for network. The end systems are connected to the access ports by links L and are labeled "M_". One end system is a network management station (NMS) or server (MlO), which may also include an external connection service and/or a VLAN management application.
FIG. 10 is a schematic illustration of an FPS switch 170 having a plurality of 10 ports 171. A host port 172 connects the switch to its host CPU 173, which may be an I960 microprocessor sold by Intel Corporation. The host CPU is connected to a system management bus (SMB) 174 for receipt and tr~n~mi~ion of discovery and other control messages.
FIG. l l illustrates the internal operation of a switch module 178. The FPS switch 186 includes in-ports 180, out-ports 181, a connection database 182, a look-up engine 183~ and a multilevel programmable arbiter MPA 184. The FPS switch 186 sends and receives messages from the host agent 185, which includes a management agent 187, a discovery agent 188, and a VLAN agent 189. The management agent 187 provides external control of the switch through the network management system M I O. The discovery agent 188 provides a mapping of local end systems to switching ports through a passive listening (snooping) capability. Adjacent 20 switches are also discovered and mapped through an explicit switch-to-switch protocol (non-passive). The VLAN agent maps VLANs to access ports or end systems.
FIG. 12 illustrates schematically a VLAN domain 140 in which a plurality of VLAN switches I ~ I, 142 are managed by a VLAN management application 143. The switches have access ports 144 connected to end systems 145, and network ports 146 connecting the 2s switches. As previously discussed, a topology exchange occurs between switches 141 and 142.
The management application 143 communicates with each switch on links 147 via the SNMP
(Simple Network Management Protocol) mes.c~gin~ protocol.
The switches may contain SMNP MIBs for element management and remote - control of the switch elements. The managed objects accessible by the MIB (Management 30 Information Base) may be accessed with the standard SNMP Get, GetNext, and Set messages.
The MIB interface allows an external application to assign the VLAN mappings to access ports andlor end systems.
RE~ll~l~ SHEET(RULE 91) ISAJEP
CA 022~6698 1998-11-30 W O 97/47113 PCTrUS97/09552.
Any of the above embodiments may be implemented in a general purpose computer 190 as shown in FIG. 13. The computer may include a computer processing unit (CPU) 191, memory 192, a processing bus 193 by which the CPU can access the memory 192, and access to a network 194.
s The invention may be a computer a~pa-dlus which performs the functions of any of the previous embodiments. Alternatively, the invention may be a memory 192, such as a floppy disk, compact disk, or hard drive, which contains a computer prograrn or data structure, for providing to a general purpose computer instructions and data for carrying out the functions of the previous embodiments.
0 In an alternative embodiment, the "Ether type" field 33 could be used instead of the "VLAN-ID" field 34 for demultiplexing the modified frame. With this approach, the Ether type field 4~ is remapped over the existing Ether type ~leld 3 3 of the packet on the ingress switch. On the egress switch, the Ether type field 45 is used to demultiplex the frame, and the original frame is restored.
In another alternative embodiment, layer 3 (i.e., network layer) switching could be used instead of layer 2 switching in the ingress switch as previously described to accomplish aggregation. In this approach, the layer 3 connection would point to the ap~lopliate virtual path/virtual circuit. The egress switch would still be multiplexed on the level 2 address.
Providing layer 3 aggregation allows different quality of service parameters to be used for 20 different MAC addresses and in essence~ provides a higher level of fidelity than layer 2.
To enable multicasting, special multicast aggregated connections could be programmed through the switch cloud. These connections could be established per VLAN, allowing multiple multicast destinations to be served by a single set of connections.
Because the virtual path 31 is a DA-SA pair, it is possible to operate this 2s invention with legacy devices serving as trunk switches. If a legacy device is an ingress or egress switch, then: (1) aggregation cannot be used for traffic terrnin~tin~ with that device; or (2) the packet must be demultiplexed by the last non-legacy switch in the cloud before the legacy switch.
CA 02256698 l998-ll-30 W O97/47113 PCT~US97/09552.
Having thus described several particular embodiments of the invention, various modifications and improvements will readily occur to those skilled in the art. Accordingly, the foregoing description is by way of example only, and not intended to be limiting.
s
.
CONNECTION AGGREGATION IN
SWITCHED COMMUNICATIONS NETWORKS
Field of the Invention This invention relates to a method and apparatus for providing connection aggregation within a switched communications network in which pre-established paths are provided in order to reduce the total number of connections required between switches.
Background of the Invention Most data communications networks today rely heavily on shared-media, packet-based LAN technologies for both access and backbone connections. These networks use bridges and routers to connect multiple LANs into global internets. However, such router-based 5 net~,vorks cannot provide the high bandwidth and quality of service required by the latest networking applications and new faster workstations.
Switched networking is a proposed solution intended to provide additional bandwidth and quality of service. In such networks, the physical routers and hubs are replaced by switches and a management system is optionally provided for monitoring the configuration of 20 the switches. The overall goal is to provide a scalable high-performance network where all links between switches can be used concurrently for connections.
One proposal is to establish a VLAN switch domain. A VLAN is a "virtual local area network" of users having full connectivity (sharing broadcast, multicast and unicast messages) independent of any particular physical or geographical location. In other words, users 25 that share a virtual LAN appear to be on a single LAN segment regardless of their actual location. Although the term "VLAN" is widely used as a new method of solving the increasing demand for bandwidth, the effectiveness of existing VLAN systems is wholly dependent on the particular implementation. For example, a VLAN implementation which allows VLAN
~ignments to end systems, as well as ports, provides a more effective means of VLAN
30 groupings. Other performance-determining characteristics include the manner of resolving unknown destination and broadcast traffic (which consume both network bandwidth and end system CPU bandwidth), the ability to allow tr~n~mi~ion out multiple ports, hop-by-hop switching determinations (as opposed to determination of a complete path at the call-origin~ting CA 022~6698 1998-11-30 -2- .~ ;~.' ;'';;' switch), and whether multi-protocol routers are required to enable transmission between separate VLANs.
Each of these may have an important effect on the total number of connections intrunk switches, the CPU load in the trunk switches, the speed of connection setup, and the 5 scalability of the system, i.e., ability to m~int ~in performance with increasing numbers of end stations and/or switches.
The journal article entitled "Providing MAC services on an ATM network with point-to-point links", in Internetworking in Broadband Networks, pp. 252-~60, IOS Press, 1993, by J.-Y. LeBoudec and H.L. Truong is directed to a method for providing MAC services to 0 terminal equipment (TE) attached to an ATM network. Specifically, TEs are connected to an ATM switch that provides connectionless service. This service relies on "partial connections"
that the terrninal equipment devices are not aware of. According to this service, TEs implement a single virtual connection for sending and receiving connectionless traffic. The TEs use an address resolution protocol to resolve destination MAC addresses to partial connections.
1~
Surnrnarv of the Invention In accordance with the present invention, a method and apparatus are provided for connection-oriented switching in a communications network. In a connection-oriented communication, a logical association is established between a source end station and a 20 destination end station, so that several separate groups of data ("a data flow") may be sent along the same path that is defined by the logical association. This is distinguished from connectionless communications, wherein each frame,of data is transmitted node-by-node independently of the previous frame.
In general, there are three phases which occur during a connection-oriented 25 communication: connection establishment; data transfer; and connection termination. In the connection establishment phase, the first time a source has data to be sent to a destination, a logical association, also called a connection or a path, is established between the source and the destin~tion. The connection defines nodes and connections between the nodes, for example, the switches between the source and destination, and the ports of the switches through which the 30 data will pass. The path set up at the establishment phase is the path on which the data will be transmitted for the duration of,the active connection. During the data transfer phase, data is transmitted from the source to the destination along the connection, which includes the port-to-A~E~IDED SHEEr CA 022~6698 1998-11-30 Q
-2~
. ~ , . . .
- port connections of the switches. Generally, after a certain amount of time, or at the occurrence of a certain event, the connection enters the termination phase, in which the connection is terminated, and the switches which made up the connection are freed to support other connections.
In accordance with the present invention, a technique referred to as "connectionaggregation" is provided in order to reduce the total number of connections required between the switches (i.e., inside the switch cloud). Connection aggregation entails providing a pre-established path between a select pair of an ingress switch (connected to the source end station) AME~IDED Sl IEE~
_ . .
CA 022~6698 1998-11-30 and an egress switch (connected to the destination end station). By establishing predetermined paths, only the ingress and egress switches need be involved in the connection setup phase, thereby reducing the connection setup time. In addition, providing predetermined paths reduces the number of connections required to be m~int,lined in the trunk switches, and reduces the CPU
load in each trunk switch.
In accordance with the invention, a "virtual path ID" is used to describe the path to be taken between an ingress device and egress device (i.e., switches). A "virtual circuit ID" is used to describe which two endpoints (i.e., source and destination end stations) are attached by the virtual path. In one embodiment described herein, the destination address (DA) and source 0 address (SA) fields in a MAC frame packet are replaced with the virtual path ID, the virtual circuit ID is inserted in a VLAN-ID field, and a packet identifier marking this as an aggregated packet is added to create a modified packet which is then sent on the pre-established path to the egress switch. In this embodiment, the 96-bit virtual path ID includes a 48-bit destination MAC
address of the in-port of the egress switch (to which the destination end station is connected).
The virtual path ID also includes a 24-bit path identifier (02:PP:PP) in which the local a-lmini~tered bit is set, and the rem~ining 16 bits (PP:PP) identify one of 65K unique paths to the egress switch. Because the virtual path ID must be unique not only to a particular switch, but also unique within the switch cloud, the last 24 bits (of the virtual path ID) contain the lower 24 bits of the ingress switch MAC address (XX:YY:ZZ). The ingress and egress switches exchange 20 their MAC addresses so each has the necessary information. Each switch on the predetermined virtual path has been set, prior to the connection setup phase, by for example entering a connection in its switching table (connection database) which maps an in-port and out-port to the virtual path ID.
The virtual circuit ID is assigned during the connection setup phase by the egress 25 switch and sent to the ingress switch in response to the connection request. When the modified packet is received by the egress switch, the virtual circuit is used to restore the original packet in order to send the restored packet to the destination end station. The other switches in the path, between the ingress and egress switches, do not need to use the virtual circuit field in the forwarding decision.
These and other aspects of the present invention will be more fully described inthe following detailed description and drawings.
CA 022~6698 1998-ll-30 W O 97/47113 PCTnUS97/09552 '4 ~ Brief Description of the Drawings Fig. 1 is a schematic logical representation of a pre-established path in a switch cloud between an ingress switch and egress switch, connecting a source end station and destination end station in accordance with this invention;
Fig. 2A is a portion of a MAC frame data packet sent by an end station, showing select fields, and Fig. 2B shows the corresponding fields of a modified packet as determined during connection setup by the ingress switch;
Fig. 3A is a schematic logical representation of a pre-established path between a source end station and destination end station, and Fig. 3B shows the corresponding portions of o the data packet as it is transmitted from the source, through the ingress switch, cloud switch and egress switch to the destination;
Fig. 4A, 4B, 4C, are flow charts illustrating steps performed at the ingress switch and data packet tr~nsmission;
Fig. 5 is a schematic logical representation of a VLAN switch domain, including multiple VLANs;
Fig. 6A-6B is an example of a local directory cache;
Figs. 7A-7C are examples of the following databases: link state, link state neighbor, and link state switching, respectively;
Fig. 8 is a schematic illustration of a portion of a switched network to illustrate an 20 exarnple of a path determination service;
Fig. 9 is a schematic illustration of a network topology built with FPS switches;
Fig. 10 is a schematic illustration of an FPS switch;
Fig. 11 is a logical view of an FPS switch;
Fig. 12 is a schematic illustration of a VLAN domain, illustrating the management 2~ of the VLAN switches;
Fig. 13 is a schematic illustration of a computer ~I,pal~lus.
Detailed Description Figs. 1-4 illustrate generally the connection aggregation scheme of the present 30 invention. Figs. 5-13 provide a more detailed description of a specific embodiment and implementation of the invention.
~UE~ll~l~ SEnEET ~RULE 91) ISAIEP
CA 02256698 1998-ll-30 W O97/47113 PCTrUS97/09552 Fig. 1 shows a switch cloud 10 Including a plurality of trunk switches 16, 17, 20 and 21. A pre-established path 12 is provided between an ingress switch 15, connected to a source end station 14, and an egress switch 18, connected to a destination end station 19. The RLE~ V SHEET ~RULE 91) ISAIEP
CA 022~6698 1998-11-30 Wo 97/47113 PCT/USg7109552 pre-established path includes trunk switches 16 and 17 between ingress switch 15 and egress switch 18.
Figs. 2-4 illustrate by way of example how a MAC frame data packet is modified to enable switching along the pre-established path. It is assumed, as will be described later, that s the virtual path 12 is already in place, and known to all switches 15, 16, 17, 18 on the path, prior to connection setup.
A MAC frame packet is sent from source end station 14, which is intended for destination end station 19. The packet includes a header portion 30 which includes the fields 31-34 shown in Fig. 2A. Field 31, labeled "DA", is the unique MAC (Media Access Control) o address of the destination end station 19. ~ield 32, labeled "SA", contains the MAC address of the source end station 14. Field 33, labeled "Ether Type", contains the IEEE defined VLAN
(Ll/L2) type field. Field 34, labeled "VLAN ID", is an optional field.
A "MAC frame" packet is a connectionless packet as described in IEEE
Publication 802.3. As described therein, a MAC frame generally contains the following fields:
5 preamble; start frame delimiter; destination address; source address; type/length field; payload (i.e., data and padding); and frame check sequence.
The data packet containing header 30, is transmitted to ingress switch 15, wherethe header portion 30 is modified to become header portion 40. As shown in Figs. 2A-2B, the header portion 40 includes three fields, which correspond to the ~lelds in header portion 30 20 connected by dashed lines. The combined fields 31 and 32 (DA and SA) become the virtual path field 41. The Ether Type field 33, which is modified to contain a packet type identifier which indicates that this is an aggregated packet, becomes the Ether Type field 45. The VLAN ID field 34 becomes the virtual circuit field 46.
In this disclosure, a field may be modified by inserting or overlaying the new data 25 in a field; thus, modifying a packet by "adding" information is meant to include inserting and/or overlaying. In addition, the specific fields which may be modified are not limited to those modified in the present embodiment; depending on the application, another field may be utilized.
The virtual path identifies the pre-established path to be taken between the ingress switch 15 and egress switch 18. As shown in Fig. 2B, the virtual path field 41 has three portions 30 42-44. The first portion 42 contains the 48-bit MAC address of the egress switch and its port instance which connects to the destination end station 19. The second portion 43 contains a 24-bit path identifier (02:PP:PP), in which the local ~-lmini~tered bit is set and PP:PP identifies one CA 022~6698 1998-ll-30 of 65K unique paths to the egress switch. The third portion 44 contains the lower three bytes (24 bits) of the MAC address of the ingress switch 15 (XX:YY:ZZ). This scheme guarantees that the g6-bit virtual path (in field 41) is unique within the switch cloud. Ether Type field 45 contains the packet identifier 48 and virtual circuit field 46 contains the out-port and out-header 47 on the 5 egress switch 18.
Fig. 4A is a flow chart illustrating the steps performed at the ingress switch. In step 49, a MAC frame data packet arrives at the ingress switch 15 from the source end station 14.
A look-up is performed on the DA-SA (and any other relevant fields) and the DA-SA fields 3 l -32 are replaced with the virtual path ID 41 (step 50). The look-up table provides mappings lO between the source and destination MAC addresses and the egress switch/port MAC address 42, the path identifier 43, and the lower three bytes of the ingress switch MAC 44. The Ether Type field is modified to include the packet identifier (step 51). In addition, the virtual circuit is inserted in the VLAN field 34 (step 52). To accomplish this, the DA/SA is sent by the ingress switch to the egress switch as part of a connection request; the egress switch then maps a new 5 connection in its lookup table (database) in which it assigns a virtual circuit ID number to the connection and stores the DA/SA in its table; the egress switch then sends the virtual circuit ID
back to the ingress switch (in response to the connection request). The packet thus modified (by the ingress switch) is forwarded to the next switch (step 53), which in this case is cloud switch 16.
As illustrated in the flow chart of Fig. 4B, the modifled packet arrives at cloud switch 16 (step 60). A look-up is performed based on the virtual path ID to determine the out-port (step 61). Then, the modified packet is forwarded from this out-port to the next switch (step 62).
After similar tr~n~mission through cloud switch 17, the modified packet arrives at 2s egress switch 18 (step 70 in Fig. 4C). A connection look-up is performed based on mapping the virtual path ID and virtual circuit ID to the out-port and out-header, to enable restoration of the original MAC frame packet and tr~nsmission to the destination end station (step 71). The virtual path in the modified packet is replaced with the DA/SA (step 72), the virtual circuit is removed - from the VLAN field (step 73), and the packet identifler in the Ether Type field is replaced with 30 the original information. The restored (re-assembled) original packet is then forwarded to the destin~tion end station (step 74). Thus the packet that came into the cloud is the same as the packet that comes out of the cloud.
RE(~ ;11 SHEET (RULE 91) ISA/EP
.
CA 022~6698 1998-11-30 There will next be described a specific embodiment for implementing the present invention. Various aspects of this embodiment may be more particularly described in copending and commonly owned U.S. Serial No. 08/626,596 entitled "Distributed Connection-Oriented Services For Switched Communications Networks," filed April 2, 1996 by K. Dobbins et al., and hereby incorporated by reference in its entirety.
FIG. 5 illustrates generally a logical view of an exemplary switched network with end systems (stations) on different VLANs. The representative network 110 has four switches 111 -114, all of the switches being connected in a meshed topology by physical links 115 between network ports forming, e.g., point-to-point connections. The plurality of end systems o 120- 131 extend from access ports on various switches. The end systems are grouped into different subsets which have different VLAN identifiers (VLAN-IDs): default VLAN (117), red VLAN (118), and blue VLAN (119), respectively. As shown in FIG. 5, red VLAN includes end systems 120, 122, 125, 128 and 130, and blue VLAN includes end systems 121, 123, 124, 126, 127, 129 and 131. Default VLAN is a special VLAN to which all ports and end systems are initially assigned; after being reassigned to another VLAN, they are removed from the default VLAN.
The operation of this exemplary VLAN network will be discussed under the following subsections:
~ Directory A~lmini.~tration ~ Link StateTopology Exchange ~ Path Determination.
Directory Administration During a discovery time, each switch discovers its local cormected end systems 25 (i.e., switch 111 in Fig. 5 discovers end systems 120-122) in order to provide a mapping of end system MAC addresses to access ports, as well as a mapping of end system MAC addresses (or access ports) to VLAN-IDs. In this particular embodiment, a local directory is provided (see Figs. 6A-6B) which contains all node-related information including:
~ the node (e.g., machine address of the end system) ~ any upper layer (alias) protocol addresses discovered with the node ~ the VLAN-IDs to which the node is mapped RE~ ;V SHEET (RULE 91) ISAIEP
CA 022~6698 1998-ll-30 W O 97/47113 PCT~US97/09552 ~ the local switch port(s) on which the node was discovered (plural for recllln(l~nt links) ~ the owner switch(es) hardware address (plural for redundant access switches).
As shown in Fig. 6A, the local directory of nodes includes in column order: the "Switch Port" (to which the end system is attached); the "Device MAC Address" (for the attached end system or switch); the "Node State" ("local" for an attached end system, "virtual node" for an attached switch); "Call Tag" (for the call associated within this entry); "Last Heard"
(the elapsed time since the attached device was last heard from); "Age" (the time since the node o was discovered), "Alias Count" (the number of alias' mapped to the MAC end system); and "VLAN Count" (the number of VLANs to which the entry belongs).
Fig. 6B includes a mapping of user MAC address to higher-layer protocol ("alias") addresses, such as network layer addresses, client addresses and server addresses. Use of these higher-layer protocol addresses enables a VLAN management application to verify or place users in the correct location. For example, if a red VLAN maps to IP subnet 42, then the network layer mappings for all red VLAN users should show an IP address that also maps to subnet 42. The Local Directory with alias address information as shown in Fig. 6B includes the fields: "Owner Switch" (the owner ofthe attached end system); "Switch Port"; "Device MAC
Address"; "Alias Type" (e.g., IP or IPX); "Alias Address"; "VLAN Policy" (discussed hereinafter); and "VLAN-ID" (e.g., red, blue, default).
The end system and/or VLAN mappings may be provided by an external application. Whether the mappings at each local access switch are done implicitly (e.g., by using a mapping criteria table or protocol-specific mappings) or explicitly (e.g., by using an external management application), the key point is that each access switch only m~int~in~ its locally 2s attached users. Taken as a group, this combination of local directories provides a "Virtual Directory" which can easily scale to fairly large numbers of users.
Assignment of VLANs to individual ports is the simplest embodiment to ~mini~ter and to engineer in a switch. A switch port can be assigned to more than one VLAN;
however, all users on a port with multiple VLANs will see all of the cross-VLAN traffic.
Alternatively, VLANs can be assigned based on lP subnets or end system MA(l addresses.
In order to provide connectivity "out of the box" (prior to any VLAN
a~mini~tration), by default all switch ports and end systems belong to a common VLAN (for tag-RE~ll~l~ SHEET(RULE 91) ISAIEP
CA 022~6698 1998-11-30 W O 97147113 PCTrUS97/09552 based flooding), known as the default VLANll9 (see Fig. S). Once a port or end system is assigned to a specific VLAN, it is automatically removed from the default VLAN.
It may also be desirable to have VLAN switches discover and automatically place end systems in one or more reserved VLANs. For example, as switches discover IPX servers, 5 they would be placed in the "IPX server" VLAN.
External services may communicate with the local directory via its application progr~mming interface (API). Information may be added to the directory by those applications that require node-related information to make switching decisions. The directory maintains the node information based on a set of rules, until the node is removed. External services may also 10 request for a node to be deleted via the API.
As implemented in an object-oriented progr~mming language, such as C~+7 the directory may comprise a class which provides the common API and manages the directory nodes and any tables used for queries. For example, the directory node table (Fig. 6a) and directory alias table (Fig. 6b) enable bi-directional queries, e.g., node-to-alias, or alias-to-node.
Link State Topology Exchange A path determination algorithm is used to determine the pre-established paths between switches. For example, a shortest path may be chosen based upon metrics such as summation of link cost, number of calls allocated on each link in the path, etc. Alternatively, 20 multiple equal-cost paths to a given destination may be chosen to provide load balancing (i.e., distribution of the traffic over the multiple paths equally). However, before a path to a destination can be chosen, the inter-switch topology must be determined.
In this embodiment, a specific link state protocol is defined for the deterrnining the inter-switch topology. For a general discussion of link state routing, see ~adia Perlman7 25 "Interconnections: Bridges and Routers" (Reading, Mass: Addison-Wesley, 1992), pages 221-222. Other link state protocols may be used in the present invention in order to enable path determination.
There are four basic components of a link state routing method. First7 each switch is responsible for meeting its neighbors and learning their names. Hello packets are sent 30 periodically on all switch interfaces in order to establish and maintain neighbor relationships. In addition7 hellos may be multicast on physical media having multicast or broadcast capability7 in order to enable dynamic discovery of a neighboring switch.
CA 022~6698 1998-11-30 All switches connected to a common network must agree on certain parameters, e.g., hello and dead intervals, etc. These parameters are included in the hello packets; differences in these parameters will inhibit the forming of neighbor relationships. For example, the hello interval designates the number of seconds between a switch's hello packets. The dead interval defines the number of seconds before declaring a silent (not heard from) switch down. The hello packet may fùrther include a list of neighbors, more specifically the switch IDs of each switch from whom valid hello packets have recently been seen on the network; recently means in the last dead interval.
A second basic component (of a link state method) is that each switch constructs a 0 packet known as a "link state packet" or "LSP" which contains a list of the names and costs to each of its neighbors. Thus, when an adjacency is being initi~li7~ t~b~ce description packets" are exchanged which describe the contents of a topological database. For this purpose, a poll-response procedure is used. One switch is designated a master, and the other a slave. The master sends database description packets (polls) which are acknowledged by database description packets sent by the slave (responses). The responses are linked to the polls via the packet's sequence numbers.
The main portion of the database description packet is a list of items, each item describing a piece of the topological database. Each piece is referred to as a "link state advertisement" and is uniquely identified by a "link state header" which contains all of the 20 information required to uniquely identify both the advertisement and the advertisement's current instance.
A third basic component (of a linlc state method) is that the LSPs are transmitted to all of the other switches, and each switch stores the most recently generated LSP from each other switch.
For example, after exch~nging database description packets with a neighboring switch, a switch may find that parts of its topological database are out of date. A "link state request packet" is used to request the pieces of the neighbor's database that are more up to date.
The sending of link state request packets is the last step in bringing up an adjacency.
A switch that sends a link state request packet has in mind the precise instance of the database pieces it is requesting (defined by LS sequence number, LS checksum, and LS age).
It may receive even more instances in response. Each advertisement requested is specified by its LS type, link state ID, and advertising switch. This uniquely identifies the advertisement, but not CA 022~6698 1998-11-30 W O 97/47113 PCTrUS97/09552 its instance. Link state request packets are understood to be requests for the most recent instance (whatever that might be).
"Link state update packets" carry a collection of link state advertisements one hop further from its origin, several link state advertisements may be included in a single packet. Link s state update packets are multicast on those physical networks that support multi-cast/broadcast.
In order to make the flooding procedure reliable, flooded advertisements are acknowledged in "link state acknowledgment packets." If retransmission of certain advertisements is necessary, the retransmitted advertisements are carried by unicast link state update packets.
In summary, there are five distinct types of link state advertisements, each of o which begins with the standard link state header:
hello ~ database description Iink state request ~ Iink state update 1S . link state acknowledgment.
Each link state advertisement describes a piece of the switch domain. All link state advertisements are flooded throughout the switch domain. The flooding algorithm is reliable, insuring that all switches have the same collection of link state advertisements. This 20 collection of advertisements is called the link state (or topological) database. From the link state database or table (see Fig. 7A), each switch constructs a shortest path tree with itself as the root.
This yields a link state switching table (see Fig. 7C), which is keyed by switch/port pair. Fig. 7B
is an example of a link state neighbor table.
The following fields may be used to describe each switch link.
2s A "type" field indicates the kind of link being described. It may be a link to a transit network, to another switch, or to a stub network.
A "link ID" field identifies the object that this switch link connects to. When connecting to an object that also originates a link state advertisement (i.e., another switch or a transit network), the link ID is equal to the other advertisement' s link state ID. The link ID
30 provides the key for looking up an advertisement in the link state database.
H~;~; l (RULE 91) ISA/EP
CA 022~6698 1998-ll-30 W O97/47113 PCTrUS97/09552.
A "link data" field contains information which depends on the link's type field.For example, it may specify a switch's associated port name, which is needed during building of the switching table, or when calculating the port name of the next hop.
A "metrics" field contains the number of different "types of service" (TOS) metrics for this link, not counting a required metric field TOS 0. For each link, separate metrics may be specified ~or each type of service. The metric is the cost of using an outbound switch link, for traff1c of the specified TOS.
Every switch originates a "switch links" advertisement. In addition, at any given time one of the switches has been elected to serve as the "Designated Switch." The Designated o Switch also originates a "network links" advertisement for each transit network (i.e., multi-access network that has more than one attached switch) in the area. The "network links" advertisement describes all switches attached to the network, including the designated switch itself. The advertisement's link state ID field lists the Switch ID of the de~ign~te-1 switch. The distance from the network to all attached switches is zero, for all types of service; thus the TOS and s metric fields need not be specified in the "network links" advertisement.
A fourth main component (of a link state method) is that each switch, now armed with a complete map of the topology (the information in the LSPs yields complete knowledge of the graph), computes a path to a given destination. Thus, once the LSPs have been distributed and proper protocol adjacencies formed, a Dijkstra algorithm (see R. Perlman, pp. 221-222, supra) may be run to compute routes to all known destinations in the network. This is discussed further in the following section entitled "Connection Management."
Some of the beneficial features of the link state protocol described herein are summarized below.
The link state protocol does not require configuration information. Instead, it employs the MAC address of a device for unique identification. Ports are also uniquely identified using the switch MAC address and a port number instance.
In addition, the link state protocol has no network layer service provider, as it operates at the MAC layer. As a result, the protocol incorporates the required features that are - typically provided by a network layer provider, such as fragmentation In order to provide network layer services, the link state protocol uses a well-known Cabletron Systems, Inc. multicast address (01001 D000000) for all packets sent and received. This enables all media to be treated as shared broadcasts, simplifying the protocol.
CA 022~6698 l998-ll-30 W O97/47113 PCTrUS97/09552 Due to the "flat" nature of switched fabrics, and the unrelated nature of MAC
address assignments, the present protocol does not provide for summarization of the address space (or classical IP subnet information), or level 2 routing (IS-IS Phase V DECNet). There exists a single area, and every switch within that area has a complete topology of the switch 5 fabric.
Because a single domain exists for the switch fabric, there is no need to provide for interdomain reachability.
Rather than calculating the best next hop as in other link state shortest path first algorithms, the present protocol method calculates the best next hops for the entire path. This is 0 significant in that the path is only determined once, instead of at each switch hop.
Path Deterrnination The following is a general example of applying metrics to the path deterrnin~tion.
s Example As illustrated in Fig. 8, a path may be determined from a call-origin~ling switch X1 (150), for a destination switch X5 (154). The protocol returns the best (meaning lowest aggregated metric) path to X5. This would be the path "e,d" (through switch X4 (153)), assuming like media and default metric assignments. Path l'e,d" has a value of 10. Path "a,b,c"
(through switches X2 (151) and X3 (152)) has value of 15 and would not be chosen. Should link "e" fail, the path "a,b,c" would take over and continue to provide connectivity. Should the value of the metric be manipulated such that path "a,b,c" and path "e,d" were of equal value, the protocol would return both as possible paths.
Once a path between an ingress switch and egress switch is determined (i.e., thepre-established or virtual path), the ingress switch sends a source-routed connect message (cont~ining an in-order list of switch nodes and links in the path) to set all switches on the path.
Each switch on the path maps a connection in its switching table (Fig. 7c) based on the virtual path identifier. The final (egress) switch on the path sends a path acknowledgment signal back to the ingress switch. Later, when the ingress switch receives a data packet intended for a destination attached to the egress switch, it forwards the data along the virtual path.
CA 022~6698 1998-11-30 W O97/47113 PCTrUS97/09552 -]4-~xemplar~ FPS Netvvork and Switches FIG. 9 shows a representative network topology built with six fast packet switches (FPS) labeled S1-S6 and connected by links L. Each switch has for example four ports;
s some ports are labeled A for access and some are labeled N for network. The end systems are connected to the access ports by links L and are labeled "M_". One end system is a network management station (NMS) or server (MlO), which may also include an external connection service and/or a VLAN management application.
FIG. 10 is a schematic illustration of an FPS switch 170 having a plurality of 10 ports 171. A host port 172 connects the switch to its host CPU 173, which may be an I960 microprocessor sold by Intel Corporation. The host CPU is connected to a system management bus (SMB) 174 for receipt and tr~n~mi~ion of discovery and other control messages.
FIG. l l illustrates the internal operation of a switch module 178. The FPS switch 186 includes in-ports 180, out-ports 181, a connection database 182, a look-up engine 183~ and a multilevel programmable arbiter MPA 184. The FPS switch 186 sends and receives messages from the host agent 185, which includes a management agent 187, a discovery agent 188, and a VLAN agent 189. The management agent 187 provides external control of the switch through the network management system M I O. The discovery agent 188 provides a mapping of local end systems to switching ports through a passive listening (snooping) capability. Adjacent 20 switches are also discovered and mapped through an explicit switch-to-switch protocol (non-passive). The VLAN agent maps VLANs to access ports or end systems.
FIG. 12 illustrates schematically a VLAN domain 140 in which a plurality of VLAN switches I ~ I, 142 are managed by a VLAN management application 143. The switches have access ports 144 connected to end systems 145, and network ports 146 connecting the 2s switches. As previously discussed, a topology exchange occurs between switches 141 and 142.
The management application 143 communicates with each switch on links 147 via the SNMP
(Simple Network Management Protocol) mes.c~gin~ protocol.
The switches may contain SMNP MIBs for element management and remote - control of the switch elements. The managed objects accessible by the MIB (Management 30 Information Base) may be accessed with the standard SNMP Get, GetNext, and Set messages.
The MIB interface allows an external application to assign the VLAN mappings to access ports andlor end systems.
RE~ll~l~ SHEET(RULE 91) ISAJEP
CA 022~6698 1998-11-30 W O 97/47113 PCTrUS97/09552.
Any of the above embodiments may be implemented in a general purpose computer 190 as shown in FIG. 13. The computer may include a computer processing unit (CPU) 191, memory 192, a processing bus 193 by which the CPU can access the memory 192, and access to a network 194.
s The invention may be a computer a~pa-dlus which performs the functions of any of the previous embodiments. Alternatively, the invention may be a memory 192, such as a floppy disk, compact disk, or hard drive, which contains a computer prograrn or data structure, for providing to a general purpose computer instructions and data for carrying out the functions of the previous embodiments.
0 In an alternative embodiment, the "Ether type" field 33 could be used instead of the "VLAN-ID" field 34 for demultiplexing the modified frame. With this approach, the Ether type field 4~ is remapped over the existing Ether type ~leld 3 3 of the packet on the ingress switch. On the egress switch, the Ether type field 45 is used to demultiplex the frame, and the original frame is restored.
In another alternative embodiment, layer 3 (i.e., network layer) switching could be used instead of layer 2 switching in the ingress switch as previously described to accomplish aggregation. In this approach, the layer 3 connection would point to the ap~lopliate virtual path/virtual circuit. The egress switch would still be multiplexed on the level 2 address.
Providing layer 3 aggregation allows different quality of service parameters to be used for 20 different MAC addresses and in essence~ provides a higher level of fidelity than layer 2.
To enable multicasting, special multicast aggregated connections could be programmed through the switch cloud. These connections could be established per VLAN, allowing multiple multicast destinations to be served by a single set of connections.
Because the virtual path 31 is a DA-SA pair, it is possible to operate this 2s invention with legacy devices serving as trunk switches. If a legacy device is an ingress or egress switch, then: (1) aggregation cannot be used for traffic terrnin~tin~ with that device; or (2) the packet must be demultiplexed by the last non-legacy switch in the cloud before the legacy switch.
CA 02256698 l998-ll-30 W O97/47113 PCT~US97/09552.
Having thus described several particular embodiments of the invention, various modifications and improvements will readily occur to those skilled in the art. Accordingly, the foregoing description is by way of example only, and not intended to be limiting.
s
Claims (20)
1. A method of forwarding a data packet along a pre-established path in a switched communications network, the method comprising:
receiving a MAC frame packet from a source node at an ingress switch, the packet including a source address of the source node and a destination address of a destination node;
determining a virtual path ID for the pre-established path from the ingress switch to an egress switch attached to the destination node through one or more intervening switches;
adding the virtual path ID to the packet to create a modified packet;
sending the modified packet on the pre-established path to the egress switch.
receiving a MAC frame packet from a source node at an ingress switch, the packet including a source address of the source node and a destination address of a destination node;
determining a virtual path ID for the pre-established path from the ingress switch to an egress switch attached to the destination node through one or more intervening switches;
adding the virtual path ID to the packet to create a modified packet;
sending the modified packet on the pre-established path to the egress switch.
2. The method of claim 1, further comprising:
determining a virtual circuit ID for the source address and destination address;
removing the source address and destination address from the packet and adding the virtual circuit ID to create the modified packet.
determining a virtual circuit ID for the source address and destination address;
removing the source address and destination address from the packet and adding the virtual circuit ID to create the modified packet.
3. The method of claim 1, further comprising:
upon receipt of the modified packet at the egress switch, creating a restored MAC frame packet and forwarding the restored packet to the destination node.
upon receipt of the modified packet at the egress switch, creating a restored MAC frame packet and forwarding the restored packet to the destination node.
4. The method of claim 1, wherein each switch on the pre-established path between the ingress switch and egress switch forwards the packet based on only the virtual path ID.
5. The method of claim 1, wherein the virtual path ID includes an identifier for the pre-established path, at least part of an address for the egress switch, and at least part of an address for the ingress switch.
6. The method of claim 2, wherein the egress switch determines the virtual circuit ID and sends it to the ingress switch.
7. The method of claim 2, wherein the virtual circuit ID comprises an outport and out-header on the egress switch to the destination node.
8. The method of claim 2, wherein the egress switch determines the destination address based on the virtual path ID and virtual circuit ID.
9. The method of claim 2, wherein the virtual circuit ID is removed from the modified packet by the egress switch.
10. The method of claim 1, wherein the source address and destination address are removed from the packet at the ingress switch and replaced by the virtual path ID.
11. The method of claim 10, wherein the virtual path ID is removed from the modified packet by the egress switch and replaced by the destination address and source address.
12. An apparatus for forwarding data packets along a pre-established path in a switched communications network to a destination end system, the network including a plurality of end systems and switches connected by links, the switches having access ports connected to end systems and network ports connected to other switches; and each end system having a unique physical address, the apparatus comprising:
each one of the switches having means for maintaining a connection database of pre-established paths between source and destination end systems; and when a MAC frame packet is received on a port of one switch from a source end system, the one switch having means for accessing its connection database to determine the pre-established path upon which the packet is forwarded based on the unique physical addresses of the source and destination end systems.
each one of the switches having means for maintaining a connection database of pre-established paths between source and destination end systems; and when a MAC frame packet is received on a port of one switch from a source end system, the one switch having means for accessing its connection database to determine the pre-established path upon which the packet is forwarded based on the unique physical addresses of the source and destination end systems.
13. The apparatus of claim 12, wherein the one switch is an ingress switch connected to the source end system and includes:
means for determining a virtual path ID for the pre-established path and means for adding the virtual path ID to create a modified packet for forwarding on the pre-established path.
means for determining a virtual path ID for the pre-established path and means for adding the virtual path ID to create a modified packet for forwarding on the pre-established path.
14. The apparatus of claim 13, wherein the one switch includes:
means for determining a virtual circuit ID for a source address of the source end system and a destination address of the destination end system;
and means for removing the source address and destination address from the packet and replacing the addresses with the virtual path ID to create the modified packet for forwarding on the pre-established path.
means for determining a virtual circuit ID for a source address of the source end system and a destination address of the destination end system;
and means for removing the source address and destination address from the packet and replacing the addresses with the virtual path ID to create the modified packet for forwarding on the pre-established path.
15. The apparatus of claim 13, further comprising:
means for creating a restored MAC frame packet and forwarding the restored packet to the destination node upon receipt of the modified packet at an egress switch connected to the destination node.
means for creating a restored MAC frame packet and forwarding the restored packet to the destination node upon receipt of the modified packet at an egress switch connected to the destination node.
16. The apparatus of claim 13, further comprising:
means for forwarding the modified packet based on only the virtual path ID.
means for forwarding the modified packet based on only the virtual path ID.
17. The apparatus of claim 13, wherein the virtual path ID includes an identifier of the pre-established path, and at least part of an address for an egress switch connected to the destination node.
18. The apparatus of claim 17, wherein the egress switch includes means for determining a virtual circuit ID and means for sending the virtual circuit ID
to the ingress switch.
to the ingress switch.
19. The apparatus of claim 18, wherein the egress switch includes means for determining the destination address based on the virtual path ID and the virtual circuit ID.
20. The apparatus of claim 18, wherein the egress switch includes means for removing the virtual circuit ID from the modified packet.
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US08/657,414 US6151324A (en) | 1996-06-03 | 1996-06-03 | Aggregation of mac data flows through pre-established path between ingress and egress switch to reduce number of number connections |
US08/657,414 | 1996-06-03 | ||
PCT/US1997/009552 WO1997047113A1 (en) | 1996-06-03 | 1997-06-02 | Connection aggregation in switched communications networks |
Publications (2)
Publication Number | Publication Date |
---|---|
CA2256698A1 CA2256698A1 (en) | 1997-12-11 |
CA2256698C true CA2256698C (en) | 2003-09-30 |
Family
ID=24637082
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CA002256698A Expired - Fee Related CA2256698C (en) | 1996-06-03 | 1997-06-02 | Connection aggregation in switched communications networks |
Country Status (7)
Country | Link |
---|---|
US (2) | US6151324A (en) |
EP (1) | EP0903028B1 (en) |
AT (1) | ATE261221T1 (en) |
AU (1) | AU721508B2 (en) |
CA (1) | CA2256698C (en) |
DE (1) | DE69727930T2 (en) |
WO (1) | WO1997047113A1 (en) |
Families Citing this family (145)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6847611B1 (en) | 1990-12-10 | 2005-01-25 | At&T Corp. | Traffic management for frame relay switched data service |
US5684800A (en) * | 1995-11-15 | 1997-11-04 | Cabletron Systems, Inc. | Method for establishing restricted broadcast groups in a switched network |
EP0873626B1 (en) * | 1995-11-15 | 2006-05-10 | Enterasys Networks, Inc. | Distributed connection-oriented services for switched communications networks |
US6400681B1 (en) * | 1996-06-20 | 2002-06-04 | Cisco Technology, Inc. | Method and system for minimizing the connection set up time in high speed packet switching networks |
US7006444B1 (en) * | 1997-03-24 | 2006-02-28 | Stone Geoffrey C | Self-configuring communication network |
US6757286B1 (en) * | 1997-03-24 | 2004-06-29 | Alcatel | Self-configuring communication network |
US6934249B1 (en) | 1997-04-01 | 2005-08-23 | Cisco Technology, Inc. | Method and system for minimizing the connection set up time in high speed packet switching networks |
US6081524A (en) | 1997-07-03 | 2000-06-27 | At&T Corp. | Frame relay switched data service |
US6188694B1 (en) * | 1997-12-23 | 2001-02-13 | Cisco Technology, Inc. | Shared spanning tree protocol |
US6580715B1 (en) * | 1998-05-04 | 2003-06-17 | Hewlett-Packard Development Company, L.P. | Load balancing switch protocols |
US6377572B1 (en) * | 1998-05-18 | 2002-04-23 | Lucent Technologies Inc. | Virtual resource allocation method and apparatus for wireless data communication systems |
FI107686B (en) * | 1998-06-16 | 2001-09-14 | Nokia Mobile Phones Ltd | Method and communication device for administering carriers in a third generation mobile communication system |
US6560228B2 (en) * | 1998-07-01 | 2003-05-06 | Agilent Technologies, Inc. | Generation of informative MAC headers for analysis of ATM routed LAN frames |
US6434156B1 (en) * | 1998-07-24 | 2002-08-13 | Nortel Networks Limited | Virtual switching for interconnected networks |
US6574238B1 (en) * | 1998-08-26 | 2003-06-03 | Intel Corporation | Inter-switch link header modification |
US6587475B1 (en) * | 1998-09-04 | 2003-07-01 | Lucent Technologies Inc. | Method of assigning circuit ID's in an IS-IS compliant network |
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) |
GB9824594D0 (en) * | 1998-11-11 | 1999-01-06 | 3Com Technologies Ltd | Modifying tag fields in ethernet data packets |
US6898189B1 (en) | 2000-08-23 | 2005-05-24 | Cisco Technology, Inc. | Restartable spanning tree for high availability network systems |
US6556541B1 (en) * | 1999-01-11 | 2003-04-29 | Hewlett-Packard Development Company, L.P. | MAC address learning and propagation in load balancing switch protocols |
US6721334B1 (en) * | 1999-02-18 | 2004-04-13 | 3Com Corporation | Method and apparatus for packet aggregation in packet-based network |
US6760336B1 (en) * | 1999-02-18 | 2004-07-06 | Nortel Networks Limited | Flow detection scheme to support QoS flows between source and destination nodes |
US7185097B1 (en) * | 1999-02-25 | 2007-02-27 | Nortel Networks Limited | Encoding addresses in a communication system |
EP1032164A1 (en) * | 1999-02-26 | 2000-08-30 | International Business Machines Corporation | Method of self-learning for the switching nodes of a data transmission network |
US6788681B1 (en) | 1999-03-16 | 2004-09-07 | Nortel Networks Limited | Virtual private networks and methods for their operation |
US6937574B1 (en) * | 1999-03-16 | 2005-08-30 | Nortel Networks Limited | Virtual private networks and methods for their operation |
US6714541B1 (en) * | 1999-08-10 | 2004-03-30 | Cisco Technology, Inc. | Method and apparatus for encoding bridging/switching information within a routing information filed in a token ring environment |
JP2001111619A (en) * | 1999-10-12 | 2001-04-20 | Sony Corp | Transmitter, communication system and its communication method |
JP3614059B2 (en) * | 1999-11-30 | 2005-01-26 | 日本電気株式会社 | Communication connection merging method and node using the same |
WO2001054354A1 (en) | 2000-01-20 | 2001-07-26 | Mci Worldcom, Inc. | Intelligent network and method for providing voice telephony over atm and point-to-multipoint connectivity |
US20140211604A1 (en) * | 2013-01-31 | 2014-07-31 | Rockstar Consortium Us Lp | Method and Apparatus for the Fast Detection of Connectivity Loss Between Devices in a Network |
US8396950B1 (en) * | 2000-03-02 | 2013-03-12 | Rockstar Consortium Us Lp | Method and apparatus for the fast detection of connectivity loss between devices in a network |
US6868086B1 (en) * | 2000-03-29 | 2005-03-15 | Intel Corporation | Data packet routing |
US6895004B1 (en) * | 2000-04-17 | 2005-05-17 | Alcatel | Internal use only addresses |
US7123620B1 (en) * | 2000-04-25 | 2006-10-17 | Cisco Technology, Inc. | Apparatus and method for scalable and dynamic traffic engineering in a data communication network |
US6647428B1 (en) * | 2000-05-05 | 2003-11-11 | Luminous Networks, Inc. | Architecture for transport of multiple services in connectionless packet-based communication networks |
US7111073B1 (en) | 2000-05-30 | 2006-09-19 | Cisco Technology, Inc. | Apparatus for estimating delay and jitter between network routers |
US6914905B1 (en) | 2000-06-16 | 2005-07-05 | Extreme Networks, Inc. | Method and system for VLAN aggregation |
AU2001270258A1 (en) * | 2000-06-29 | 2002-01-14 | Phonex Broadband Corporation | Data link for multi protocol facility distributed communication hub |
US6868068B1 (en) | 2000-06-30 | 2005-03-15 | Cisco Technology, Inc. | Method and apparatus for estimating delay and jitter between network routers |
US7111163B1 (en) | 2000-07-10 | 2006-09-19 | Alterwan, Inc. | Wide area network using internet with quality of service |
US6912203B1 (en) | 2000-07-31 | 2005-06-28 | Cisco Technology, Inc. | Method and apparatus for estimating delay and jitter between many network routers using measurements between a preferred set of routers |
US6850495B1 (en) * | 2000-08-31 | 2005-02-01 | Verizon Communications Inc. | Methods, apparatus and data structures for segmenting customers using at least a portion of a layer 2 address header or bits in the place of a layer 2 address header |
US8087064B1 (en) | 2000-08-31 | 2011-12-27 | Verizon Communications Inc. | Security extensions using at least a portion of layer 2 information or bits in the place of layer 2 information |
US7020166B2 (en) * | 2000-10-03 | 2006-03-28 | Broadcom Corporation | Switch transferring data using data encapsulation and decapsulation |
US6868071B1 (en) * | 2000-11-15 | 2005-03-15 | Intel Corporation | System and method of transmitting data frames in a mesh of data switches |
JP3760767B2 (en) * | 2000-12-21 | 2006-03-29 | 株式会社日立製作所 | Network management apparatus and network management method |
US6912592B2 (en) * | 2001-01-05 | 2005-06-28 | Extreme Networks, Inc. | Method and system of aggregate multiple VLANs in a metropolitan area network |
US7120150B2 (en) * | 2001-01-30 | 2006-10-10 | At & T Corp. | Technique for ethernet access to packet-based services |
US8670446B2 (en) * | 2001-01-30 | 2014-03-11 | At&T Intellectual Property Ii, L.P. | Technique for Ethernet access to packet-based services |
US7092389B2 (en) | 2001-01-30 | 2006-08-15 | At&T Corp. | Technique for ethernet access to packet-based services |
US8156209B1 (en) * | 2001-02-15 | 2012-04-10 | Cisco Technology, Inc. | Aggregation devices processing keep-alive messages of point-to-point sessions |
US7065059B1 (en) * | 2001-08-09 | 2006-06-20 | Cisco Technology, Inc. | Technique for restoring adjacencies in OSPF in a non-stop forwarding intermediate node of a computer network |
JP4236398B2 (en) * | 2001-08-15 | 2009-03-11 | 富士通株式会社 | Communication method, communication system, and communication connection program |
US7647422B2 (en) | 2001-11-06 | 2010-01-12 | Enterasys Networks, Inc. | VPN failure recovery |
US8347075B1 (en) * | 2001-11-14 | 2013-01-01 | Verizon Laboratories Inc. | Methods to mitigate attacks against fiber-to-the-home network systems |
US8713185B2 (en) * | 2001-12-07 | 2014-04-29 | Rockstar Bidco, LP | Methods of establishing virtual circuits and of providing a virtual private network service through a shared network, and provider edge device for such network |
US7286528B1 (en) | 2001-12-12 | 2007-10-23 | Marvell International Ltd. | Multiple address databases in a switch without the need for extra memory |
US7286533B2 (en) * | 2001-12-27 | 2007-10-23 | Alcatel-Lucent Canada Inc. | Method and apparatus for routing data frames |
US20030140163A1 (en) * | 2002-01-22 | 2003-07-24 | Conexant Systems, Inc. | Low-processor-load aggregation |
US7496096B1 (en) * | 2002-01-31 | 2009-02-24 | Cisco Technology, Inc. | Method and system for defining hardware routing paths for networks having IP and MPLS paths |
US6973082B2 (en) * | 2002-02-01 | 2005-12-06 | Fujitsu Limited | Forwarding packets to aggregated links using distributed ingress card processing |
US7263192B2 (en) * | 2002-02-14 | 2007-08-28 | Hewlett-Packard Development Company, L.P. | Establishing an encrypted session |
EP2375690B1 (en) | 2002-03-01 | 2019-08-07 | Extreme Networks, Inc. | Locating devices in a data network |
JP3875121B2 (en) * | 2002-03-01 | 2007-01-31 | 株式会社エヌ・ティ・ティ・ドコモ | COMMUNICATION SYSTEM, COMMUNICATION METHOD, TRANSFER DEVICE, AND NETWORK MANAGEMENT DEVICE |
US7630403B2 (en) | 2002-03-08 | 2009-12-08 | Texas Instruments Incorporated | MAC aggregation frame with MSDU and fragment of MSDU |
EP1546894A4 (en) * | 2002-09-17 | 2011-05-18 | Broadcom Corp | System and method for access point (ap) aggregation and resiliency in a hybrid wired/wireless local area network |
DE10245561B3 (en) * | 2002-09-30 | 2004-06-03 | Siemens Ag | Connection method for time division multiplex communications network using graph of possible network node connections for determining optimum connection path |
US7606939B1 (en) * | 2002-10-31 | 2009-10-20 | Cisco Technology, Inc. | Scaling private virtual local area networks (VLANs) across large metropolitan area networks (MANs). |
US7792991B2 (en) * | 2002-12-17 | 2010-09-07 | Cisco Technology, Inc. | Method and apparatus for advertising a link cost in a data communications network |
US7707307B2 (en) * | 2003-01-09 | 2010-04-27 | Cisco Technology, Inc. | Method and apparatus for constructing a backup route in a data communications network |
WO2004064310A2 (en) * | 2003-01-11 | 2004-07-29 | Omnivergent Communications Corporation | Cognitive network |
GB2400265A (en) * | 2003-03-31 | 2004-10-06 | Sony Uk Ltd | Routing data |
US7006499B2 (en) * | 2003-04-28 | 2006-02-28 | Alcatel Ip Networks, Inc. | Source identifier for MAC address learning |
JP3886934B2 (en) * | 2003-06-09 | 2007-02-28 | 株式会社東芝 | Wireless communication apparatus, communication control program, and communication control method |
US7301949B2 (en) * | 2003-07-15 | 2007-11-27 | Telefonaktiebolaget Lm Ericsson (Publ) | Arrangements for connection-oriented transport in a packet switched communications network |
US20050013307A1 (en) * | 2003-07-17 | 2005-01-20 | Sharp Laboratories Of America, Inc. | Method for bridging traffic on a PLC LAN segment |
US7624187B1 (en) | 2003-09-19 | 2009-11-24 | At&T Intellectual Property, I, L.P. | Method, system and computer program product for providing Ethernet VLAN capacity requirement estimation |
US20050066036A1 (en) * | 2003-09-19 | 2005-03-24 | Neil Gilmartin | Methods, systems and computer program products for facilitating the design and analysis of virtual networks based on total hub value |
US7640359B1 (en) * | 2003-09-19 | 2009-12-29 | At&T Intellectual Property, I, L.P. | Method, system and computer program product for facilitating the design and assignment of ethernet VLANs |
US7466661B1 (en) * | 2003-09-22 | 2008-12-16 | Cisco Technology, Inc. | Method and apparatus for establishing adjacency for a restarting router during convergence |
CN1286297C (en) * | 2003-09-25 | 2006-11-22 | 华为技术有限公司 | Method of realizing sign delivery of user's position |
US7554921B2 (en) * | 2003-10-14 | 2009-06-30 | Cisco Technology, Inc. | Method and apparatus for generating routing information in a data communication network |
US7580360B2 (en) * | 2003-10-14 | 2009-08-25 | Cisco Technology, Inc. | Method and apparatus for generating routing information in a data communications network |
US20050105538A1 (en) * | 2003-10-14 | 2005-05-19 | Ananda Perera | Switching system with distributed switching fabric |
US7349985B2 (en) * | 2003-11-24 | 2008-03-25 | At&T Delaware Intellectual Property, Inc. | Method, system and computer program product for calculating a VLAN latency measure |
US7363387B1 (en) | 2003-12-09 | 2008-04-22 | Cisco Technology, Inc. | System and method for reducing information being transmitted in a network environment |
US7298707B2 (en) * | 2004-01-21 | 2007-11-20 | Cisco Technology, Inc. | System and method for controlling the flooding of information in a network environment |
US7580403B2 (en) | 2004-02-26 | 2009-08-25 | Enterasys Networks, Inc. | Status transmission system and method |
US7710882B1 (en) | 2004-03-03 | 2010-05-04 | Cisco Technology, Inc. | Method and apparatus for computing routing information for a data communications network |
US8572665B2 (en) * | 2004-03-03 | 2013-10-29 | Cisco Technology, Inc. | Selective distribution of cell based video streams over packet based networks |
US20070050520A1 (en) * | 2004-03-11 | 2007-03-01 | Hewlett-Packard Development Company, L.P. | Systems and methods for multi-host extension of a hierarchical interconnect network |
US20050220096A1 (en) | 2004-04-06 | 2005-10-06 | Robert Friskney | Traffic engineering in frame-based carrier networks |
US8923292B2 (en) | 2004-04-06 | 2014-12-30 | Rockstar Consortium Us Lp | Differential forwarding in address-based carrier networks |
US7848240B2 (en) * | 2004-06-01 | 2010-12-07 | Cisco Technology, Inc. | Method and apparatus for forwarding data in a data communications network |
US20060013231A1 (en) * | 2004-06-22 | 2006-01-19 | Sbc Knowledge Ventures, Lp | Consolidated ethernet optical network and apparatus |
US7457244B1 (en) | 2004-06-24 | 2008-11-25 | Cisco Technology, Inc. | System and method for generating a traffic matrix in a network environment |
US8422500B2 (en) | 2004-07-02 | 2013-04-16 | Rockstar Consortium Us Lp | VLAN support of differentiated services |
US7391730B1 (en) | 2004-07-21 | 2008-06-24 | Cisco Technology | System and method for synchronizing link state databases in a network environment |
US7945945B2 (en) | 2004-08-06 | 2011-05-17 | Enterasys Networks, Inc. | System and method for address block enhanced dynamic network policy management |
WO2006015614A1 (en) * | 2004-08-13 | 2006-02-16 | Matsushita Electric Industrial Co., Ltd. | Providing mobility to a mobile host in a network employing point-to-multipoint multi-protocol label switching |
US7408936B2 (en) * | 2004-08-20 | 2008-08-05 | Alcatel Lucent | Scalable VLAN grouping in a provider Metro Ethernet |
US8699525B2 (en) | 2004-09-10 | 2014-04-15 | Interdigital Technology Corporation | Method for sending an acknowledgement to an ingress mesh point in a mesh network and a medium access control frame format |
US7958208B2 (en) * | 2004-09-22 | 2011-06-07 | At&T Intellectual Property I, L.P. | System and method for designing a customized switched metro Ethernet data network |
US7347628B2 (en) | 2004-11-08 | 2008-03-25 | Enterasys Networks, Inc. | Optical interface identification system |
CA2595788C (en) * | 2005-02-04 | 2013-06-25 | Level 3 Communications, Inc. | Ethernet-based systems and methods for improved network routing |
US8064467B2 (en) * | 2005-02-04 | 2011-11-22 | Level 3 Communications, Llc | Systems and methods for network routing in a multiple backbone network architecture |
JP4583456B2 (en) * | 2005-02-14 | 2010-11-17 | テレフオンアクチーボラゲット エル エム エリクソン(パブル) | Method and node for bridging data traffic on an access domain |
JP4454661B2 (en) * | 2005-03-31 | 2010-04-21 | 富士通株式会社 | Frame transfer device |
US20060288109A1 (en) * | 2005-06-17 | 2006-12-21 | Utstarcom, Inc. | Method and apparatus to facilitate Layer 3 internet protocol socket connections |
KR100653634B1 (en) * | 2005-06-23 | 2006-12-06 | 조창환 | System and method for controlling a traffic of a net-work |
US8086232B2 (en) | 2005-06-28 | 2011-12-27 | Enterasys Networks, Inc. | Time synchronized wireless method and operations |
US20070076709A1 (en) * | 2005-07-01 | 2007-04-05 | Geoffrey Mattson | Apparatus and method for facilitating a virtual private local area network service with realm specific addresses |
DE102005034549A1 (en) * | 2005-07-23 | 2007-02-01 | Siemens Ag | Translating MAC addresses |
US20070147363A1 (en) * | 2005-12-23 | 2007-06-28 | Oswal Anand K | Network edge device configured for adding protocol service header identifying service encoding of IP packet payload |
US9426092B2 (en) * | 2006-02-03 | 2016-08-23 | Level 3 Communications Llc | System and method for switching traffic through a network |
CN1852254A (en) * | 2006-02-17 | 2006-10-25 | 华为技术有限公司 | Ethernetwork exchanging apparatus and method for realizing MPLS message retransmission |
US8892706B1 (en) | 2010-06-21 | 2014-11-18 | Vmware, Inc. | Private ethernet overlay networks over a shared ethernet in a virtual environment |
US8838756B2 (en) * | 2009-07-27 | 2014-09-16 | Vmware, Inc. | Management and implementation of enclosed local networks in a virtual lab |
US8619771B2 (en) | 2009-09-30 | 2013-12-31 | Vmware, Inc. | Private allocated networks over shared communications infrastructure |
US8924524B2 (en) | 2009-07-27 | 2014-12-30 | Vmware, Inc. | Automated network configuration of virtual machines in a virtual lab data environment |
US8077720B2 (en) * | 2007-02-27 | 2011-12-13 | Alcatel-Lucent Usa Inc. | Methods and devices for generating and forwarding translated MAC addresses |
KR20080111691A (en) * | 2007-06-19 | 2008-12-24 | 삼성전자주식회사 | Connector and communication method thereof |
JP4820781B2 (en) * | 2007-06-26 | 2011-11-24 | Kddi株式会社 | Route management apparatus and computer program |
US8195774B2 (en) | 2008-05-23 | 2012-06-05 | Vmware, Inc. | Distributed virtual switch for virtualized computer systems |
CN101299718B (en) * | 2008-06-13 | 2011-04-13 | 华为技术有限公司 | Port switching method, network equipment and network system |
US7813344B2 (en) * | 2008-12-17 | 2010-10-12 | At&T Intellectual Property I, Lp | End user circuit diversity auditing methods |
US8514876B2 (en) * | 2009-08-11 | 2013-08-20 | Cisco Technology, Inc. | Method and apparatus for sequencing operations for an incoming interface check in data center ethernet |
US8488490B2 (en) * | 2009-10-14 | 2013-07-16 | At&T Intellectual Property I, L.P. | Methods and apparatus to determine a capacity for a network layer topology |
US8122127B2 (en) | 2009-12-31 | 2012-02-21 | Juniper Networks, Inc. | Automatic aggregation of inter-device ports/links in a virtual device |
US8923277B1 (en) * | 2010-12-15 | 2014-12-30 | Juniper Networks, Inc. | Methods and apparatus related to flexible physical interface naming in a distributed switch fabric system |
US8868700B2 (en) | 2010-12-28 | 2014-10-21 | Nant Holdings Ip, Llc | Distributed network interfaces for application cloaking and spoofing |
US20140016649A1 (en) * | 2011-03-31 | 2014-01-16 | Tejas Networks Limited | Optimizing forward database for a bursty network traffic |
US9185056B2 (en) | 2011-09-20 | 2015-11-10 | Big Switch Networks, Inc. | System and methods for controlling network traffic through virtual switches |
US9378886B2 (en) | 2011-12-22 | 2016-06-28 | General Electric Company | Electronic power transformer |
US20150063330A1 (en) * | 2013-08-30 | 2015-03-05 | Qualcomm Incorporated | Aggregation of data packets for multiple stations |
US9350607B2 (en) | 2013-09-25 | 2016-05-24 | International Business Machines Corporation | Scalable network configuration with consistent updates in software defined networks |
US9525638B2 (en) | 2013-10-15 | 2016-12-20 | Internap Corporation | Routing system for internet traffic |
US9112794B2 (en) * | 2013-11-05 | 2015-08-18 | International Business Machines Corporation | Dynamic multipath forwarding in software defined data center networks |
US9413612B2 (en) * | 2013-12-24 | 2016-08-09 | Cisco Technology, Inc. | Automatic resolution of virtual network instance to VLAN mapping conflicts in dual-homed deployments in a dynamic fabric automation network architecture |
US9680745B2 (en) * | 2014-01-20 | 2017-06-13 | Huawei Technologies Co., Ltd. | Multi-domain source routed forwarding based on collaborating network controllers |
US10681000B2 (en) | 2017-06-30 | 2020-06-09 | Nicira, Inc. | Assignment of unique physical network addresses for logical network addresses |
US10637800B2 (en) | 2017-06-30 | 2020-04-28 | Nicira, Inc | Replacement of logical network addresses with physical network addresses |
US10637778B1 (en) * | 2017-08-09 | 2020-04-28 | Open Invention Network Llc | Systems, methods and devices for scalable expansion of rules-based forwarding paths in network communications devices for distributed computing systems |
JP7467415B2 (en) * | 2018-08-23 | 2024-04-15 | ジョン メツァリングア アソシエイツ エルエルシー | SYSTEM AND METHOD FOR CREATING AND MANAGING A PRIVATE SUB-NETWORK OF LTE BASE STATIONS - Patent application |
Family Cites Families (18)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CA1245327A (en) * | 1985-09-06 | 1988-11-22 | Northern Telecom Limited | Path oriented routing system and method for packet switching networks |
JP2892689B2 (en) * | 1989-07-05 | 1999-05-17 | 株式会社日立製作所 | Packet communication network and packet switch |
US5193152A (en) * | 1989-11-03 | 1993-03-09 | Racal-Datacom, Inc. | Network management system with group naming |
JPH04107029A (en) * | 1990-08-27 | 1992-04-08 | Mitsubishi Electric Corp | System for connection between local area networks |
EP0567711B1 (en) * | 1992-04-27 | 1997-06-25 | International Business Machines Corporation | Support to connectionless services in ATM network using partial connections |
WO1994009576A1 (en) * | 1992-10-21 | 1994-04-28 | Bell Communications Research, Inc. | A broadband virtual private network service and system |
US5365524A (en) * | 1992-11-06 | 1994-11-15 | At&T Bell Laboratories | Establishing telecommunications call paths between clustered switching entities |
JPH07107990B2 (en) * | 1992-11-12 | 1995-11-15 | 日本電気株式会社 | ATM-based transmitter and communication system |
GB9302225D0 (en) * | 1993-02-05 | 1993-03-24 | Int Computers Ltd | Data processing system |
US5420858A (en) * | 1993-05-05 | 1995-05-30 | Synoptics Communications, Inc. | Method and apparatus for communications from a non-ATM communication medium to an ATM communication medium |
US5408469A (en) * | 1993-07-22 | 1995-04-18 | Synoptics Communications, Inc. | Routing device utilizing an ATM switch as a multi-channel backplane in a communication network |
JP2861771B2 (en) * | 1993-12-27 | 1999-02-24 | 日本電気株式会社 | Signaling method using logical relay route information in packet network |
US5485455A (en) * | 1994-01-28 | 1996-01-16 | Cabletron Systems, Inc. | Network having secure fast packet switching and guaranteed quality of service |
JP2682459B2 (en) * | 1994-08-23 | 1997-11-26 | 日本電気株式会社 | Communication control device |
US5706279A (en) * | 1995-03-24 | 1998-01-06 | U S West Technologies, Inc. | Methods and systems for managing packet flow into a fast packet switching network |
US5684800A (en) * | 1995-11-15 | 1997-11-04 | Cabletron Systems, Inc. | Method for establishing restricted broadcast groups in a switched network |
US5699347A (en) * | 1995-11-17 | 1997-12-16 | Bay Networks, Inc. | Method and apparatus for routing packets in networks having connection-oriented subnetworks |
US6148000A (en) * | 1996-10-02 | 2000-11-14 | International Business Machines Corporation | Merging of data cells at network nodes |
-
1996
- 1996-06-03 US US08/657,414 patent/US6151324A/en not_active Expired - Lifetime
-
1997
- 1997-06-02 DE DE69727930T patent/DE69727930T2/en not_active Expired - Lifetime
- 1997-06-02 CA CA002256698A patent/CA2256698C/en not_active Expired - Fee Related
- 1997-06-02 AU AU31543/97A patent/AU721508B2/en not_active Ceased
- 1997-06-02 EP EP97926884A patent/EP0903028B1/en not_active Expired - Lifetime
- 1997-06-02 WO PCT/US1997/009552 patent/WO1997047113A1/en active IP Right Grant
- 1997-06-02 AT AT97926884T patent/ATE261221T1/en not_active IP Right Cessation
-
2000
- 2000-11-20 US US09/716,675 patent/US6449279B1/en not_active Expired - Lifetime
Also Published As
Publication number | Publication date |
---|---|
US6449279B1 (en) | 2002-09-10 |
EP0903028A1 (en) | 1999-03-24 |
AU721508B2 (en) | 2000-07-06 |
ATE261221T1 (en) | 2004-03-15 |
AU3154397A (en) | 1998-01-05 |
US6151324A (en) | 2000-11-21 |
WO1997047113A1 (en) | 1997-12-11 |
CA2256698A1 (en) | 1997-12-11 |
DE69727930T2 (en) | 2005-02-03 |
DE69727930D1 (en) | 2004-04-08 |
EP0903028B1 (en) | 2004-03-03 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CA2256698C (en) | Connection aggregation in switched communications networks | |
US8462794B2 (en) | Distributed connection-oriented services for switched communication networks | |
US6711171B1 (en) | Distributed connection-oriented services for switched communications networks | |
US7411916B2 (en) | Data forwarding method and apparatus | |
Cisco | ISO CLNS Commands | |
Cisco | ISO CLNS Commands | |
Cisco | ISO CLNS Commands | |
Cisco | ISO CLNS Commands | |
Cisco | ISO CLNS Commands | |
Cisco | ISO CLNS Commands | |
Cisco | ISO CLNS Commands | |
Cisco | ISO CLNS Commands | |
Cisco | ISO CLNS Commands | |
Cisco | ISO CLNS Commands | |
Cisco | Frame Relay Commands | |
Cisco | Frame Relay Commands | |
Cisco | Frame Relay Commands | |
Cisco | ISO CLNS Commands | |
Cisco | ISO CLNS Commands | |
Cisco | ISO CLNS Commands | |
Cisco | ISO CLNS Commands | |
Cisco | IBM Connectivity | |
Cisco | IBM Connectivity | |
Cisco | IBM Connectivity | |
Cisco | Frame Relay Commands |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
EEER | Examination request | ||
MKLA | Lapsed |