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] This disclosure relates to telecommunications signal processing.

Background Art

[0002] The Ethernet-related standard specifications defined by the IEEE 802 standard specifications, particularly IEEE (trademark) 802.3 and IEEE 802.1, are based on the hierarchical protocol model introduced by the OSI basic reference model. In this model, protocol entities instantiated in a specific protocol layer communicate with other protocol entities instantiated in the same protocol layer. This communication occurring within a specific layer depends on the services provided by the immediately lower protocol layer.

[0003] The relative layer positions of protocol entities and protocol services are referenced by an index N. As an example, the (N) service is provided by the (N) entity that uses the (N - 1) service provided by the (N - 1) entity. The (N) service user is the (N + 1) entity.

[0004] Each service is provided to a single protocol entity at a service access point (SAP: Service Access Point). A specific (N) entity can support multiple N - SAPs and can use one or more (N - 1) SAPs. The SAP is an abstraction that marks the boundary between protocol specifications and defines the observable behavior between entities.

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

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

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

[0008] These parameters constitute the frame.

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

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

[0011] Figure 2 shows primitives processed by a MAC service (supported by MAC sublayers as defined in IEEE standard 802.3) which includes a MAC client (upper layer) and a physical layer (PHY, lower layer).

[0012] The parameters for these primitives are shown below. MA_DATA.request { destination_address, source_address, mac_service_data_unit, frame_check_sequence }.

[0013] The destination_address parameter specifies the MAC entity address of an individual MAC entity or a group of MAC entities. This parameter contains sufficient information to create the DA (Destination Address) field that is added to the beginning of the frame by the local MAC sublayer entity, along with any physical information.

[0014] The `source_address` parameter specifies individual MAC addresses, if present. 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 sent by the MAC sublayer entity. The MAC sublayer entity has sufficient information associated with `mac_service_data_unit` to determine the length of the data unit.

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

[0017] Upon receiving, the MAC sublayer entity inserts all MAC-specific fields (DA, SA, ...), passes the frame formed from this information to the lower protocol layer, and forwards it 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 can be an individual address specified by the DA field of the received frame, or it can 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 a 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] MA_DATA.indication is passed from the MAC sublayer entity to one or more MAC client entities in order to indicate that a frame destined for a 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 primitive of IEEE802.3 ● forms the corresponding MA_DATA.request by ignoring the priority parameter specified for M_UNITDATA.request, ● does not provide the priority parameter specified for M_UNITDATA.indication from the corresponding MA_DATA.indication, ● forms the corresponding MA_UNITDATA.indication by removing the frame_check_sequence parameter, ● does not map reception_status within the corresponding MA_UNITDATA.indication, and is mapped / conformed to each IEEE802.1 MA_UNITDATA.x primitive accordingly.

[0025] Regarding the IEEE standard 802.1 bridge, according to the VLAN bridge architecture, such a bridge comprises at least one bridge component, which includes the following. ● A MAC relay entity that interconnects the ports of the bridge, ● At least two ports, ● A higher layer entity.

[0026] The architecture of the VLAN bridge is shown in Figure 3. <00​MAC relay entities handle media access method-independent functions such as relaying frames between bridge ports, filtering frames, and learning filtering information. MAC relay entities use Enhanced Internal Sublayer Services (EISS) provided by each bridge port. EISS extends the Internal Sublayer Service (ISS) that provides the basic MAC service at the bridge port.

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

[0029] In this particular case, the primitives provided by 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] M_UNITDATA.request is converted to IEEE802.3 MA_DATA.request as follows: ● The destination_address and source_address parameters are passed without modification. ● The mac_service_data_unit may be padded in some cases 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 will be adjusted to include the added padding. ● The priority, drop_eligible, service_access_point_identifier, and connection_identifier parameters are ignored.

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

[0032] The EISS primitive adds three parameters to the ISS primitive. Of these parameters, vlan_identifier transmits the VID contained in the VLAN-Tag of the 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 as follows: ● Frame relay and filtering, ● Maintaining information necessary for filtering and relaying frames, ● Management.

