How to send an Ethernet MAC frame

Abstract

The present disclosure relates to a method for transmitting an Ethernet MAC frame, the method being performed by a communication device having an output port for forming a frame to be transmitted based on received data of the frame, the method including: determining whether at least one parameter (chunk, transmitChunkOffset, chunkPresent) related to frame division is present in the data of the frame; and, if present, starting formation of the frame at the output port according to a cut-through forwarding mode without waiting for reception of all frame data.

Description

[Technical Field]

[0001] The present disclosure relates to telecommunications signal processing. [Background technology]

[0002] The Ethernet-related standards defined by the IEEE 802 standards, particularly IEEE™ 802.3 and IEEE 802.1, are based on the layered protocol model introduced by the OSI Basic Reference Model, in which protocol entities instantiated at a particular protocol layer communicate with other protocol entities instantiated at the same protocol layer. This communication within a particular layer depends on the services provided by the protocol layer immediately below.

[0003] The relative layer positions of protocol entities and protocol services are referenced by index N. As an example, (N) services are provided by (N) entities using (N-1) services provided by (N-1) entities. (N) service users are (N+1) entities.

[0004] Each service is offered to a single protocol entity at a Service Access Point (SAP). A particular (N) entity can support multiple N-SAPs and can use one or more (N-1) SAPs. SAPs are abstractions that mark the boundaries between protocol specifications and specify the observable behavior between entities.

[0005] (N) Service users interact with (N) service providers through primitives and their parameters.

[0006] Figure 1 illustrates these concepts through the Media Access Control (MAC) sublayer of an Ethernet network (contained in OSI Layer 2), which contains MAC entities that provide MAC services to MAC service users (MAC clients).

[0007] For the IEEE802MAC service, two primitives are defined: data request and data indication. These primitives carry the following as parameters: ○ MAC destination address, ○ MAC source address, ○ MAC Service Data Units (MSDUs) containing one or more octets, and ○ Priority parameters.

[0008] These parameters make up a frame.

[0009] FIG. 1 shows the MAC service primitives (defined in IEEE standard 802.1AC) that may be used in a bridge: MA_UNITDATA.request and MA_UNITDATA.indication.

[0010] The IEEE Std 802.3 specification defines the services provided to MAC clients by the MAC sublayer with slightly changed primitive names and parameters.

[0011] Figure 2 shows the primitives handled by the MAC service (supported by the MAC sublayer defined in IEEE Std 802.3) with the MAC client (upper layer) and the physical layer (PHY, lower layer).

[0012] The parameters of these primitives are as follows: MA_DATA.request { destination_address, source_address, mac_service_data_unit, frame_check_sequence }.

[0013] The destination_address parameter specifies an individual MAC entity address or a group of MAC entity addresses. This parameter contains enough information to create the DA (Destination Address) field that is prepended to the frame by the local MAC sublayer entity, plus optional physical information.

[0014] The source_address parameter, if present, specifies an individual MAC address. If the source_address (SA) parameter is omitted, the local MAC sublayer entity inserts the value associated with that entity.

[0015] The mac_service_data_unit parameter specifies the MAC service data unit transmitted by the MAC sublayer entity. There is enough information associated with the mac_service_data_unit for the MAC sublayer entity to determine the length of the data unit.

[0016] The frame_check_sequence parameter, if present, specifies the frame check sequence field of the frame. If the frame_check_sequence parameter is omitted, the local MAC sublayer entity computes this field and appends it to the end of the frame.

[0017] Upon receipt, the MAC sublayer entity inserts all MAC specific fields (DA, SA, ...) and passes the frame formed from this information to the lower protocol layers for forwarding to the peer MAC sublayer entity. MA_DATA.indication { destination_address, source_address, mac_service_data_unit, frame_check_sequence, reception_status }

[0018] The destination_address parameter may be an individual address specified by the DA field of the received frame, or it may be a group address.

[0019] The source_address parameter is the individual address specified by the SA field of the received frame.

[0020] The mac_service_data_unit parameter specifies the MAC service data unit received by the local MAC entity.

[0021] The frame_check_sequence parameter is the cyclic redundancy check value specified by the FCS (Frame Check Sequence) field of the received frame. This parameter may be omitted or (optionally) passed to the MAC client by the MAC sublayer entity.

[0022] The reception_status parameter is used to pass status information to the MAC client entity.

[0023] The MA_DATA.indication is passed from the MAC Sublayer entity to one or more MAC Client entities to indicate that a frame destined for the MAC Client has arrived at the local MAC Sublayer entity. Such a frame is reported only if it is validly formed and received without error.

[0024] The MA_DATA.x primitives of IEEE802.3 are: ● Ignoring the priority parameter specified for the M_UNITDATA.request and forming the corresponding MA_DATA.request; ● The priority parameter specified for an M_UNITDATA.indication is not provided by the corresponding MA_DATA.indication; ● removing the frame_check_sequence parameter to form the corresponding MA_UNITDATA.indication; ● Do not map reception_status into the corresponding MA_UNITDATA.indication, are mapped / adapted to the respective IEEE802.1 MA_UNITDATA.x primitives by

[0025] Regarding IEEE Standard 802.1 Bridges, according to the VLAN Bridge architecture, such a bridge comprises at least one bridge component, which includes: ● MAC relay entities that interconnect the ports of bridges; ● At least two ports, ● Higher layer entities.

[0026] The VLAN bridge architecture is shown in Figure 3.

[0027] The MAC Relay entity handles the media access method independent functions of relaying frames between bridge ports, filtering frames, and learning filtering information. The MAC Relay entity uses the Enhanced Internal Sublayer Service (EISS) provided by each bridge port. EISS extends the ISS (Internal Sublayer Service) that provides the basic MAC service at the bridge port.

