USRE40999E1 - Vlan frame format - Google Patents

Vlan frame format Download PDF

Info

Publication number
USRE40999E1
USRE40999E1 US10/225,708 US22570802A USRE40999E US RE40999 E1 USRE40999 E1 US RE40999E1 US 22570802 A US22570802 A US 22570802A US RE40999 E USRE40999 E US RE40999E
Authority
US
United States
Prior art keywords
field
virtual network
network identifier
data frame
data
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 - Lifetime
Application number
US10/225,708
Inventor
Paul James Frantz
Geoffrey O. Thompson
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
International License Exchange Of America LLC
Original Assignee
Nortel Networks Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Family has litigation
First worldwide family litigation filed litigation Critical https://patents.darts-ip.com/?family=41327977&utm_source=google_patent&utm_medium=platform_link&utm_campaign=public_patent_search&patent=USRE40999(E1) "Global patent litigation dataset” by Darts-ip is licensed under a Creative Commons Attribution 4.0 International License.
Priority claimed from US08/613,726 external-priority patent/US5959990A/en
Priority to US10/225,708 priority Critical patent/USRE40999E1/en
Application filed by Nortel Networks Ltd filed Critical Nortel Networks Ltd
Priority to US12/459,465 priority patent/USRE44775E1/en
Publication of USRE40999E1 publication Critical patent/USRE40999E1/en
Application granted granted Critical
Assigned to NORTEL NETWORKS LIMITED reassignment NORTEL NETWORKS LIMITED ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: THOMPSON, GEOFFREY O., FRANTZ, PAUL J.
Assigned to Rockstar Bidco, LP reassignment Rockstar Bidco, LP ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: NORTEL NETWORKS LIMITED
Assigned to ROCKSTAR CONSORTIUM US LP reassignment ROCKSTAR CONSORTIUM US LP ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: Rockstar Bidco, LP
Priority to US13/728,698 priority patent/USRE45598E1/en
Priority to US13/728,747 priority patent/USRE45521E1/en
Priority to US13/728,846 priority patent/USRE45095E1/en
Priority to US13/728,867 priority patent/USRE45121E1/en
Priority to US13/728,838 priority patent/USRE45708E1/en
Priority to US13/728,823 priority patent/USRE45081E1/en
Priority to US13/728,787 priority patent/USRE45065E1/en
Assigned to SPHERIX PORTFOLIO ACQUISITION II, INC. reassignment SPHERIX PORTFOLIO ACQUISITION II, INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: ROCKSTAR CONSORTIUM US LP
Assigned to SPHERIX INCORPORATED reassignment SPHERIX INCORPORATED ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: SPHERIX PORTFOLIO ACQUISITION II, INC.
Assigned to ROCKSTAR CONSORTIUM US LP reassignment ROCKSTAR CONSORTIUM US LP SECURITY INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: SPHERIX INCORPORATED, SPHERIX PORTFOLIO ACQUISITION II, INC.
Assigned to RPX CLEARINGHOUSE LLC reassignment RPX CLEARINGHOUSE LLC SECURITY INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: ROCKSTAR CONSORTIUM US LP
Assigned to SPHERIX INCOPORATED reassignment SPHERIX INCOPORATED RELEASE BY SECURED PARTY (SEE DOCUMENT FOR DETAILS). Assignors: RPX CLEARINGHOUSE LLC
Anticipated expiration legal-status Critical
Assigned to INTERNATIONAL LICENSE EXCHANGE OF AMERICA, LLC reassignment INTERNATIONAL LICENSE EXCHANGE OF AMERICA, LLC ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: SPHERIX INCORPORATED
Expired - Lifetime legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W84/00Network topologies
    • H04W84/18Self-organising networks, e.g. ad-hoc networks or sensor networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46Interconnection of networks
    • H04L12/4633Interconnection of networks using encapsulation techniques, e.g. tunneling
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46Interconnection of networks
    • H04L12/4641Virtual LANs, VLANs, e.g. virtual private networks [VPN]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W72/00Local resource management
    • H04W72/50Allocation or scheduling criteria for wireless resources
    • H04W72/56Allocation or scheduling criteria for wireless resources based on priority criteria
    • H04W72/566Allocation or scheduling criteria for wireless resources based on priority criteria of the information or information source or recipient
    • H04W72/569Allocation or scheduling criteria for wireless resources based on priority criteria of the information or information source or recipient of the traffic information
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W76/00Connection management
    • H04W76/10Connection setup
    • H04W76/11Allocation or use of connection identifiers
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46Interconnection of networks
    • H04L12/4641Virtual LANs, VLANs, e.g. virtual private networks [VPN]
    • H04L12/4645Details on frame tagging
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46Interconnection of networks
    • H04L12/4641Virtual LANs, VLANs, e.g. virtual private networks [VPN]
    • H04L12/467Arrangements for supporting untagged frames, e.g. port-based VLANs