[0034] These 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. ● Discard frames that do not transmit user data. ● If present, decrypt the priority and drop eligibility from the VLAN tag, and regenerate the priority as necessary. ● Assignment of VID to each received frame, ● Ensuring that each frame is limited to the active topology, ● Frame dropping to support management control across the active topology of each VLAN. ● Discarding frames after applying filtering information. ● Frame measurement, marking as eligible for drop if necessary, or discarding frames that exceed bandwidth limits. ● Transfer of received frames to other bridge ports, ● Selection of traffic class and queuing of frames by traffic class, ● Frame discarding to ensure that the maximum bridge transit delay is not exceeded. ● Prioritizing the discarding of drop-eligible frames to maintain QoS for other frames. ● Selection of sending queued frames, ● SDU mapping and FCS recalculation as needed. ● Frame discard due to exceeding the maximum transmittable SDU size. ● Selection of transmission access priority, ● Frame transmission.

[0035] The forwarding process is a set of actions performed by a MAC relay entity on a specific port (referred to as the "receiving port") for a particular frame. A frame can be forwarded for transmission on some ports (referred to as the "transmitting ports"), or discarded without being transmitted on other ports.

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

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

[0038] In the case of transmission, upon request from a MAC client, the data supplied by the client is used by the full-duplex MAC sublayer's transmission data encapsulation components to form a frame.

[0039] This component adds a preamble and frame start delimiter to the beginning of the frame, and optionally adds a pad to the end of the MAC service data unit to meet the minimum frame size requirement. It also adds the destination and source addresses, and optionally adds a frame check sequence for error detection. Frame transmission begins after the carrierSense signal is removed and the necessary inter-frame delay has occurred (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] The IEEE standard 802.3 defines the control flow for transmission operations, as shown in Figure 5.

[0042] In the case of reception, the physical layer detects the reception of a frame by synchronizing with the receive preamble and indicating the receiveDataValid signal (in the MAC sublayer). The physical layer then passes the decoded bits to the MAC sublayer, which discards the preamble and frame start delimiter. The received bits are collected as long as the receiveDataValid signal is active. Once the frame is discarded, it is truncated to an octet boundary and passed to the receive data decapsulation unit for processing.

[0043] The received data decapsulation unit passes the destination address (DA), source address (SA), MAC service data unit, and (optionally) frame check sequence (FCS), as well as a status code.

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

[0045] The IEEE 802.3 standard also shows the control flow for the receive operation, as shown in Figure 6.

[0046] The above overview of the full-duplex MAC sublayer indicates that the information entity processed by the IEEE standard 802.3 MAC sublayer is the entire frame.

[0047] During reception, the MAC sublayer waits for an instruction from the physical layer, via the receiveDataValid envelope signal, to indicate that bitwise reception of the frame is complete before initiating the frame decapsulation process and presenting the received frame to the MAC client via an instruction primitive.

[0048] Similarly, during transmission, the MAC client must provide the IEEE 802.3 MAC sublayer with all the information elements required by the MAC. This allows the IEEE 802.3 MAC sublayer to proceed with frame assembly and provide the frame to the physical layer for transmission bit by bit.

[0049] Therefore, MAC clients involved with ports on IEEE 802.1 compliant bridges (ISS or higher) also process entire frames, which are units of information manipulated by the forwarding process functions of MAC relay entities within the bridge.

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

[0051] This cumulative delay is detrimental 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, continuous segments that transmit enough information for the bridge's MAC relay entities to process. Such a forwarding principle is called "cut-through forwarding," and frames may be forwarded at the bridge's output ports before they are all received through the output ports.

[0053] Since cut-through transmission is not defined by the IEEE 802.3 or IEEE 802.1 standards, there is no defined method for identifying frames that are cut-through transmitted.

[0054] In cut-through mode transfers, processing the frame segment before the FCS calculated across the entire frame is confirmed results in: ● Identifying frames that are cut-through transmitted, ● Transfer process and, However, this carries the risk of incorporating erroneous frame information as input for making decisions.

