HK1121883B - Method and system for computer networking - Google Patents

Description

System and method for computer networking

Technical Field

The present invention relates to computer networking and, more particularly, to a method and system for tunneling MACSec packets through non-MACSec (media access control security) nodes.

Background

A computer network is a collection of two or more processing nodes that are communicatively connected by a transmission medium for communicating information. Most networks follow the hierarchical structure provided by the Open Systems Interconnection (OSI) reference model. The OSI reference provides a 7-layer structure that includes an application layer (layer 7), a presentation layer (layer 6), a session layer (layer 5), a transport layer (layer 4), a network layer (layer 3), a data link layer (layer 2), and a physical layer (layer 1). Layers 7 through 5, which it encompasses, may comprise upper layer protocols, while layers 4 through 1 may comprise lower layer protocols. Some networks may use a portion of 7 layers. For example, the TCP/IP model or the ethernet reference model generally uses a 5-layer model, which includes an application layer (layer 7), a transport layer (layer 4), a network layer (layer 3), a data link layer (layer 2), and a physical layer (layer 1). These 5 layers can be divided into fairly well-defined task groups or service groups.

Layer 7, the application layer, is typically used to support network applications such as web browsers and email client programs. And it is generally run in software of terminal systems such as personal computers and servers. Typical layer 5 protocols include HTTP to support the world wide web and SMTP to support email.

Layer 6, a presentation layer, is generally used to mark any data format differences that may occur between partially or completely different systems. The presentation layer defines an architecture-independent data transmission format and may enable encoding, decoding, encryption, decryption, compression, and/or decompression of data.

Layer 5, the session layer, is typically used to manage user sessions. In this regard, the session layer may be used to control the establishment and termination of logical links between users. The session layer may also be used to provide upper layer error handling and reporting.

Layer 4, the transport layer, is typically used to transfer application layer information between the client and server sides of an application. In this regard, the transport layer may be used to manage end-to-end transport of messages in the network. The transport layer may include various error recovery and/or flow control mechanisms for providing reliable information transfer. The two most common layer 4 protocols in ethernet to date are the Transmission Control Protocol (TCP) and the User Datagram Protocol (UDP) used in the internet.

Layer 3, the network layer, is generally used to determine how to transfer data between network devices. Data may be transmitted according to a unique network address. In this regard, the network layer may communicate data messages between end systems. Such as the internet protocol, defines the format and content of datagrams and may be implemented in layer 3 in conjunction with any number of routing protocols that may be implemented in different nodes (e.g., routers and bridges, etc.) along the path of datagrams from one end system to another.

Layer 2, the data link layer, is typically used to transfer packets from one node to another. The data link layer defines various steps and mechanisms for running a communication link and may implement framing of data packets, such as within a network. The data link layer may be used for packet error detection and/or correction. The ethernet (IEEE 802.3) protocol is a link layer protocol commonly used in modern computer networks.

Layer 1, the physical layer, is generally used to define physical components, including optical, electrical, and/or mechanical components that use network devices to transmit data over a communication medium through the network devices. The bit stream from layer 2 is converted into a series of physical signals for transmission over the medium. For example, layer 2 technologies (e.g., ethernet) may implement multiple layer 1 protocols depending on whether the signal is carried over twisted pair or air.

At layer 2, today's enterprise networks are based primarily on IEEE 802.3 ethernet technology. While ethernet provides ubiquitous and low-cost network connectivity for enterprises, it is not very effective in controlling access to the network. Although IEEE has attempted to improve access control to wired ethernet using the IEEE 802.1x standard, this standard has not gained widespread acceptance for a variety of reasons. One negative reason for this relates to the fact that IEEE 802.1x cabling is effectively active and follows a one device per port pattern only when the user starts using the network. When more than one device per port mode is supported, there is no acknowledgement for each packet, nor is there any standard method of performing access control. The seller provides only non-standard components for the latter, which are still not realizable.

The IEEE standards 802.1ae, 802.1af and 802.1ar constitute a new architecture for ethernet network access control. These three standards constitute an alternative to existing IEEE 802.1x based access control mechanisms. The IEEE 802.1ae (macsec) standard defines a data link layer encryption and authentication mechanism. 802.1af (currently under development) defines the control panel and keying protocol for 802.1 ae. IEEE 802.1ar (currently under development) defines how networks and devices connected to the networks authenticate and verify each other's identity.