Definitions

  • 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.
  • a small baseband local area network 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.
  • nodes e.g., a server and workstations
  • IEEE Institute of Electrical and Electronics Engineers 802.3 standard local area 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.
  • 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.
  • 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.
  • MAC Media Access Control
  • layer 2 Data Link layer
  • ISO International Standards Organization
  • OSI Open Systems Interconnection
  • a router 100 separates LAN segments 103 , 110 and 120 into one broadcast domain 11 , and LAN segments 105 , 130 and 140 into another broadcast domain 12 .
  • 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.
  • 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 are dedicated LAN segments, therefore, nodes 104 and 106 have all available bandwidth to themselves.
  • 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.
  • FDDI Fiber Distributed Data Interface
  • 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.
  • data network 10 involves significant hardware and software expenses associated with two network switches, a router, and the multiple communication lines required to achieve multiple broadcast domains. Moreover, a significant amount of administrative overhead is required to maintain the configuration and operation of the internetworking devices as required, for example, when a node is moved from one segment to another segment in the same or different broadcast domain. Thus, it is desirable to implement the data network 10 of FIG. 1 using a single network switch and virtual local area networks (VLANs).
  • VLANs virtual local area networks
  • FIG. 2A illustrates data network 10 using a single network switch 200 and virtual local area networks (VLANs) to create multiple broadcast domains 11 and 12 .
  • a VLAN is a logical local area network comprised of a plurality of physical local area networks as determined by some network administrator-defined criteria, e.g., grouping local area networks based on geographical topology of the data network, or business units/functions of a company, such as finance or engineering departments.
  • Such VLANs are generally configured based on the points where the physical LANs enter a switched network.
  • network switch 200 is configured such that ports 201 through 203 and 207 belong to VLAN 210 , and ports 204 - 206 belong to VLAN 220 .
  • the configuration of data network 10 in FIG. 2A is relatively less expensive than the configuration of data network 10 in FIG. 1 in that only one switch is required.
  • VLANs are configured at network switch 200 , a network administrator can maintain configuration and operation of the network without concern for moving a node from one LAN segment to another LAN segment in the same VLAN.
  • FIG. 2B shows the addition of switch 300 to the network shown in FIG. 2 A.
  • LAN segment 190 is used to link switch 300 to switch 200 .
  • Switch 300 supports segments 150 and 160 in VLAN 210 and segments 170 and 180 in VLAN 220 .
  • switch 200 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 ).
  • 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 .
  • the VLAN configuration of switch 200 is such that nodes in one VLAN cannot communicate with nodes in the other VLAN via network switch 200 .
  • node 104 can communicate with node 122 but cannot communicate with node 142 by way of switch 200 .
  • router 100 connects VLAN 210 to VLAN 220 via communications mediums 101 and 102 respectively, so that node 104 can communicate with node 142 .
  • Router 100 also allows a network administrator to configure appropriate policy restrictions and security rules to reduce unnecessary or unwanted traffic in data network 10 .
  • routers commonly provide a capability for bridging frames of non-routable protocols. For example, assume node 106 in VLAN 220 uses the DEC LAT protocol in an attempt to transmit a data frame to a node in VLAN 210 . Switch 200 receives the data frame from node 106 over dedicated communications medium 105 and transfers it to router 100 via communications medium 102 .
  • DEC LAT network layer protocol
  • NetBIOS NetBIOS
  • Router 100 may bridge the data frame back to switch 200 via communications medium 101 .
  • Switch 200 receives the data frame and, because the data frame is bridged instead of routed, the source MAC address is unchanged.
  • Switch 200 has now received on both ports 205 (in VLAN 220 ) and 207 (in VLAN 210 ) a data frame having the MAC address for node 106 , and cannot, therefore, unambiguously determine over which port node 106 is connected, or which VLAN should be associated with node 106 . Therefore, switch 200 is unable to inform switch 300 of which VLAN should be associated with the MAC address of node 106 .
  • 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 .
  • a routing protocol e.g., the DecNet routing protocol
  • VLAN virtual local area network
  • FIG. 3 one means of reducing this expense is to combine multiple communications links into a single shared communications medium 300 between switch 200 and router 100 .
  • the same problems which prevented switch 300 in FIG. 2B from reliably determining the proper VLAN for frames received over segment 190 also prevent switch 200 in FIG. 3 from reliably associating VLANs with data frames received over segment 300 .
  • a means is needed to identify the virtual local area network (VLAN) from which a frame originated when transferring the frame over a communications medium shared among multiple VLANs.
  • VLAN virtual local area network
  • 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 FIG.
  • each device may utilize a protocol to exchange lookup tables so that each device knows which VLAN is assigned to each port on each device and what nodes (identified by their respective MAC addresses) are reachable via each port as well as which nodes belong to the same VLAN and are allowed, therefore, to communicate with each other.
  • 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).
  • 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.
  • FIG. 4 illustrates the frame format for an IEEE 802.3 MAC/802.10 SDE data frame utilizing the MDF to identify the VLAN associated with the data frame.
  • Portion 401 of data frame 400 is the IEEE 802.3 media access control (MAC) header, comprising a 6 byte destination MAC address field, and 6 byte source MAC address field, and a 2 byte length field.
  • Portion 402 indicates the IEEE 802.10 secure data exchange (SDE) clear header, comprising the SDE designator field 404 containing a special destination service access point (DSAP), source service access point (SSAP), and control field for SDE frames, a security association identifier (SAID) field 405 , and the management defined field (MDF) 406 .
  • SDE secure data exchange
  • 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.
  • switch 200 When the frame is subsequently transmitted across a shared communications medium, such as when switch 300 of FIG. 2B forwards over shared communications medium 190 a data frame destined for a node coupled to a port associated with a different VLAN on switch 200 , switch 200 is able to determine the VLAN from which the data frame was received by switch 300 and forward it accordingly to router 100 (if, indeed, inter-VLAN communication is required). Router 100 then routes the data frame back to switch 200 , where switch 200 then determines whether to forward the frame to the appropriate port based on the VLAN identifier in the MDF and destination MAC address in the destination MAC address field.
  • the frame format illustrated in FIG. 4 supports only the IEEE 802.3 media access control standards.
  • An Ethernet-based data frame is considered nonstandard by the IEEE, and, therefore, cannot utilize the IEEE 802.10 header, or any other IEEE based header to preserve the VLAN, except through the use of an additional layer of encapsulation.
  • IEEE Recommended Practice 802.1H is one way of performing this additional encapsulation. This extra layer of encapsulation reduces the efficiency of bandwidth utilization and adds complexity to the implementation.
  • a method and frame format for identifying the VLAN associated with a data frame received at a network switch from either an Ethernet LAN or an IEEE 802.3 LAN 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 Ethernet-based nodes on the same shared media with nodes supporting VLAN identification.
  • 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.
  • a data frame format extends the traditional Ethernet frame format to accommodate a VLAN header.
  • 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.
  • 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.
  • 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.
  • FIG. 1 illustrates a prior art data network topology
  • FIG. 2A illustrates a prior art data network topology utilizing virtual local area networks
  • FIG. 2B illustrates a prior art data network topology utilizing virtual local area networks and shared communications media between network devices
  • FIG. 3 further illustrates a prior art data network topology utilizing virtual local area networks and shared communications media between network devices.
  • FIG. 4 illustrates the IEEE 802 3 MAC/802 1 SDE frame format as may be utilized in the prior art
  • FIG. 5 (a) illustrates an Ethernet frame format
  • FIG. 5 (b) illustrates a modified Ethernet frame format as may be utilized by the present invention.
  • FIG. 5 (c) illustrates a modified Ethernet frame format as may be utilized by the present invention.
  • 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.
  • VLAN virtual local area network
  • VLANs virtual local area networks
  • the MAC address of each 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.
  • a network device e.g., a network switch
  • 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.
  • 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.
  • VLANs virtual local area networks
  • FIG. 5 (a) illustrates the data frame format for an Ethernet network.
  • the Ethernet frame format begins with a 6 byte destination MAC address field followed by a 6 byte source MAC address field.
  • a 2 byte Ethernet type (ETYPE) field 503 follows the source MAC address field.
  • the ETYPE field indicates the protocol type of the next upper layer protocol header which begins immediately following the ETYPE field (e.g., 0800(h) indicates the IP network layer protocol).
  • the data field 504 comprises any upper layer protocol information and user data, all of which is considered data from the perspective of the MAC sublayer.
  • FCS frame check sequence
  • FCC frame check sequence
  • 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.
  • FIG. 5 (b) illustrates a data frame format that may be utilized by one embodiment of the present invention.
  • the frame format extends the Ethernet frame format illustrated in FIG. 5 (a) to accommodate a virtual load area network (VLAN) header 514 , along with its associated VTYPE field 513 .
  • FIG. 5 (b) illustrates a virtual type (VTYPE) field 513 .
  • VTYPE field 513 is inserted after the source MAC address field 512 and before the ETYPE field 520 of an Ethernet data frame or the length field of an IEEE 802.3 data frame.
  • the virtual type (VTYPE) field 513 identifies the remainder of the frame as an extended Ethernet frame comprising a VLAN header 514 inserted, for example, after the Ethernet type field 520 and before the data field 515 shown in FIG. 5 (b).
  • the contents of the ETYPE field 503 in FIG. 5 (a), or the length field of an IEEE 802.3-based data frame is retained.
  • Location 503 in FIG. 5 (a) becomes location 520 in FIG. 5 (b).
  • the ETYPE field at location 520 returns back to location 503 in FIG. 5 (a) when the data frame is transferred from a shared communications medium used to transmit data frames for multiple VLANs to a dedicated communications medium used to transmit data frames for a single VLAN.
  • VLAN ID TYPE VLAN identifier type
  • VLAN LEN VLAN identifier length
  • VLAN LEN The VLAN identifier length (VLAN LEN) field specifies the length of the VLAN identifier field in bytes.
  • 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.
  • FCS 516 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.
  • VLAN header 514 comprises the VLAN ID TYPE field, the VLAN identifier length (VLAN LEN) field, and the VLAN identifier (VLAN ID) field
  • VLAN ID VLAN identifier
  • alternative embodiments do not necessarily utilize such a VLAN header.
  • the ETYPE field 503 in FIG. 5 (a), or the length field of an IEEE 802.3-based data frame is contained in the VLAN header.
  • the VLAN header 514 includes the location 520 wherein the value in the ETYPE field 503 in FIG. 5 (a), or the length field of an IEEE 802.3-based data frame is preserved.
  • the VLAN header does not contain one or both of the VLAN ID TYPE field and the VLAN identifier length (VLAN LEN) field.
  • the VLAN header can contain any number of fields in addition to the VLAN identifier (VLAN ID) field. It is appreciated that the format of the VLAN header can be differentiated by assignment of differing values to VTYPE field 513 .
  • the extended Ethernet frame format illustrated in FIG. 5 (b) may be utilized in the following manner.
  • a network device e.g., a network switch
  • a data frame utilizing the Ethernet frame format (see FIG. 5 (a)) or IEEE 802.3-based frame format may be transmitted by a node over a dedicated communications medium to the network switch.
  • the network switch receives the data frame at a port coupled to the dedicated communications medium.
  • the network switch inserts a VTYPE field 513 between the source MAC address field 512 and the ETYPE field or length field 520 (depending on the frame format).
  • the network switch then inserts a VLAN header between the ETYPE field or length field and data field of the data frame.
  • the value originally in the ETYPE field 503 (or length field in the case of an IEEE 802.3-based frame format) of FIG. 5 (a) is retained in ETYPE/Length field 520 as shown in FIG. 5 (b).
  • a value is placed in the VTYPE field 513 identifying the frame as containing VLAN identifier information (VTYPE 513 ).
  • VLAN identifier type and VLAN identifier length field is inserted in VLAN header 514 at 521 and 522 .
  • VLAN identifier associated with the data frame is placed in the VLAN identifier field 523 .
  • the data frame now having an extended Ethernet frame format is then transmitted over a shared communications medium.
  • a network device 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.
  • the network device 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.
  • FIG. 5 (c) illustrates a data frame format that may be utilized by an alternative embodiment of the present invention.
  • the frame format also extends the Ethernet frame format illustrated in FIG. 5 (a) or an IEEE 802.3-based frame format, as did the frame format in FIG. 5 (b), to accommodate a virtual local area network (VLAN) header 514 .
  • VLAN virtual local area network
  • a virtual type (VTYPE) field 513 and VLAN header 514 is inserted between the source MAC address field 512 and ETYPE field 520 of an Ethernet data frame (or the length field of IEEE 802.3-based data frame) to respectively identify the frame as an extended Ethernet frame, and provide the VLAN identifier.
  • VTYPE virtual type
  • the VLAN header 514 is inserted between the VTYPE field 513 and the ETYPE/Length field 520 such that the ETYPE field 520 follows the VTYPE field 513 and VLAN header 514 .
  • the extended Ethernet frame format illustrated in FIG. 5 (c) may be utilized in a similar manner as the previously described embodiments of the invention. For example, when a network switch receives the data frame at a port coupled to the dedicated communications medium, at that time, or prior to transmitting the data frame over a shared communications medium to another network device, the network switch inserts, at a location following the source address field 512 , the VTYPE field 513 . A value in the VTYPE 513 indicates the presence of a VLAN header. The network switch also inserts the VLAN header 514 following the VTYPE field 513 . The data frame, now having an extended Ethernet frame format, can be transmitted over a shared communications medium.
  • a network device 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.
  • VLAN ID VLAN identifier
  • VLAN LEN VLAN identifier length
  • 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.
  • FIG. 5 (c) can be modified in any number of ways, as long as a VTYPE field is followed, in order, by a VLAN identifier field and an Ethernet type field (or length field for IEEE 802.3-based data frames).
  • 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.
  • 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.
  • the present invention is intended to be limited only by the claims presented below.
  • VLAN virtual local area network

Abstract

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.