[0055] This information includes other data fields contained in the DA, SA, and MAC service data units (e.g., VLAN-ID in VLAN-Tag). Neither the IEEE 802.3 MAC sublayer nor the IEEE 802.1 MAC client and forwarding process provides protection against such errors. [Overview of the project] [Problems that the invention aims to solve]

[0056] This disclosure aims to improve 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 carried out by a communication device having an output port that forms a frame to be transmitted based on received data of the frame, and the method To check whether at least one parameter related to frame division exists within the frame data, If present, according to the cut-through transfer mode, frame formation will begin at the output port without waiting for all frame data to be received, We propose a method that includes this.

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

[0059] Therefore, the aforementioned cut-through transmission mode makes it possible to begin transmitting the first bit of a frame even if the entire frame itself (i.e., its last bit) is not yet ready for transmission. This cut-through transmission mode is therefore in contrast to the normal store-and-forward mode, which is typically used for transmitting MAC Ethernet frames. In store-and-forward mode, the last bit must be processed before frame transmission can begin.

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

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

[0062] In one embodiment, the communication device includes a bridge (having the output and / or input ports described above) that operates according to the OSI layer model, and the OSI layer model is A MAC sublayer that provides MAC services, The higher layer related to the MAC client, Lower physical layer, Includes, When parameters for frame splitting exist, the MAC client provides a series of frame segments called "chunks" to the MAC sublayer, allowing the frame transmission function (TransmitFrame, as shown in the example below) to continue without interruption while the frame being sent is not fully transmitted through the MAC service layer.

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

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

[0065] In one embodiment, a specific primitive (referred to as "MA_DATA_CHUNK.request" in the following example) that requests a transmission service from the MAC sublayer is invoked by the MAC client, A chunk that targets a segment of the frame being sent, Chunk offset, which is the chunk offset relative to the beginning of the frame, Define the parameters related to this.

[0066] This offset parameter (referred to as "transmitChunkOffset" in the diagram and the following embodiments) makes it possible to identify the "0 offset" chunk, which in particular corresponds to the beginning of a frame, thereby making it possible to identify a new frame to be transmitted in cut-through transmission mode.

[0067] In one embodiment, the frame transmission function (referred to as "TransmitFrame" in the following example) invokes a procedure to encapsulate the frame data to be transmitted (referred to as "TransmitDataEncap" in the example). This procedure includes checking whether a chunk is processed instead of the entire frame, depending on whether a parameter (chunkPresent) exists.

[0068] In this embodiment, if parameters exist, this procedure can add a preamble and a start frame delimiter to the beginning of the first chunk of the frame.

[0069] Therefore, the usefulness of labeling the chunk offset, or more specifically the "0" offset of the first chunk, is evident from this embodiment.

[0070] In this embodiment, the first chunk is identified by a chunk offset of "0," which indicates the beginning of a new frame.

[0071] In 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 receive procedure (hereinafter referred to as "BitReceiver") from the bit string received from the physical layer, which includes a boundary representation of the consecutive chunks to be passed to the MAC client.

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

[0073] Instead, when the last chunk is received by the MAC sublayer, a generic primitive (hereinafter referred to as "MA_DATA.indication") is initiated to indicate the end of receiving the entire frame.

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

[0075] In one embodiment, the first chunk of a received frame is identified by a chunk offset of "0," thereby indicating the beginning of the received frame. In this embodiment, the aforementioned specific 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 to be equal to at least the field bit length of the destination address, and the MAC sublayer initiates a procedure (hereinafter referred to as "ReceiveChunkDecap") to deencapsulate the chunks of the received frame to indicate at least the boundary of the frame destination address from the first chunk (with an offset of "0").

[0076] The destination address is typically one piece of information available to a MAC client, and can be used, for example, to determine whether a frame is actually intended for that communication device or whether the frame should be forwarded to another communication device (and, in cut-through mode, immediately transmitted in chunks through the output port). More generally, the first chunk of data, large enough to include the Ethernet address (usually destination and source) and possibly other initial data in the frame (e.g., VLAN tag or cut-through mode tag as shown below), is useful in informing the MAC client (or a higher layer) to begin frame processing in the same way as in normal store-and-forward mode.