MACSec integrates security in wired ethernet networks by: devices connected to the LAN are identified and classified as authorized and unauthorized devices. Typical identifiable and categorizable network devices include: computers, wireless access points, servers, VOIP phones, routers, switches, bridges, and hubs.

While MACSec may provide better network security and reliability, upgrading existing networks to MACSec-compatible may present problems. In this regard, MACSec thus provides network protection at the data link layer: encrypting data of the ethernet frame, inserting a header (SecTAG) between the source MAC address and the encrypted data, and adding an Integrity Check Value (ICV) after encrypting the data. Thus, since the SecTAG of a MACSec frame occupies the bit positions typically used for one or more Virtual Local Area Network (VLAN) tags in a conventional ethernet frame, network nodes that are not available for MACSec will not be able to process MACSec frames because the SecTAG is not properly resolved as a VLAN tag.

Further limitations and disadvantages of conventional and traditional approaches will become apparent to one of skill in the art, through comparison of such systems with some features of the present invention as set forth in the remainder of the present application with reference to the drawings.

Disclosure of Invention

A system and/or method for tunneling MACSec packets through non-MACSec nodes, substantially as shown in and/or described in connection with at least one of the figures, as set forth more completely in the claims.

According to one aspect of the present invention, there is provided a method for computer networking, comprising:

determining whether a destination of the MACSec packet needs to traverse one or more non-MACSec available network nodes (MACSec enabled network nodes); and

inserting additional header information in the MACSec packet based on the determination to allow the MACSec packet to be identified as passing through the one or more non-MACSec-capable nodes.

Preferably, the method further comprises inserting the additional header information between a source MAC address field of the MACSec packet and a SecTAG.

Preferably, the additional header information comprises one or more VLAN tags.

Preferably, the additional header information includes an ethertype field for identifying the MACSec packet.

Preferably, the method further comprises parsing additional header information inserted into the MACSec packet.

Preferably, the method further comprises identifying an ethertype associated with the parsed additional header information inserted into the MACSec packet.

Preferably, the method further comprises removing the inserted additional header information from between the source MAC address field and the SecTAG field of the MACSec packet based on the ethertype.

Preferably, the method further comprises generating one or more control bits based on the removed additional header information.

Preferably, the method further comprises processing the MACSec packet based on the generated one or more control bits.

Preferably, the method further comprises generating the additional header information inserted into the MACSec packet based on one or more control bits.

Preferably, the MACSec packet including the inserted additional header information is identifiable by a MACSec-capable node.

According to one aspect of the present invention, there is provided a machine readable storage, having stored thereon, a computer program comprising at least one code section for computer networking, the execution of the at least one code section by a machine causes the machine to perform the steps of:

determining whether a destination of the MACSec packet needs to pass through one or more non-MACSec-capable network nodes; and

inserting additional header information in the MACSec packet based on the determination to allow the MACSec packet to be identified as passing through the one or more non-MACSec-capable nodes.

Preferably, said at least one code segment is adapted to insert said additional header information between a source MAC address field of said MACSec packet and a SecTAG.

Preferably, the additional header information comprises one or more VLAN tags.

Preferably, the additional header information includes an ethertype field for identifying the MACSec packet.

Preferably, the at least one code segment is configured to parse additional header information inserted into the MACSec packet.

Preferably, the at least one code segment is configured to identify an ethertype associated with the parsed additional header information inserted into the MACSec packet.

Preferably, said at least one code segment is adapted to remove said inserted additional header information from between a source MAC address field and a SecTAG field of said MAC sec packet based on said ethertype.

Preferably, said at least one code segment is adapted to generate one or more control bits based on said removed additional header information.

Preferably, the at least one code segment is configured to process the MACSec packet based on the generated one or more control bits.

Preferably, the at least one code segment is configured to generate the additional header information inserted into the MACSec packet based on one or more control bits.

Preferably, the MACSec packet including the inserted additional header information is identifiable by a MACSec-capable node.

According to one aspect of the present invention, there is provided a system for computer networking, the system comprising:

at least one processor configured to determine whether a destination of a MACSec packet needs to traverse one or more non-MACSec-capable network nodes; and

the at least one processor configured to insert additional header information in the MACSec packet based on the determination to allow the MACSec packet to be identified when passing through the one or more non-MACSec-capable nodes.

Preferably, the at least one processor is configured to insert the additional header information between a source MAC address field of the MACSec packet and a SecTAG.

Preferably, the additional header information comprises one or more VLAN tags.

Preferably, the additional header information includes an ethertype field for identifying the MACSec packet.

Preferably, the at least one processor is configured to parse additional header information inserted into the MACSec packet.

Preferably, the at least one processor is configured to identify an ethertype associated with the parsed additional header information inserted into the MACSec packet.

Preferably, the at least one processor is configured to remove the inserted additional header information from between the source MAC address field of the MACSec packet and the SecTAG based on the ethertype.

Preferably, the at least one processor is configured to generate one or more control bits based on the removed additional header information.

Preferably, the at least one processor is configured to process the MACSec packet based on the generated one or more control bits.

Preferably, the at least one processor is configured to generate the additional header information inserted into the MACSec packet based on one or more control bits.

Preferably, the MACSec packet including the inserted additional header information is identifiable by a MACSec-capable node.

Various advantages, aspects and novel features of the invention, as well as details of an illustrated embodiment thereof, will be more fully described with reference to the following description and drawings.

Drawings

FIG. 1A is an exemplary diagram of an Ethernet packet according to an embodiment of the invention;

FIG. 1B is an exemplary diagram of a VLAN tagged Ethernet packet according to an embodiment of the present invention;

figure 1C is an exemplary diagram of a MACSec packet according to an embodiment of the present invention;

fig. 1D is an exemplary diagram of a modified MACSec packet for nodes that may be made available through MACSec and non-MACSec in accordance with an embodiment of the present invention;

fig. 2A is an exemplary diagram of a network that may be used to transmit and receive MACSec packets through MACSec and non-MACSec capable nodes in accordance with an embodiment of the present invention;

fig. 2B is an exemplary schematic diagram of a network similar to network 200 including node 250 operable to transmit and receive MACSec packets through MACSec and non-MACSec-enabled nodes in accordance with an embodiment of the present invention;

figure 3 is a flowchart of exemplary steps for delivering a MACSec packet into a network including a MACSec node and a non-MACSec-capable node, in accordance with an embodiment of the present invention;

fig. 4 is a flowchart illustrating exemplary steps for receiving a MACSec packet from a network that includes both MACSec nodes and nodes that are not MACSec-capable, in accordance with an embodiment of the present invention.

Detailed Description

Particular embodiments of the present invention may relate to a method and system for tunneling MACSec packets through non-MACSec network nodes. In this regard, various aspects of the invention may be used to transport MACSec ethernet packets through non-MACSec-capable nodes and MACSec nodes. In one embodiment of the invention, additional header information is inserted in the MACSec packet before the MACSec packet is transmitted to the non-MACSec-capable node. Accordingly, various aspects of the present invention may be used to remove additional header information from packets received from non-MACSec-capable nodes. This flag may include a distinct ethertype in order to distinguish the packet including the insertion of additional header information.

Fig. 1A is an exemplary diagram of an ethernet packet 100a according to an embodiment of the present invention. Referring to fig. 1A, an ethernet packet includes a destination MAC address field 102, a source MAC address field 104, an ethertype field 106, a data field 108, and a Frame Check Sequence (FCS) 110.

The destination MAC address field 102 may include information identifying the node to which the packet is destined. The source MAC address field 104 may include information identifying the node that generated the data packet. The ethertype field 106 may include information for identifying the protocol (e.g., IPv4 or IPv6) being transported in the data packet. The data field 108 may include the data being transferred. The FCS 110 may include information that may be used to provide error detection for a data packet.

In operation, when a packet (e.g., 100a) arrives at a network node, the node may parse one or more fields of the packet to determine an action to be taken with respect to the packet. In this regard, this node may be a network switch, and the network switch may parse the destination MAC address field 102 and the source MAC address field 104 to determine which interface to forward the packet to. Optionally, this node may be an end system and may parse the ethertype field 106 to determine the network layer protocol used to upload the data packet. Typical ethertypes include 0x0800 for internet protocol version 4(IPv4), 0x0806 for Address Resolution Protocol (ARP), and 0x86DD for IPv 6.