Description

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
NOTICE: More than one reissue application has been filed for the reissue of U.S. Pat. No. 6.111,876. The reissue applications are application Ser. Nos. 10/225,708 (the present application), and application Ser. No. 12/459,465 that is being concurrently filed with the payment of the issue fee in the above referenced application Ser. No. 10/225,708, all of which are divisional reissues of U.S. Pat. No. 6,111,876.
COPYRIGHT NOTICE
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.
BACKGROUND OF THE INVENTION
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 FIG. 1, a data network 10 is illustrated wherein a number of internet-working devices are installed to reduce traffic levels on each LAN segment. A router 100 separates LAN segments 103, 110 and 120 into one broadcast domain 11, and LAN segments 105, 130 and 140 into another broadcast domain 12.
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 FIG. 1, data network 10 involves significant hardware and software expenses associated with two network switches, a router, and the multiple communication lines required to achieve multiple broadcast domains. Moreover, a significant amount of administrative overhead is required to maintain the configuration and operation of the internetworking devices as required, for example, when a node is moved from one segment to another segment in the same or different broadcast domain. Thus, it is desirable to implement the data network 10 of FIG. 1 using a single network switch and virtual local area networks (VLANs).
FIG. 2A illustrates data network 10 using a single network switch 200 and virtual local area networks (VLANs) to create multiple broadcast domains 11 and 12. A VLAN is a logical local area network comprised of a plurality of physical local area networks as determined by some network administrator-defined criteria, e.g., grouping local area networks based on geographical topology of the data network, or business units/functions of a company, such as finance or engineering departments. Such VLANs are generally configured based on the points where the physical LANs enter a switched network. For example, network switch 200 is configured such that ports 201 through 203 and 207 belong to VLAN 210, and ports 204-206 belong to VLAN 220. LAN segments 103, 110 and 120 coupled to ports 201-203, respectively, belong to VLAN 210. LAN segments 130, 140 and 105 coupled to ports 204, 207, and 205, respectively, belong to VLAN 220. The configuration of data network 10 in FIG. 2A is relatively less expensive than the configuration of data network 10 in FIG. 1 in that only one switch is required. Moreover, since VLANs are configured at network switch 200, a network administrator can maintain configuration and operation of the network without concern for moving a node from one LAN segment to another LAN segment in the same VLAN.
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. FIG. 2B shows the addition of switch 300 to the network shown in FIG. 2A. LAN segment 190 is used to link switch 300 to switch 200. Switch 300 supports segments 150 and 160 in VLAN 210 and segments 170 and 180 in VLAN 220.
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 FIG. 2A, even though all physical LAN segments 103, 105, 120, 130, and 140 are connected to ports on LAN switch 200, the VLAN configuration of switch 200 is such that nodes in one VLAN cannot communicate with nodes in the other VLAN via network switch 200. For example, node 104 can communicate with node 122 but cannot communicate with node 142 by way of switch 200. Rather, router 100 connects VLAN 210 to VLAN 220 via communications mediums 101 and 102 respectively, so that node 104 can communicate with node 142. Messages transferred between nodes of different VLANs are most often transmitted at the Network layer of the OSI reference model, based on the Network layer address of each node, e.g., an Internet Protocol (IP) address. Router 100 also allows a network administrator to configure appropriate policy restrictions and security rules to reduce unnecessary or unwanted traffic in data network 10.
Using a routing function to transfer data frames between VLAN 210 and VLAN 220 as illustrated in FIG. 2B is inappropriate, however, for data frames of protocol suites that do not support a network layer protocol, e.g., DEC LAT or NetBIOS. To deal with this problem, routers commonly provide a capability for bridging frames of non-routable protocols. For example, assume node 106 in VLAN 220 uses the DEC LAT protocol in an attempt to transmit a data frame to a node in VLAN 210. Switch 200 receives the data frame from node 106 over dedicated communications medium 105 and transfers it to router 100 via communications medium 102. Router 100, not being able to route DEC LAT traffic, may bridge the data frame back to switch 200 via communications medium 101. Switch 200 receives the data frame and, because the data frame is bridged instead of routed, the source MAC address is unchanged. Switch 200 has now received on both ports 205 (in VLAN 220) and 207 (in VLAN 210) a data frame having the MAC address for node 106, and cannot, therefore, unambiguously determine over which port node 106 is connected, or which VLAN should be associated with node 106. Therefore, switch 200 is unable to inform switch 300 of which VLAN should be associated with the MAC address of node 106.
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 FIG. 2A is that a communications link is needed between network switch 200 and router 100 for each virtual local area network (VLAN). As the number of physical LAN segments and VLAN segments increase, and as the distance between LANs increase necessitating utilization of metropolitan- and wide-area communications mediums/facilities, the monetary and administrative expense required to maintain data network 10 also increases. As illustrated in FIG. 3, one means of reducing this expense is to combine multiple communications links into a single shared communications medium 300 between switch 200 and router 100. The same problems which prevented switch 300 in FIG. 2B from reliably determining the proper VLAN for frames received over segment 190 also prevent switch 200 in FIG. 3 from reliably associating VLANs with data frames received over segment 300. Thus, a means is needed to identify the virtual local area network (VLAN) from which a frame originated when transferring the frame over a communications medium shared among multiple VLANs.
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 FIG. 3, they may utilize a protocol to exchange lookup tables so that each device knows which VLAN is assigned to each port on each device and what nodes (identified by their respective MAC addresses) are reachable via each port as well as which nodes belong to the same VLAN and are allowed, therefore, to communicate with each other.
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.
FIG. 4 illustrates the frame format for an IEEE 802.3 MAC/802.10 SDE data frame utilizing the MDF to identify the VLAN associated with the data frame. Portion 401 of data frame 400 is the IEEE 802.3 media access control (MAC) header, comprising a 6 byte destination MAC address field, and 6 byte source MAC address field, and a 2 byte length field. Portion 402 indicates the IEEE 802.10 secure data exchange (SDE) clear header, comprising the SDE designator field 404 containing a special destination service access point (DSAP), source service access point (SSAP), and control field for SDE frames, a security association identifier (SAID) field 405, and the management defined field (MDF) 406. The remainder of the original data frame, comprising its IEEE 802.2 LLC header followed by the user data, is included in field 403.
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 FIG. 2B forwards over shared communications medium 190 a data frame destined for a node coupled to a port associated with a different VLAN on switch 200, switch 200 is able to determine the VLAN from which the data frame was received by switch 300 and forward it accordingly to router 100 (if, indeed, inter-VLAN communication is required). Router 100 then routes the data frame back to switch 200, where switch 200 then determines whether to forward the frame to the appropriate port based on the VLAN identifier in the MDF and destination MAC address in the destination MAC address field.
However, the frame format illustrated in FIG. 4 supports only the IEEE 802.3 media access control standards. An Ethernet-based data frame is considered nonstandard by the IEEE, and, therefore, cannot utilize the IEEE 802.10 header, or any other IEEE based header to preserve the VLAN, except through the use of an additional layer of encapsulation. IEEE Recommended Practice 802.1H is one way of performing this additional encapsulation. This extra layer of encapsulation reduces the efficiency of bandwidth utilization and adds complexity to the implementation. Thus, a method and frame format for identifying the VLAN associated with a data frame received at a network switch from either an Ethernet LAN or an IEEE 802.3 LAN 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 Ethernet-based nodes on the same shared media with nodes supporting VLAN identification.
SUMMARY OF THE DISCLOSURE
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.
BRIEF DESCRIPTION OF THE DRAWINGS
The present invention is illustrated by way of example and not limitation in the following figures. Like references indicate similar elements, in which.
FIG. 1 illustrates a prior art data network topology.
FIG. 2A illustrates a prior art data network topology utilizing virtual local area networks
FIG. 2B illustrates a prior art data network topology utilizing virtual local area networks and shared communications media between network devices
FIG. 3 further illustrates a prior art data network topology utilizing virtual local area networks and shared communications media between network devices.
FIG. 4 illustrates the IEEE 802 3 MAC/802 1 SDE frame format as may be utilized in the prior art
FIG. 5(a) illustrates an Ethernet frame format.
FIG. 5(b) illustrates a modified Ethernet frame format as may be utilized by the present invention.
FIG. 5(c) illustrates a modified Ethernet frame format as may be utilized by the present invention.
DETAILED DESCRIPTION OF THE EMBODIMENTS OF THE INVENTION
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.
FIG. 5(a) illustrates the data frame format for an Ethernet network. Like the IEEE standard 802.3 frame format, the Ethernet frame format begins with a 6 byte destination MAC address field followed by a 6 byte source MAC address field. However, unlike the IEEE standard 802.3 frame format, a 2 byte Ethernet type (ETYPE) field 503 follows the source MAC address field. The ETYPE field indicates the protocol type of the next upper layer protocol header which begins immediately following the ETYPE field (e.g., 0800(h) indicates the IP network layer protocol). The data field 504 comprises any upper layer protocol information and user data, all of which is considered data from the perspective of the MAC sublayer. Finally, a frame check sequence (FCS) field 505, comprising a 32-bit cyclical redundancy check (CRC) of the contents of fields 501, 502, 503 and 504, completes the data frame.
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.
FIG. 5(b) illustrates a data frame format that may be utilized by one embodiment of the present invention. The frame format extends the Ethernet frame format illustrated in FIG. 5(a) to accommodate a virtual load area network (VLAN) header 514, along with its associated VTYPE field 513. FIG. 5(b) illustrates a virtual type (VTYPE) field 513. VTYPE field 513 is inserted after the source MAC address field 512 and before the ETYPE field 520 of an Ethernet data frame or the length field of an IEEE 802.3 data frame. The virtual type (VTYPE) field 513 identifies the remainder of the frame as an extended Ethernet frame comprising a VLAN header 514 inserted, for example, after the Ethernet type field 520 and before the data field 515 shown in FIG. 5(b).
The contents of the ETYPE field 503 in FIG. 5(a), or the length field of an IEEE 802.3-based data frame is retained. Location 503 in FIG. 5(a) becomes location 520 in FIG. 5(b). The ETYPE field at location 520 returns back to location 503 in FIG. 5(a) when the data frame is transferred from a shared communications medium used to transmit data frames for multiple VLANs to a dedicated communications medium used to transmit data frames for a single VLAN.
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 FIG. 5(a), or the length field of an IEEE 802.3-based data frame is contained in the VLAN header. In other words, the VLAN header 514 includes the location 520 wherein the value in the ETYPE field 503 in FIG. 5(a), or the length field of an IEEE 802.3-based data frame is preserved. In other embodiments, the VLAN header does not contain one or both of the VLAN ID TYPE field and the VLAN identifier length (VLAN LEN) field. Thus, the VLAN header can contain any number of fields in addition to the VLAN identifier (VLAN ID) field. It is appreciated that the format of the VLAN header can be differentiated by assignment of differing values to VTYPE field 513.
The extended Ethernet frame format illustrated in FIG. 5(b) may be utilized in the following manner. A network device (e.g., a network switch) has been configured so that a virtual local area network identifier representing a virtual local area network is assigned to each port on the network device. A data frame utilizing the Ethernet frame format (see FIG. 5(a)) or IEEE 802.3-based frame format may be transmitted by a node over a dedicated communications medium to the network switch. The network switch receives the data frame at a port coupled to the dedicated communications medium. At that time, or prior to transmitting the data frame over a shared communications medium to another network device, the network switch inserts a VTYPE field 513 between the source MAC address field 512 and the ETYPE field or length field 520 (depending on the frame format). The network switch then inserts a VLAN header between the ETYPE field or length field and data field of the data frame. The value originally in the ETYPE field 503 (or length field in the case of an IEEE 802.3-based frame format) of FIG. 5(a) is retained in ETYPE/Length field 520 as shown in FIG. 5(b). A value is placed in the VTYPE field 513 identifying the frame as containing VLAN identifier information (VTYPE 513). If utilized, a VLAN identifier type and VLAN identifier length field is inserted in VLAN header 514 at 521 and 522. Finally, the VLAN identifier associated with the data frame is placed in the VLAN identifier field 523. The data frame now having an extended Ethernet frame format is then transmitted over a shared communications medium.
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.
FIG. 5(c) illustrates a data frame format that may be utilized by an alternative embodiment of the present invention. The frame format also extends the Ethernet frame format illustrated in FIG. 5(a) or an IEEE 802.3-based frame format, as did the frame format in FIG. 5(b), to accommodate a virtual local area network (VLAN) header 514. A virtual type (VTYPE) field 513 and VLAN header 514 is inserted between the source MAC address field 512 and ETYPE field 520 of an Ethernet data frame (or the length field of IEEE 802.3-based data frame) to respectively identify the frame as an extended Ethernet frame, and provide the VLAN identifier. Unlike the embodiment described in reference to FIG. 5(b) wherein the ETYPE/Length field 520 follows the VTYPE field 513 and precedes the VLAN header 514 in the data frame, the VLAN header 514 is inserted between the VTYPE field 513 and the ETYPE/Length field 520 such that the ETYPE field 520 follows the VTYPE field 513 and VLAN header 514.
The extended Ethernet frame format illustrated in FIG. 5(c) may be utilized in a similar manner as the previously described embodiments of the invention. For example, when a network switch receives the data frame at a port coupled to the dedicated communications medium, at that time, or prior to transmitting the data frame over a shared communications medium to another network device, the network switch inserts, at a location following the source address field 512, the VTYPE field 513. A value in the VTYPE 513 indicates the presence of a VLAN header. The network switch also inserts the VLAN header 514 following the VTYPE field 513. The data frame, now having an extended Ethernet frame format, can be transmitted over a shared communications medium.
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 FIG. 5(c) can be modified in any number of ways, as long as a VTYPE field is followed, in order, by a VLAN identifier field and an Ethernet type field (or length field for IEEE 802.3-based data frames).
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.