[0028] In a bridge port, a MAC client is formed from the ISS and the EISS, and the ISS performs a convergence function as a client of the IEEE 802.3 MAC sublayer by translating primitives exchanged with the IEEE 802.3 MAC sublayer.

[0029] In this particular case, the primitives provided by the ISS are M_UNITDATA.indication and M_UNITDATA.request, which carry the following parameters: M_UNITDATA.indication { destination_address, source_address, mac_service_data_unit, priority, drop_eligible, frame_check_sequence, service_access_point_identifier, connection_identifier } M_UNITDATA.request { destination_address, source_address, mac_service_data_unit, priority, drop_eligible, frame_check_sequence, service_access_point_identifier, connection_identifier }.

[0030] The M_UNITDATA.request is converted to an IEEE802.3 MA_DATA.request as follows: ● The destination_address and source_address parameters are passed unchanged. ● The mac_service_data_unit is optionally padded to comply with the minimum frame length required by IEEE 802.3. ● If frame_check_sequence is included in the M_UNITDATA.request primitive, its value is adjusted to include the added padding. ● The priority parameter, drop_eligible parameter, service_access_point_identifier parameter, and connection_identifier parameter are ignored.

[0031] Conversely, an IEEE802.3 MA_DATA.indication is translated into an M_UNITDATA.request as follows: ● The destination_address, source_address, mac_service_data_unit, and frame_check_sequence parameters are passed unchanged. ● The drop_eligible parameter of M_UNITDATA.indication is FALSE. ● The priority parameter of the M_UNITDATA.indication takes the value of the Default Priority parameter of the SAP that received the MA_DATA.indication. The priority parameter can be set by the administrator or can be left at the default value of 0.

[0032] The EISS primitive adds three parameters to the ISS primitive. Among these parameters, vlan_identifier carries the VID contained in the VLAN-Tag of a VLAN-tagged frame. The mac_service_data_unit parameter passed via EISS is two bytes shorter than the mac_service_data_unit parameter passed via ISS. This is because the vlan_id parameter is extracted from the two-byte VLAN-Tag located in the first two bytes of the ISS mac_service_data_unit parameter.

[0033] The main functions of a VLAN bridge are: ● Frame relaying and filtering, • Maintaining the information needed to make frame filtering and relaying decisions; ● Management.

[0034] Its functions are distributed among the bridge's ports, forwarding process functions and higher layer functions and can be listed as follows: ● Frame reception, ● Discarding received frames with errors, ● Discarding frames that do not carry user data, Decoding priority and drop eligibility from the VLAN tag, if present, and regenerating priority as needed; ● Assigning a VID to each received frame; ● Ensuring that each frame is restricted to the active topology; ● Frame discarding supporting administrative control over the active topology of each VLAN; ● Discarding frames after applying filtering information; ● Metering frames and possibly marking them as eligible to be dropped or discarding frames that exceed bandwidth limits; ● Forwarding received frames to other bridge ports, ● Traffic class selection and queuing of frames by traffic class; ● Frame discarding to ensure that the maximum bridge transit delay is not exceeded; ● Preferential discard of drop-eligible frames to maintain the QoS of other frames; ● Selecting the transmission of queued frames; ● SDU mapping and FCS recalculation if necessary; ● Frame discard due to exceeding the transmittable SDU size, ● Selecting the transmission access priority; ● Frame transmission.

[0035] The set of functions that perform actions taken on a particular frame received by a MAC Relay entity at a particular port (called the "receiving port") constitutes the forwarding process. The frame may be forwarded for transmission on some ports (called the "transmitting port") and discarded without being transmitted on other ports.

[0036] The functionality of the forwarding process is shown in Figure 4.

[0037] The operation of the MAC sublayer described herein is restricted to full-duplex operation as specified in IEEE Standard 802.3 Annex 4A.

[0038] For transmission, upon request of the MAC client, data provided by the client is used by the transmit data encapsulation component of the full duplex MAC sublayer to construct a frame.

[0039] This component adds a preamble and start-of-frame delimiter to the beginning of the frame, and possibly pads the end of the MAC Service Data Unit to meet minimum frame size requirements. This component also adds the destination and source addresses, and optionally a frame check sequence for error detection. Frame transmission begins after the carrierSense signal is removed and the required inter-frame delay has passed (see Figure 1).

[0040] The MAC sublayer indicates to the MAC client when transmission is complete and waits for the next frame transmission request.

[0041] IEEE standard 802.3 specifies the control flow for transmit operations as shown in FIG.

[0042] On receive, the physical layer detects the reception of a frame by synchronizing to the receive preamble and asserting the receiveDataValid signal (at the MAC sublayer). The physical layer passes further decoded bits to the MAC sublayer, which discards the preamble and start-of-frame delimiter. Received bits are collected as long as the receiveDataValid signal is active. Once the frame is removed, it is truncated to an octet boundary and passed to the receive data decapsulator for processing.

[0043] The receive data decapsulator passes the Destination Address (DA), Source Address (SA), MAC Service Data Unit, and (optionally) Frame Check Sequence (FCS), and status code.

[0044] The receiving data decapsulator checks the FCS to detect erroneous frames.

[0045] IEEE standard 802.3 also specifies the control flow for receive operations, as shown in FIG.

[0046] The full-duplex MAC sublayer schematic shown above indicates that the information entity processed by the IEEE Std 802.3 MAC sublayer is the entire frame.

[0047] On reception, the MAC sublayer waits for an indication of complete bit-by-bit reception of the frame by the physical layer via the receiveDataValid envelope signal before initiating the frame decapsulation process and presenting the received frame to the MAC client via an indication primitive.