Fig. 1B is an exemplary block diagram of a VLAN tagged ethernet packet 100B according to an embodiment of the present invention. Referring to fig. 1B, a VLAN tagged ethernet packet may include a VLAN tag 112 inserted after the source MAC address and before the ethertype field.

VLAN tag 112 may include a VLAN ethertype 114 and a Tag Control Information (TCI) field 116. Ethertype 114 can include a numeric identifier that can be used to identify packets that have been tagged by a VLAN and thus parsed. A typical numeric designator may comprise 0x 8100. The TCI field 116 may include two bytes of information. The information may be used to determine the priority of the data packet, the compatibility of the data packet with ethernet and token ring networks; the information may also include a numerical identifier indicating the VLAN to which the packet belongs.

In this regard, VLAN tagged ethernet packet 100b has a modified structure relative to 100a such that a network node requires a method of identifying the format of the received packet in order to properly parse the packet. VLAN ethertype 114 may thus be used to identify the network node of a packet, which may be a VLAN tagged packet.

Fig. 1C is an exemplary diagram of a MACSec packet 100C according to an embodiment of the invention. Referring to fig. 1C, a MACSec packet 100C may include a security label (SecTAG)118, a security data field 130, and an Integrity Check Value (ICV) 140.

A security tag (SecTAG) may be inserted after the source MAC address field, which may include a MACSec ethertype 120, a TCI/AN field 122, a SL field 124, a number of packets field 126, and a Secure Channel Identifier (SCI) field 128. The MACSec ethertype 120 may include a numeric designator, 0x88E5, which may indicate that the packet is a MACSec packet, which may be parsed accordingly. The TCI/AN field 122 may include a version that may be used to determine the MACSec protocol used in the packet and may also include information for sending the packet over the secure channel. SL field 124 may include information for determining the number of bytes between the last byte of the SecTAG and the first byte of ICV 140. The number of packets field 126 may include a monotonically increasing value to prevent "playback" attacks. SCI field 128 may include information that may be used to identify the source address and port from which the packet is sent.

Source data field 130 may include VLAN tag 132, ethernet type 134, and data field 136. VLAN tag 132 may include similar information as VLAN tag 104 in fig. 1A, except that VLAN tag 132 may be encrypted. Ethertype 134 can include similar information as ethertype 106 in fig. 1A, with the difference that ethertype 134 can be encrypted. Data field 136 may include information similar to data field 108 in fig. 1A, except that data field 136 may be encrypted.

Integrity Check Value (ICV)140 may include information that may be used to check the integrity of data packet 100 c. The FCS 138 may include similar information to the FCS 110 in fig. 1A.

MACSec packet 100c may have a modified structure relative to packets 100a and 100b such that a network node needs a way to identify the format of the received packet in order to properly parse the packet. Thus, the MACSec ethertype 120 may indicate to the network node that the packet is a MACSec packet. However, since the MACSec protocol has only recently been standardized, most of the network hardware deployed in existing networks is incompatible with MACSec. At this point, the hardware may not recognize the MACSec ethertype 120, e.g., 08x88E5, as a valid ethertype, and may not be able to properly parse MACSec packets (e.g., MACSec packet 100 c).

Fig. 1D is an exemplary diagram of a modified MACSec packet 100D for nodes that may be made available through MACSec and non-MACSec in accordance with an embodiment of the present invention. Referring to fig. 1D, the packet may include additional header information 142 inserted after the source MAC address field.

In one embodiment of the present invention, for example, the inserted additional header information 142 may include one or more VLAN tags (e.g., VLAN tag 112) having a 0x8100 ethertype. In this manner, when packet 100d arrives at a non-MACSec-capable network node, the node may resolve the 0x8100 ethertype and treat this packet as a VLAN tagged ethernet packet and may forward this packet accordingly. When a packet arrives at a MACSec-capable network node, this node may resolve the 0x8100 ethertype and treat it as a packet modified to traverse non-MACSec-capable network nodes. Thus, the MACSec-capable network node may strip out the additional header information 142 before further parsing and processing of this MACSec packet.