Claims (68)

1. A method of identifying a virtual network associated with a data frame when transmitter 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, a value of 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 type 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.
2. The method of claim 1, further comprising the steps of:
1 a) inserting between said second type field and said virtual network identifier field a virtual network identifier type field; and
2 b) assigning a second value to said virtual network identifier type field indicating a type of said first value in said virtual network identifier field.
3. The method of claim 1, further comprising the steps of:
1 a) inserting between said second type field and said virtual network identifier field a virtual network identifier length field; and
2 b) assigning a second value to said virtual network identifier length field indicating a length of said first value in said virtual network identifier field.
4. The method of claim 1 wherein said virtual network identifier field is 4 bytes.
5. The method of claim 1 wherein said virtual network identifier field is a multiple of 4 bytes.
6. The method of claim 1 wherein a value of said first type field indicates a protocol type.
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, a value of 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.
8. The method of claim 7, further comprising the steps of:
1 a) inserting between said type field and said virtual network identifier field a virtual network identifier type field; and
2 b) assigning a second value to said virtual network identifier type field indicating a type of said first value in said virtual network identifier field.
9. The method of claim 7, further comprising the steps of:
1 a) inserting between said type field and said virtual network identifier field a virtual network identifier length field; and
2 b) assigning a second value to said virtual network identifier length field indicating a length of said first value in said virtual network identifier field.
10. The method of claim 8 wherein said virtual network identifier field is a multiple of 4 bytes.
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.
12. The method of claim 11 wherein said virtual network identifier field is 4 bytes.
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.
14. The method of claim 13 further comprising:
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.
15. The method of claim 13 wherein said virtual network identifier field is 4 bytes.
16. The method of claim 13 wherein said virtual network identifier field is a multiple of 4 bytes.
17. The method of claim 1 wherein said virtual network identifier field is an integer number of bytes long.
18. The method of claim 17 wherein said virtual network identifier field is 4 bytes.
19. The method of claim 8 wherein said virtual network identifier field is an integer number of bytes in length.
20. The method of claim 19 wherein said virtual network identifier field is a multiple of 4 bytes.
21. The method of claim 13 wherein said virtual network identifier field is an integer number of bytes long.
22. The method of claim 21 wherein said virtual network identifier field is 4 bytes.
23. A method of identifying a virtual network associated with a data frame transmitted between a communications medium and a shared communications medium, the method comprising:
a) obtaining a first data frame from the communications medium, the first data frame comprising a data field and either an e-type or a data length field having a corresponding value indicating a protocol type or a length of the data field, respectively; and
b) producing a second data frame using the first data frame, the second data frame comprising a vtype field, a virtual network identifier field, a virtual network identifier type field, the data field, and whichever of the e-type field or data length field that the first data frame contains, a value of the vtype field indicating that the second data frame comprises the virtual network identifier field, and the virtual network identifier field having a virtual network identifier field value corresponding to the virtual network;
wherein the second data frame is configured such that the vtype field will be transmitted before the virtual network identifier type field, the virtual network identifier type field before the virtual network identifier field, and the virtual network identifier field before whichever of the e-type field or the data length field that the second data frame contains.
24. The method of claim 23 further comprising transmitting the second frame via the shared communications medium.
25. The method of claim 23 wherein the virtual network identifier field value is an integer number of bytes in length.
26. The method of claim 25 wherein the virtual network identifier field value is a multiple of four bytes in length.
27. The method of claim 26 wherein the virtual network identifier field value is four bytes in length.
28. The method of claim 23 wherein a value of the virtual network identifier type field indicates a type of the virtual network identifier field value.
29. The method of claim 28 wherein the second data frame further comprises a virtual network identifier length field having a corresponding value indicating a length of the virtual network identifier field value, wherein the second frame is configured such that the virtual network identifier length field will be transmitted after the virtual network identifier type field and before the virtual network identifier field.
30. The method of claim 23 wherein producing the second data frame includes determining the virtual network identifier field value in accordance with at least one rule.
31. The method of claim 30 wherein determining the virtual network identifier field value in accordance with the at least one rule uses at least one of a number of a port through which the first data frame is obtained, a protocol type of the first data frame, a MAC address of the first data frame, a network-layer source address of the first data frame, and a time of day when the first data frame is received.
32. The method of claim 23 wherein the second data frame is produced with the e-type field if the first data frame is an Ethernet frame and is produced with the data length field if the first data frame is an LLC frame.
33. A method of identifying a virtual network associated with a data frame transmitted between a communications medium and a shared communications medium, the method comprising:
a) obtaining a first data frame from the communications medium, the first data frame comprising a data field and either an e-type field or a data length field having a corresponding value indicating a protocol type or a length of the data field, respectively; and
b) producing a second data frame using the first data frame, the second data frame comprising a vtype field, a virtual network identifier field, a virtual network identifier length field, the data field, and whichever of the e-type field or the data length field that the first data frame contains, a value of the vtype field indicating that the second data frame comprises the virtual network identifier field, and the virtual network identifier field having a virtual network identifier field value corresponding to the virtual network;
wherein the second data frame is configured such that the vtype field will be transmitted before virtual network identifier length field, the virtual network identifier length field before the virtual identifier field, and the virtual network identifier field before whichever of the e-type field or the data length field that the second data frame contains.
34. The method of claim 33 further comprising transmitting the second frame via the shared communications medium.
35. The method of claim 33 wherein the virtual network identifier field value consists of an integer number of bytes.
36. The method of claim 35 wherein the virtual network identifier field value is a multiple of four bytes in length.
37. The method of claim 36 wherein the virtual network identifier field value is four bytes in length.
38. The method of claim 33 wherein a value of the virtual network identifier length field indicates a length of the virtual network identifier field value.
39. The method of claim 38 wherein the second data frame further comprises a virtual network identifier type field having a corresponding value indicating a type of the virtual network identifier field value, wherein the second frame is configured such that the virtual network identifier type field will be transmitted after the type field and before the virtual network identifier length field.
40. The method of claim 33 wherein producing the second data frame includes determining the virtual network identifier field value in accordance with at least one rule.
41. The method of claim 40 wherein determining the virtual network identifier field value in accordance with the at least one rule uses at least one of a number of a port through which the first data frame is obtained, a protocol type of the first data frame, a MAC address of the first data frame, a network-layer source address of the first data frame, and a time of day when the first data frame is received.
42. The method of claim 33 wherein the second data frame is produced with the e-type field if the first data frame is an Ethernet frame and is produced with the data length field if the first data frame is an LLC frame.
43. In a network device comprising a first port coupled to a local area network (LAN) and a second port coupled to a shared communications medium, a method of transmitting a data frame associated with the LAN via the second port, the method comprising:
transmitting destination and source media access control addresses,
transmitting a virtual network type field having a value indicating that a virtual network identifier field will be transmitted;
transmitting at least one of a virtual network identifier type field and a virtual network identifier length field, a value of the virtual network identifier type field indicating a type of the virtual network identifier field, and a value of the virtual network identifier length field indicating a length of the virtual network identifier field; and
transmitting the virtual network identifier field having a value associated with the LAN.
44. The method of claim 43 wherein transmitting at least one of a virtual network identifier type field and a virtual network identifier length field includes transmitting both the virtual network identifier type field and the virtual network identifier length field.
45. The method of claim 44 wherein the transmitting occurs in an order of: destination media access control address, source media access control address, virtual network type field, virtual network identifier type field, virtual network identifier length field, and virtual network identifier field.
46. The method of claim 45 further comprising transmitting a data field.
47. The method of claim 46 wherein transmitting the data field occurs after transmitting the virtual network identifier field.
48. The method of claim 47 further comprising transmitting either an e-type field or a data length field having a corresponding value indicative of a protocol type or a length of the data field, respectively.
49. The method of claim 48 wherein transmitting whichever of the e-type field or the data length field occurs after transmitting the virtual network identifier field and before transmitting the data field.
50. A network device comprising:
a first port configured to be coupled to a local area network (LAN);
a second port configured to be coupled to a shared communications medium;
a processing unit configured to receive a first data frame via the first port, the first data frame including a destination address field, a source address field, either an e-type field or a data length field having a corresponding value indicating a protocol type or a length of a data field, respectively, and the data field, the processing unit being further configured to produce a second data frame and transmit the second data frame via the second port, the second data frame including the destination address field, the source address field, a virtual network type field having a value indicating that the second data frame includes a virtual network identifier field, at least one of a virtual network identifier type field and a virtual network identifier length field, the virtual network identifier field, whichever of the e-type field or the data length field was received, and the data field, the virtual network identifier field having a value indicative of the LAN, the virtual network identifier type field having a value indicating a type of the virtual network identifier field and the virtual network identifier length field having a value indicating a length of the virtual network identifier field.
51. The network device of claim 50 wherein the second data frame includes both the virtual network identifier type field and the virtual network identifier length field.
52. The network device of claim 51 wherein the processing unit is configured to transmit components of the second data frame in an order of: virtual network type field, virtual network identifier type field, virtual network identifier length field, and virtual network identifier field.
53. The network device of claim 51 wherein the control unit is configured to transmit components of the second data frame in an order of: destination address, source address, virtual network type field, virtual network identifier type field, virtual network identifier length field, virtual network identifier field, whichever of the e-type field or the length field that the second data frame contains, and data field.
54. The network device of claim 50 wherein the processing unit is configured to produce the second data frame by determining the virtual network identifier field in accordance with at least one rule.
55. The network device of claim 54 wherein determining the virtual network identifier field in accordance with the at least one rule uses at least one of a number of the first port, a protocol type of the first data frame, a MAC address of the first data frame, a network-layer source address of the first data frame, and a time of day when the first data frame is received.
56. The network device of claim 50 wherein the processing unit is configured to produce the second data frame with the e-type field if the first data frame is a type-encoded frame and to produce the second data frame with the data length field if the first data frame is a length-encoded frame.
57. A method of identifying a virtual network associated with a data frame transmitted between a communications medium and a shared communications medium, the method comprising:
a) obtaining a first data frame from the communications medium, the first data frame comprising a data field and either an e-type field or a data length field having a corresponding value indicating a protocol or a length of the data field, respectively; and
b) producing a second data frame using the first data frame, the second 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 second data frame is associated with the virtual network, and the virtual network identifier field having a virtual network identifier field value corresponding to the virtual network.
58. The method of claim 57 further comprising obtaining the virtual network identifier field value dynamically.
59. The method of claim 58 wherein the virtual network identifier field value is obtained from a network-wide authority.
60. The method of claim 59 wherein the network-wide authority is a network administrator.
61. The method of claim 57 wherein the virtual network identifier field has one of a plurality of formats, and wherein the type field value further indicates which of the plurality of formats the virtual network identifier field has.
62. The method of claim 57 wherein the at least one other field includes a plurality of other fields.
63. The method of claim 57 wherein producing the second data frame includes determining the virtual network identifier field value in accordance with at least one rule.
64. The method of claim 63 wherein determining the virtual network identifier field value in accordance with the at least one rule uses at least one of a number of a port through which the first data frame is obtained, a protocol type of the first data frame, a MAC address of the first data frame, a network-layer source address of the first data frame, and a time of day when the first data frame is received.
65. A method of identifying a virtual network associated with a data frame transmitted between a communications medium and a shared communications medium, the method comprising:
a) obtaining a first data frame from the communications medium, the first data frame comprising a data field and either an e-type field or a data length field having a corresponding value indicating a protocol or a length of the data field, respectively; and
b) producing a second data frame using the first data frame, the second data frame comprising a type field, and a virtual network header including a virtual network identifier field, the type field having a value indicating that the second data frame is associated with the virtual network, and the virtual network identifier field having a virtual network identifier field value corresponding to the virtual network;
wherein the virtual network header has an associated format and the type field value further indicates which of a plurality of formats the associated format is.
66. The method of claim 65 wherein the associated format is a format of the virtual network identifier field value.
67. The method of claim 65 wherein producing the second data frame includes determining the virtual network identifier field value in accordance with at least one rule.
68. The method of claim 67 wherein determining the virtual network identifier field value in accordance with the at least one rule uses at least one of a number of a port through which the first data frame is obtained, a protocol type of the first data frame, a MAC address of the first data frame, a network-layer source address of the first data frame, and a time of day when the first data frame is received.
US10/225,708 1996-03-12 2002-08-22 Vlan frame format Expired - Lifetime USRE40999E1 (en)