[0048] Similarly, for transmission, the MAC client must provide all information elements required by the MAC to the IEEE 802.3 MAC sublayer so that the IEEE 802.3 MAC sublayer can proceed to assemble the frame and provide it bit by bit to the physical layer for transmission.

[0049] Thus, a MAC client participating in a port of an IEEE 802.1 compliant bridge (ISS or higher) also processes the entire frame, which is the unit of information that is manipulated by the forwarding process function of the MAC Relay entity within the bridge.

[0050] This method of sending, receiving and forwarding frames is called "store and forward" and incurs a delay proportional to the size of the frame as it traverses each network node, including MAC sublayer and MAC relay entities.

[0051] This cumulative delay is hostile to the transmission performance required for time-critical applications such as industrial communications, audio / video communications, or internal data center communications.

[0052] Minimizing this delay can be achieved by modifying the operation of the IEEE 802.3 MAC sublayer so that it processes frames in smaller contiguous portions that carry enough information to be processed by the bridge's MAC relay entity. Such a forwarding principle is called "cut-through forwarding", where a frame may be forwarded at the bridge's output port before it has been received in its entirety via the input port.

[0053] Cut-through forwarding is not specified by the IEEE 802.3 standard or the IEEE 802.1 standard, and therefore the method for identifying frames to be cut-through forwarded is not defined.

[0054] By processing a frame segment before checking the FCS calculated over the entire frame, cut-through mode forwarding ● Identifying frames to be cut-through forwarded and ● The transfer process and However, there is a risk that they may take erroneous frame information as input for making their decisions.

[0055] This information includes the DA, SA, and other data fields contained in the MAC service data unit (e.g., the VLAN-ID in the VLAN-Tag). Neither the IEEE 802.3 MAC sublayer nor the IEEE 802.1 MAC client and forwarding processes provide any protection against such errors. Summary of the Invention [Problem to be solved by the invention]

[0056] The present disclosure improves this situation. [Means for solving the problem]

[0057] To that end, the present disclosure provides a method for transmitting an Ethernet MAC frame, the method being performed by a communications device having an output port that forms a frame to be transmitted based on received data of the frame, the method comprising: determining whether there is at least one parameter in the data of the frame that is related to the division of the frame; If so, initiating formation of a frame at the output port according to a cut-through forwarding mode without waiting for receipt of all frame data; The present invention proposes a method including:

[0058] The aforementioned "at least one parameter" can typically be one of the parameters shown in the transmission scheme of Figure 19 (bottom right box), such as "chunk", "transmitChunkOffset", and "chunkPresent", as shown in the example embodiment detailed below.

[0059] The aforementioned cut-through forwarding mode therefore makes it possible to start transmitting the first bit of a frame even when the entire frame itself (i.e., its last bit) is not yet ready for transmission. This cut-through forwarding mode is therefore the opposite of the regular store-and-forward mode normally used for transmitting MAC Ethernet frames, which requires processing of the last bit before starting frame transmission.

[0060] In one embodiment, where a communication device typically has an input port that receives data for a frame to be transmitted, the step of forming the frame at the output port can begin without waiting for all frame data to be received at the input port.

[0061] Thus, when transferring a frame from one communication device to another, the frame transmission can begin even before the last bit is received.

[0062] In one embodiment, the communication device comprises a bridge (with the above-mentioned output and / or input ports) operating according to the OSI layer model, which comprises: a MAC sublayer providing MAC services; and upper layers associated with the MAC client; a lower physical layer; Including, When frame segmentation parameters are present, the MAC client provides a series of frame segments, called "chunks", to the MAC sublayer to perform the frame transmission function (TransmitFrame in the example below) without interruption while the frame to be transmitted is not completely forwarded through the MAC service layer.

[0063] In one embodiment, the frame data further includes a chunk size parameter, and each time a number of bits of a frame equal to the chunk size parameter are received from the physical layer, a chunk is incrementally passed to the MAC client.

[0064] In one embodiment, the frame data further includes a chunk offset parameter that indicates the position of the chunk in the series of bits that make up the frame relative to the start of the frame.

[0065] In one embodiment, a specific primitive (in the following example, referred to as "MA_DATA_CHUNK.request") is initiated by the MAC client to request transmission services from the MAC sublayer; chunks covering segments of frames to be transmitted; a chunk offset, which targets the offset of the chunk relative to the start of the frame; Define the parameters associated with

[0066] This offset parameter (called "transmitChunkOffset" in the figures and in the following example embodiments) makes it possible to identify, in particular, the "0 offset" chunk corresponding to the beginning of the frame, and thereby to identify a new frame to be transmitted in cut-through transport mode.

[0067] In one embodiment, a frame transmit function (referred to in the examples below as "TransmitFrame") calls a procedure (referred to in the examples as "TransmitDataEncap") to encapsulate the frame data to be transmitted. This procedure includes checking whether a chunk is processed instead of the entire frame depending on whether a parameter (chunkPresent) is present or not.

[0068] In this embodiment, the procedure can prepend a preamble and start frame delimiter to the beginning of the first chunk of a frame, when the parameters are present.

[0069] Therefore, the usefulness of labeling the offset of the chunks, and more particularly the first chunk with a "0" offset, is evident from this embodiment.

[0070] And, in this embodiment, the first chunk is identified by a chunk offset of "0", thereby indicating the beginning of a new frame.

[0071] On reception, when a frame formed according to the cut-through transfer mode is received from another communication device, the MAC sublayer can initiate a bit reception procedure (hereinafter referred to as "BitReceiver") from the bit string received from the physical layer, which includes boundary indications of successive chunks to be passed to the MAC client.