Fig. 2A is an exemplary diagram of a network that may be used to transmit and receive MACSec packets through MACSec and non-MACSec-capable nodes according to an embodiment of the invention. Referring to fig. 2A, a typical network 200 may include multiple macarec-capable networks 202 and non-macarec-capable networks 204. Each exemplary network 202, 204 of fig. 2A may include a computer 210, a server 212, and a switch 214. Fig. 2 shows transmission paths 220, 222, and 224. Transmission path 220 may communicatively connect network 202a to network 202c through switches 214a and 214 c. Transmission path 222 may communicatively connect network 202a to network 204 through switches 214a and 214 b. Transmission path 224 may communicatively connect network 204 to network 202c through switches 214b and 214 c. Although only three exemplary groups are described, the network may include any number and combination of networks. Each network may thus include any number of computers, servers, switches, routers, hubs, and any other network nodes.

The computer 210 and the server 212 may comprise suitable logic, circuitry, and/or code that may be operable to generate and exchange messages over a network. In this regard, the computer 210 and the server 212 can generate application Layer messages that can be downloaded to a Network Abstraction Layer (Network Abstraction Layer) for transmission over the Network. Similarly, computer 210 and server 212 may be used to receive data from the network, parse the data, and upload it to the network abstraction layer.

Switch 214 may comprise suitable logic, circuitry, and/or code that may be operable to receive an ethernet packet from a network, parse the packet to determine one or more destination nodes for the packet, and forward the packet to one or more nodes in the network. In this regard, switch 214 may perform layer 2 functions for parsing and compressing ethernet data and may also perform layer 1 functions for receiving and transmitting bits of these packets over a physical medium.

In operation, a typical network communication may include the computer 210a generating and sending a message onto the network in the form of one or more MACSec packets destined for the server 212 c. In this exemplary communication, a MACSec packet arriving up switch 214a may select one of two routes to reach server 212 c. The first route (path 220) includes forwarding MACSec packets directly from the MACSec-capable switch 214a to the MACSec-capable switch 214 c. The second route (paths 222 and 224) includes forwarding mac sec packets from the mac sec available switch 214a to the non-mac sec available switch 214b to the mac sec available switch 214 c.

In forwarding one or more mac sec packets between switches 214a and 214c over path 220, aspects of the invention may enable switch 214a to determine that switch 214c is a mac sec-capable node and enable switch 214a to forward the mac sec packets without inserting any additional header information in the packets. In this regard, the data packet transmitted on path 220 may be in the format of data packet 100 c. Thus, various aspects of the invention may use switch 214c to determine that the packet received from switch 214a may be in the format of packet 100c, so switch 214c may parse the packet.

In forwarding one or more mac sec packets between switches 214a and 214c via paths 222 and 224, aspects of the present invention may use switch 214a to determine that switch 214b is a non-mac sec-capable switch and may cause switch 214a to insert additional header information (e.g., header information 142 disclosed in fig. 1D) into the packet prior to forwarding the packet to switch 214 b. At this point, the packet transmitted from switch 214a to switch 214c via paths 222 and 224 is in the format of packet 100 d. Accordingly, aspects of the present invention enable switch 214c to determine that the packet received from switch 214b is in the format of packet 100 d. In this regard, aspects of the present invention may use switch 214c to strip out additional header information of packets received from switch 214b prior to further parsing and processing the packets. In an exemplary embodiment of the invention, the additional header information may include one or more VLAN tags.

Figure 2B is an exemplary diagram of a network similar to network 200 including node 250, where node 250 may be used to transmit and receive MACSec packets, according to an embodiment of the present invention. In this regard, node 250 may be considered a switch (e.g., switch 214 disclosed in FIG. 2A). Referring to fig. 2B, a typical node 250 may include a memory 252, a network interface hardware driver 254, and a processor 256.

The memory 252 may comprise suitable logic, circuitry, and/or code that may be operable to store information for processing a data packet. In this regard, the memory 252 may include one or more lookup tables/databases for determining whether a network node is MACSec compatible; one or more look-up tables/databases for determining the insertion of additional header information in the MACSec packet; and for generating one or more control bits for use by processor 256 in processing and forwarding the data packets.