Priority Applications (9)

Application Number Priority Date Filing Date Title
US10/225,708 USRE40999E1 (en) 1996-03-12 2002-08-22 Vlan frame format
US12/459,465 USRE44775E1 (en) 1996-03-12 2009-06-30 VLAN frame format
US13/728,846 USRE45095E1 (en) 1996-03-12 2012-12-27 VLAN frame format
US13/728,867 USRE45121E1 (en) 1996-03-12 2012-12-27 VLAN frame format
US13/728,698 USRE45598E1 (en) 1996-03-12 2012-12-27 VLAN frame format
US13/728,838 USRE45708E1 (en) 1996-03-12 2012-12-27 VLAN frame format
US13/728,823 USRE45081E1 (en) 1996-03-12 2012-12-27 VLAN frame format
US13/728,747 USRE45521E1 (en) 1996-03-12 2012-12-27 VLAN frame format
US13/728,787 USRE45065E1 (en) 1996-03-12 2012-12-27 VLAN frame format

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US08/613,726 US5959990A (en) 1996-03-12 1996-03-12 VLAN frame format
US08/705,631 US6111876A (en) 1996-03-12 1996-08-30 VLAN frame format
US10/225,708 USRE40999E1 (en) 1996-03-12 2002-08-22 Vlan frame format

Related Parent Applications (2)

Application Number Title Priority Date Filing Date
US08/613,726 Continuation-In-Part US5959990A (en) 1996-03-12 1996-03-12 VLAN frame format
US08/705,631 Reissue US6111876A (en) 1996-03-12 1996-08-30 VLAN frame format

Related Child Applications (2)

Application Number Title Priority Date Filing Date
US08/705,631 Division US6111876A (en) 1996-03-12 1996-08-30 VLAN frame format
US12/459,465 Division USRE44775E1 (en) 1996-03-12 2009-06-30 VLAN frame format

Publications (1)

Publication Number Publication Date
USRE40999E1 true USRE40999E1 (en) 2009-11-24

Family

ID=41327977

Family Applications (9)

Application Number Title Priority Date Filing Date
US08/705,631 Ceased US6111876A (en) 1996-03-12 1996-08-30 VLAN frame format
US10/225,708 Expired - Lifetime USRE40999E1 (en) 1996-03-12 2002-08-22 Vlan frame format
US12/459,465 Expired - Lifetime USRE44775E1 (en) 1996-03-12 2009-06-30 VLAN frame format
US13/728,823 Expired - Lifetime USRE45081E1 (en) 1996-03-12 2012-12-27 VLAN frame format
US13/728,846 Expired - Lifetime USRE45095E1 (en) 1996-03-12 2012-12-27 VLAN frame format
US13/728,698 Expired - Lifetime USRE45598E1 (en) 1996-03-12 2012-12-27 VLAN frame format
US13/728,747 Expired - Lifetime USRE45521E1 (en) 1996-03-12 2012-12-27 VLAN frame format
US13/728,867 Expired - Lifetime USRE45121E1 (en) 1996-03-12 2012-12-27 VLAN frame format
US13/728,787 Expired - Lifetime USRE45065E1 (en) 1996-03-12 2012-12-27 VLAN frame format

Family Applications Before (1)

Application Number Title Priority Date Filing Date
US08/705,631 Ceased US6111876A (en) 1996-03-12 1996-08-30 VLAN frame format

Family Applications After (7)

Application Number Title Priority Date Filing Date
US12/459,465 Expired - Lifetime USRE44775E1 (en) 1996-03-12 2009-06-30 VLAN frame format
US13/728,823 Expired - Lifetime USRE45081E1 (en) 1996-03-12 2012-12-27 VLAN frame format
US13/728,846 Expired - Lifetime USRE45095E1 (en) 1996-03-12 2012-12-27 VLAN frame format
US13/728,698 Expired - Lifetime USRE45598E1 (en) 1996-03-12 2012-12-27 VLAN frame format
US13/728,747 Expired - Lifetime USRE45521E1 (en) 1996-03-12 2012-12-27 VLAN frame format
US13/728,867 Expired - Lifetime USRE45121E1 (en) 1996-03-12 2012-12-27 VLAN frame format
US13/728,787 Expired - Lifetime USRE45065E1 (en) 1996-03-12 2012-12-27 VLAN frame format