[0072] Typically, while the last chunk of a frame received in cut-through forwarding mode has not been received by the MAC sublayer, a specific primitive (hereinafter referred to as "MA_DATA_CHUNK.indication") indicates successive chunks to be passed to the MAC client.

[0073] Instead, once the last chunk is received by the MAC sublayer, a general primitive (hereafter referred to as "MA_DATA.indication") is initiated to indicate the end of reception of the entire frame.

[0074] Typically, this "generic" primitive is the normal primitive that would be invoked to process the entire frame reception in normal "store-and-forward" mode. In fact, even in cut-through mode, there is no need to have any other primitives than those used in store-and-forward mode, especially for the end of the frame. Therefore, higher OSI layers that may ignore other primitives in cut-through mode can operate normally for the processing of the entire frame in question in both modes.

[0075] In one embodiment, where the first chunk of a received frame is identified by a chunk offset of "0", thereby indicating the beginning of the received frame, the particular primitive (hereinafter referred to as "MA_DATA_CHUNK.indication") further declares at least the destination address of the frame. More specifically, the minimum size of the chunk is set equal to at least the destination address field bit length, and the MAC sublayer initiates a procedure (hereinafter referred to as "ReceiveChunkDecap") to decapsulate the chunks of the received frame from the first chunk (which has an offset of "0") to indicate at least the boundary of the frame destination address.

[0076] The destination address is typically one piece of information that the MAC client can use to know, for example, whether the frame is actually intended for the communication device, or whether the frame should be forwarded to another communication device (and immediately sent in chunks out the output port in cut-through mode). More generally, an initial chunk of data large enough to contain the Ethernet addresses (usually destination, source) and possibly other initial data of the frame (e.g., a tag, such as a VLAN tag, or a cut-through mode tag as described below) is useful to signal the MAC client (or higher layers) to begin processing the frame as in normal store-and-forward mode.

[0077] In one embodiment, a tag is added to the frame data before transmission of the frame, the tag comprising: indicates that the frame was formed in accordance with cut-through transport mode, including at least one piece of data for performing a frame check when receiving a frame; A communication device, upon receiving a frame from another communication device according to the cut-through transfer mode, determining whether a tag is present in the frame; If present, the data in the tag is read to see if the frame has any errors.

[0078] In one embodiment, the above parameters related to frame splitting are declared among other parameters including at least the destination address and / or the source address, and the communication device starts forming the frame directly at the output port in cut-through forwarding mode, ignoring the addresses.

[0079] Also, if the communication device is not configured to implement cut-through forwarding mode, the communication device may start processing the frame data by ignoring parameters related to frame splitting and taking into account other parameters including at least addresses.

[0080] Thus, either device can continue to operate in cut-through mode (if the device is configured for cut-through mode) or store-and-forward mode without interfering with the device's ability to communicate.

[0081] The present disclosure is also directed to a computer program comprising instructions, which when executed by a processor cause the computer program to perform the above-described method.

[0082] The present disclosure is also directed to a communications device comprising processing circuitry for carrying out the method as defined above.

[0083] Further details are provided in the following description with reference to the accompanying drawings. [Brief explanation of the drawings]

[0084] [Figure 1] FIG. 1 illustrates MAC service primitives that can be used in a bridge of a prior art communication device as disclosed in IEEE Standard 802.1AC. [Figure 2] FIG. 1 illustrates prior art primitives processed by a MAC service (supported by the MAC sublayer defined in IEEE Std 802.3) with a MAC client (upper layer) and a physical layer (PHY, lower layer). [Figure 3] FIG. 1 illustrates a general architecture of a VLAN bridge. [Figure 4] A diagram showing the general forwarding process functions in a bridge relay entity. [Figure 5] FIG. 1 is a diagram showing the control flow of a transmission operation defined in the prior art IEEE standard 802.3. [Figure 6] FIG. 1 is a diagram showing the control flow of a receiving operation defined in the prior art IEEE standard 802.3. [Figure 7] FIG. 1 illustrates a typical TransmitFrame operation according to prior art IEEE standard 802.3. [Figure 8] 8 illustrates a TransmitDataEncap procedure that is invoked when the TransmitFrame operation of FIG. 7 is initiated. [Figure 9] 8 illustrates the TransmitLinkMgmt procedure that is invoked when the TransmitFrame operation of FIG. 7 is initiated. [Figure 10] FIG. 8 illustrates the BitTransmitter processes involved when the TransmitFrame operation of FIG. 7 is initiated. [Figure 11] FIG. 1 illustrates a typical ReceiveFrame operation according to prior art IEEE standard 802.3. [Figure 12] 12 illustrates a ReceiveLinkMgmt procedure that is called when the ReceiveFrame operation of FIG. 11 is initiated. [Figure 13] FIG. 12 illustrates the BitReceiver processes involved when the ReceiveFrame operation of FIG. 11 is initiated. [Figure 14] 12 illustrates a ReceiveDataDecap procedure that is called when the ReceiveFrame operation of FIG. 11 is initiated. [Figure 15] FIG. 1 illustrates prior art MAC client transmit interface operation, in which the mac_service_data_unit parameter passed through the MAC client's MA_DATA.request primitive is the concatenation of the lengthOrType field and the data field passed to the MAC sublayer. [Figure 16]FIG. 1 illustrates prior art MAC client receive interface operation, in which the lengthOrType field and data payload field passed from a received MAC frame are concatenated to form the mac_service_data_unit parameter passed using the MA_DATA.indication primitive. [Figure 17] 10 illustrates new parameters chunkParam, transmitChunkOffsetParam, and chunkParamPresent that are included in a frame to indicate cut-through transport mode in a TransmitFrame operation according to the present disclosure. [Figure 18] FIG. 10 illustrates a TransmitDataEncap procedure modified in the present disclosure to check whether a chunk is processed instead of an entire frame. [Figure 19] FIG. 1 illustrates an example state machine that specifies the operation of a MAC service interface that supports both cut-through forwarding mode and normal store-and-forward mode. [Figure 20] FIG. 10 illustrates a BitReceiver procedure modified in the present disclosure to indicate chunk boundaries from the bit stream received from the physical layer. [Figure 21] 10 illustrates a ReceiveChunk procedure and a ReceiveChunkDecap procedure performed in receiving a received frame in a cut-through forwarding mode according to the present disclosure. [Figure 22] FIG. 10 illustrates the parameters used for reception in either cut-through or store-and-forward mode, depending on whether the ReceiveChunk procedure is invoked or not. [Figure 23] FIG. 2 illustrates the format of a tag included in a frame that indicates whether the frame is encoded according to cut-through forwarding mode, according to an example embodiment of the present disclosure. [Figure 24] FIG. 24 illustrates details of the tag of FIG. 23 in an example embodiment. [Figure 25] 1 is a diagram illustrating a schematic diagram of a communication device according to the present disclosure in an example embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0085] The following disclosure proposes modifications to the operation of the IEEE 802.3 MAC sublayer's framing functions (TransmitFrame and ReceiveFrame processes) and media management functions (BitReceiver and BitTransmitter processes). On transmit, these modifications allow frames to be sent as soon as the first segment is available to the MAC client. On receive, these modifications allow successive segments of a frame to be passed to the MAC client as soon as the first of the successive segments has been extracted from the physical layer.