The NIHW device 254 may comprise suitable logic, circuitry, and/or code that may be operable to receive and/or transmit data packets in a network. In this regard, the NIHW device 254 may be used to receive and transmit bits on a physical medium and may be used to transmit the received bits to the processor 256 and/or the memory 252.

The processor 256 may comprise suitable logic, circuitry, and/or code and may be operable to enable the processor 256 to interact with the memory 252 and enable the NIHW device 254 to receive, process, and upload data packets. In this regard, the processor may provide control signals and/or instructions to the memory 252 and NIHW device 254 for causing the node 250 to receive and transmit data packets formatted as the data packets 100b, 100c and 100d disclosed in fig. 1.

In operation, a data packet may arrive at node 250 in the form of a bitstream on a physical medium. NIHW device 254 may receive these bits and transfer them to processor 256 and/or memory 252. Processor 256 may parse the ethertype field of the received packet and determine whether the packet comprises a MACSec packet (e.g., packet 100c) or a modified MACSec packet (e.g., packet 100 d). If the source of this packet is MACSec available, its ethertype field may indicate that this packet is in the format of packet 100 c. The processor can further parse and process this packet. This ethertype field may indicate that the packet is in the format of packet 100d if the source of the packet is not MACSec available. Thus, the processor strips the tag from the packet before further parsing and processing the packet. Thus, the processor may convert the additional header information removed from the data packet into one or more control bits that may be used to further parse and process the data packet.

When a packet is to be forwarded, the processor may search the memory 252 and determine whether a non-MACSec-capable node in the network needs to be traversed to reach the destination. In this regard, for example, the processor may search the memory 252 for a destination MAC address of the packet and/or an egress port (egresport) for transmitting the packet. If the destination packet does not need to pass through a non-MACSec-capable node, the processor may format the packet similar to packet 100c and NIHW device 254 may send the packet to the network. If this destination needs to go through a non-MACSec-capable node, the processor will insert additional header information (such as header information 142 in packet 100d) and the NIHW device 254 may send the packet to the network. In this regard, the processor may need to determine the additional header information to be inserted using one or more control bits generated upon receipt of the data packet or using the memory 252. In an exemplary embodiment of the present invention, the additional header information may include one or more VLAN tags.

Fig. 3 is a flow chart of exemplary steps for a process of transmitting MACSec packets in a network (e.g., network 200 disclosed in fig. 2A) that includes MACSec nodes and nodes that are not MACSec-capable, in accordance with an embodiment of the present invention. Referring to fig. 3, the process begins at step 304, where a packet is ready to be transmitted by a network node (e.g., computer 210a in fig. 2), and then proceeds to step 306. In step 306, a determination is made as to whether the destination requires traversing a non-MACSec-capable node (e.g., switch 214b) in the network. In the event that it is determined that the destination does not need to traverse a non-MACSec-capable node, then the processor will proceed to step 310 where the packet is transmitted into the network in the format of the packet in fig. 1B.

Returning to step 306, in the event that it is determined that the destination needs to pass through a non-MAC sec-capable node (e.g., switch 214b), then the process proceeds to step 308, where additional header information (e.g., one or more VLAN tags) may be inserted after the source MAC address field, as indicated by the additional header information in fig. 1D, in step 308. Following step 308, the entire process may proceed to step 310.

Fig. 4 is a flow diagram illustrating exemplary steps for a process of receiving a MACSec packet in a network (e.g., network 200 in fig. 2A) that includes a MACSec node and a node that is not MACSec-capable, in accordance with an embodiment of the present invention. Referring to fig. 4, the process begins at step 404, where a packet is received at a network node (e.g., switch 214c in fig. 2A), and the process then proceeds to step 406. A determination may be made in step 406 whether the packet is from a MACSec-capable node (e.g., switch 214a) based on the ethertype of the packet. In the case where it is determined that the packet is from a MACSec-capable node and may be in the packet format disclosed in fig. 1C, the process may then proceed to step 412, where the MACSec packet may be processed. In this regard, processing of the data packet may include parsing, decrypting, authenticating, validating, and/or processing the data packet for uploading.

