In a network device such as a network switch having a port coupled to a communications medium dedicated to a single virtual local area network and another port coupled to a communications medium shared among multiple virtual local area networks for transmitting data frames between the dedicated communications medium and the shared communications medium, a method of identifying the virtual network associated with each data frame received by the network switch when transmitting the data frames over the shared communications medium. The method comprises receiving data frames from the dedicated communications medium coupled to one port, and, with respect to each data frame so received, inserting a new type field and a virtual network identifier field. The contents of the new type field indicate the data frame comprises a virtual network identifier field. The method further includes placing a value in the virtual network identifier field identifying the virtual network associated with the data frame and transmitting the data frame over the shared communications medium. Upon receipt of the data frames from over the shared communications medium, another network device can discern from the virtual network identifier field in each data frame the virtual network from which the data frames were received and determine whether to forward the data frames accordingly.
|
0. 17. A method of transmitting a data frame to a virtual network associated with the data frame, the data frame being transmitted between a communications medium and a shared communications medium, the method comprising:
a) receiving the data frame, the data frame comprising a type field, and a virtual network header including a virtual network identifier field and at least one other field, the type field having a value indicating that the data frame is associated with a virtual network, and the virtual network identifier field having a virtual network identifier field value corresponding to the virtual network;
b) reading the type field and determining that the data frame is associated with a virtual network;
c) in response to determining that the data frame is associated with a virtual network, reading the virtual network identifier field value to determine the virtual network with which the data frame is associated; and
d) transmitting the data frame at least toward the virtual network corresponding to the virtual network identifier field value.
0. 22. A method of transmitting a data frame to a virtual network associated with the data frame, the data frame being transmitted between a communications medium and a shared communications medium, the method comprising:
a) receiving the data frame, the data frame comprising a type field, and a virtual network header having an associated format and including a virtual network identifier field, the type field having a value indicating which of a plurality of formats the associated format is and that the data frame is associated with a virtual network, and the virtual network identifier field having a virtual network identifier field value corresponding to the virtual network;
b) reading the type field and determining that the data frame is associated with a virtual network and determining the format;
c) in response to determining that the data frame is associated with a virtual network and determining the format, reading the virtual network identifier field in accordance with the determined format to determine the virtual network with which the data frame is associated; and
d) transmitting the data frame at least toward the virtual network corresponding to the virtual network identifier field value.
0. 1. A method of identifying a virtual network associated with a data frame when transmitting said data frame between a communications medium and a shared communications medium, comprising the steps of:
a) receiving said data frame from said communications medium, said data frame comprising a first type field and a data field;
b) inserting a second type field at a location within said data frame preceding said first type field, said second type field indicating said data frame comprises a virtual network identifier field;
c) inserting said virtual network identifier field at a location between said second typo field and said first type field;
d) assigning a first value to said virtual network identifier field, said first value corresponding to said virtual network; and
e) transmitting said data frame over said shared communications medium.
0. 2. The method of
1) inserting between said second type field and said virtual network identifier field a virtual network identifier type field; and
2) assigning a second value to said virtual network identifier type field indicating a type of said first value in said virtual network identifier field.
0. 3. The method of
1) inserting between said second type field and said virtual network identifier field a virtual network identifier length field; and
2) assigning a second value to said virtual network identifier length field indicating a length of said first value in said virtual network identifier field.
0. 4. The method of
0. 5. The method of
0. 6. The method of
0. 7. A method of identifying a virtual network associated with a data frame when transmitting said data frame between a communications medium and a shared communications medium, comprising the steps of:
a) receiving said data frame from said communications medium, said data frame comprising a length field and a data field;
b) inserting a type field at a location within said data frame preceding said length field, said type field indicating said data frame comprises a virtual network identifier field;
c) inserting said virtual network identifier field at a location between said type field and said length field;
d) assigning a first value to said virtual network identifier field, said first value corresponding to said virtual network; and
e) transmitting said data frame over said shared communications medium.
0. 8. The method of
1) inserting between said type field and said virtual network identifier field a virtual network identifier type field; and
2) assigning a second value to said virtual network identifier type field indicating a type of said first value in said virtual network identifier field.
0. 9. The method of
1) inserting between said type field and said virtual network identifier field a virtual network identifier length field; and
2) assigning a second value to said virtual network identifier length field indicating a length of said first value in said virtual network identifier field.
0. 10. The method of
0. 11. In a network device, a method of transmitting a virtual network identifier in a data frame transmitted on a shared communications medium coupled to said network device, comprising:
a) transmitting a preamble field;
b) transmitting a destination and source media access control address field;
c) transmitting a first type field whose contents indicate said virtual network identifier is present in said data frame;
d) transmitting a virtual network identifier field containing said virtual network identifier;
e) transmitting a second type field whose contents indicate a protocol type associated with said data frame; and,
f) transmitting a data field.
0. 12. The method of
0. 13. In a network device having a first port coupled to a local area network (LAN) segment and a second port coupled to a shared communications medium, a method of associating a virtual network with a data frame received from said LAN segment and transmitted to said shared communications medium, comprising:
a) receiving said data frame at said first port, said data frame comprising a type field and a data field;
b) replacing a first value in said type field representing a protocol type with a second value indicating said data frame comprises a virtual network identifier field;
c) inserting said virtual network identifier field in said data frame between said type field containing said second value and said data field;
d) assigning a value representing said virtual network to said virtual network identifier field; and
e) transmitting said data frame from said second port.
0. 14. The method of
a) inserting a new type field between said virtual network identifier field and said data field; and
b) assigning said first value representing said protocol type to said new type field to preserve said protocol type.
0. 15. The method of
0. 16. The method of
0. 18. The method of claim 17 wherein the virtual network identifier field value is in one of a plurality of formats, and the method further comprises determining which format the virtual network identifier field value is in based upon a value of the type field, and using the determined format to determine the virtual network identifier field value.
0. 19. The method of claim 17 wherein the virtual network header further includes at least one of a virtual network identifier type field having a value indicative of a type of the virtual network identifier field and a virtual network identifier length field having a value indicative of a length of the virtual network identifier field, the method further comprising reading the at least one of the virtual network identifier type field and the virtual network identifier length field.
0. 20. The method of claim 19 wherein the virtual network header includes the virtual network identifier type field, the method further comprising reading the virtual network identifier type field to determine a format of the virtual network identifier field value and using the determined format to determine the virtual network identifier field value.
0. 21. The method of claim 17 wherein the at least one other field includes a plurality of other fields.
0. 23. The method of claim 22 wherein the associated format is a format of the virtual network identifier field value.
0. 24. The method of claim 17, wherein transmitting the data frame at least toward the virtual network corresponding to the virtual network identifier field value comprises forwarding at least part of the received data frame on a port selected based at least in part on the value of the virtual network identifier field.
0. 25. The method of claim 24 wherein, when the port selected based at least in part on the value of the virtual network identifier field is connected to a dedicated communications medium, forwarding at least part of the received data frame comprises:
removing the type field and the virtual network identifier field from the data frame; and
forwarding the data frame without the type field and without the virtual network identifier field on the selected port.
0. 26. The method of claim 25, wherein the dedicated communications medium is dedicated to a virtual network associated with the value of the virtual network identifier field.
0. 27. The method of claim 25, wherein forwarding the data frame without the type field and without the virtual network identifier field comprises:
calculating a frame check sequence for the data frame with the type field and the virtual network identifier field removed; and
forwarding the data frame with the calculated frame check sequence.
0. 28. The method of claim 24 wherein, when a port which is eligible to receive the data frame based on a destination media access control address is assigned a virtual network identifier corresponding to the value of the virtual network identifier field of the data frame, forwarding at least part of the received data frame comprises:
removing the type field and the virtual network identifier field from the data frame; and
forwarding the data frame without the type field and without the virtual network identifier field on the port.
0. 29. The method of claim 28, wherein forwarding the data frame without the type field and without the virtual network identifier field comprises:
calculating a frame check sequence for the data frame with the type field and the virtual network identifier field removed; and
forwarding the data frame with the calculated frame check sequence.
0. 30. The method of claim 22, wherein transmitting the data frame at least toward the virtual network corresponding to the virtual network identifier field value comprises forwarding at least part of the received data frame on a port selected based at least in part on the value of the virtual network identifier field.
0. 31. The method of claim 30 wherein, when the port selected based at least in part on the value of the virtual network identifier field is connected to a dedicated communications medium, forwarding at least part of the received data frame comprises:
removing the type field and the virtual network identifier field from the data frame; and
forwarding the data frame without the type field and without the virtual network identifier field on the selected port.
0. 32. The method of claim 31 wherein the dedicated communications medium is dedicated to a virtual network associated with the value of the virtual network identifier field.
0. 33. The method of claim 31 wherein forwarding the data frame without the type field and without the virtual network identifier field comprises:
calculating a frame check sequence for the data frame with the type field and the virtual network identifier field removed; and
forwarding the data frame with the calculated frame check sequence.
0. 34. The method of claim 30 wherein, when a port which is eligible to receive the data frame based on a destination media access control address is assigned a virtual network identifier corresponding to the value of the virtual network identifier field of the data frame, forwarding at least part of the received data frame comprises:
removing the type field and the virtual network identifier field from the data frame; and
forwarding the data frame without the type field and without the virtual network identifier field on the port of the network device.
0. 35. The method of claim 34, wherein forwarding the data frame without the type field and without the virtual network identifier field comprises:
calculating a frame check sequence for the data frame with the type field and the virtual network identifier field removed; and
forwarding the data frame with the calculated frame check sequence.
|
NOTICE: More than one reissue application has been filed for the reissue of U.S. Pat. No. 6,111,876. The reissue applications are U.S. application Ser. No. 10/225,708, now Reissue Pat. No. RE40,999, issued on Nov. 24, 2009, and U.S. application Ser. No. 12/459,465, now Reissue Pat. No. RE44,775, issued on Feb. 25, 2014, which is a divisional reissue of U.S. application Ser. No. 10/225,708, now Reissue Pat. No. RE40,999. The present U.S. application Ser. No. 13/728,698, filed on Dec. 27, 2012 which has been filed during the pendency of U.S. application Ser. No. 12/459,465, now Reissue Pat. No. RE44,775, is a divisional reissue of U.S. application Ser. No. 12/459,465, now Reissue Pat. No. RE44,775, which is a divisional reissue of U.S. Pat. No. 6,111,876.
Other reissue applications include: U.S. application Ser. No. 13/728,787, filed Dec. 27, 2012, now Reissue Pat. No. RE45,065, issued on Aug. 5, 2014, which is a continuation reissue of U.S. application Ser. No. 12/459,465, now Reissue Pat. No. RE44,775; U.S. application Ser. No. 13/728,823, filed Dec. 27, 2012, now Reissue Pat. No. RE45,081, issued on Aug. 19, 2014, which is a continuation reissue of U.S. application Ser. No. 12/459,465, now Reissue Pat. No. RE44,775; U.S. application Ser. No. 13/728,838, filed Dec. 27, 2012, which is a continuation reissue of U.S. application Ser. No. 12/459,465, now Reissue Pat. No. RE44,775; U.S. application Ser. No. 13/728,846, filed Dec. 27, 2012, now Reissue Pat. No. RE45,095, issued on Aug. 26, 2014, which is a continuation reissue of U.S. application Ser. No. 12/459,465, now Reissue Pat. No. RE44,775; U.S. application Ser. No. 13/728,867, filed Dec. 27, 2012, which is a continuation reissue of U.S. application Ser. No. 12/459,465, now Reissue Pat. No. RE44,775; U.S. application Ser. No. 13/728,770, filed Dec. 27, 2012, which is a continuation reissue of U.S. application Ser. No. 12/459,465, now Reissue Pat. No. RE44,775; U.S. application Ser. No. 13/728,747, filed Dec. 27, 2012, which is a divisional reissue of U.S. application Ser. No. 12/459,465, now Reissue Pat. No. RE44,775.
This application is a continuation-in-part of United States patent application entitled, “VLAN FRAME FORMAT”, Ser. No. 08/613,726, filed on Mar. 12, 1996, now U.S. Pat. No. 5,959,990.
Contained herein is material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction of the patent disclosure by any person as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all rights to the copyright whatsoever.
1. Field of the Invention
The present invention relates to the field of data communications. More specifically, the present invention relates to a method and frame format for preserving in a data frame the virtual local area network (VLAN) associated with the data frame as determined by a network device from which the data frame was received when transmitting the data frame over a communications medium shared among multiple VLANs. The method and frame format are equally applicable when the network device uses criteria in addition to or instead of the ingress port to associate a VLAN with the data frame.
2. Description of the Related Art
A small baseband local area network (LAN) typically connects a number of nodes, e.g., a server and workstations, to a shared communications medium wherein all nodes compete for available bandwidth on the shared communications medium. In an Ethernet or Institute of Electrical and Electronics Engineers (IEEE) 802.3 standard local area network, when a node transmits a unicast data frame on the network, every node coupled to the shared medium receives and processes the data frame to determine if it is the node to which the data frame is destined. Moreover, when a station transmits a broadcast data frame on the network, all nodes see the data frame and must process it to determine whether they should respond to the broadcasting node. As the number of nodes coupled to the medium increase, data traffic can become congested, resulting in an undesirable level of collisions and network related delays in transmitting data frames, which in turn results in network and node performance degradation.
A common prior art method of reducing congestion is to separate a LAN into multiple LAN segments by way of a network device, such as a bridge or network switch, operating at the Media Access Control (MAC) sublayer of the Data Link layer (layer 2) of the International Standards Organization (ISO) Open Systems Interconnection (OSI) reference model. While all nodes in the data network may still belong to the same broadcast domain, that is, each node still transmits and receives broadcast data frames to/from all nodes on all LAN segments in the network, nodes sharing the same LAN segment see only unicast data frames generated by or destined to a node on the same LAN segment. Given that the bulk of data traffic on a LAN is unicast in nature, segmentation may somewhat reduce collisions and traffic related performance problems.
However, as the number of LAN segments and nodes per segment increases in the same broadcast domain, the nodes can become overburdened processing broadcast data frames. It may be desirable under such circumstances to separate the growing data network into multiple broadcast domains. One possible approach to creating multiple broadcast domains is to separate one or more LAN segments using a network device such as a router, operating at the Network layer (layer 3) of the OSI reference model. With reference to
For example, router 100 only forwards a unicast data frame from a node on LAN segments 103, 110 or 120 that is specifically addressed (at layer 3 of the OSI model) to a node on LAN segments 105, 130 or 140, and vise versa. Network devices 101 and 102 may be, for example, network switches. Network switch 101 separates LAN segments 103, 110 and 120 to reduce unicast traffic on each segment while the segments still remain in the same broadcast domain 11. Network switch 102 functions in a similar manner with respect to LAN segments 105, 130 and 140.
LAN segments 110, 120, 130 and 140 may have multiple nodes attached. For example, LAN segment 110 has nodes 111 and 112 coupled to it, and functions, therefore, as a shared communications medium, wherein the nodes share the available bandwidth (e.g., 10 million bits per second in a traditional Ethernet carrier sense, multiple access data bus with collision detection [CSMA/CD]). LAN segments 103 and 105, on the other hand, are dedicated LAN segments, therefore, nodes 104 and 106 have all available bandwidth to themselves. For example, nodes 104 and 106 may be servers requiring greater bandwidth. Dedicated LAN segments 103 and 105 may be any technology supporting delivery of Ethernet or IEEE 802 LLC data frames including CSMA/CD or Fiber Distributed Data Interface (FDDI) segments operating at 100 million bits per second, or Asynchronous Transfer Mode LAN emulation service running over segments operating at 155 million bits per second.
The router 100 has the further advantage of allowing for the implementation of policy restrictions among network administrator-defined groups in the network. For example, it may be desirable to prohibit nodes in broadcast domain 12 from communicating with nodes in broadcast domain 11 using any protocol except those specifically allowed by the network administrator.
However, as can be seen in
When the system grows beyond the capacity of a single switch or when geographical constraints create a need for switching capacity at more than one site, additional switches are added to the network.
In the prior art, when switch 200 receives a broadcast packet from VLAN 210, station 104, it forwards the packet out all of its other VLAN 210 ports (202, 203 and 207) and also forwards it from port 208 to switch 300. Switch 300 examines the MAC source address (i.e., the ISO layer 2 source address) and based on a prior exchange of information with switch 200 is able to determine the proper VLAN to use for frames from that source address, in this case, VLAN 210. Based on this determination, switch 300 forwards the frame to all of its VLAN 210 ports (e.g., ports 302 and 303).
The success of this approach depends on prohibiting frames having the same MAC source address from appearing on multiple VLANs. However, the prohibition makes this approach unusable in some networks. To work around this problem, some prior art implementations use additional fields within the packet, such as the ISO layer 3 source address, to resolve ambiguities. However, even this approach does not work in all cases, as there are many types of frames which do not contain sufficient information to make a reliable VLAN determination. Examples of such frames include Internet Protocol (IP) BOOTP requests, IPX Get Nearest Server requests and frames from non-routable protocols.
All messages (in the form of a data frame) transferred between nodes of the same VLAN are transmitted at the MAC sublayer of the Data Link layer of the OSI reference model, based on each node's MAC layer address. However, there is no connectivity between nodes of different VLANs within network switch 200 or 300.
For example, with reference to
Using a routing function to transfer data frames between VLAN 210 and VLAN 220 as illustrated in
Another circumstance which creates difficulties in establishing a MAC address to VLAN mapping is when a routing protocol, e.g., the DecNet routing protocol, transmits data frames using the same source MAC address on both communications mediums 101 and 102.
Yet another drawback of the configuration of data network 10 as illustrated in
One such prior art method identifying the VLAN associated with a MAC address of a node involves creating and maintaining a lookup table on each network device in the data network. The lookup table contains entries associating the MAC address of a node with the port on the network device over which the node is reachable. The node may be coupled to a shared or dedicated communications medium which is further coupled to the port. Each entry also contains a VLAN identifier identifying the virtual local area network (VLAN) assigned to the port. If multiple network devices exist in the data network, as illustrated in
A prior art method of reliably identifying the VLAN from which a data frame originated utilizes a management defined field (MDF) of an IEEE standard 802.10 Secure Data Exchange (SDE) Protocol Data Unit (PDU). The MDF allows the transfer of proprietary information that may facilitate the processing of a data frame. The prior art method uses the MDF to store a VLAN identifier as the data frame is transferred from a network device over a communications medium shared among multiple VLANs so that when another network device receives a data frame from the shared communications medium, it can determine the VLAN associated with the data frame and determine whether to forward the frame accordingly, depending on the VLANs configured for each port on the network device.
A VLAN identifier representing the VLAN associated with the data frame received by the network device is placed in the MDF 406 by the MAC layer and other relevant hardware and software in the network device. When the frame is subsequently transmitted across a shared communications medium, such as when switch 300 of
However, the frame format illustrated in
The present invention relates to a method and frame format for preserving in a data frame as the data frame is transmitted across a communications medium shared among a plurality of virtual local area networks (VLANs), the VLAN which was associated with the data frame at the point where it entered the network. The method supports existing data network infrastructures, including Ethernet based data network infrastructures.
According to one aspect of the invention, a data frame format extends the traditional Ethernet frame format to accommodate a VLAN header. In one embodiment, a unique Ethernet type field value is used to identify the data frame as having a VLAN header inserted between the Ethernet type field and the user data field. In another embodiment, the unique Ethernet type field value is used to identify the data frame as having a VLAN header inserted prior to the Ethernet type field of the original Ethernet frame.
The original Ethernet type field or the length field of an IEEE 802.3 data frame is preserved when the data frame is transferred from a shared communications medium to a dedicated communications medium, as when happens when a network switch receives the data frame over shared communications medium coupling the network switch to another network switch, and transmits the data frame over a dedicated communications medium coupling the network switch to a node.
The VLAN header comprises a VLAN identifier field that identifies the VLAN associated with the frame at the point at which the data frame was received by a network switch. In one embodiment, the VLAN header is further comprised of a VLAN identifier type and/or a VLAN identifier length field, both of which precede the VLAN identifier field and respectively specify a format and length of the subsequent VLAN identifier field.
Thus it is an object of the present invention to provide a method and frame format for identifying the VLAN associated with a data frame received at a network switch from an Ethernet or IEEE 802.3 LAN. This is needed to support the existing infrastructure of Ethernet networks in a data network transmitting data frames from multiple VLANs across a shared communications medium. This will allow compatibility with both IEEE 802.3-based and traditional Ethernet-based nodes on the same shared media with nodes supporting VLAN identification as well.
It is another object of the present invention to provide a data frame format that allows for inclusion of a VLAN identifier field that does not extend the MAC frame so far as to require fragmentation to avoid ambiguity between Ethernet and IEEE 802.3 frame types.
The present invention is illustrated by way of example and not limitation in the following figures. Like references indicate similar elements, in which:
Described herein is a method and frame format for preserving in a data frame the virtual local area network (VLAN) associated with the data frame when transmitting the data frame over a communications medium shared among multiple VLANs. In the following description, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be apparent, however, to one of ordinary skill in the art that the present invention may be practiced without these specific details. In other instances, well-known standards, frame format details, and techniques have not been shown in order not to unnecessarily obscure the present invention.
As network switching becomes more prevalent in data networks, and in particular, local area networks, it is desirable to segment data traffic into groups of virtual local area networks (VLANs), as discussed above. Generally, the MAC address of each node, as determined by the contents of the source MAC address field of a data frame transmitted by the node, is mapped to, or associated with, a VLAN assigned to the port of a network device (e.g., a network switch) at which the data frame enters the switched network. The method by which the network device forwards the data frame varies depending on whether the target node (as determined by the MAC address in the destination MAC address field of the data frame) resides on the same or different VLAN as the source node. It may be desirable to use a standard shared communications medium such as IEEE standard 10BASE-F or 100BASE-T for a backbone transmission fabric between network devices in a switched network. However, unless separate cables are use for each VLAN, the VLAN association of each data frame cannot be determined when the data frame is transmitted over the shared communications medium. A means for identifying, or preserving, the VLAN associated with each data frame when transmitting the data frames over a shared communications medium is needed.
The method described herein provides for a shared communications medium for transferring data frames from multiple virtual local area networks (VLANs) while preserving the VLAN associated with each frame, regardless of whether the data network supports the interconnection of Ethernet or IEEE standard 802.3 nodes.
An IEEE 802.3 frame format also begins with a 6 byte destination MAC address field followed by a 6 byte source MAC address field. As is well known to those of skill in the art, a 2 byte LENGTH field follows the source MAC address field. It should be noted that the present invention, although based on a modification of the Ethernet frame format described above, applies equally well when the original frame is an IEEE 802-standard format (e.g., IEEE 802.3). In such a case, the field following the MAC source address contains not the protocol type of an upper layer protocol, but a value indicating the length of the data field, as discussed above. The present invention preserves the value in that field in a new extended Ethernet frame format, but makes no other use of it, and is, therefore, not sensitive to whether the field contains protocol type or length information.
The contents of the ETYPE field 503 in
A VLAN identifier type (VLAN ID TYPE) field and VLAN identifier length (VLAN LEN) field are present at locations 521 and 522, respectively. These two fields are used in combination to specify the format of the VLAN identifier (VLAN ID) field 523. Although this embodiment of the present invention utilizes only one type and length of VLAN ID field, is it foreseeable that multiple types of VLAN identifiers may be utilized, and that such identifiers may be of varying lengths, depending on the information conveyed by such identifiers, in which case, a network device receiving the data frame should check the VLAN ID TYPE and VLAN LEN fields and determine whether to accept or reject the data frame. In the event multiple VLAN ID TYPEs are utilized, it is envisioned that the VLAN ID TYPE values will be dispensed by an administrative authority.
The VLAN identifier length (VLAN LEN) field specifies the length of the VLAN identifier field in bytes. In this embodiment, the VLAN identifier field is 4 bytes in length. It is envisioned that the length of the VLAN identifier field will be a multiple of 4 bytes to maintain word alignment of fields in the data frame.
The VLAN identifier (VLAN ID) field 523 identifies the VLAN associated with the data frame. A network administrator or similar network wide authority is required to dispense values on a dynamic basis when configuring the virtual networks of the data network.
A new FCS 516 is calculated and replaces the prior FCS 505. FCS 516 performs a CRC on the destination and source MAC address fields, VTYPE field, ETYPE field, VLAN header, and data field.
While one embodiment has been described wherein the VLAN header 514 comprises the VLAN ID TYPE field, the VLAN identifier length (VLAN LEN) field, and the VLAN identifier (VLAN ID) field, alternative embodiments do not necessarily utilize such a VLAN header. For example, in one embodiment, the ETYPE field 503 in
The extended Ethernet frame format illustrated in
Upon receiving the data frame, a network device processes the data frame. It determines the MAC address of a target node based on the contents of the destination MAC address field 511. Following the source MAC address field 512, the device then detects the presence of a VLAN header based on the contents of the VTYPE field, and determines the VLAN identifier associated with the data frame based on the contents of the VLAN identifier field. If a port on the network device which is eligible to receive the frame based on the destination MAC address is assigned the same VLAN identifier as the data frame, the network device then removes the VTYPE field and VLAN header from the data frame, calculates a new FCS for the data frame, and transmits the data frame out the port over a dedicated communications medium to the target node.
The extended Ethernet frame format illustrated in
Upon receiving the data frame, a network device processes the data frame. It determines the MAC address of a target node based on the contents of the destination MAC address field 511, and the MAC address of a source node based on the contents of the source MAC address field 512. The device then processes the VTYPE field 513. In processing the VTYPE field 513, the device detects the presence of the VLAN header 514, and determines the format of the VLAN identifier (VLAN ID) field 523 associated with the data frame from the VLAN identifier type (VLAN ID TYPE) field 521 and the VLAN identifier length (VLAN LEN) field 522. Subsequent to processing the VLAN header 514, the network device continues processing the data frame as is would process a non-VLAN frame.
While one embodiment has been described wherein a VLAN identifier type field is followed by a VLAN length field in the VLAN header, alternative embodiments of the invention do not necessarily use one or both of these fields, or may specify a VLAN length field followed by a VLAN identifier type field in a VLAN header. Thus, it is appreciated that the embodiment illustrated in
There are, of course, other alternatives to the described embodiments of the invention which are within the understanding of one of ordinary skill in the relevant art. For example, the type of network switch which has a single VLAN identifier associated with each port and assumes that a data frame received on a port is destined for the VLAN associated with that port is just one type of network switch. Network switches may present more sophisticated methods of handling VLANs. In the general case, when a data frame is received from an end station on a network switch port, the switch will apply a set of rules to determine the VLAN to which that data frame should be forwarded. The rules can include such things as the port number at which a data frame is received, the data frame's ISO Layer 3 protocol type, the data frame's MAC or network layer source address, time of day, etc. More importantly, the first VLAN aware network switch to receive the data frame should apply its rules and assign the data frame to a VLAN. Thus, the present invention is intended to be limited only by the claims presented below.
Thus, what has been described is a method and frame format for preserving in a data frame the virtual local area network (VLAN) associated with a port on a network device from which the data frame was received when transmitting the data frame over a shared communications medium.
Thompson, Geoffrey O., Frantz, Paul James
Patent | Priority | Assignee | Title |
Patent | Priority | Assignee | Title |
5046308, | Sep 25 1987 | Exhaust system for internal combustion engines provided with a device for housing filters designed to trap solid particles and unburned hydrocarbons entrained in exhaust gases | |
5220564, | Sep 06 1990 | AGERE Systems Inc | Transmission control for a wireless local area network station |
5394402, | Jun 17 1993 | ASCOM ENTERPRISE NETWORKS, INC ; ASCOM USA INC ; ASCOM TIMEPLEX, INC | Hub for segmented virtual local area network with shared media access |
5560038, | Jul 22 1994 | Network Peripherals, Inc. | Apparatus for translating frames of data transferred between heterogeneous local area networks |
5583862, | Mar 28 1995 | RPX CLEARINGHOUSE LLC | Method and apparatus for routing for virtual networks |
5617421, | Jun 17 1994 | Cisco Technology, Inc | Extended domain computer network using standard links |
5684800, | Nov 15 1995 | Extreme Networks, Inc | Method for establishing restricted broadcast groups in a switched network |
5740171, | Mar 28 1996 | Cisco Technology, Inc | Address translation mechanism for a high-performance network switch |
5742604, | Mar 28 1996 | Cisco Technology, Inc | Interswitch link mechanism for connecting high-performance network switches |
5764636, | Mar 28 1996 | Cisco Technology, Inc | Color blocking logic mechanism for a high-performance network switch |
5946308, | Nov 15 1995 | Extreme Networks, Inc | Method for establishing restricted broadcast groups in a switched network |
6111876, | Mar 12 1996 | INTERNATIONAL LICENSE EXCHANGE OF AMERICA, LLC | VLAN frame format |
8023515, | Nov 15 1995 | Extreme Networks, Inc | Distributed connection-oriented services for switched communication networks |
20090245227, | |||
20110134858, | |||
RE40999, | Mar 12 1996 | INTERNATIONAL LICENSE EXCHANGE OF AMERICA, LLC | Vlan frame format |
RE44775, | Mar 12 1996 | INTERNATIONAL LICENSE EXCHANGE OF AMERICA, LLC | VLAN frame format |
Executed on | Assignor | Assignee | Conveyance | Frame | Reel | Doc |
Jul 04 2000 | FRANTZ, PAUL J | Nortel Networks Limited | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 029908 | /0097 | |
Jul 31 2000 | THOMPSON, GEOFFREY O | Nortel Networks Limited | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 029908 | /0097 | |
Jul 29 2011 | Nortel Networks, Limited | Rockstar Bidco, LP | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 030928 | /0170 | |
May 09 2012 | Rockstar Bidco, LP | Rockstar Consortium US LP | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 030928 | /0634 | |
Dec 27 2012 | Spherix Incorporated | (assignment on the face of the patent) | / | |||
Dec 31 2013 | Rockstar Consortium US LP | SPHERIX PORTFOLIO ACQUISITION II, INC | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 034799 | /0847 | |
Jan 08 2014 | Spherix Incorporated | Rockstar Consortium US LP | SECURITY INTEREST SEE DOCUMENT FOR DETAILS | 035463 | /0584 | |
Jan 08 2014 | SPHERIX PORTFOLIO ACQUISITION II, INC | Rockstar Consortium US LP | SECURITY INTEREST SEE DOCUMENT FOR DETAILS | 035463 | /0584 | |
Mar 28 2014 | SPHERIX PORTFOLIO ACQUISITION II, INC | Spherix Incorporated | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 034799 | /0953 | |
Apr 17 2015 | Rockstar Consortium US LP | RPX CLEARINGHOUSE LLC | SECURITY INTEREST SEE DOCUMENT FOR DETAILS | 035463 | /0588 | |
Feb 25 2016 | RPX CLEARINGHOUSE LLC | SPHERIX INCOPORATED | RELEASE BY SECURED PARTY SEE DOCUMENT FOR DETAILS | 037992 | /0488 | |
May 24 2016 | Spherix Incorporated | INTERNATIONAL LICENSE EXCHANGE OF AMERICA, LLC | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 038787 | /0297 |
Date | Maintenance Fee Events |
Date | Maintenance Schedule |
Jun 30 2018 | 4 years fee payment window open |
Dec 30 2018 | 6 months grace period start (w surcharge) |
Jun 30 2019 | patent expiry (for year 4) |
Jun 30 2021 | 2 years to revive unintentionally abandoned end. (for year 4) |
Jun 30 2022 | 8 years fee payment window open |
Dec 30 2022 | 6 months grace period start (w surcharge) |
Jun 30 2023 | patent expiry (for year 8) |
Jun 30 2025 | 2 years to revive unintentionally abandoned end. (for year 8) |
Jun 30 2026 | 12 years fee payment window open |
Dec 30 2026 | 6 months grace period start (w surcharge) |
Jun 30 2027 | patent expiry (for year 12) |
Jun 30 2029 | 2 years to revive unintentionally abandoned end. (for year 12) |