[0086] The standard primitives available at the service access point between the MAC client and the MAC sublayer are augmented with additional primitives that signal the exchange of frame segments via this SAP. Such a set of primitives ensures backward compatibility for MAC clients that do not support the new SAPs by simply ignoring the additional primitives.

[0087] To eliminate the risk that MAC Client and MAC Relay entities will perform processing based on erroneous or incomplete frame information carried in the DA, SA, and MAC Service Data Units, a tag is introduced: a CTF (short for "Cut-Through Frame")-Tag that contains supplemental frame information and a check sequence that protects the information the MAC Client and MAC Relay entities need for their processing.

[0088] The following disclosure first details the frame transmission process, frame reception process, and primitive generation process as specified in IEEE Std 802.3 Annex 4A, with some simplifications to align with the changes introduced later to support cut-through mode.

[0089] The modified sending process, receiving process, primitive generation process, and CTF-Tag based protection are introduced later in this disclosure.

[0090] For the transmission of IEEE 802.3 MAC sublayer frames, the TransmitFrame operation is synchronous with the actual frame transmission, i.e., it lasts for the entire frame transmission time.

[0091] When transmission is possible, the TransmitFrame operation of Figure 7 first calls the TransmitDataEncap procedure shown in Figure 8 to assemble the frame from the parameters passed by the MAC client, and then calls the TransmitLinkMgmt procedure of Figure 9 to begin the actual frame transmission.

[0092] The MAC client indicates via fcsParamPresent whether to pass the frame check sequence for the frame. If so, the MAC client also passes the fcsParamValue parameter to provide any necessary padding. If the fcsParamPresent parameter is false, the fcsParamValue parameter is not specified, and TransmitDataEncap first calls the ComputePad function, followed by the CRC32 (for 32-bit Cyclic Redundancy Check) function to generate the frame's padding (if required) and frame check sequence fields.

[0093] Note that what remains from the traditional Ethernet MAC specification is the lengthOrTypeParam, and how this is handled when generating request primitives between the MAC client and the MAC sublayer will be explained later in this disclosure.

[0094] The TransmitLinkMgmt procedure is responsible for transmitting frames, as shown in Figure 9. When deferenceMode is true, this procedure first defers to the physical layer to ensure proper inter-frame spacing if the next packet is not ready.

[0095] LayerMgmtTransmitCounters updates the transmit counters and transmit error counters.

[0096] At the start of each frame transmission, StartTransmit is called to notify the BitTransmitter process that bit-by-bit transmission can begin. The transmit variable is used to synchronize the TransmitLinkMgmt (which reacts to events issued by the MAC Client) with the BitTransmitter process, which synchronizes to the timing of the physical link, as shown in Figure 10.

[0097] In the case of IEEE 802.3 MAC sublayer frame reception, the ReceiveFrame operation is synchronized with the actual frame reception, i.e., it lasts for the entire frame reception time and is completed when the frame is completely received, as shown in Figure 11. The fields of the frame are delivered through an output parameter with a ReceiveStatus status code.

[0098] If so, ReceiveFrame calls ReceiveLinkMgmt to receive the next valid frame, and then calls the internal ReceiveDataDecap function to return the frame's fields to the MAC client according to the frame's DA (see ReceiveDataDecap description). The returned ReceiveStatus indicates possible errors in the frame, as shown in Figure 12.

[0099] The ReceiveLinkMgmt procedure then begins receiving frame bits continuously, discarding any fragments that are smaller than the minimum valid frame size.

[0100] As shown in FIG. 13, the BitReceiver process is synchronized to the physical layer bit timing specified by the ReceiveBit operation and divides the received bits into frames.

[0101] The receive variable is used to connect the asynchronous ReceiveLinkMgmt and BitReceiver processes.

[0102] PhysicalSignalDecap checks whether a valid Start Frame Delimiter (SFD) is detected from consecutive bits from the physical layer, and if so, discards this SFD as shown in Figure 14.