Country Status (1)

Country Link
US (9) US6111876A (en)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7953089B1 (en) * 2006-05-16 2011-05-31 Cisco Technology, Inc. Systems and methods for multicast switching in a private VLAN
USRE45065E1 (en) * 1996-03-12 2014-08-05 Rockstar Consortium Us Lp VLAN frame format
US20150098474A1 (en) * 2013-10-07 2015-04-09 Dell Products L.P. System and method for managing vlan associations with network ports
USRE45708E1 (en) * 1996-03-12 2015-09-29 Spherix Incorporated VLAN frame format
US9906499B1 (en) 2013-09-11 2018-02-27 Talati Family LP Apparatus, system and method for secure data exchange
US20210271748A1 (en) * 2016-08-03 2021-09-02 Hewlett-Packard Development Company, L.P. Digitally signed data

Families Citing this family (114)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6370142B1 (en) * 1995-07-12 2002-04-09 Nortel Networks Limited Method and apparatus for performing per-port IP multicast pruning
US6347089B1 (en) * 1997-07-02 2002-02-12 Advanced Communication Devices Corp. Simplified ethernet frame switching system architecture without local buffer requirement
CA2217275C (en) * 1997-10-03 2005-08-16 Newbridge Networks Corporation Multiple internetworking realms within an internetworking device
US6469987B1 (en) * 1998-01-13 2002-10-22 Enterasys Networks, Inc. Virtual local area network with trunk stations
US6301224B1 (en) * 1998-01-13 2001-10-09 Enterasys Networks, Inc. Network switch with panic mode
US6112251A (en) 1998-01-13 2000-08-29 Cabletron Systems, Inc. Virtual local network for sending multicast transmissions to trunk stations
US6266705B1 (en) * 1998-09-29 2001-07-24 Cisco Systems, Inc. Look up mechanism and associated hash table for a network switch
US6526052B1 (en) 1998-12-23 2003-02-25 Enterasys Networks, Inc. Virtual local area networks having rules of precedence
US7146354B1 (en) 1999-06-18 2006-12-05 F5 Networks, Inc. Method and system for network load balancing with a compound data structure
US6405219B2 (en) 1999-06-22 2002-06-11 F5 Networks, Inc. Method and system for automatically updating the version of a set of files stored on content servers
US6374300B2 (en) 1999-07-15 2002-04-16 F5 Networks, Inc. Method and system for storing load balancing information with an HTTP cookie
US7287084B1 (en) 1999-07-15 2007-10-23 F5 Networks, Inc. Enabling encryption of application level persistence between a server and a client
US7346695B1 (en) 2002-10-28 2008-03-18 F5 Networks, Inc. System and method for performing application level persistence
US6532225B1 (en) * 1999-07-27 2003-03-11 At&T Corp Medium access control layer for packetized wireless systems
US7441045B2 (en) * 1999-12-13 2008-10-21 F5 Networks, Inc. Method and system for balancing load distribution on a wide area network
JP2001211190A (en) * 2000-01-25 2001-08-03 Hitachi Ltd Device and method for managing communication
US7047301B2 (en) * 2000-01-31 2006-05-16 F5 Networks, Inc. Method and system for enabling persistent access to virtual servers by an LDNS server
US8380854B2 (en) 2000-03-21 2013-02-19 F5 Networks, Inc. Simplified method for processing multiple connections from the same client
US7343413B2 (en) * 2000-03-21 2008-03-11 F5 Networks, Inc. Method and system for optimizing a network by independently scaling control segments and data flow
US7200145B1 (en) 2000-05-22 2007-04-03 Cisco Technology, Inc. Private VLANs
US6741592B1 (en) * 2000-05-22 2004-05-25 Cisco Technology, Inc. Private VLANs
US6765869B2 (en) * 2000-12-21 2004-07-20 At&T Wireless Services, Inc. Medium access dynamic congestion control mechanism for wireless data
US6765870B2 (en) * 2000-12-21 2004-07-20 At&T Wireless Services, Inc. Medium access dynamic congestion control mechanism for wireless data
US6618388B2 (en) * 2001-01-05 2003-09-09 Extreme Networks Method and system for VMAN protocol
US20020167950A1 (en) * 2001-01-12 2002-11-14 Zarlink Semiconductor V.N. Inc. Fast data path protocol for network switching
US7450595B1 (en) * 2001-05-01 2008-11-11 At&T Corp. Method and system for managing multiple networks over a set of ports
US20030235191A1 (en) * 2002-06-19 2003-12-25 Heggarty Jonathan W. VLAN inheritance
JP2004080323A (en) * 2002-08-16 2004-03-11 Fujitsu Ltd Lan switching method and lan switch
US7430755B1 (en) 2002-09-03 2008-09-30 Fs Networks, Inc. Method and system for providing persistence in a secure network access
US7133915B2 (en) * 2002-10-10 2006-11-07 International Business Machines Corporation Apparatus and method for offloading and sharing CPU and RAM utilization in a network of machines
FR2851865B1 (en) * 2003-02-28 2005-05-06 Quadrillium Sarl PLESIOCHRONES DIGITAL DATA TRAIN TRANSMISSION SYSTEM
US7706363B1 (en) 2003-06-11 2010-04-27 Radlan Computer Communications, Ltd Method and apparatus for managing packets in a packet switched network
JP4587446B2 (en) * 2003-08-07 2010-11-24 キヤノン株式会社 NETWORK SYSTEM, SWITCH DEVICE, ROUTE MANAGEMENT SERVER, ITS CONTROL METHOD, COMPUTER PROGRAM, AND COMPUTER-READABLE STORAGE MEDIUM
FR2867642B1 (en) * 2004-03-09 2006-08-18 Cit Alcatel DEVICE AND METHOD FOR PROCESSING MULTIPROTOCOLAR FIELD FRAMES FOR A COMMUNICATIONS NETWORK
US20060088163A1 (en) * 2004-10-25 2006-04-27 Carmichael Richard D Integrated circuit capable of pre-descrambling a portion of a frame
US7680053B1 (en) 2004-10-29 2010-03-16 Marvell International Ltd. Inter-device flow control
US8464299B1 (en) 2004-11-17 2013-06-11 Rockstar Consortium Us Lp Resource conservation for packet television services
US7710966B1 (en) 2005-07-19 2010-05-04 Google Inc. Distributing packets more evenly over trunked network links
US8189599B2 (en) * 2005-08-23 2012-05-29 Rpx Corporation Omni-protocol engine for reconfigurable bit-stream processing in high-speed networks
US7633956B1 (en) * 2006-01-19 2009-12-15 Cisco Technology, Inc. System and method for providing support for multipoint L2VPN services in devices without local bridging
US8924524B2 (en) 2009-07-27 2014-12-30 Vmware, Inc. Automated network configuration of virtual machines in a virtual lab data environment
US8892706B1 (en) 2010-06-21 2014-11-18 Vmware, Inc. Private ethernet overlay networks over a shared ethernet in a virtual environment
US8619771B2 (en) 2009-09-30 2013-12-31 Vmware, Inc. Private allocated networks over shared communications infrastructure
US8566452B1 (en) 2006-08-03 2013-10-22 F5 Networks, Inc. Intelligent HTTP based load-balancing, persistence, and application traffic management of SSL VPN tunnels
WO2008021372A2 (en) * 2006-08-11 2008-02-21 Slt Logic Llc Enhanced ethernet protocol for shortened data frames within a constrained neighborhood based on unique id
US8379638B2 (en) * 2006-09-25 2013-02-19 Certes Networks, Inc. Security encapsulation of ethernet frames
US8806053B1 (en) 2008-04-29 2014-08-12 F5 Networks, Inc. Methods and systems for optimizing network traffic using preemptive acknowledgment signals
US8195774B2 (en) 2008-05-23 2012-06-05 Vmware, Inc. Distributed virtual switch for virtualized computer systems
US7975025B1 (en) 2008-07-08 2011-07-05 F5 Networks, Inc. Smart prefetching of data over a network
US8566444B1 (en) 2008-10-30 2013-10-22 F5 Networks, Inc. Methods and system for simultaneous multiple rules checking
US10157280B2 (en) 2009-09-23 2018-12-18 F5 Networks, Inc. System and method for identifying security breach attempts of a website
US8868961B1 (en) 2009-11-06 2014-10-21 F5 Networks, Inc. Methods for acquiring hyper transport timing and devices thereof
US9313047B2 (en) 2009-11-06 2016-04-12 F5 Networks, Inc. Handling high throughput and low latency network data packets in a traffic management device
US10721269B1 (en) 2009-11-06 2020-07-21 F5 Networks, Inc. Methods and system for returning requests with javascript for clients before passing a request to a server
US8819161B1 (en) 2010-01-18 2014-08-26 Marvell International Ltd. Auto-syntonization and time-of-day synchronization for master-slave physical layer devices
US9141625B1 (en) 2010-06-22 2015-09-22 F5 Networks, Inc. Methods for preserving flow state during virtual machine migration and devices thereof
US10015286B1 (en) 2010-06-23 2018-07-03 F5 Networks, Inc. System and method for proxying HTTP single sign on across network domains
US8908545B1 (en) 2010-07-08 2014-12-09 F5 Networks, Inc. System and method for handling TCP performance in network access with driver initiated application tunnel
US8347100B1 (en) 2010-07-14 2013-01-01 F5 Networks, Inc. Methods for DNSSEC proxying and deployment amelioration and systems thereof
US9083760B1 (en) 2010-08-09 2015-07-14 F5 Networks, Inc. Dynamic cloning and reservation of detached idle connections
US8630174B1 (en) 2010-09-14 2014-01-14 F5 Networks, Inc. System and method for post shaping TCP packetization
US8463909B1 (en) 2010-09-15 2013-06-11 F5 Networks, Inc. Systems and methods for managing server resources
US8886981B1 (en) 2010-09-15 2014-11-11 F5 Networks, Inc. Systems and methods for idle driven scheduling
US8804504B1 (en) 2010-09-16 2014-08-12 F5 Networks, Inc. System and method for reducing CPU load in processing PPP packets on a SSL-VPN tunneling device
US8959571B2 (en) 2010-10-29 2015-02-17 F5 Networks, Inc. Automated policy builder
EP2633667B1 (en) 2010-10-29 2017-09-06 F5 Networks, Inc System and method for on the fly protocol conversion in obtaining policy enforcement information
US8627467B2 (en) 2011-01-14 2014-01-07 F5 Networks, Inc. System and method for selectively storing web objects in a cache memory based on policy decisions
US10135831B2 (en) 2011-01-28 2018-11-20 F5 Networks, Inc. System and method for combining an access control system with a traffic management system
US9246819B1 (en) 2011-06-20 2016-01-26 F5 Networks, Inc. System and method for performing message-based load balancing
US9270766B2 (en) 2011-12-30 2016-02-23 F5 Networks, Inc. Methods for identifying network traffic characteristics to correlate and manage one or more subsequent flows and devices thereof
US10230566B1 (en) 2012-02-17 2019-03-12 F5 Networks, Inc. Methods for dynamically constructing a service principal name and devices thereof
US9231879B1 (en) 2012-02-20 2016-01-05 F5 Networks, Inc. Methods for policy-based network traffic queue management and devices thereof
US9172753B1 (en) 2012-02-20 2015-10-27 F5 Networks, Inc. Methods for optimizing HTTP header based authentication and devices thereof
EP2853074B1 (en) 2012-04-27 2021-03-24 F5 Networks, Inc Methods for optimizing service of content requests and devices thereof
US9525632B1 (en) 2012-05-01 2016-12-20 F5 Networks, Inc. Minimize recycle SYN issues for split TCP hot flows to improve system reliability and performance
US9338095B2 (en) 2012-05-01 2016-05-10 F5 Networks, Inc. Data flow segment optimized for hot flows
US9154423B1 (en) 2012-05-01 2015-10-06 F5 Networks, Inc. Minimize SYN-flood issues with flow cache while maintaining performance
US8811409B2 (en) * 2012-06-04 2014-08-19 Telefonaktiebolaget L M Ericsson (Publ) Routing VLAN tagged packets to far end addresses of virtual forwarding instances using separate administrations
US9203771B1 (en) 2012-07-23 2015-12-01 F5 Networks, Inc. Hot service flow hardware offloads based on service priority and resource usage
US10375155B1 (en) 2013-02-19 2019-08-06 F5 Networks, Inc. System and method for achieving hardware acceleration for asymmetric flow connections
US9350657B2 (en) 2013-07-08 2016-05-24 Nicira, Inc. Encapsulating data packets using an adaptive tunnelling protocol
CN103326889B (en) * 2013-07-18 2016-06-08 迈普通信技术股份有限公司 Communicate between a kind of new and old edition compatible method and device
US9485185B2 (en) 2013-09-24 2016-11-01 Nicira, Inc. Adjusting connection validating control signals in response to changes in network traffic
US10187317B1 (en) 2013-11-15 2019-01-22 F5 Networks, Inc. Methods for traffic rate control and devices thereof
US10015143B1 (en) 2014-06-05 2018-07-03 F5 Networks, Inc. Methods for securing one or more license entitlement grants and devices thereof
US9742881B2 (en) 2014-06-30 2017-08-22 Nicira, Inc. Network virtualization using just-in-time distributed capability for classification encoding
US11838851B1 (en) 2014-07-15 2023-12-05 F5, Inc. Methods for managing L7 traffic classification and devices thereof
US10122630B1 (en) 2014-08-15 2018-11-06 F5 Networks, Inc. Methods for network traffic presteering and devices thereof
US10182013B1 (en) 2014-12-01 2019-01-15 F5 Networks, Inc. Methods for managing progressive image delivery and devices thereof
US11895138B1 (en) 2015-02-02 2024-02-06 F5, Inc. Methods for improving web scanner accuracy and devices thereof
US10834065B1 (en) 2015-03-31 2020-11-10 F5 Networks, Inc. Methods for SSL protected NTLM re-authentication and devices thereof
US11350254B1 (en) 2015-05-05 2022-05-31 F5, Inc. Methods for enforcing compliance policies and devices thereof
US10505818B1 (en) 2015-05-05 2019-12-10 F5 Networks. Inc. Methods for analyzing and load balancing based on server health and devices thereof
US11757946B1 (en) 2015-12-22 2023-09-12 F5, Inc. Methods for analyzing network traffic and enforcing network policies and devices thereof
US10404698B1 (en) 2016-01-15 2019-09-03 F5 Networks, Inc. Methods for adaptive organization of web application access points in webtops and devices thereof
US10797888B1 (en) 2016-01-20 2020-10-06 F5 Networks, Inc. Methods for secured SCEP enrollment for client devices and devices thereof
US11178150B1 (en) 2016-01-20 2021-11-16 F5 Networks, Inc. Methods for enforcing access control list based on managed application and devices thereof
US10791088B1 (en) 2016-06-17 2020-09-29 F5 Networks, Inc. Methods for disaggregating subscribers via DHCP address translation and devices thereof
US11063758B1 (en) 2016-11-01 2021-07-13 F5 Networks, Inc. Methods for facilitating cipher selection and devices thereof
US10505792B1 (en) 2016-11-02 2019-12-10 F5 Networks, Inc. Methods for facilitating network traffic analytics and devices thereof
US11496438B1 (en) 2017-02-07 2022-11-08 F5, Inc. Methods for improved network security using asymmetric traffic delivery and devices thereof
US10791119B1 (en) 2017-03-14 2020-09-29 F5 Networks, Inc. Methods for temporal password injection and devices thereof
US10812266B1 (en) 2017-03-17 2020-10-20 F5 Networks, Inc. Methods for managing security tokens based on security violations and devices thereof
US10931662B1 (en) 2017-04-10 2021-02-23 F5 Networks, Inc. Methods for ephemeral authentication screening and devices thereof
US10972453B1 (en) 2017-05-03 2021-04-06 F5 Networks, Inc. Methods for token refreshment based on single sign-on (SSO) for federated identity environments and devices thereof
US11122042B1 (en) 2017-05-12 2021-09-14 F5 Networks, Inc. Methods for dynamically managing user access control and devices thereof
US11343237B1 (en) 2017-05-12 2022-05-24 F5, Inc. Methods for managing a federated identity environment using security and access control data and devices thereof
US10637800B2 (en) 2017-06-30 2020-04-28 Nicira, Inc Replacement of logical network addresses with physical network addresses
US10681000B2 (en) 2017-06-30 2020-06-09 Nicira, Inc. Assignment of unique physical network addresses for logical network addresses
US11122083B1 (en) 2017-09-08 2021-09-14 F5 Networks, Inc. Methods for managing network connections based on DNS data and network policies and devices thereof
US11658995B1 (en) 2018-03-20 2023-05-23 F5, Inc. Methods for dynamically mitigating network attacks and devices thereof
US11044200B1 (en) 2018-07-06 2021-06-22 F5 Networks, Inc. Methods for service stitching using a packet header and devices thereof
US11095545B2 (en) 2019-10-22 2021-08-17 Vmware, Inc. Control packet management
KR20230097717A (en) * 2021-12-24 2023-07-03 삼성전자주식회사 Electronic apparatus and controlling method thereof

Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5220564A (en) * 1990-09-06 1993-06-15 Ncr Corporation Transmission control for a wireless local area network station
US5394402A (en) * 1993-06-17 1995-02-28 Ascom Timeplex Trading Ag Hub for segmented virtual local area network with shared media access
US5560038A (en) * 1994-07-22 1996-09-24 Network Peripherals, Inc. Apparatus for translating frames of data transferred between heterogeneous local area networks
US5583862A (en) * 1995-03-28 1996-12-10 Bay Networks, Inc. Method and apparatus for routing for virtual networks
US5617421A (en) * 1994-06-17 1997-04-01 Cisco Systems, Inc. Extended domain computer network using standard links
US5684800A (en) * 1995-11-15 1997-11-04 Cabletron Systems, Inc. Method for establishing restricted broadcast groups in a switched network
US5740171A (en) * 1996-03-28 1998-04-14 Cisco Systems, Inc. Address translation mechanism for a high-performance network switch
US5742604A (en) * 1996-03-28 1998-04-21 Cisco Systems, Inc. Interswitch link mechanism for connecting high-performance network switches
US5764636A (en) * 1996-03-28 1998-06-09 Cisco Technology, Inc. Color blocking logic mechanism for a high-performance network switch

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
IT1211803B (en) * 1987-09-25 1989-11-03 Castellammare Di Stabia Napoli EXHAUST PIPE FOR INTERNAL COMBUSTION ENGINES EQUIPPED WITH FILTER HOUSING DEVICE FOR THE ABATEMENT OF SUSPENDED SOLID PARTICLES AND HYDROCARBONS INCOMBUSED IN THE EXHAUST GAS
FI92361C (en) * 1992-12-14 1994-10-25 Nokia Telecommunications Oy Procedure for controlling overload situations in a frame switching network and a node for a frame switching network
US6035105A (en) * 1996-01-02 2000-03-07 Cisco Technology, Inc. Multiple VLAN architecture system
US6111876A (en) * 1996-03-12 2000-08-29 Nortel Networks Limited VLAN frame format
US5959990A (en) * 1996-03-12 1999-09-28 Bay Networks, Inc. VLAN frame format
KR100904433B1 (en) * 2008-01-07 2009-06-24 엘지전자 주식회사 A method for scheduling of distributed virtual resource blocks
US8451819B2 (en) * 2008-03-26 2013-05-28 Qualcomm Incorporated Methods and apparatus for uplink frame synchronization in a subscriber station