[0077] In one embodiment, a tag is added to the frame data before the frame is transmitted, and the tag is, This indicates that the frame was formed according to the cut-through transfer mode. Includes at least one piece of data for performing a frame check when a frame is received, When a communication device receives a frame from another communication device in cut-through transfer mode, Determine whether the tag exists in the frame, If present, read the data within the tag to check if the frame has an error.

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

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

[0080] Therefore, any 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 its communication capabilities.

[0081] This disclosure also covers computer programs including instructions, the instructions, when executed by a processor, causing the processor to carry out the methods described above.

[0082] This disclosure also relates to a communication device comprising processing circuitry for performing the method defined above.

[0083] Further details are presented in the following description of this specification, with reference to the attached drawings. [Brief explanation of the drawing]

[0084] [Figure 1] This figure shows MAC service primitives that can be used in bridging prior art communication devices as disclosed in the IEEE standard 802.1AC. [Figure 2] This figure shows primitives processed by conventional technologies using a MAC service (supported by the MAC sublayer as defined in IEEE standard 802.3) that includes a MAC client (upper layer) and a physical layer (PHY, lower layer). [Figure 3] This diagram shows a typical VLAN bridge architecture. [Figure 4] This diagram shows the typical forwarding process functionality in a bridge relay entity. [Figure 5] This diagram shows the control flow of the transmission operation as defined in the conventional IEEE standard 802.3. [Figure 6] This diagram shows the control flow of the receive operation as defined in the conventional IEEE standard 802.3. [Figure 7] This diagram shows the normal TransmitFrame operation according to the conventional IEEE standard 802.3. [Figure 8] This figure shows the TransmitDataEncap procedure that is called when the TransmitFrame operation shown in Figure 7 is initiated. [Figure 9] This figure shows the TransmitLinkMgmt procedure that is called when the TransmitFrame operation in Figure 7 is initiated. [Figure 10] This figure shows the BitTransmitter process involved when the TransmitFrame operation in Figure 7 is initiated. [Figure 11] This diagram shows the typical ReceiveFrame operation according to the conventional IEEE standard 802.3. [Figure 12] This figure shows the ReceiveLinkMgmt procedure that is called when the ReceiveFrame operation in Figure 11 is initiated. [Figure 13] This figure shows the BitReceiver process involved when the ReceiveFrame operation in Figure 11 is initiated. [Figure 14] This figure shows the ReceiveDataDecap procedure that is called when the ReceiveFrame operation in Figure 11 is initiated. [Figure 15] This diagram illustrates the operation of the MAC client transmission interface using conventional technology. In this diagram, the mac_service_data_unit parameter passed through the MAC client's MA_DATA.request primitive is a concatenation of the lengthOrType field and the data field passed to the MAC sublayer. [Figure 16]This diagram illustrates the operation of a MAC client receiving interface using conventional technology. In this diagram, the lengthOrType field and data payload field passed from the received MAC frame are concatenated to form the mac_service_data_unit parameter, which is passed using the MA_DATA.indication primitive. [Figure 17] This figure shows new parameters chunkParam, transmitChunkOffsetParam, and chunkParamPresent included in the frame to indicate the cut-through transfer mode in the TransmitFrame operation in accordance with this disclosure. [Figure 18] This figure shows the TransmitDataEncap procedure as modified in this disclosure to verify whether chunks are processed instead of the entire frame. [Figure 19] This figure shows an example of a state machine that specifies the operation of a MAC service interface that supports both cut-through transfer mode and normal store-and-forward mode. [Figure 20] This figure shows the BitReceiver procedure as modified in this disclosure to indicate chunk boundaries from the bit string received from the physical layer. [Figure 21] This figure shows the ReceiveChunk procedure and ReceiveChunkDecap procedure performed when receiving a received frame in the cut-through transfer mode according to this disclosure. [Figure 22] This diagram shows the parameters used for reception in either cut-through mode or store-and-forward mode, depending on whether the ReceiveChunk procedure is initiated. [Figure 23] This figure shows the format of tags included in a frame, indicating whether or not the frame is encoded according to a cut-through transfer mode, according to an example of an embodiment of the present disclosure. [Figure 24] This figure shows the details of the tag in Figure 23 in one example of an embodiment. [Figure 25] This figure schematically illustrates a communication device according to the present disclosure in one example of an embodiment. [Modes for carrying out the invention]