[0103] The ReceiveDataDecap function is called by ReceiveFrame and returns the frame's fields to the MAC client if the frame's addresses have the expected values. The returned ReceiveStatus indicates whether there are any detected transmission errors in the frame.

[0104] The destinationFieldOK function checks whether the destination address field of the received frame contains the address of the receiving station. When the Ethernet interface of this station is in "promiscuous" mode, all destination addresses are considered valid. The same situation applies to the input port of a bridge, so that destinationFieldOK is always TRUE.

[0105] Note that what remains from the legacy Ethernet MAC specification is the lengthOrTypeParam. How this is handled when generating indication primitives between the MAC sublayer and the MAC client is described below.

[0106] For simplicity of explanation, possible padding handling (removal) is not shown.

[0107] Currently, in the case of an IEEE 802.3 MAC service implementation, the MAC sublayer provides MAC frame transmission and reception services to MAC clients through the service primitives MA_DATA.request and MA_DATA.indication. The following state machines (shown in Figures 15 and 16, described below) define the relationship between the TransmitFrame and ReceiveFrame functions and these service primitives.

[0108] The MAC Client transmit interface operation is shown in Figure 15. In this figure, the mac_service_data_unit parameter passed through the MAC Client's MA_DATA.request primitive is the concatenation of the lengthOrType field and the data field passed to the MAC sublayer.

[0109] Note that when operating in full-duplex mode, TransmitStatus can be ignored here.

[0110] The MAC client receive interface operation is shown in Figure 16. In this figure, the lengthOrType field and data payload field passed from the received MAC frame are concatenated to form the mac_service_data_unit parameter passed using the MA_DATA.indication primitive.

[0111] Note that the ReceiveStatus included in the primitive parameters can be ignored by the MAC client in the bridge, i.e., the ISS.

[0112] The following description details the modifications made to the IEEE 802.3 MAC sublayer to support cut-through forwarding. To this end, frames are processed in segments, hereafter referred to as "chunks."

[0113] In the case of a transmit, the MAC client provides a sequence of chunks to the TransmitFrame function, which ensures that the resulting sequence of bits passed to the physical layer is not interrupted while the frame to be transmitted is not completely transferred over the MAC Service Interface.

[0114] On reception, each time a number of bits equal to the chunk size is extracted from the physical layer, the chunk is passed incrementally to the MAC client.

[0115] The position of a chunk within the array of bits that make up a frame can be signaled by an offset relative to the start of the frame.

[0116] The interface of the TransmitFrame operation is modified to accommodate chunk parameters.

[0117] The configuration of the TransmitFrame operation is not changed except as follows: - The TransmitFrame operation first invokes the TransmitDataEncap procedure to assemble a frame from the parameters passed by the MAC client, and then - Invoke the TransmitLinkManagement procedure to trigger the actual frame transmission.

[0118] The parameter "chunkParam" is a chunk parameter of size chunkSize, as shown in Figure 17. chunkSize is preferably a number of octets.

[0119] transmitChunkOffsetParam is the offset of the chunk contained in parameter chunkParam, preferably expressed as a number of octets relative to the start of the frame.

[0120] chunkParamPresent indicates whether chunks are passed as parameters to TransmitFrame. If this is TRUE, TransmitFrame takes chunkParam and transmitChunkOffsetParam as input parameters and ignores all other frame parameters. If this is FALSE, it takes the set of parameters defined in IEEE Std 802.3 as input and ignores chunkParam and transmitChunkOffsetParam.

[0121] In cut-through mode, it is the responsibility of the MAC client to correctly insert the various fields of the frame, i.e., destination and source addresses, MAC service data unit, and FCS, into successive chunks that it passes to the CTF MAC sublayer (see the description of TransmitDataEncap below). It is also the MAC client's responsibility to ensure that the frame length is greater than the minimum allowed frame size and is aligned on an octet boundary.

[0122] As shown in the example of Figure 18, the TransmitDataEncap procedure has been modified to check whether a chunk is being processed instead of an entire frame. If chunkParamPresent is TRUE, the only action taken by this process is to prepend the preamble and SFD to the chunk. In the case of cut-through operation, TransmitDataEncap does not process the traditional frame parameters (address, MAC service data unit, FCS).

[0123] In cut-through mode, TransmitDataEncap is called only once, for example, to transmit the first chunk of a frame.

[0124] The TransmitLinkMgmt, StartTransmit and BitTransmitter procedures are unchanged compared to those specified in IEEE Std 802.3.

[0125] In the case of the CTF MAC send service, a new primitive can be invoked by the MAC client, taking as parameters: ● Chunk: The segment of the frame to be sent, ● transmitChunkOffset: The offset of the chunk relative to the beginning of the frame, Defined as MA_DATA_CHUNK.request that receives

[0126] The MA_DATA.request primitive remains unchanged and is invoked when operating in store-and-forward mode.

[0127] The state machine shown in Figure 19 specifies the operation of the MAC service interface, which supports both cut-through and store-and-forward modes.

[0128] A new state CONTINUE_TRANSMIT_FRAME is introduced, which updates variables (lastTransmitBit, OutgoingFrame[]) that are handled by the asynchronous BitTransmitter procedure.

[0129] lastTransmitBit is a normal parameter indicating the end of a frame in store-and-forward mode, and in this specification corresponds to the last bit of the last received chunk (the last transmitted bit of the last received chunk) in cut-through mode. If lastTransmitBit is not updated before the physical layer receives a new chunk, the physical layer stops encoding, but the received frame can be interpreted as finally finished.