Patent Citations (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5220564A (en) * 1990-09-06 1993-06-15 Ncr Corporation Transmission control for a wireless local area network station
US5394402A (en) * 1993-06-17 1995-02-28 Ascom Timeplex Trading Ag Hub for segmented virtual local area network with shared media access
US5617421A (en) * 1994-06-17 1997-04-01 Cisco Systems, Inc. Extended domain computer network using standard links
US5560038A (en) * 1994-07-22 1996-09-24 Network Peripherals, Inc. Apparatus for translating frames of data transferred between heterogeneous local area networks
US5583862A (en) * 1995-03-28 1996-12-10 Bay Networks, Inc. Method and apparatus for routing for virtual networks
US5684800A (en) * 1995-11-15 1997-11-04 Cabletron Systems, Inc. Method for establishing restricted broadcast groups in a switched network
US5946308A (en) * 1995-11-15 1999-08-31 Cabletron Systems, Inc. Method for establishing restricted broadcast groups in a switched network
US5740171A (en) * 1996-03-28 1998-04-14 Cisco Systems, Inc. Address translation mechanism for a high-performance network switch
US5742604A (en) * 1996-03-28 1998-04-21 Cisco Systems, Inc. Interswitch link mechanism for connecting high-performance network switches
US5764636A (en) * 1996-03-28 1998-06-09 Cisco Technology, Inc. Color blocking logic mechanism for a high-performance network switch

Non-Patent Citations (16)

* Cited by examiner, † Cited by third party
Title
Alantec, Intelligent Switching Hubs, "An Efficient Frame-Tagging Format for VLANs", IEEE 802.1 Meeting: Jan. 24-25, 1996: John Wakerly: Efficient Frame-Tagging for VLANs, 7 pages.
Alantec, Intelligent Switching Hubs, "Forwarding Methods for VLAN-Tagged Frames in a Bridged LAN", IEEE 802.1 Meeting: Jan. 24-25, 1996: John Wakely: Efficient Frame-Tagging for VLANs.
Alantec, Intelligent Switching Hubs, "Some VLAN Styles", IEEE 802.1 Meeting: Oct. 11-13, 1995: John Wakerly: Some VLAN Styles.
Brief Minutes of 802.1-Maui, Jul. 1995, 41 pages.
Draft Recommended Practice 802.1H, "Media Access Control (MAC) Bridging of Ethernet V2.0 in 802 Local Area Networks," pp. 1-22, Jul. 7, 1994. *
International Standard ISO/IEC 8802-3, ANS/IEEE Std. 802.3, Fourth Edition, 1993, "Information Technology-Local Metropolitan Area Networks", Part 3, pp. 41-43.
Local and Metropolitan Area Networks 802.10 Supplements, "IEEE Standards-Secure Data Exchange (SDE) Sublayer Management (Subclause 28) and Recommended Practice for SDE on Ethernet V2.0 in IEEE 802 LANS (Annex 2H)," May 19, 1994. *
Local and Metropolitan Area Networks 802.10 Supplements, "Interoperable LAN/MAN Security (SILS)-Currently Contains Secure Data Exchange (SDE) (Clause 2)," Feb. 5, 1993. *
Minutes from 802.1 Interim Meeting, Jun. 1996, Wakefield, MA, 4 pages.
Minutes from 802.1 Plenary Meeting, Mar. 11, 1996, LaJolla, CA, & Plenary Meeting, Mar. 13, 1996, 8 pages.
Minutes from IEEE 802.1 (unofficial) VLAN meeting, Jan. 24-25, 1996, 2 pages.
Norman W. Finn, "Two Models for VLAN Tagging", Mar. 8, 1996, 5 pages.
Notes on the Short Tag breakout session Thursday afternoon Jan. 25, 1996, 3 pages.
Notes on the 'Short Tag' breakout session Thursday afternoon, Jan. 25, 1996, 2 pages.
Steven E. Horowitz, editor, "Dancing Bears", IEEE 802.1 Virtual LANs, May 28, 1996, 51 pages.
The Ethernet Specification, Data Link Layer and Physical Layer, Version 2.0, Nov. 1982, pp. 27-80.

Cited By (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
USRE45708E1 (en) * 1996-03-12 2015-09-29 Spherix Incorporated VLAN frame format
USRE45598E1 (en) * 1996-03-12 2015-06-30 Spherix Incorporated VLAN frame format
USRE45065E1 (en) * 1996-03-12 2014-08-05 Rockstar Consortium Us Lp VLAN frame format
USRE45081E1 (en) * 1996-03-12 2014-08-19 Rockstar Consortium Us Lp VLAN frame format
USRE45095E1 (en) * 1996-03-12 2014-08-26 Rockstar Consortium Us Lp VLAN frame format
USRE45121E1 (en) * 1996-03-12 2014-09-09 Rockstar Consortium Us Lp VLAN frame format
USRE45521E1 (en) * 1996-03-12 2015-05-19 Spherix Incorporated VLAN frame format
US7953089B1 (en) * 2006-05-16 2011-05-31 Cisco Technology, Inc. Systems and methods for multicast switching in a private VLAN
US8625603B1 (en) 2006-05-16 2014-01-07 Cisco Technology, Inc. Systems and methods for multicast switching in a private VLAN
US9906499B1 (en) 2013-09-11 2018-02-27 Talati Family LP Apparatus, system and method for secure data exchange
US20150098474A1 (en) * 2013-10-07 2015-04-09 Dell Products L.P. System and method for managing vlan associations with network ports
US9929880B2 (en) * 2013-10-07 2018-03-27 Dell Products L.P. System and method for managing VLAN associations with network ports
US20210271748A1 (en) * 2016-08-03 2021-09-02 Hewlett-Packard Development Company, L.P. Digitally signed data
US11783023B2 (en) * 2016-08-03 2023-10-10 Hewlett-Packard Development Company, L.P. Digitally signed data

Also Published As

Publication number Publication date
USRE45081E1 (en) 2014-08-19
USRE45065E1 (en) 2014-08-05
USRE45521E1 (en) 2015-05-19
USRE45121E1 (en) 2014-09-09
USRE45598E1 (en) 2015-06-30
USRE44775E1 (en) 2014-02-25
USRE45095E1 (en) 2014-08-26
US6111876A (en) 2000-08-29

Similar Documents

Publication Publication Date Title
USRE40999E1 (en) Vlan frame format
USRE45708E1 (en) VLAN frame format
EP0861544B1 (en) Method for establishing restricted broadcast groups in a switched network
US6430621B1 (en) System using different tag protocol identifiers to distinguish between multiple virtual local area networks
US6157647A (en) Direct addressing between VLAN subnets
US6172981B1 (en) Method and system for distributing network routing functions to local area network stations
CA2256698C (en) Connection aggregation in switched communications networks
US7154889B1 (en) Peer-model support for virtual private networks having potentially overlapping addresses
US7369556B1 (en) Router for virtual private network employing tag switching
US5600644A (en) Method and apparatus for interconnecting LANs
Cisco Transparent Bridging Commands
Cisco Transparent Bridging Commands
Cisco Transparent Bridging Commands
Cisco Transparent Bridging Commands
Cisco Transparent Bridging Commands
Cisco Transparent Bridging Commands
Cisco Transparent Bridging Commands
Cisco Transparent Bridging Commands
Cisco Transparent Bridging Commands
Cisco Transparent Bridging Commands
Cisco Transparent Bridging Commands
Cisco Transparent Bridging Commands
Cisco Transparent Bridging Commands
Cisco Transparent Bridging Commands
Cisco Transparent Bridging Commands

Legal Events

Date Code Title Description
FEPP Fee payment procedure

Free format text: PAYOR NUMBER ASSIGNED (ORIGINAL EVENT CODE: ASPN); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

AS Assignment

Owner name: NORTEL NETWORKS LIMITED, CANADA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:FRANTZ, PAUL J.;THOMPSON, GEOFFREY O.;SIGNING DATES FROM 20000704 TO 20000731;REEL/FRAME:026132/0360

AS Assignment

Owner name: ROCKSTAR BIDCO, LP, NEW YORK

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:NORTEL NETWORKS LIMITED;REEL/FRAME:027143/0717

Effective date: 20110729

FPAY Fee payment

Year of fee payment: 12

AS Assignment

Owner name: ROCKSTAR CONSORTIUM US LP, TEXAS

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:ROCKSTAR BIDCO, LP;REEL/FRAME:029496/0948

Effective date: 20120509

CC Certificate of correction
AS Assignment

Owner name: SPHERIX PORTFOLIO ACQUISITION II, INC., VIRGINIA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:ROCKSTAR CONSORTIUM US LP;REEL/FRAME:032611/0084

Effective date: 20140227

AS Assignment

Owner name: SPHERIX INCORPORATED, MARYLAND

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:SPHERIX PORTFOLIO ACQUISITION II, INC.;REEL/FRAME:035253/0918

Effective date: 20140328

AS Assignment

Owner name: ROCKSTAR CONSORTIUM US LP, TEXAS

Free format text: SECURITY INTEREST;ASSIGNORS:SPHERIX INCORPORATED;SPHERIX PORTFOLIO ACQUISITION II, INC.;REEL/FRAME:035463/0584

Effective date: 20140108

Owner name: RPX CLEARINGHOUSE LLC, CALIFORNIA

Free format text: SECURITY INTEREST;ASSIGNOR:ROCKSTAR CONSORTIUM US LP;REEL/FRAME:035463/0588

Effective date: 20150417

AS Assignment

Owner name: SPHERIX INCOPORATED, MARYLAND

Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:RPX CLEARINGHOUSE LLC;REEL/FRAME:037992/0488

Effective date: 20160225

AS Assignment

Owner name: INTERNATIONAL LICENSE EXCHANGE OF AMERICA, LLC, PE

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:SPHERIX INCORPORATED;REEL/FRAME:038787/0297

Effective date: 20160524