[0085] The following disclosure proposes changes to the operation of the framing functions (TransmitFrame and ReceiveFrame processes) and media management functions (BitReceiver and BitTransmitter processes) of the IEEE 802.3 MAC sublayer. In transmission, these changes allow frames to be transmitted as soon as the first segment becomes available to the MAC client. In reception, these changes allow consecutive segments of a frame to be delivered to the MAC client as soon as the first consecutive segment of the frame is extracted from the physical layer.

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

[0087] Tags are introduced to eliminate the risk that MAC clients and MAC relay entities may process erroneous or incomplete frame information transmitted in DA, SA, and MAC service data units. These tags are CTF (Cut-Through Frame) tags that include supplemental frame information and a check sequence that protects the information that MAC clients and MAC relay entities need to process.

[0088] The following disclosure first provides a detailed description of the frame transmission process, frame reception process, and primitive generation process as defined in IEEE standard 802.3 Annex 4A. Some simplifications have been made to align with changes that will be introduced later to support cut-through mode.

[0089] The modified transmission process, reception process, primitive generation process, and CTF-Tag-based protection are described later in this disclosure.

[0090] When transmitting IEEE 802.3 MAC sublayer frames, the TransmitFrame operation is synchronized with the actual frame transmission; that is, this operation continues throughout the entire frame transmission time.

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

[0092] The MAC client indicates whether to pass the frame check sequence for the frame via fcsParamPresent. If so, the MAC client also passes the fcsParamValue parameter to provide the 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 (representing 32-bit cyclic redundancy check) function to generate the frame padding (if necessary) and frame check sequence fields.

[0093] It should be noted that the only remaining element from the conventional Ethernet MAC specification is lengthOrTypeParam. How this is handled when generating request primitives between the MAC client and the MAC sublayer will be explained later in this disclosure.

[0094] As shown in Figure 9, the TransmitLinkMgmt procedure is responsible for transmitting frames. When deferenceMode is true, this procedure first delegates to the physical layer to ensure an appropriate inter-frame interval if the next packet is not ready.

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

[0096] Each time frame transmission begins, StartTransmit is called to notify the BitTransmitter process that bitwise transmission is ready to start. The transmission variables are used to synchronize TransmitLinkMgmt (which responds to events issued by the MAC client) with the BitTransmitter process, which is synchronized with 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. That is, this operation continues throughout the entire frame reception time, as shown in Figure 11, and completes when the frame is fully received. The frame fields are delivered through an output parameter with a ReceiveStatus status code.

[0098] If receivable, 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 description of ReceiveDataDecap). The returned ReceiveStatus indicates any possible errors in the frame, as shown in Figure 12.

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

[0100] As shown in Figure 13, the BitReceiver process is synchronized with the bit timing of the physical layer identified by the ReceiveBit operation and divides the received bits into frames.

[0101] The received variables are used to connect the asynchronous ReceiveLinkMgmt and BitReceiver processes.

[0102] PhysicalSignalDecap checks whether a valid Start Frame Delimiter (SFD) has been detected from the consecutive bits of the physical layer. If it has been detected, the SFD is discarded as shown in Figure 14.

[0103] The ReceiveDataDecap function is invoked by ReceiveFrame and, if the frame's address matches the expected value, returns the frame's fields to the MAC client. The returned ReceiveStatus indicates whether any detected transmission errors are present in the frame.

[0104] The destinationFieldOK function checks whether the destination address field of a received frame contains the address of the receiving station. When the station's Ethernet interface is in "promiscuous" mode, all destination addresses are considered valid. The same applies to the input ports of a bridge, and as a result, destinationFieldOK is always TRUE.

[0105] It should be noted that the only remaining element from the traditional Ethernet MAC specification is lengthOrTypeParam. The following explains how this is handled when generating instruction primitives between the MAC sublayer and the MAC client.