[0130] The modified TransmitFrame procedure is invoked when the MAC client invokes the MA_DATA.request primitive (store-and-forward mode) or when the MAC client invokes the MA_DATA_Chunk.request primitive with the initial chunk of the frame (transmitChunkOffset parameter equals 0).

[0131] When in cut-through mode, the MAC client continues transmitting successive chunks of the frame following the initial chunk by further invoking MA_DATA_Chunk.request, which causes the state machine to update the lastTransmitBit variable when it enters the CONTINUE_TRANSMIT_FRAME state, causing the BitTransmitter process to continue providing bits for transmission by the physical layer.

[0132] If the MAC client is late in providing a non-initial chunk, i.e., the BitTransmitter process has finished sending the bits of the previous chunk and set the send variable to 0, then the invocation of the MA_DATA_CHUNK.request primitive is ignored, and further invocations of primitives are also ignored, until the MA_DATA_CHUNK.request primitive is invoked to send the initial frame chunk.

[0133] In that case, a truncated, possibly overly short, frame is transmitted (using the lastTransmitBit indication process described above to terminate frame processing if necessary).

[0134] In the case of a CTF MAC sublayer frame reception, the ReceiveFrame operation is unchanged: when reception is possible, this operation first calls the ReceiveLinkMgmt procedure, then the ReceiveDataDecap procedure.

[0135] The ReceiveLinkMgmt and StartReceive procedures are also unchanged and initiate frame bit transfer between the physical layer and the MAC sublayer as long as the physical layer detects bits belonging to a physical frame.

[0136] The ReceiveDataDecap procedure is also unchanged and performs the same frame checking and field decapsulation operations.

[0137] The BitReceiver procedure is modified to indicate chunk boundaries from the bit stream received from the physical layer, as shown in FIG.

[0138] While receiveDataValid is set to TRUE by the physical layer, consecutive bits decoded by the physical layer are accumulated to form the received frame (incomingFrame[]). Once a number of bits corresponding to receiveChunkSize has been received, the availability of a chunk (a segment of incomingFrame[]) is detected (receiveChunk) and the ReceiveChunk procedure is called with the chunk parameters: chunk offset (receiveChunkOffset) and the bit array that constitutes the chunk (receiveChunk[]), as shown in Figure 21.

[0139] The parameter receiveChunkSize is fixed and is set through a configuration procedure not described here. Its value is preferably a number of octets.

[0140] The ReceiveChunk procedure first checks whether the chunk is the initial chunk of a frame (receiveChunkOffset is equal to 0). If its length is longer than the size of an Ethernet address, the receiveChunkDecap procedure is called, which attempts to delineate the boundaries of the destination address, source address, and MAC service data unit or part thereof.

[0141] The ReceiveChunk procedure also returns a signal set to TRUE upon completion, which is used by the CTF MAC receive service state machine to generate a chunk availability indication primitive towards the MAC client.

[0142] The CTF MAC receive service state machine handles the indication of receipt of an entire frame in the same way for both cut-through and store-and-forward modes of operation. The last chunk of a frame received in cut-through mode is signaled by sending the normal primitive MA_DATA.indication.

[0143] To accommodate cut-through mode of operation, the CTF MAC receive service interface relies on a modified state machine and provides an additional primitive, MA_DATA_CHUNK.indication.

[0144] The MA_DATA_CHUNK.indication provides the following set of parameters to the MAC client: ● receiveChunk, ● receiveChunkOffset: The position of the received chunk within the frame relative to the beginning of the frame; ● destination_address: The destination address carried by the frame if the received chunk is the first chunk of the frame and its length is greater than the address length; ● source_address: The source address carried by the frame if the received chunk is the first chunk of the frame and its length is greater than or twice the address length; ● msdu_chunk: The MAC service data unit, or part of it, carried by the frame if the received chunk is the first chunk of the frame and its length is greater than twice the length of the address.

[0145] Store-and-forward MAC clients are compatible with the new service interface by simply ignoring the MA_DATA_CHUNK.indication primitive.

[0146] As shown in Figure 22, after the WAIT_FOR_RECEIVE state initiates a ReceiveFrame operation, the MAC client is notified of chunk reception every time receiveChunkSize frame fragments are received, while signal reception is activated by the ReceiveLinkMgmt procedure and maintained by the BitReceiver procedure.

[0147] Once the frame is completely received, i.e. the receive signal is deactivated, a standard IEEE 802.3 MA_DATA.indication is passed to the MAC Client to wait for the next frame (and chunk) to be received.

[0148] Referring again back to FIG. 3, the forwarding process contained in the bridge's relay entity performs different actions on received frames depending on the contents of some of their data fields and their length.

[0149] A cut-through MAC client must be able to decide whether to cut-through or store-and-forward a received frame. To do this, the cut-through MAC client needs some classification information. This classification information is preferably present in the first frame chunk received (as minimum delay must be achieved).

[0150] The forwarding and classification information can be the destination and source addresses as well as additional information included in the MAC service data unit. This is the case, for example, when the forwarding decision or classification is based on a combination of the destination address, VLAN-ID, and PCP value. The VLAN-ID and PCP (Priority Code Point) are contained in the VLAN-Tag (specified in IEEE Std 802.1Q) contained in the first two octets of the MAC service data unit in most application configurations.

[0151] To avoid incorrect forwarding or classification decisions, an error detection code can be inserted in the frame immediately following the information needed for these decisions, hereinafter referred to as the intermediate check sequence.

[0152] Additionally, the length information of the frame can be signaled explicitly in a separate information field protected by an intermediate check sequence.

[0153] A tag, hereafter referred to as "CTF-Tag", is defined as holding the fields listed below and shown in Figure 23. - Ethertype: 2 bytes defining the tag type (CTF-Tag), - Reserved (RSV) field: 2 bytes, - Frame length (FRAME_LEN): 2 bytes, - Intermediate Check Sequence (ICS): 2 bytes.