Returning to step 406, in the event that the packet is determined to be from a non-MACSec-capable node (such as switch 214c) and may be in the packet format disclosed in fig. 1D, then the process will proceed to step 408. In step 408, additional header information may be removed from the data packet and the process proceeds to step 410. In step 410, the removed additional header channel may be converted into one or more control bits. The bits may be used to protect information including the removed additional header information, and the process proceeds to step 412.

Aspects of the present invention may be found in methods and systems that may be used to determine whether a destination of a mac sec packet (e.g., packet 100c) needs to traverse one or more mac sec-capable network nodes (e.g., switch 214b), and to insert additional header information (e.g., header 142 in packet 100d) in the mac sec packet based on the determination. Additional header information 142 may be generated for insertion based on one or more control bits generated from one or more received data packets. The inserted additional header information may allow the MACSec-capable network nodes and non-MACSec-capable network nodes to identify the MACSec packet. In this regard, in an exemplary embodiment of the present invention, the additional header information may include one or more VLAN tags similar to VLAN tag 112 disclosed in fig. 1B and/or ethertype fields similar to ethertype fields 104, 114, and 134 disclosed in fig. 1 for identifying the MACSec packet.

In various embodiments of the invention, additional header information may be inserted between the source MAC address field 104 and the SecTAG field 118 in the MACSec packet, as shown in packet 100 d. The network may parse the additional header information inserted in the MACSec packet and the additional header information may include an ethertype identifying the inserted header information. In this manner, various embodiments of the present invention may remove the inserted header 142 based on the identification bit type. The removed header information may be converted into one or more control bits, based on which the MACSec packet may be processed.

Accordingly, the present invention may be realized in hardware, software, or a combination of hardware and software. The present invention can be realized in a centralized fashion in at least one computer system, or in a distributed fashion where different elements are spread across several interconnected computer systems. Any kind of computer system or other apparatus adapted for carrying out the methods described herein is suited. A typical combination of hardware and software could be a general purpose computer system with a computer program that, when being loaded and executed, controls the computer system such that it carries out the methods described herein.

The present invention may also be implemented by a computer program product, comprising all the features enabling the implementation of the methods of the invention, when loaded in a computer system. The computer program in this document refers to: any expression, in any programming language, code or notation, of a set of instructions intended to cause a system having an information processing capability to perform a particular function either directly or after either or both of the following: a) conversion to other languages, codes or symbols; b) reproduced in a different format.

While the invention has been described with reference to specific embodiments, it will be understood by those skilled in the art that various changes may be made and equivalents may be substituted without departing from the scope of the invention. In addition, many modifications may be made to adapt a particular situation or material to the teachings of the invention without departing from its scope. Therefore, it is intended that the invention not be limited to the particular embodiment disclosed, but that the invention will include all embodiments falling within the scope of the appended claims.

Claims (7)

1. A method for computer networking, comprising:

determining whether a destination of the MACSec packet needs to pass through one or more non-MACSec-capable network nodes; and

inserting additional header information in the MACSec packet based on the determination to allow the MACSec packet to be identified when passing through the one or more non-MACSec-capable nodes; wherein the position of the inserted additional header information is different from the position of the SecTAG in the MACSec message, the additional header information comprising one or more VLAN tags.

2. The method of claim 1, comprising inserting the additional header information between a source MAC address field of the MACSec packet and a SecTAG.

3. The method of claim 1, wherein the additional header information comprises an ethertype field for identifying the MACSec packet.

4. The method of claim 1, comprising parsing additional header information inserted into the MACSec packet.

5. A system for computer networking, the system comprising:

a first unit, configured to determine whether a destination of the MACSec packet needs to pass through one or more non-MACSec-capable network nodes; and

means for inserting additional header information into the MACSec packet based on the determination to allow the MACSec packet to be identified as passing through the one or more non-MACSec-capable nodes; wherein the position of the inserted additional header information is different from the position of the SecTAG in the MACSec message, the additional header information comprising one or more VLAN tags.

6. The system of claim 5, wherein the system comprises:

a third unit for inserting the additional header information between the source MAC address field of the MACSec packet and the SecTAG.

7. The system of claim 5, wherein the additional header information comprises an ethertype field for identifying the MACSec packet.