[0106] To simplify the explanation, we will not show any possible padding treatments (removals).

[0107] Currently, when implementing IEEE 802.3 MAC services, the MAC sublayer provides MAC clients with the services of sending and receiving MAC frames through the service primitives MA_DATA.request and MA_DATA.indication. The following state machine (shown in Figures 15 and 16, which are described below) defines the relationship between the TransmitFrame and ReceiveFrame functions and these service primitives.

[0108] Figure 15 illustrates the MAC client transmission interface operation. In this figure, the mac_service_data_unit parameter passed through the MAC client's MA_DATA.request primitive is a concatenation of the lengthOrType field and the data field passed to the MAC sublayer.

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

[0110] Figure 16 illustrates the operation of the MAC client receive interface. 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, which is passed using the MA_DATA.indication primitive.

[0111] Here, it should be noted that the MAC client in the bridge, i.e., ISS, can ignore the ReceiveStatus included in the primitive's parameters.

[0112] The following description details the changes made to the IEEE 802.3 MAC sublayer to support cut-through transmission. For this purpose, frames are processed in segments, which will be referred to as "chunks" below.

[0113] In the case of transmission, the MAC client provides a series of chunks to the TransmitFrame function, ensuring that the series of resulting bits passed to the physical layer are not interrupted while the transmitted frame is not being fully transferred through the MAC service interface.

[0114] In the case of receiving data, chunks are passed to the MAC client incrementally, with each chunk containing a number of bits equal to the chunk size being extracted from the physical layer.

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

[0116] The interface for TransmitFrame operation will be modified to support chunk parameters.

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

[0118] As shown in Figure 17, the parameter "chunkParam" is a chunk parameter of size chunkSize. Ideally, chunkSize should be the number of octets.

[0119] `transmitChunkOffsetParam` is the chunk offset included in the parameter `chunkParam`. This offset should preferably be expressed as the number of octets relative to the beginning of the frame.

[0120] chunkParamPresent indicates whether a chunk is passed as a parameter to TransmitFrame. If this is TRUE, TransmitFrame accepts chunkParam and transmitChunkOffsetParam as input parameters and ignores all other frame parameters. If this is FALSE, it accepts the set of parameters defined in IEEE standard 802.3 as input and ignores chunkParam and transmitChunkOffsetParam.

[0121] In cut-through mode, the MAC client's responsibility is to correctly insert the various fields of the frame—namely, the destination and source addresses, the MAC service data unit, and the FCS—into the consecutive chunks that the MAC client 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 that it is aligned on an octet boundary.

[0122] As shown in the example in Figure 18, the TransmitDataEncap procedure has been modified to check whether chunks are processed instead of the entire frame. If chunkParamPresent is TRUE, the only action this process takes is to append the preamble and SFD to the beginning of the chunk. In cut-through operation, TransmitDataEncap does not process the conventional frame parameters (address, MAC service data unit, FCS).

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

[0124] The TransmitLinkMgmt procedure, StartTransmit procedure, and BitTransmitter procedure remain unchanged compared to those specified in IEEE standard 802.3.

[0125] In the case of the CTF MAC transmission service, a new primitive can be invoked by the MAC client, with the parameter being: ● Chunk: Segments of the transmitted frame, ● transmitChunkOffset: The chunk offset relative to the beginning of the frame, It is defined as MA_DATA_CHUNK.request, which receives the data.