[0154] CTF-Tag values ​​are unique and may be assigned by the IEEE registration authority.

[0155] The RSV field is an information placeholder reserved for further use not necessarily related to cut-through forwarding.

[0156] FRAME_LEN is the cumulative length, in octets, of the destination address, source address, MAC service data unit, and FCS.

[0157] The ICS is preferably a 16-bit cyclic redundancy check code calculated over the destination address, the source address, and the portion of the MAC service data unit up to and including the CTF-Tag.

[0158] The CTF-Tag is inserted by the CTF MAC client before transmitting a frame at an offset specified by the CTF MAC client's management entity. This location information is used by the peer CTF MAC client (on reception) to locate the CTF-Tag and perform ICS calculations on the corresponding part of the received frame.

[0159] FIG. 24 shows the format of a frame including a CTF-Tag.

[0160] The receiving CTF MAC client discards the frame when the calculated ICS value does not match the received ICS value.

[0161] When in cut-through mode of operation, the MAC client may then update a counter that counts frames received with erroneous ICS in addition to a counter of erroneous frames.

[0162] 25 shows an example of a communications device DEV including a bridge BR with an input port IP and an output port EP linked to a processing circuit including a processor PROC and a memory MEM, the memory MEM storing at least instruction data of a computer program according to the present disclosure, the processor PROC being able to access the memory MEM to read the instruction data and to implement the methods set out above (in transmission through the output port or in reception through the input port).

Claims

1. 1. A method of transmitting an Ethernet MAC frame, the method being performed by a communications device having an output port that forms the frame to be transmitted based on received data of the frame, the method comprising: determining whether there is present in the data of said frame at least one parameter related to the division of said frame; If so, initiating formation of the frame at the output port according to a cut-through transfer mode without waiting for receipt of all frame data; A method comprising:

2. The communication device includes a bridge having at least the output port and operating according to an OSI layer model, the OSI layer model comprising: a MAC sublayer that provides MAC services; a MAC client related upper layer; the underlying physical layer; Including, 2. The method of claim 1, wherein, when the parameter is present, the MAC client provides the MAC sublayer with a series of frame segments called "chunks" to perform frame transmission functions without interruption while the frame to be transmitted is not completely transferred through the MAC service layer.

3. 3. The method of claim 2, wherein the frame data further includes a chunk size parameter, and the chunk is passed incrementally to the MAC client each time a number of bits of the frame equal to the chunk size parameter is received from the physical layer.

4. 4. The method of claim 2 or 3, wherein the frame data further includes a chunk offset parameter indicating the position of a chunk within a series of bits that make up the frame relative to the beginning of the frame.

5. a primitive is initiated by the MAC client to request a transmission service from the MAC sublayer; chunks covering segments of frames to be transmitted; a chunk offset that targets the offset of the chunk relative to the beginning of the frame; The method according to any one of claims 2 to 4, further comprising defining a parameter related to:

6. 6. The method according to claim 2, wherein the frame sending function calls a procedure for encapsulating the frame data to be sent, the encapsulation procedure comprising checking whether a chunk is to be processed instead of the whole frame depending on whether a parameter chunkParamPresent is present or not.

7. 7. The method of claim 6, wherein the encapsulating step adds a preamble and a start frame delimiter to the beginning of the first chunk of the frame when the parameter is present.

8. 8. The method of claim 7 in combination with claim 5, wherein the first chunk is identified by a chunk offset of "0", thereby indicating the beginning of a new frame.

9. 9. The method according to claim 2, wherein, upon receiving a frame formed in accordance with the cut-through forwarding mode from another communication device, the MAC sublayer initiates a bit reception procedure including boundary indications of successive chunks to be passed to the MAC client from the bit sequence received from the physical layer.

10. 10. The method of claim 9, wherein while the last chunk of a received frame received in the cut-through forwarding mode has not been received by the MAC sublayer, a specific primitive indicates the successive chunks to be passed to the MAC client.

11. The method of claim 10 , wherein when the last chunk is received by the MAC sublayer, a general primitive is initiated to indicate the end of reception of the received frame.

12. 12. The method of claim 10 or 11, wherein a first chunk of the received frame is identified by a chunk offset of "0", thereby indicating the beginning of the received frame, the specific primitive further declares at least a destination address, a minimum chunk size is at least equal to a field bit length of the destination address, and the MAC sublayer initiates a procedure to decapsulate chunks of the received frame to indicate at least the boundaries of the destination address.

13. A tag is added to the frame data before transmission of the frame, the tag comprising: indicates that the frame was formed in accordance with the cut-through transfer mode; including at least one piece of data for performing a frame check when receiving a frame; When the communication device receives a frame from another communication device according to the cut-through forwarding mode, determining whether the tag is present in the frame; A method according to any preceding claim, further comprising reading the data in the tag, if present, to ascertain whether the frame has any errors.

14. 14. The method according to claim 1, wherein the parameters related to the splitting of the frame are declared among other parameters including at least a destination address and / or a source address, and the communication device, in the cut-through forwarding mode, starts forming the frame directly at the output port, ignoring the addresses.

15. 15. The method of claim 14, wherein a communication device that is not configured to implement the cut-through forwarding mode ignores the parameters related to splitting the frame and starts processing the frame data by taking into account the other parameters including at least the address.

16. A computer program comprising instructions which, when executed by a processor, cause the computer program to perform the method of any one of claims 1 to 15.

17. A communications device comprising processing circuitry for carrying out the method of any one of claims 1 to 15.

Images