[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 a MAC service interface that supports both cut-through mode and store-and-forward mode.

[0128] A new state, CONTINUE_TRANSMIT_FRAME, is introduced. This state updates the variables (lastTransmitBit, OutgoingFrame[]) that are processed 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, in cut-through mode, it corresponds to the last bit of the last received chunk (the last bit transmitted of the last received chunk). 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 having finally ended.

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

[0131] When in cut-through mode, the MAC client continues to send consecutive chunks of frames following the initial chunk by further invoking MA_DATA_Chunk.request, and as a result, when the state machine enters the CONTINUE_TRANSMIT_FRAME state, it updates the lastTransmitBit variable and causes 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., if the BitTransmitter process has finished sending bits for the previous chunk and set the transmit variable to 0, the invocation of the MA_DATA_CHUNK.request primitive will be ignored until the MA_DATA_CHUNK.request primitive is invoked to send the initial frame chunk, and the invocation of any further primitives will also be ignored.

[0133] In that case, the truncated, and possibly excessively short, frame is sent (using the lastTransmitBit instruction process described above to terminate frame processing if necessary).

[0134] When receiving a CTF MAC sublayer frame, the ReceiveFrame behavior remains unchanged. Once receivable, this behavior first calls the ReceiveLinkMgmt procedure, and then the ReceiveDataDecap procedure.

[0135] The ReceiveLinkMgmt and StartReceive procedures remain unchanged, and while the physical layer is detecting bits belonging to the physical frame, frame bit transfer is initiated between the physical layer and the MAC sublayer.

[0136] The ReceiveDataDecap procedure remains unchanged, performing the same frame check and field deencapsulation operations.

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

[0138] As long as receiveDataValid is set to TRUE by the physical layer, consecutive bits decoded by the physical layer are accumulated to form a received frame (incomingFrame[]). When a number of bits equivalent to receiveChunkSize are received, the availability of the chunk (a segment of incomingFrame[]) is detected (receiveChunk), as shown in Figure 21, and the ReceiveChunk procedure is called with the chunk's parameters, namely the chunk's offset (receiveChunkOffset) and the bit array that makes up the chunk (receiveChunk[]).

[0139] The parameter `receiveChunkSize` is fixed and is set through configuration procedures not described herein. Its value is preferably an octet.

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

[0141] Additionally, the ReceiveChunk procedure returns a signal set to TRUE upon completion. This signal is used by the CTF MAC Receive Service Status Machine to generate a chunk availability indicator primitive directed to MAC clients.

[0142] The CTF MAC receiving service status machine processes instructions for receiving the entire frame in the same way for both cut-through and store-and-forward operating modes. In cut-through mode, the last chunk of the received frame is indicated by sending the normal primitive MA_DATA.indication.

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

[0144] 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 transmitted by the frame when the received chunk is the first chunk of the frame and its length is longer than the length of the address. ● source_address: The source address transmitted by the frame when the received chunk is the first chunk of the frame and its length is longer than or twice the length of the address. ● msdu_chunk: The MAC service data unit, or part thereof, transmitted by the frame, if the received chunk is the first chunk of the frame and its length is longer than twice the length of the address.

[0145] The store-and-forward MAC client is 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 the ReceiveFrame operation, and while signal reception is activated by the ReceiveLinkMgmt procedure and maintained by the BitReceiver procedure, the MAC client is notified of chunk reception each time a frame fragment of receiveChunkSize is received.

[0147] Once a frame is fully received, i.e., the received signal is deactivated, the IEEE 802.3 MA_DATA.indication standard is passed to the MAC client, and it waits for the next frame (and chunk) to be received.

[0148] Returning to Figure 3, the forwarding process included in the bridge's relay entity performs various actions on the received frame depending on the contents of some of its data fields and their lengths.

[0149] A cut-through MAC client must be able to determine whether to cut through or store-and-forward incoming frames. To do this, the cut-through MAC client requires some classification information. This classification information is preferably present in the first received frame chunk (when minimum latency must be achieved).

[0150] Relay and classification information can be the destination and source addresses, as well as additional information included in the MAC service data unit. This is true, 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 included in the VLAN-Tag (as defined in IEEE standard 802.1Q), which is contained in the first two octets of the MAC service data unit, in most application configurations.

[0151] To avoid incorrect transfer or classification decisions, an error detection code can be inserted within the frame immediately following the information required for these decisions. This error detection code will be referred to below as an intermediate check sequence.

[0152] Furthermore, frame length information can be explicitly indicated in a separate information field protected by an intermediate check sequence.

[0153] A tag referred to as "CTF-Tag" below is defined as one that holds the fields shown in Figure 23, which are listed below. - Defines the tag type (CTF-Tag): Ethertype: 2 bytes, - 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 IEEE registration authorities.

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

[0156] FRAME_LEN is an octet value that is the sum of the lengths of the destination address, source address, MAC service data unit, and FCS.

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

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

[0159] Figure 24 shows the frame format including the CTF-Tag.

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

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

[0162] Figure 25 shows an example of a communication device DEV including a bridge BR having an input port IP and an output port EP, linked to a processing circuit including a processor PROC and memory MEM. Memory MEM stores at least instruction data of the computer program according to this disclosure, and processor PROC can access memory MEM to read the instruction data and perform the methods described above (in transmission through the output port or reception through the input port).

Claims

1. A method for transmitting an Ethernet MAC frame, the method being carried out by a communication device having an output port that sequentially forms and transmits frames based on received data. The communication device comprises at least the output port and a bridge that operates according to the OSI layer model, and the OSI layer model is A MAC sublayer that provides MAC services, Higher layers related to MAC clients, The lower physical layer, Includes, The aforementioned method, To confirm whether at least one first parameter related to the division of the frame exists in the aforementioned data, When the first parameter exists, the MAC client provides the MAC sublayer with a series of frame segments called "chunks" to perform the frame transmission function without interruption while the transmitted frame has not been fully transferred through the MAC service interface, and, in accordance with the cut-through transfer mode, to begin forming the frame at the output port without waiting for the reception of all the data. Methods that include...

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

3. The method according to claim 1 or 2, wherein the data further includes, as the first parameter, a chunk offset parameter that indicates the position of a chunk in a series of bits constituting the frame relative to the beginning of the frame.

4. A primitive that requests a transmission service from the MAC sublayer is invoked by the MAC client, A chunk that targets a segment of the frame being sent, A chunk offset that targets the offset of the chunk relative to the beginning of the frame, The method according to claim 1 or 2, wherein a parameter related to is defined as the first parameter.

5. The method according to claim 1 or 2, wherein the frame transmission function calls a procedure for encapsulating the data relating to the frame to be transmitted, and the encapsulation procedure includes checking whether a chunk is processed instead of the entire frame, depending on whether the first parameter chunkParamPresent exists.

6. The method according to claim 5, wherein the encapsulation procedure, when the parameter chunkParamPresent is present, adds a preamble and a start frame delimiter to the beginning of the first chunk of the frame.

7. The method according to claim 6, wherein the first chunk is identified by a chunk offset of "0", thereby indicating the beginning of a new frame.

8. The method according to claim 1 or 2, wherein when the MAC sublayer receives a frame formed according to the cut-through transfer mode from another communication device, the MAC sublayer initiates a bit reception procedure which includes a boundary representation of a contiguous chunk to be passed to the MAC client from the bit sequence received from the physical layer.

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

10. The method according to claim 9, 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.

11. The method according to claim 9, wherein the first chunk of the received frame is identified by a chunk offset of "0", thereby indicating the beginning of the received frame, the identified primitive further declares at least a destination address, the minimum size of the chunk is equal to at least the field bit length of the destination address, and the MAC sublayer initiates a procedure to deencapsulate the chunk of the received frame to indicate at least the boundary of the destination address.

12. The tag is added to the data before the frame is transmitted, and the tag is, This indicates that the frame was formed according to the cut-through transfer mode. Includes at least one piece of data for performing a frame check when a frame is received, When the aforementioned communication device receives a frame from another communication device in accordance with the cut-through transfer mode, Determine whether the aforementioned tag is present in the aforementioned frame. The method according to claim 1 or 2, wherein, if present, the data in the tag is read to determine whether the frame has an error.

13. The method according to claim 1 or 2, wherein the parameters relating 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 transfer mode, ignores the destination address and / or source address and directly forms the frame at the output port.

14. The method according to claim 13, wherein a communication device not configured to perform the cut-through transfer mode begins processing the data by ignoring the parameters related to the splitting of the frame and taking into account other parameters, including at least the destination address and / or source address.

15. A computer program including instructions, wherein, when executed by a processor, the instructions cause the method according to claim 1 or 2 to be carried out.

16. A communication device comprising a processing circuit for performing the method according to claim 1 or 2.

Images