CN112491492B

CN112491492B - Method and device for time slot negotiation

Info

Publication number: CN112491492B
Application number: CN201911008430.7A
Authority: CN
Inventors: 易科; 李旺乾; 胡永健; 何向
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2019-09-12
Filing date: 2019-10-22
Publication date: 2022-03-08
Anticipated expiration: 2039-10-22
Also published as: CN112491492A

Abstract

The application relates to a time slot negotiation method and equipment. The method comprises the following steps: a sending end network device TX sends a first flexible Ethernet Flexe overhead frame to a receiving end network device RX, and the first flexible Ethernet Flexe overhead frame is used for requesting the main/standby switching of a time slot allocation table; while the RX is in the restart state, it does not respond to the first FlexE overhead frame received. And the RX sends a second Flexe overhead frame which is refreshed routinely to the TX, and the TX determines that the second Flexe overhead frame is not a response to the first Flexe overhead frame according to indication information carried by the second Flexe overhead frame. And the TX sends a third Flexe overhead frame and requests the main-standby switching of the time slot allocation table again. With the method of the present application, TX can determine whether a received FlexE overhead frame is a response by RX to its issued slot negotiation request. Therefore, the operation of the time slot allocation table error switching of the TX side caused by RX error response can be avoided, and the service interruption possibly brought by the existing time slot negotiation mechanism is effectively reduced.

Description

Method and device for time slot negotiation

Technical Field

The present application relates to the field of communications, and in particular, to a method, device, system, and storage medium for timeslot negotiation.

Background

The flexible Ethernet (Flex Ethernet, Flexe) technology is an interface technology for realizing service isolation bearing and network fragmentation of a bearing network, develops rapidly in two years, and is widely accepted by various large standard organizations. The FlexE standard originally originated from the Optical Internet Forum (OIF) interface physical layer standard, and has the characteristics of flexible and adjustable bandwidth, data isolation, perfect adaptation to 5G services, and the like. The FlexE technology introduces a flexible ethernet protocol layer (which may also be referred to as a FlexE Shim layer) on the basis of IEEE802.3, and realizes decoupling of a Medium Access Control (MAC) layer and a physical link interface layer (which may also be referred to as a PHY), thereby realizing flexible rate matching. Based on a Time Division Multiplexing (TDM) distribution mechanism, Flex Shim schedules and distributes data of a plurality of FlexE clients to a plurality of different sub-channels according to a Time slot mode, so that hard isolation of transmission pipeline bandwidth is realized, one service data stream can be distributed to one or a plurality of Time slots, and matching of services with various rates is realized.

According to the current OIF standard definition, the Flexe Shim layer embodies the time slot mapping relationship in a Flexe client and a Flexe Group and the working mechanism of a calander in a mode of defining an Overhead Frame (English: Overhead Frame, OH Frame) and an Overhead MultiFrame (English: OH MultiFrame). In the current FlexE overhead frame timeslot negotiation mechanism, when a sending end sends a timeslot table allocation table switching request (which may also be referred to as timeslot negotiation request) to a receiving end, the receiving end restarts due to some reasons (e.g., device power down, related service unicast failure, single board hard reset for failure recovery, etc.), and at this time, there is a case that the receiving end responds incorrectly, thereby causing service interruption from the sending end to the receiving end. Therefore, how to effectively avoid the influence of the above situation on the FlexE service is a problem to be solved at present.

Disclosure of Invention

The application provides a time slot negotiation method, network equipment, a communication system, a storage medium and a computer program product, which solve the problem of flow interruption caused by receiving end false response in the current Flexe overhead frame time slot negotiation mechanism. By adopting the technical scheme of the application, the accuracy of time slot negotiation between network equipment can be effectively improved, and service interruption can be effectively prevented.

In a first aspect, the present application provides a timeslot negotiation method, which is performed by a first network device, and includes: sending a first flexible Ethernet (FlexE) overhead frame to a second network device, wherein the first FlexE overhead frame comprises first request information, and the first request information is used for requesting the second network device to switch a standby time slot allocation table into a main time slot allocation table; receiving a second Flexe overhead frame sent by the second network equipment; determining that the second Flexe overhead frame is not a response to the first request information according to first indication information in the second Flexe overhead frame; and sending a third FLexE overhead frame to the second network device, where the third FLexE overhead frame includes second request information, and the second request information is used to request the second network device to switch the standby timeslot allocation table to the active timeslot allocation table.

In the method, after a first network device sends a first FlexE overhead frame for a time slot negotiation request to a second network device, according to first indication information carried in a received second FlexE overhead frame, it can be determined that the second FlexE overhead frame is not a response to the time slot negotiation request sent by the second FlexE overhead frame. Therefore, the first network device does not perform the active/standby switching of the timeslot allocation table. The first network device sends a third FLexE overhead frame for the time slot negotiation request to the second network device again, wherein the second network device is requested to perform the active-standby switching of the time slot allocation table through second request information carried in the third FLexE overhead frame. Therefore, the first network device can avoid the mistaken identification of the second FLExE overhead frame as the response of the second network device to the time slot negotiation request, and avoid the mistaken switching of the time slot allocation table. The method effectively prevents service interruption caused by misoperation due to the current time slot negotiation mechanism.

In an optional design, the method may further include: receiving a fourth Flexe overhead frame sent by the second network equipment;

and determining that the fourth Flexe overhead frame is a response to the second request information according to second indication information carried in the fourth Flexe overhead frame.

In an optional design, the method further comprises: and in response to determining that the fourth FlexE overhead frame is a response to the second request message, the first network device switches the standby timeslot allocation table to the active timeslot allocation table.

In an optional design, the method further comprises: and the first network equipment sends a fifth Flexe overhead frame to the second network equipment to indicate the second network equipment to switch the standby time slot allocation table into the active time slot allocation table.

In a second aspect, the present application provides a timeslot negotiation method, which is performed by a second network device, and includes: receiving a first Flexe overhead frame sent by a first network device, wherein the first Flexe overhead frame comprises first request information, and the first request information is used for requesting the second network device to switch a standby time slot allocation table into a main time slot allocation table;

sending a second Flexe overhead frame to the first network device, the second Flexe overhead frame including first indication information for indicating that the second Flexe overhead frame is not a response to the first request information;

and receiving a third FlexE overhead frame sent by the first network device, where the third FlexE overhead frame includes second request information, and the second request information is used to request the second network device to switch the standby timeslot allocation table to the active timeslot allocation table.

In the method, the flexible ethernet FlexE overhead frame routinely sent by the second network device to the first network device includes indication information for indicating that the flexible ethernet FlexE overhead frame is not a response to the flexible ethernet FlexE overhead frame sent by the first network device. Therefore, the first network device can determine, according to the indication information carried in the received second FlexE overhead frame, that the second FlexE overhead frame is not a response to the slot negotiation request sent by the second FlexE overhead frame. Therefore, the first network device does not perform the active/standby switching of the timeslot allocation table. The second network device may receive a third FLexE overhead frame for the timeslot negotiation request sent again by the first network device, and at this time, if the second network device is ready for the active-standby switching of the timeslot allocation table, the second network device may execute a related operation for the active-standby switching of the timeslot allocation table according to an indication of the second request information carried in the third FLexE overhead frame. Thereby, the second network device can perform a correct slot negotiation with the first network device. The method effectively ensures the time slot negotiation and prevents the service interruption caused by the current time slot negotiation mechanism.

In an optional design, the method may further include: the second network device sends a fourth Flexe overhead frame to the first network device;

wherein the fourth FlexE overhead frame carries second indication information, and the second indication information is used to indicate that the fourth FlexE overhead frame is a response to the second request information.

In an optional design, the method further comprises: and the second network equipment receives a fifth Flexe overhead frame sent by the first network equipment, and switches the standby time slot allocation table into the active time slot allocation table according to the indication of the fifth Flexe overhead frame.

In an optional design, the first request information is a first request packet carried in a management channel of the first FlexE overhead frame.

In an optional design, the first request information is information indicated by a CR field and a CCC field carried in the first FlexE overhead frame. Wherein, the values of the CR field and the CCC field are different.

In an optional design, the first indication information is information indicated by a management channel of the second FlexE overhead frame, the management channel of the second FlexE overhead frame does not carry a first response packet, and the first response packet is used to indicate that the second FlexE overhead frame is a response to the first request information.

In an optional design, the first indication information is information indicated by a first field in the second FlexE overhead frame, and the first field is different from a timeslot assignment table switch acknowledgement CA field of the second FlexE overhead frame.

In an optional design, the first indication information is information indicated by a timeslot assignment table switch acknowledgement CA field of the second FlexE overhead frame, the first indication information is used to indicate that the second FlexE overhead frame is not a response to the first request information, and the first indication information is not used to indicate a timeslot assignment table.

In an optional design, the second indication information is information indicated by a management channel of the fourth FlexE overhead frame, the management channel of the fourth FlexE overhead frame carries a second response packet, and the second response packet is used to indicate that the fourth FlexE overhead frame is a response to the second request information.

In an optional design, the second indication information is information indicated by a timeslot assignment table switch acknowledgement CA field of the fourth FlexE overhead frame, the second indication information is used to indicate that the fourth FlexE overhead frame is a response to the second request information, and the second indication information is not used to indicate a timeslot assignment table.

In an optional design, the second indication information is information indicated by a second field in the fourth FlexE overhead frame, and the second field is different from a timeslot assignment table switch acknowledgement CA field of the fourth FlexE overhead frame.

In a third aspect, the present application provides a first network device, which includes a transceiver unit and a processing unit, where when the first network device executes the method described in any one of the optional designs of the first aspect and the first aspect, the transceiver unit is configured to perform a transceiving operation, and the processing unit is configured to perform an operation other than transceiving. For example, when the first network device executes the method according to the first aspect, the transceiver unit is configured to send a first flexible ethernet FlexE overhead frame to a second network device, receive a second FlexE overhead frame sent by the second network device, and send a third FlexE overhead frame to the second network device. The processing unit is configured to determine, according to the first indication information in the second FlexE overhead frame, that the second FlexE overhead frame is not a response to the first request information.

In a fourth aspect, the present application provides a second network device, which includes a transceiver unit and a processing unit, where the transceiver unit is configured to perform a transceiving operation when the second network device performs the method described in any one of the optional designs of the second aspect and the second aspect, and the processing unit is configured to perform an operation other than transceiving. For example, when the second network device executes the method according to the second aspect, the transceiver unit is configured to receive a first flexible ethernet FlexE overhead frame sent by a first network device, send a second FlexE overhead frame to the first network device, and receive a third FlexE overhead frame sent by the first network device. The processing unit is configured to generate the second FlexE overhead frame.

In a fifth aspect, the present application provides a first network device comprising a memory and a processor coupled to the memory. The memory has stored therein instructions that, when read by the processor, cause the first network device to perform the method of any one of the first aspect and the optional design of the first aspect.

In a sixth aspect, the present application provides a second network device comprising a memory and a processor coupled to the memory. The memory has stored therein instructions that, when read by the processor, cause the second network device to perform the method of any of the second aspects and their alternative designs.

In a seventh aspect, the present application provides a first network device, including a communication interface and a processor connected to the communication interface, where the first network device is configured to perform the method described in any one of the optional designs of the first aspect and the first aspect through the communication interface and the processor. The communication interface is used for executing transceiving operation, and the processor is used for executing operations except transceiving. For example, when the first network device executes the method of the first aspect, the communication interface is configured to send a first flexible ethernet FlexE overhead frame to a second network device, receive a second FlexE overhead frame sent by the second network device, and send a third FlexE overhead frame to the second network device. The processor is configured to determine that the second FlexE overhead frame is not a response to the first request information according to the first indication information in the second FlexE overhead frame.

In an eighth aspect, the present application provides a second network device, including a communication interface and a processor connected to the communication interface, where the second network device is configured to perform the method described in any one of the optional designs of the second aspect and the second aspect through the communication interface and the processor. The communication interface is used for executing transceiving operation, and the processor is used for executing operations except transceiving. For example, when the first network device executes the method according to the second aspect, the communication interface is configured to receive a first flexible ethernet FlexE overhead frame sent by the first network device, send a second FlexE overhead frame to the first network device, and receive a third FlexE overhead frame sent by the first network device. The processor is configured to generate the second FlexE overhead frame.

In a ninth aspect, the present application provides a communication system, including the first network device according to any one of the third aspect, the fifth aspect or the seventh aspect, and the second network device according to any one of the fourth aspect, the sixth aspect or the eighth aspect.

In a tenth aspect, the present application provides a computer-readable storage medium comprising computer-readable instructions which, when executed on a computer, cause the computer to perform the method of any one of the possible designs of the first aspect, the second aspect, the first aspect, or any one of the possible designs of the second aspect described above.

In an eleventh aspect, the present application provides a computer program product comprising a computer program which, when run on a computer, causes the computer to perform the method of any one of the possible designs of the first aspect, the second aspect, the first aspect or any one of the possible designs of the second aspect as described above.

Drawings

FIG. 1 is a diagram of a Flexe generic architecture based on a flexible Ethernet protocol;

FIG. 2 is a schematic diagram of the slot allocation of the Flexe Group across 4 physical link interfaces (aggregating 4 PHYs);

fig. 3 is a schematic view of an application scenario of a FlexE communication system according to the present application;

FIG. 4 is a schematic diagram of a process for transmitting data using Flexe technology to which the present application relates;

FIG. 5 is a schematic diagram of the structure of an overhead frame and an overhead multiframe of a 100GE interface given in the OIF IA-FLEXE-02.1 standard;

FIG. 6 is a flowchart illustrating a method of time slot negotiation;

FIG. 7 is a schematic diagram illustrating a scenario for explaining the problem of causing an RX false answer;

fig. 8 is a schematic diagram of a timeslot negotiation method provided in the present application;

fig. 9 is a schematic diagram of a message format for expanding overhead frames according to the present application;

fig. 10 is a flowchart illustrating a timeslot negotiation processing method provided in the present application;

fig. 11 is a flowchart illustrating a timeslot negotiation processing method provided in the present application;

fig. 12a is a schematic diagram of a CR Request message format provided in the present application;

fig. 12b is a schematic diagram of a CR Ack packet format provided in the present application;

fig. 12c is a schematic diagram of an LLDP packet format provided in the present application;

fig. 12d is a schematic diagram of a CR Request message format provided in the present application;

fig. 12e is a schematic diagram of a CR Request message format provided in the present application;

fig. 13 is a flowchart illustrating a timeslot negotiation processing method provided in the present application;

fig. 14 is a flowchart illustrating a timeslot negotiation method provided in the present application;

fig. 15 is a schematic structural diagram of a network device according to an embodiment of the present application;

fig. 16 is a schematic structural diagram of a network device according to an embodiment of the present application;

fig. 17 is a schematic structural diagram of a network device according to an embodiment of the present application;

fig. 18 is a schematic structural diagram of a network device according to an embodiment of the present application.

Detailed Description

Ordinal numbers such as "1", "2", "3", "4", "first", "second", "third", and "fourth" in this application are used to distinguish between different objects and are not used to limit the order of a plurality of objects. Furthermore, the terms "comprising" and "having" are not exclusive. For example, a process, method, system, article, or apparatus that comprises a list of steps or elements is not limited to only those steps or elements listed, but may include other steps or elements not listed.

The prior art relating to Flexe referred to in this application can be found in the Flexe standards, IA OIF-FLEXE-01.0, IA OIF-FLEXE-02.0, or IA OIF-FLEXE02.1, established by OIF, which are incorporated herein by reference in their entirety.

Fig. 1 illustrates a FlexE generic architecture diagram based on the flexible ethernet protocol. As shown in fig. 1, the FlexE Group includes 4 PHYs. The FlexE Client represents a Client data stream transmitted in a specified time slot (one time slot or a plurality of time slots) on a FlexE Group, one FlexE Group can carry a plurality of FlexE clients, one FlexE Client can correspond to one to a plurality of user service data streams (also called MAC clients), and the FlexE Shim layer provides data adaptation and conversion from the FlexE Client to the MAC clients. The Flexe can support the mapping and transmission of any plurality of different Flexe clients on any group of PHYs, thereby realizing the functions of PHY binding, channelization, subrate and the like. The multiple PHYs are combined together to form a FlexE Group (also called FlexE Group in english) for carrying one or multiple FlexE client data streams distributed and mapped through a FlexE Shim layer. Taking 100GE PHY as an example, the FlexE Shim layer may divide each 100GE PHY in the FlexE Group into data carrying channels of 20 slots (slots), where each slot corresponds to a bandwidth of 5 Gbps.

Fig. 2 schematically shows a schematic diagram of the slot allocation case of the FlexE Group across 4 physical link interfaces (aggregating 4 PHYs). As shown in fig. 2, each PHY has 20 slots, so the FlexE Group has 20 × 4 slots. As shown in fig. 2, the FlexE Group in fig. 1 includes 4 PHYs, which are PHY a 1201, PHY B1202, PHY C1203 and PHY D1204, respectively. A FlexE Group corresponds to a slot allocation table (english may also be called a calendar); the timeslot mapping table corresponding to a single physical link included in one FlexE Group may be referred to as a sub-timeslot allocation table (english may be referred to as sub-calendar). The FlexE calendar may consist of one or more sub-calendars. Each sub-calendar may indicate how 20 slots (slots) on the single physical link are allocated to a respective FlexE client. That is, each sub-calendar may indicate a corresponding relationship of a time slot and a FlexE client on the single physical link. As shown in fig. 2, each PHY may correspond to 20 slots, which are indicated by slots 0 through 19, respectively. Fig. 2 shows a schematic diagram of 20 slots corresponding to each PHY in PHY a 1201, PHY B1202, PHY C1203, and PHY D1204, respectively.

Fig. 3 shows a schematic application scenario of the FlexE communication system according to the present application. As shown in fig. 3, the FlexE communication system 100 includes a network device 1, a network device 2, a user device 1, and a user device 2. The network device 1 may be an intermediate node, in which case the network device 1 is connected to the user equipment 1 via other network devices. The network device 1 may be an edge node, in which case the network device 1 is directly connected to the user equipment 1. The network device 1 may be an intermediate node, in which case the network device 1 is connected to the user equipment 1 via other network devices. The network device 1 may also be an edge node, in which case the network device 1 is directly connected to the user equipment 1. The network device 2 may be an intermediate node, in which case the network device 2 is connected to the user equipment 2 via other network devices. The network device 2 may also be an edge node, in which case the network device 2 is directly connected to the user device 2. The network device 1 comprises a FlexE interface 1 and the network device 2 comprises a FlexE interface 2. The FlexE interface 1 is adjacent to the FlexE interface 2. Each FlexE interface comprises a sending port and a receiving port, and is different from a traditional ethernet interface in that one FlexE interface can bear a plurality of clients, and the FlexE interface serving as a logical interface can be formed by combining a plurality of physical interfaces. The flow of traffic data in the forward channel shown in fig. 3 is shown by solid arrows in fig. 3, and the flow of traffic data in the reverse channel is shown by dashed arrows in fig. 3. The transmission channel of the embodiment of the invention takes a forward channel as an example, and the flow direction of the service data in the transmission channel is user equipment 1, network equipment 2 and user equipment 2

It should be understood that fig. 3 only shows 2 network devices and 2 user devices by way of example, and the network may include any other number of network devices and user devices, which is not limited by the embodiments of the present application. The FlexE communication system shown in fig. 3 is only an example, and the application scenario of the FlexE communication system provided by the present application is not limited to the scenario shown in fig. 3. The technical scheme provided by the application is suitable for all network scenes using the Flexe technology for data transmission.

The process of the network device 1 and the network device 2 shown in fig. 3 for transmitting data using the FlexE technology is further described below with reference to fig. 4.

As shown in FIG. 4, PHY1, PHY2, PHY3, and PHY4 are bound together as a Flexe group. The network device 1 and the network device 2 are connected through a FlexE group interface, that is, the FlexE interface 1 is connected with the FlexE interface 2. The above-mentioned FlexE group interface may also be referred to as a FlexE interface. The FlexE group interface is a logical interface formed by binding a group of physical interfaces. The Flexe group interface carries 6 clients in total, namely client1 to client 6. Wherein, the data of the client1 and the client2 are mapped and transmitted on the PHY 1; data mapping of client3 is transmitted on PHY2 and PHY 3; data mapping of client4 is transmitted on PHY 3; data maps for client5 and client6 are transmitted on PHY 4. Different Flexe clients map and transmit on the Flexe group, and the binding function is realized. Wherein:

FlexE group: also referred to as a bundle group. Each FlexE group includes a plurality of PHYs having a logically bundled relationship. By logically bundled, it is meant that there may be no physical connection between different PHYs, and thus, multiple PHYs in a FlexE group may be physically independent. The network device in the FlexE can identify which PHYs are contained in one FlexE group by the numbers of the PHYs, so as to realize the logical binding of a plurality of PHYs. For example, the number of each PHY may be identified by a number between 1-254, with 0 s and 255 being reserved numbers. The number of one PHY may correspond to one interface on the network device. The same number is used between two adjacent network devices to identify the same PHY. The numbers of the individual PHYs included in one FlexE group do not have to be consecutive. Normally, there is one FlexE group between two network devices, but the application does not limit that there is only one FlexE group between two network devices, that is, there may be multiple FlexE groups between two network devices. One PHY may be used to carry at least one client, and one client may be transmitted on at least one PHY.

The Flexe client corresponds to various user interfaces of the network and is consistent with the traditional service interface in the existing IP/Ethernet network. The FlexE client can be flexibly configured according to the bandwidth requirement, and supports ethernet MAC data streams of various rates (such as 10G, 40G, n × 25G data streams, even nonstandard rate data streams), for example, the data streams can be delivered to the FlexE shim layer by means of 64B/66B coding. A FlexE client can be interpreted as an ethernet stream based on one physical address. Clients transmitting through the same FlexE group need to share the same clock and these clients need to adapt according to the allocated slot rate.

Flexe shim is a core framework for realizing Flexe technology based on a calendar time slot distribution mechanism as an additional logic layer inserted between MAC and PHY (PCS sublayer) of a traditional Ethernet framework. The main role of FlexE shim is to slice data according to the same clock and encapsulate the sliced data into pre-divided slots (slots). And then, mapping each divided time slot to a PHY in a Flexe group for transmission according to a pre-configured time slot allocation table. Where each slot is mapped to one PHY in a FlexE group.

Calender: the slot allocation table may also be referred to as a slot table. A FlexE Group corresponds to a calendar, and a slot mapping table corresponding to a single physical link (PHY) included in one FlexE Group may be referred to as a sub-slot allocation table (english). The FlexE calendar may consist of one or more sub-calendars. Each sub-calendar may indicate how 20 slots (which may be written as slots in english) on the single physical link are allocated to a corresponding FlexE client. That is, each sub-calendar may indicate a corresponding relationship of a time slot and a FlexE client on the single physical link. As defined in the current standard, two callers are specified in each FlexE overhead frame, which are the current primary slot table (calller a) and the standby slot table (calller B).

Flexe constructs a fixed frame format for physical interface transmission and performs TDM time slot division. Next, the conventional FlexE frame format is exemplified. The slot granularity of FlexE may be 66B, corresponding to carrying one 64B/66B coded block, with each 64/66B coded block carried in a slot. One FlexE frame comprises 8 rows, the first 64B/66B bit block position of each row is a FlexE overhead block, and a payload area for time slot division is behind the overhead block, and the payload area takes 66 bits as granularity and corresponds to 20x1023 66 bit bearing spaces. Taking the 100GE interface as an example, the bandwidth of the 100GE interface is divided into 20 slots, and the bandwidth of each slot is about 5Gbps, which is called a slot. 64B/66B can be understood as a block of bits of 64 bits and a coded block of 66 bits resulting from its coding. FlexE implements multiple transmission channels, i.e., multiple time slots, on a single physical interface in an interleaved multiplexing manner. FlexE is only an interface technology, and the related switching technology may be performed based on the existing ethernet packet, or may be performed based on FlexE interleaving, which is not described herein again.

As described above, the FlexE shim layer embodies the slot mapping relationship between the client and the FlexE group and the CALENDAR working mechanism by defining the overhead frame and the overhead multiframe. It should be noted that the overhead frame may also be referred to as a flexible ethernet overhead frame (hereinafter, referred to as a FlexE overhead frame), and the overhead Multiframe may also be referred to as a flexible ethernet overhead Multiframe (hereinafter, referred to as a FlexE overhead Multiframe). The Flexe shim layer provides an in-band management channel through overhead, supports the transmission of configuration and management information between two butted Flexe interfaces, and realizes the automatic negotiation establishment of a link.

The data on each PHY of the FlexE is aligned by periodically inserting code blocks of FlexE Overhead (OH) frames, such as 1 66B overhead code block FlexE OH every 1023x20 66B payload data code blocks. According to the Flexe Implementation agent protocol, a Flexe Group sends a 64B/66B code block of a Flexe overhead frame to a remote PHY at preset time intervals on each PHY, and the 64B/66B code blocks of 8 sequentially sent Flexe overhead frames form a Flexe overhead frame. The FlexE defines some fields on the overhead frame to carry the timeslot allocation table, and synchronizes the timeslot allocation table to the PHY on the remote communication device through the FlexE overhead frame, so as to ensure that the dual-end communication device receives and transmits the data stream corresponding to the FlexE client by using the same timeslot allocation table. Specifically, an overhead frame has 8 overhead blocks (overhead slots), which may also be referred to as overhead slots. The overhead block may be, for example, a 64B/66B encoded block of code that appears once every interval 1023x20 blokcs, but the fields contained in each overhead block are different.

Fig. 5 shows a schematic diagram of the structure of the overhead frame and overhead multiframe of the 100GE interface given in the OIF IA-flex-02.1 standard. The structure of the FlexE overhead frame (hereinafter referred to simply as an overhead frame) is briefly described below with reference to fig. 5. As shown in fig. 5, one overhead frame includes 8 overhead blocks. The overhead frame specifies a bit field (or may also be referred to as a field) for guiding slot negotiation between communication devices in overhead block 1(block1) to overhead block 3(block 3). Overhead blocks 4(block4) to 8(block8) of the overhead frame are Management channels (english: Management Channel), and the Management channels can be used for carrying 1588 messages, synchronous ethernet messages, DCN messages, link search messages, and the like. The management channel has no limitation on the types of the messages which can be carried by the management channel, and only needs to ensure that the coding format of the messages can be decoded normally by the communication equipment.

Some bit fields involved in slot negotiation in the overhead frame shown in fig. 5 are described below.

C: 1bit for indicating the currently used slot allocation table configuration (callback configuration in use). The C bit has 3 positions defined in the overhead, and has the same meaning, mainly to ensure reliability, and this bit field is represented by CCC field in the following description. For example, if the value of CCC is 0, it indicates that the current primary timeslot allocation table is calenar a; if the value of CCC is 1, the currently working time slot allocation table is called Calendar B. It should be noted that in the present application, the values of the 3C bits in the overhead frame are always the same, i.e. both are 0 or both are 1. The CCC value is 1, which means that 3C bits all take the value of 1; the value of CCC is 0, which means that the values of 3C bits are all 0.

CR: 1bit, which is used to indicate a timeslot negotiation Request, and the timeslot negotiation Request may also be referred to as a timeslot allocation table Switch Request (callback Request). In the routine overhead frame refreshing process between the sending end device and the receiving end device, the value of the CR field is consistent with the value of the CCC field, and the current main time slot allocation table is indicated. After the sending end initiates the time slot negotiation request, the value of the CR field will be different from the value of the CCC field, at this time, the value of the CR field points to the standby time slot allocation table, and the value of the CCC field points to the current primary time slot allocation table. It will be understood by those skilled in the art that "slot negotiation request" and "slot allocation table switch request" may be used in the same sense, and in this application, the two are often used interchangeably.

CA: 1bit for indicating a timeslot allocation table Switch acknowledgement (callback acknowledgement). In the current standard, the CA field semantics have ambiguity for indicating the response of the receiving device (hereinafter RX) to the slot negotiation request sent by the sending device (hereinafter TX), and for indicating the slot allocation table. If the value of the CA field carried in the overhead frame responded by the RX is consistent with the value of the CR field carried in the overhead frame sent by the received TX, the TX considers that the response is the response of the RX to the time slot negotiation request sent by the RX, and the RX is ready to switch to the time slot allocation table indicated by the CA field. And the TX is switched to the standby time slot allocation table from the main time slot allocation table, modifies the value of the CCC field into the value which is the same as the CR field when the time slot negotiation request is sent, and sends the value to the RX along with the overhead frame. After receiving the overhead frame of CR ═ CCC, RX also switches from the primary timeslot allocation table to the standby timeslot allocation table.

Referring to fig. 6, a method 100 for performing timeslot negotiation between network devices will be briefly described by taking the scenario shown in fig. 3 as an example. For simplicity of description, in fig. 6, the network device 1 is identified as TX and the network device 2 is identified as RX. For some reasons, the TX direction initiates the switching from the primary timeslot table calenar a to the standby timeslot table calenar B, and the reason for triggering the switching of the timeslot tables may be, for example:

a) modifying the time slot bandwidth of the Flexe Client in the TX direction;

b) the TX and/or RX direction Flexe Group changes in the addition and deletion of the PHY or the state of the PHY;

c) the devices in TX and/or RX direction are initialized at restart.

To accomplish the slot table switch, a method 100 of slot negotiation between TX and RX is performed, comprising:

s101, a time slot negotiation request is initiated in a TX direction, and an RX is requested to switch a standby time slot allocation table into a main time slot allocation table. Specifically, CR is called calenar B (CR ═ 1), and CCC is called calenar a (CCC ═ 0) in this case, and is transmitted to RX through the FlexE overhead. Then wait for the RX direction to reply with the CA message.

S102, the RX direction receives a timeslot negotiation request (CR 1/CCC 0) from the TX, and if the RX direction is ready and the received Calendar B configuration information is legal, sets CA to Calendar B (CA 1), and sends the request to the TX through the FlexE overhead.

After receiving the timeslot negotiation response in the RX direction (CA ═ 1), the TX direction switches the local primary timeslot table to calenar B, modifies CCC to calenar B (CCC ═ 1), and sends the result to RX through FlexE overhead. The RX also switches the local master timeslot table to the calenar B after receiving the FlexE overhead (CR 1/CCC 1).

S101-S103 describe a complete slot negotiation procedure in the normal case. The process of switching from the subsequent TX direction initiating the timeslot table calenar B to calenar a is also a similar flow. It will be understood by those skilled in the art that after S101, if the TX direction does not receive the slot negotiation response of the RX for a long time, the slot negotiation request will be sent again at regular time. The subsequent steps are the same as S102 and S103, and are not described again.

The FlexE overhead slot negotiation mechanism described in the method 100 above has the problem of RX false acknowledgement. The scenario that causes the above problem is described in detail below with reference to fig. 7.

As shown in fig. 7, TX and RX at two ends of the FlexE Group establish communication connection, and RX performs device restart for some reasons (e.g., device power down, plugging/unplugging of a related service board, or board hard reset triggered by self-healing failure, etc.). And at the RX side, all negotiation data about the Flexe Group are cleared, a main time slot table of the RX is defaulted to be Calendar A, and at the moment, the values of fields CA, CR and CCC in an overhead frame of routine refreshing sent by the RX are all 0. On the TX side, the current primary timeslot allocation table of TX is calenar B. After the UP of the PCS layer of the FlexE GROUP PHY is recovered in the restart process in the RX direction and the preparation in the TX direction is ready, a timeslot negotiation request is triggered to perform timeslot negotiation with the RX. Wherein, the preparation work in the TX direction comprises the following steps:

PHY grouping: and adding the configuration of the Flexe Group number of the PHY into the management of the corresponding Flexe Group.

TX slot refresh: and sending down time slot configuration in the TX direction.

The specific timeslot negotiation method 200 includes:

s201, a time slot negotiation request is initiated in a TX direction, and a time slot allocation table is requested to be switched. TX sets CR to calenar a (CR ═ 0), and CCC is calenar B (CCC ═ 1) at this time, and transmits it to RX through a FlexE overhead frame. Waiting for the RX direction to reply with the CA message.

When the RX direction receives the timeslot negotiation request, the restart recovery process is still in progress, the relevant processing data is not prepared, and the RX direction is not ready, so that no response is made to the timeslot negotiation request. The preparation in the RX direction includes:

Flexe group establishment: and the RX receives a Flexe overhead frame of the TX opposite end, analyzes the internal Group number and PHY number, and checks that the internal Group number and PHY number are consistent with the local configuration, so that the Flexe Group establishment operation is considered to be successful.

CR interrupt on: when the data of the FlexE group and the PHY are ready, the CR interrupt is turned on to accept the slot negotiation request in the TX direction.

The RX direction dependent CR interrupt does the following:

a) when the RX direction finds that CR is inconsistent with CCC in the Flexe overhead, the RX direction considers the new time slot negotiation request.

b) The RX extracts the time slot allocation table information designated by the CR from the Flexe overhead and configures the spare time slot allocation table information corresponding to the physical Mac according to the Flexe Client ID in the time slot allocation table. (since the RX side equipment restarts, the RX side physical Mac's active slot allocation table is empty and invalid)

c) And responding to the CA corresponding to the TX direction through the Flexe overhead according to the CR value in the received Flexe overhead. Then wait for the TX direction reply CR CCC.

d) And receiving a Flexe overhead frame of a TX direction response CR ═ CCC, and switching a standby time slot allocation table of the physical Mac to a main time slot allocation table by the RX side.

If the RX does not complete the operations of steps a) -d), it will cause the timeslot information of the RX side physical MAC to be empty or inconsistent with the TX side timeslot configuration, and thus a current break occurs.

S202, RX sends a refreshed FlexE overhead frame to the TX routine at regular periodic intervals.

Although as described above, the RX direction is not ready after receiving the slot negotiation request sent by the TX, and therefore does not respond effectively to the slot negotiation request. However, the RX may send FlexE overhead frames to the TX routine at a natural periodicity. In a FlexE overhead frame that RX routinely transmits to TX, the CA value is set to 0 by default. At this time, since the CA that the TX is waiting for the RX reply is also 0, the FlexE overhead frame that the TX mistakenly believes the RX routine to transmit is a response to the slot negotiation request transmitted in S201, and therefore, S203 described below is continuously performed. Subsequently, when the TX does not renegotiate the slot requirement, the TX will not re-initiate the slot negotiation request. It follows that the FlexE overhead of the RX routine acknowledges the slot negotiation request of the TX transmission.

After the TX direction receives the FlexE overhead frame sent by the RX direction, because CA carried in the FlexE overhead frame is 0, the local master timeslot table is switched to calandar a, CCC is modified to calandar a (CCC is 0), and the FlexE overhead frame is sent to RX.

After receiving the FlexE overhead frame sent by the TX in S203, even though the RX is ready as described above, the RX cannot acquire the correct timeslot information because the timeslot negotiation request sent by the TX in S201 is not correctly processed, which results in traffic interruption from the TX to the RX.

It can be seen that, when TX and RX perform timeslot negotiation, if the RX side is just in a device restart state for some reason, at this time, the FlexE overhead frame routinely transmitted by RX may erroneously respond to the timeslot negotiation request transmitted by TX, so that TX may mistakenly assume that RX has effectively responded to the timeslot negotiation request. But in practice, TX and RX do not perform an efficient slot negotiation. How to effectively avoid the above situation, improve the accuracy of time slot negotiation, and avoid the influence on normal services becomes a problem to be solved. To solve the above problem, the present application provides a timeslot negotiation method 300.

The method 300 provided by the embodiment of the present application is described in detail below with reference to fig. 8. The network architecture to which the method 300 applies includes a network device 1 and a network device 2. The network device 1 and the network device 2 may be, for example, the network device 1 and the network device 2 shown in fig. 3. The network device 1 and the network device 2 are connected by a single PHY, or may be connected by a FlexE group. The network architecture may be, for example, the network architecture shown in fig. 3. Referring now to FIG. 8, a method 300 is described, taking the architecture shown in FIG. 3 as an example. The method 300 includes:

s301, the network device 1 sends a FlexE overhead frame 1 to the network device 2.

Specifically, the FlexE overhead frame 1 includes request information 1, where the request information 1 is used to request the network device 2 to execute the active/standby switching of the timeslot allocation table, that is, request the network device to switch the standby timeslot allocation table to the active timeslot allocation table.

In a specific embodiment, the request information 1 is information indicated by a CR field and a CCC field in a FlexE overhead frame 1. For example, the CR field carried in the FlexE overhead frame 1 has a value of 0 and the CCC field has a value of 1. When the values of the CR field and the CCC field are different, the FlexE overhead frame 1 is used to send out a slot negotiation request 1, which may also be referred to as a slot allocation table switch request 1. When the value of the CCC field is 1, it indicates that the current primary timeslot allocation table is timeslot allocation table 1. When the value of the CR field is 0, it indicates a request to switch the current primary timeslot allocation table to the standby timeslot allocation table, i.e., timeslot allocation table 2. When the CR field is 1 and the CCC field is 0, it indicates that switching from the slot allocation table 2 to the slot allocation table 1 is requested. When the CR field is 0 and the CCC field is 1, it indicates that a switch from slot allocation table 1 to slot allocation table 2 is requested. In a specific embodiment, according to the current OIF standard, the timeslot allocation table 1 may be a calenar B defined in the standard, and the timeslot allocation table 2 is a calenar a defined in the standard.

In a specific implementation manner, the request information 1 may be a request message 1 carried in a management channel of the first FlexE overhead frame. The request message 1 may also be referred to as a timeslot negotiation request message 1. The specific format of the request packet carried in the management channel can be referred to the following specific description with reference to fig. 12a), or fig. 12c and fig. 12 d. Those skilled in the art can understand that the format of the request packet carried in the management channel is not limited to the examples given in this application, and the application does not specifically limit the specific format of the request packet carried in the management channel.

S302, the network device 2 receives the FlexE overhead frame 1.

When the network device 2 is in the device restart state, a discard operation may be performed on the received FlexE overhead frame 1 without actual processing.

S303, the network device 2 sends a FlexE overhead frame 2 to the network device 1.

The FlexE overhead frame 2 is a FlexE overhead frame that the network device 2 routinely transmits to the network device 1 at a fixed time period. The value of the CA field in the FlexE overhead frame 2 is the same as the value of the CR field in the FlexE overhead frame 1. For example, the CR field carried in the FlexE overhead frame 1 takes a value of 0, and the CA field value of the FlexE overhead frame 2 also takes a value of 0.

S304, the network device 1 receives the FlexE overhead frame 2 sent by the network device 2.

S305, the network device 1 determines that the FlexE overhead frame 2 is not a response to the request information 1 according to the indication information 1 carried in the FlexE overhead frame 2. The FlexE overhead frame 2 is not a response to the request information 1, which also means that the FlexE overhead frame 2 is not a response to the slot negotiation request 1, not a response to the FlexE overhead frame 1.

The network device 1 determines that the FlexE overhead frame 2 is not a response to the request information 1, which means that the network device 1 can correctly recognize that the received FlexE overhead frame is not a trusted response of the network device 2 to the slot negotiation request 1 sent by the network device. The specific description of S305 is specifically described below, and is not repeated here.

S306, the network device 1 sends a FlexE overhead frame 3 to the network device 2.

Similar to S301, the FlexE overhead frame 3 includes request information 2 for requesting the network device 2 to execute the active/standby switching of the timeslot allocation table, that is, requesting the network device 2 to switch the standby timeslot allocation table to the active timeslot allocation table. The specific format of request information 2 is the same as that of request information 1, except that it is carried in a different FlexE overhead frame. Therefore, the description of the request information 2 refers to the above description of the request information 1, and is not repeated here.

The CR field carried in the FlexE overhead frame 3 has a value of 0 and the CCC field has a value of 1. The network device 1 determines that the FlexE overhead frame 2 is not a response to the request information 1, the network device 1 issues a slot negotiation request to the network device 2 again. The FlexE overhead frame 3 is used to issue a slot negotiation request 2, i.e. a slot allocation table switch request 2. That is, the network device 1 requests to perform timeslot negotiation with the network device 2 again, and requests to switch the standby timeslot allocation table to the primary timeslot allocation table.

S307, the network device 2 receives the FlexE overhead frame 3.

S308, the network device 2 sends a FlexE overhead frame 4 to the network device 1, and responds to the received request message 2.

Specifically, when the network device 2 has completed the device restart and has made the relevant preparation work, the network device 2 starts the CR interrupt and responds to the slot negotiation request 2 sent by the network device 1. And the network equipment 1 and the network equipment 2 continue to execute the operation of switching the time slot allocation table according to the negotiation result. It will be understood by those skilled in the art that if the network device 2 is still in the restart state at this time, or is not ready to do the relevant work, the triggering of the slot negotiation request is repeated until the network device 1 determines that the network device 2 has made a valid response to the slot negotiation request sent by it. Indication information 2 is included in the FlexE overhead frame 4, and the indication information 2 is used to indicate that the FlexE overhead frame 4 is a response to the request information 2.

S309, the network device 1 receives the FlexE overhead frame 4.

And S310, the network device 1 determines that the Flexe overhead frame 4 is a response to the request information 2 according to the indication information 2, and switches the standby time slot allocation table to the active time slot allocation table.

The specific description of S310 will be described below together with S305.

S311, the network device 1 sends a FlexE overhead frame 5 to the network device 2, and instructs the network device 2 to switch the standby timeslot allocation table to the active timeslot allocation table.

The value of the CCC field in the FlexE overhead frame 5 is the same as the value of the CR field in the FlexE overhead frame 1.

S312, the network device 2 receives the FlexE overhead frame 5, and switches the standby timeslot allocation table to the active timeslot allocation table.

It can be understood by those skilled in the art that the FlexE overhead frame 3 does not necessarily mean an overhead frame adjacent to the FlexE overhead frame 2 in time sequence, but may also be an overhead frame after the network device 1 sends a slot negotiation request to the network device 2 for multiple times. The operation "CR interrupt" mentioned in this application refers to that, after the network device receives a timeslot negotiation request overhead frame (the received value of CR and CCC in the FlexE overhead frame is different, it is considered as a timeslot negotiation request), the timeslot allocation table information carried in the overhead frame is read, and the timeslot table configuration stored locally is refreshed. In one particular embodiment, the execution of the CR interrupt may be implemented by software on the processor. The processor reads the overhead frame information stored in the register through an interface connected with the network forwarding chip, and refreshes the configuration of the time slot allocation table stored locally according to the configuration information of the latest time slot allocation table carried in the overhead frame. In another embodiment, the CR interrupt may be performed by a forwarding chip. For example, a processing logic may be set in the chip, the information of the timeslot negotiation overhead frame is read, and the configuration of the timeslot allocation table stored locally is refreshed according to the configuration information of the latest timeslot allocation table carried in the overhead frame.

In the timeslot negotiation method provided by the application, indication information is carried in a FlexE overhead frame replied to the TX in the RX, so that the indication information can indicate whether the FlexE overhead frame is a response to a timeslot negotiation request sent by the TX. And when the TX determines that the received Flexe overhead frame does not respond to the time slot negotiation request sent by the TX according to the indication information, the TX resends the time slot negotiation request until the TX confirms that the RX responds to the time slot negotiation request sent by the RX. Therefore, the problem of traffic interruption caused by the fact that the RX responds to the time slot negotiation request sent by the TX by mistake can be effectively avoided.

The following specifically describes the indication information 1 and the indication information 2 mentioned in S305 and S310 in the above-described method 300. In the present application, the network device 1 may determine whether the received FlexE overhead frame is a response to the request information (or the time slot negotiation request) issued by the network device 1, but is not limited to the following manners one to three.

First, the indication information 1 and the indication information 2 are information indicated by a newly extended field in the FlexE overhead frame, which is not a CA field. For example, one or more bits are added to a Reserved (Reserved) field of the FlexE overhead frame shown in fig. 5 to identify the indication information 1 and the indication information 2. Or adding a field in the FlexE overhead frame management channel to identify the indication information 1 and the indication information 2. Specifically, the at least one newly added bit in the FlexE overhead frame 2 is the indication information 1, and the at least one newly added bit in the FlexE overhead frame 4 is the indication information 2. In a specific embodiment, a bit is added to the FlexE overhead frame, and the indication information 1 and the indication information 2 are respectively identified by different values of the added bit. When the value of the newly added bit in the Flexe overhead frame is 1, indicating that the Flexe overhead frame is a response to the received time slot negotiation request; and when the value of the newly added bit is 0, indicating that the FlexE overhead frame is not the response to the time slot negotiation request. Specifically, when the value of the newly added bit in the FlexE overhead frame 2 is 1, the method is used for indicating that the FlexE overhead frame 2 is a response to the request information 1; and when the value of the newly added bit is 0, indicating that the FlexE overhead frame 2 is not a response to the request information 1. Similarly, when the value of the newly added bit in the FlexE overhead frame 4 is 1, the method is used for indicating that the FlexE overhead frame 4 is a response to the request information 2; and when the value of the newly added bit is 0, the method is used for indicating that the Flexe overhead frame 4 is not a response to the request information 2. In another specific embodiment, the indication information 1 and the indication information 2 may also be identified in a bit map (bit map) manner. For example, two bits are added to a FlexE overhead frame, and each bit is mapped with indication information 1 and indication information 2, and the specific indication manner is not described again. It should be understood that the present application is not limited to the above-described embodiments. In the scheme of the first mode, whether a FlexE overhead frame sent by an RX is a response to request information carried in a FlexE overhead frame sent by a TX is indicated by a newly extended field in the FlexE overhead frame, and a CA field in the FlexE overhead frame is used for indicating a timeslot allocation table and is not used for indicating whether the FlexE overhead frame is a response to the request information. By the implementation method, the ambiguity problem of the existing CA field can be solved under the condition of not changing the format of the existing overhead frame, the flow interruption caused by the problem can be effectively avoided, and the service continuity and stability are ensured.

The first embodiment will be described below with reference to fig. 9 and 10 by taking an example of extending one bit.

As shown in fig. 9, a 1Bit free Bit field is found in the FlexE overhead frame, and for convenience of description, this application is referred to as an rr (rx CR Ready flag) flag Bit, and it is to be understood that the naming of this identifier is not limited thereto.

1) When the RX direction FlexE GROUP has been activated and PHY added and CR interrupt in TX direction has been processed, this RR flag is set to 1. When RR is 1, RX replies to the CA content in the FlexE overhead of TX for indicating the trusted slot allocation table that responded to the slot negotiation request.

2) If RR of Flexe overhead is received, the TX direction considers that the RX direction does not respond to the time slot negotiation request, the TX continuously initiates the time slot negotiation request until the RX direction responds to a Flexe overhead frame carrying RR of 1 and CA of an expected value, the negotiation is considered to be successful, otherwise, the time slot negotiation state is continuously maintained.

A specific timeslot negotiation method 3000 of the first embodiment will be described below with reference to fig. 10.

The TX direction initiates the switch of the slot allocation table calenar B to calenar a for some of the reasons described above.

S3301, TX initiates a time slot negotiation request.

TX sends a FlexE overhead frame (CR 0/CCC 1) to RX direction for issuing the slot negotiation request. Wherein, the TX sends the latest configuration information of the calenar a to the RX through the FlexE overhead frame.

S3302, RX sends a slot negotiation response to TX.

After the RX side is ready to perform the relevant preparation work (for example, the FlexE Group has already completed the Group activation and the PHY grouping action, and has opened the CR timeslot negotiation interrupt and successfully received the timeslot negotiation request (CR ═ 0/CCC ═ 1) processed in the TX side), it sends a timeslot negotiation response to the TX. Specifically, RX sends a FlexE overhead frame to TX in response to the slot negotiation request. In the FlexE overhead frame, the RR flag is set to 1, and the CA flag is set to 0.

S3303, TX is switched from calenar B to calenar a. And transmitting FlexE overhead (CR is 0 and CCC is 0) to RX, triggering RX to complete handover from Calendar B to Calendar a.

When TX receives a FlexE overhead frame (where CA is 0 and RR is 1), it considers a valid response. TX then completes the slot negotiation action, switches the slot allocation table from calenar B to calenar a, and sends a FlexE OH overhead frame (where CR is 0 and CCC is 0) to RX.

If the TX direction does not receive a time slot negotiation response valid for RX for a long time, it will periodically send a time slot negotiation request again.

After receiving the TX FlexE overhead frame (CR is 0 and CCC is 0), S3304 and RX switch the slot allocation table from calenar B to calenar a.

After S3304, in the FlexE overhead of the routine refresh sent by RX to TX, RR is reset to 0 to wait for processing the next time slot negotiation request procedure initiated by TX.

In this embodiment, after S3301 and before S3302, the following operations may be further included:

if RX is not ready for the relevant task, a Flexe overhead frame is routinely sent to TX, with RR set to 0.

TX receives a FlexE overhead frame with RR set to 0 and determines that the FlexE overhead is not responsive to the slot negotiation request it issues.

The TX re-sends the slot negotiation request to the RX, and in the FlexE overhead frame, CR is set to 0 and CCC is set to 1.

The second way, the indication information 1 and the indication information 2 may be information indicated by a CA field in a FlexE overhead frame. In this way, the semantics of the CA field defined in the current standard are changed. Specifically, in the current OIF standard, the semantics of the CA field are ambiguous and are used to both express the negotiated response and to indicate the slot allocation table. The ambiguous definition in the current standard regarding the CA phrase leads to the technical problem described in the above of the present application. In the present embodiment, by changing the semantics of the CA, it is used to indicate the validity of the negotiation response, but not to indicate the slot allocation table, in other words, not to indicate the output of the negotiation. For example: when CA is 0, it indicates that the overhead frame is not a response to the slot negotiation request, and when CA is 1, it indicates that the overhead frame is a response to the slot negotiation request. At this time, the value of the CA is independent of the configuration of the slot allocation table, i.e. independent of the negotiated output. The CA field is used to indicate whether the RX-issued FlexE overhead frame is responsive to the TX-issued slot allocation table negotiation request. Specifically, in S305, the indication information 1 is the information indicated when the CA field of the FlexE overhead frame 2 is assigned the first value. In S310, the indication information 2 is the information indicated when the CA field of the FlexE overhead frame 4 is assigned the second value. For example, when the CA field in the FlexE overhead frame 2 is assigned 0, it is used to indicate that the FlexE overhead frame 2 is a response to the slot negotiation request 1, but is not used to indicate the slot allocation table. When the CA field of the FlexE overhead frame 4 is assigned 1, it is used to indicate that the FlexE overhead frame 4 is a response to the slot negotiation request 2, but not to indicate the slot allocation table. In the second mode, the RX locally completes the preparation of the timeslot allocation table switching, in the FlexE overhead frame replied to the TX, the CA field is no longer used for indicating the timeslot allocation table, and the TX continues the switching process of the timeslot allocation table as long as it receives the FlexE overhead frame whose CA is assigned as the second value, that is, it considers that the negotiation is completed.

The scheme provided by the second mode changes the semantics of the existing CA field, and abandons the semantic characteristic that the CA indicates the time slot allocation table, namely abandons the semantic characteristic that the CA field is used for indicating the negotiation output. The CA language segment is used for indicating the effectiveness of the negotiation response, not just the negotiation output, so that the ambiguity problem of the existing CA field is solved, and the influence on the service caused by the error of the time slot negotiation process is effectively avoided.

The negotiation flow 400 provided in the second mode is illustrated in conjunction with fig. 11.

S401, the TX initiates a time slot negotiation request.

TX sends a FlexE overhead frame (CR 0/CCC 1) to RX direction for issuing the slot negotiation request. Wherein, the TX sends the latest configuration information of the calenar a to the RX through the FlexE overhead.

S402, RX sends a slot negotiation response to TX.

After the RX side is ready to perform the relevant preparation work (for example, the FlexE Group has already completed the Group activation and the PHY grouping action, and has opened the CR timeslot negotiation interrupt and successfully received the timeslot negotiation request (CR ═ 0/CCC ═ 1) processed in the TX side), it sends a timeslot negotiation response to the TX. Specifically, RX sends a FlexE overhead frame to TX in response to the slot negotiation request. In the FlexE overhead frame, the CA flag is set to 1 to indicate that the FlexE overhead frame is a response to the received slot negotiation request.

And S403, TX is switched from Calendar B to Calendar A. And sends a FlexE overhead frame (CR ═ 0 and CCC ═ 0) to RX, triggering RX to complete the handover from calenar B to calenar a.

When TX receives a FlexE overhead frame (where CA ═ 1), it is considered a valid response. TX then completes the slot negotiation action, switches the slot allocation table from calenar B to calenar a, and sends a FlexE overhead frame (where CR is 0 and CCC is 0) to RX.

S404 and RX receive the TX FlexE overhead frame (CR is 0 and CCC is 0), and then switch the slot allocation table from calenar B to calenar a.

After S404, in a FlexE overhead frame of routine refresh sent by the RX to the TX, the CA is reset to 0 to wait for processing the next time slot negotiation request procedure initiated by the TX.

In this embodiment, after S401 and before S402, the following operations may be further included:

a) if RX is not ready for the relevant task, Flexe overhead is sent to TX routine, where CA is set to 0.

b) After sending the time slot negotiation request, the TX receives a FlexE overhead frame with CA set to 0, and determines that the FlexE overhead is not a response to the time slot negotiation request sent by the TX.

c) The TX re-sends the slot negotiation request to the RX, and in the FlexE overhead frame, CR is set to 0 and CCC is set to 1.

And thirdly, adding a request message and a response message in a management channel of the FlexE overhead frame to complete the time slot negotiation between the network device 1 and the network device 2. In this way, by adding a set of messages in the management channel to indicate the validity of the negotiation response, the value of the CA field in the overhead frame can be used to indicate the slot allocation table, i.e. to express the output of the negotiation, but not to express the validity of the negotiation response. In the method, a request message (also referred to as a time slot negotiation request message in the application) and a response message (also referred to as a time slot negotiation response message in the application) are added in a management channel to express a request and a response of time slot negotiation, and a TX judges whether a received overhead frame is a response to the time slot negotiation request message sent by the TX according to whether the management channel of the overhead frame carries the time slot negotiation response message, so that the ambiguity problem of the existing CA field is solved, and the influence on services caused by errors in a time slot negotiation process is effectively avoided. Specifically, in the third mode, the indication information 1 in S305 is information indicated by the management channel of the FlexE overhead frame 2, and the indication information 2 in S310 is information indicated by the management channel of the FlexE overhead frame 4. The management channel provided in the FlexE overhead does not limit the type of the message carried by the management channel, and only needs to ensure that the message is transmitted according to a specified coding format. The specified encoding format is only required to be correctly decoded by the opposite terminal equipment. For the message format added in the embodiment of the present application, the present application is not particularly limited, and in the following, we will describe the message by taking an example of an ethernet message format, but the message format is used for indicating the validity of timeslot negotiation, but is not limited to the message format illustrated in the present application.

It should be noted that the management channel described in the present application complies with the management channel of the overhead frame defined in the existing standard, for example, the management channel is defined as 4 th to 8 th blocks of the overhead frame in the current standard. In future industry standards or enterprise standards, if the definition of the management channel changes, the management channel described in the application is compatible with the definition of the management channel by various standards.

The negotiation flow according to the third embodiment will be described below with reference to fig. 12a to 12e and fig. 13.

In a specific embodiment, fig. 12a illustrates a message format of a timeslot negotiation Request message (CR Request) added in a management channel, and fig. 12b illustrates a message format of a timeslot negotiation response message (CR Ack) added in a management channel.

The following describes formats of the CR Request message and the CR Ack message with reference to fig. 12a and 12 b:

SMAC: the source MAC address, which may be 6 bits in length, for example, may be the MAC address of the source port.

DMAC: the destination MAC, for example, may be 6 bits in length and may have a value of all 1's.

TYPE: the message type, length may be 2 bits, for example, and the value may be all 0's.

Flexe GROUP number, which may be 2 bits in length, for example, indicates which Flexe GROUP it belongs to.

Flag is the type of message subtype, and the length can be 20 bits, for example. In a specific embodiment, in the CR Request message, the value of the Flag field may be a character string "CR Request"; in the CR Ack message, the value of the Flag field may be the string "CR Ack".

In another specific embodiment, fig. 12c to 12d exemplarily show another specific example of the CR Request message and the CR Ack. In this example, a sub TLV type is added by extending a parent TLV field carried in a payload of a Link Layer Discovery Protocol (LLDP) packet, and is used to carry a CR Request packet and a CR Ack packet.

The payload of the LLDP packet includes a plurality of concatenated TLVs, and fig. 12c shows a parent TLV, where the parent TLV includes a type field, a length field, and a value field. Wherein, the value field can be concatenated by a plurality of sub-TLVs. For example, a vendor-reserved TLV TYPE (TYPE 127) is a parent TLV TYPE. In the following, a parent TLV type127 (i.e. T field value 127) is taken as an example to illustrate how to carry the CR Request packet and the CR Ack packet in the parent TLV field of the LLDP packet.

Fig. 12d) is a diagram illustrating a specific format of a sub-TLV for indicating a CR Request message extended in a Value field shown in fig. 12c), and fig. 12e) is a diagram illustrating a specific format of a sub-TLV for indicating a CR Request message extended in a Value field shown in fig. 12 c).

In fig. 12d), the sub-TLV field includes a type field, a length field, and a value field. Wherein, the type field is used for indicating that the type of the sub-TLV is a CR Request packet, and the length may be 7bits, for example; the Length field indicates the Length of the V field, which may be, for example, 9 bits; the value field is used to carry the Flexe Group number, and the length may be 2bytes, for example.

In fig. 12d), the sub-TLV field includes a type field, a length field, and a value field. Wherein, the type field is used to indicate that the type of the sub-TLV is a CR Ack packet, and the length may be 7bits, for example; the Length field indicates the Length of the V field, which may be, for example, 9 bits; the value field is used to carry the Flexe Group number, and the length may be 2bytes, for example.

Those skilled in the art will appreciate that the message formats given in the embodiments of the present application, the CR Request message and the CR Ack message, are only examples, and should not be construed as limiting the message formats.

The method 500 for timeslot negotiation using mode three is illustrated below with reference to fig. 13.

S501, the TX sends a CR Request message to the RX and sends a time slot negotiation Request to the RX.

Specifically, TX sends a FlexE overhead frame 1 to RX, sending a slot negotiation request 1. The Request information 1 is carried in a management channel of a FlexE overhead frame 1, specifically, the Request information 1 is a CR Request message 1, and requests the network device 2 to switch from a current timeslot allocation table B to a timeslot allocation table a. At this time, the primary timeslot allocation table is timeslot allocation table B, and the standby timeslot allocation table is timeslot allocation table a. After the TX sends a Request to the RX to send CR Request message 1, it waits for the response from the RX.

After S501, two cases can be divided.

a) If the RX responds to the CR Ack message, the RX is considered to be ready, and the time slot allocation table can be switched. Then execution continues with S510-S512 after S501.

b) If the RX direction does not respond to the CR Ack message, S502-S512 are executed after S501. The TX direction will send a CR Request message again for making a timeslot negotiation Request again and wait for the RX direction to respond.

After receiving the CR Request message, the RX direction:

after the FlexE Group at the local end is judged to have completed the preparation work such as the Group activation action, the Group adding action of the PHY, and the CR timeslot negotiation interruption is started, the CR Ack packet is responded through the management channel of the FlexE overhead.

And if the RX direction is not ready to process the time slot negotiation, not responding to the CR Request message, namely not sending the CR Ack message.

S502, RX sends a routinely refreshed FlexE overhead frame 2 to TX.

The management channel of the FlexE overhead frame 2 does not carry the response message 1, and in this embodiment, the response message 1 is a CR Ack message 1. At this time, the management channel of the FlexE overhead frame 2 is the indication information 1 carried in the FlexE overhead frame 2 described in this application.

S503, TX receives the FlexE overhead frames 2,.

S504, the TX determines that the Flexe overhead frame 2 is not a response to the time slot negotiation request 1 according to the management channel of the Flexe overhead frame 2.

S505, TX sends a FlexE overhead frame 3 to RX for sending a slot negotiation request 2.

The management channel of the FlexE overhead frame 3 carries request information 2, that is, a negotiation request message 2(CR request message 2), for sending a timeslot negotiation request 2.

S506, RX receives the FlexE overhead frame 3.

S507, the RX sends a FlexE overhead frame 4 to the TX in response to the received timeslot negotiation request 2.

Specifically, the management channel of the FlexE overhead frame 4 carries a response packet 2, that is, a negotiation response packet 2(CR Ack packet 2). At this time, the management channel of the FlexE overhead frame 4 is the indication information 2 carried in the FlexE overhead frame 4 described in this application.

S508, TX receives a FlexE overhead frame 4.

S509, the TX determines that the FlexE overhead frame 4 is a response to the timeslot negotiation request 2 according to the indication information 2.

S510, TX is switched from Calendar B to Calendar A.

S511, sends a FlexE overhead frame 5(CR is 0 and CCC is 0) to RX, and triggers RX to complete the handover from Calendar B to Calendar a.

S512, the RX receives the Flexe overhead frame 5, and the switching from the Calendar B to the Calendar A is completed.

In another specific embodiment, in the timeslot negotiation process of TX and RX, the above-mentioned S501 to S509 are used as a pre-negotiation process, and after S509 and before S510, the TX confirms that the pre-negotiation process is successful, and then starts to execute a formal negotiation process. By the method, the existing time slot negotiation process can be ensured to be unchanged, and in the formal negotiation process, the definition of the CA field conforms to the definition in the existing standard, because in the formal negotiation process, the pre-negotiation process is already completed, and the formal negotiation can be started only under the condition that the pre-negotiation is successful, so that the problem that the RX responds to the time slot negotiation request sent by the TX by mistake can be avoided, and the normal service forwarding is effectively ensured.

The following is a brief description of the formal negotiation procedure mentioned in this embodiment, and the detailed description of the method 100 described above may also be referred to for the description of the formal negotiation procedure.

Step A, TX initiates slot negotiation request 3 to RX.

Specifically, the TX receives a CR Ack message in the direction indicating that the RX is ready to perform a slot negotiation with the TX. TX again sends a FlexE overhead frame 6 to RX to initiate a slot negotiation request 3. And the TX and the RX begin to negotiate time slots according to the existing flow and initiate the negotiation of the switching from the time slot table Calendar B to the Calendar A. And the TX direction sends the latest content of the calenar a to the RX through a FlexE overhead frame 6, wherein CR is 0 and CCC is 1 in the FlexE overhead frame 6, and is used for negotiating with the RX to switch the currently operating timeslot allocation table from the timeslot allocation table B to the timeslot allocation table a.

Step B, RX sends a response to slot negotiation request 3 to TX.

After RX receives slot negotiation request 3(CR 0/CCC 1) from TX, RX is ready since it has responded to a CR Ack to TX before, and can process TX-initiated slot negotiation request 2 normally. The RX turns on the CR interrupt, refreshes the configuration of the slot allocation table a, and sends a FlexE overhead frame 7 to the TX in response to the received slot negotiation request 3. Wherein the RX sends the response by sending a FlexE overhead frame 7 to the TX, in which FlexE overhead frame 4 the CA field is set to 0.

Step C, TX switches the local primary timeslot allocation table from calenar B to calenar a, and sends FlexE overhead (CR is 0 and CCC is 0) to RX, triggering RX to complete the switch from calenar B to calenar a.

After step C, the above steps S510-S512 are continued, which is not described herein again.

In summary, the time slot negotiation method provided by the present application can solve the problem of false response in the FlexE overhead time slot negotiation mechanism defined by the current OIF standard, and the nature of this false response problem is that the response message of the FlexE overhead time slot negotiation only looks at the expression of the CA Bit field, but because the CA Bit field is only 1Bit, both the output of the negotiation and the negotiation response are expressed, so that the ambiguity of semantic expression exists. By the scheme, the problem of CA bit domain ambiguity is effectively solved, so that TX can accurately judge whether the received Flexe overhead is a response to the time slot negotiation request sent by TX, and whether to trigger the time slot negotiation request again or switch the time slot allocation table is determined based on the judgment result, thereby ensuring that TX and RX can carry out correct time slot negotiation and ensuring the accuracy of the time slot negotiation result. The success rate of time slot negotiation is effectively improved, and the influence of time slot negotiation error caused by RX false response on normal flexible Ethernet service in the prior art is reduced.

Fig. 14 is a flowchart illustrating a timeslot negotiation method 600 according to an embodiment of the present application. The network architecture to which the method 600 is applied includes at least the first network device and the second network device. For example, the first network device may be network device 1(TX) shown in fig. 3, and the second network device may be network device 2(RX) shown in fig. 3. The method shown in fig. 14 may embody the method shown in any of the embodiments described in connection with fig. 6-13. For example, the first network device and the second network device in fig. 14 may be network device 1 and network device 2, respectively, in method 300 shown in fig. 8. The method 600 illustrated in FIG. 14 includes the following.

S601, the first network device sends a first flexible Ethernet Flexe overhead frame to the second network device.

The first FlexE overhead frame includes first request information, where the first request information is used to request the second network device to switch the standby timeslot allocation table to the active timeslot allocation table.

S602, the second network device receives the first Flexe overhead frame of the first network device.

S603, the second network equipment sends a second Flexe overhead frame to the first network equipment.

S604, the first network device receives a second Flexe overhead frame sent by the second network device.

S605, the first network device determines that the second Flexe overhead frame is not a response to the first request message according to the first indication message in the second Flexe overhead frame.

S606, the first network device sends a third FLexe overhead frame to the second network device.

S607, the second network device receives the third FLexE overhead frame.

The third FLexE overhead frame includes second request information, where the second request information is used to request the second network device to switch the standby timeslot allocation table to the active timeslot allocation table.

In a specific embodiment, the first request information is a first request packet carried in a management channel of the first FlexE overhead frame. The first request message may be, for example, a timeslot negotiation request message having a message format as described in the embodiments corresponding to fig. 12a and fig. 12 c.

In a specific embodiment, the first request information is information indicated by CR and CCC fields carried by a first FlexE overhead frame. And if the values of the CR field and the CCC field are different, the first Flexe overhead frame is used for the time slot negotiation request.

In a specific embodiment, the second solution information is a second solution packet carried in a management channel of the third FlexE overhead frame. The second request message may be, for example, a timeslot negotiation request message, and has the message format as described in the embodiments corresponding to fig. 12a and fig. 12 c.

In a specific embodiment, the second request message is information indicated by CR and CCC fields carried in a third lex overhead frame. And if the values of the CR field and the CCC field are different, the third lexE overhead frame is used for the time slot negotiation request.

In a specific embodiment, the first indication information is a management channel of the second FlexE overhead frame, the management channel of the second FlexE overhead frame does not carry a first response packet, and the first response packet is used to indicate that the second FlexE overhead frame is a response to the first request information.

In a specific embodiment, the first indication information is information indicated by a first field in the second FlexE overhead frame, and the first field is different from a timeslot assignment table switching confirmation CA field of the second FlexE overhead frame.

In a specific embodiment, the first indication information is information indicated by a timeslot allocation table switch acknowledgement CA field of the second FlexE overhead frame, the first indication information is used to indicate that the second FlexE overhead frame is not a response to the first request information, and the first indication information is not used to indicate a timeslot allocation table.

Through the time slot negotiation method 600, after the first network device sends the first time slot negotiation request to the second network device, a new time slot negotiation request is sent again by determining that the FlexE overhead frame returned by the second network device is not a response to the time slot negotiation request sent by the second network device. Therefore, service interruption caused by recognizing the FlexE overhead frame routinely refreshed by the second network device as a response to the slot negotiation request sent by the second network device can be effectively avoided.

In the method 600, after S607, the method may further include:

a) the first network equipment receives a fourth Flexe overhead frame sent by the second network equipment;

and determining that the fourth Flexe overhead frame is a response to the second request information by using second indication information carried in a Flexe overhead frame of the first network device.

b) In a specific embodiment, when the first network device determines that the fourth FlexE overhead frame is a response to the second request information, it performs active-standby switching of the timeslot allocation table, that is, switches the standby timeslot allocation table to the active timeslot allocation table.

In another specific manner, when the method 600 performs timeslot negotiation by adding a request message and a response message in a management channel of a FlexE overhead frame, after step b), the method 600 may further include:

c) and the first network equipment sends a fifth Flexe overhead frame to the second network equipment, wherein the CR field and the CCC field in the fifth Flexe overhead frame are different and are used for sending a third time slot negotiation request to switch the standby time slot allocation table into the main time slot allocation table.

d) And the second network equipment receives the fifth Flexe overhead frame and sends a sixth Flexe overhead frame to the first network equipment.

A sixth FlexE overhead frame is a response to the third slot negotiation request.

e) And the first network equipment receives the sixth Flexe overhead frame, and determines that the sixth Flexe overhead frame is a response to the third time slot negotiation request according to the CA field of the sixth Flexe overhead frame.

f) The first network device executes the master-slave switching of the time slot allocation table, that is, the standby time slot allocation table is switched to the master time slot allocation table.

In a specific embodiment, the second indication information is a management channel of the fourth FlexE overhead frame, the management channel of the fourth FlexE overhead frame carries a second response packet, and the second response packet is used to indicate that the fourth FlexE overhead frame is a response to the second request information.

In another specific embodiment, the second indication information is information indicated by a timeslot allocation table switching acknowledgement CA field of the fourth FlexE overhead frame, the second indication information is used to indicate that the fourth FlexE overhead frame is a response to the second request information, and the second indication information is not used to indicate a timeslot allocation table.

In another specific embodiment, the second indication information is information indicated by a second field in the fourth lex overhead frame, and the second segment is different from the timeslot allocation table switching confirmation CA field of the fourth lex overhead frame.

When the method 600 shown in fig. 14 is used to implement the method corresponding to any one of fig. 6 to 13, the first request information and the second request information may correspond to, for example, the request information 1 and the request information 2 described in the foregoing method embodiments. The first indication information and the second indication information may correspond to, for example, indication information 1 and indication information 2 described in the foregoing method examples. For specific formats of the first request information, the second request information, the first indication information, and the second indication information, and specific implementation manners of the steps in the method 600, reference may be made to related descriptions of the corresponding steps in the foregoing method embodiments, and details are not described here.

A network device 700 provided in an embodiment of the present application is described below with reference to fig. 15. Network device 700 may be employed in the network architecture shown in fig. 3. For example, the network device 700 may be the network device 1(TX) or the network device 2(RX) described herein, and is configured to perform the method of the embodiment corresponding to any one of the foregoing fig. 6-14. The network device 700 may also be a first network device or a second network device described herein, configured to execute the method corresponding to fig. 14. The network device 700 comprises a transceiving unit 701 and a processing unit 702. The transceiving unit 701 is configured to perform transceiving operations, and the processing unit is configured to perform operations other than transceiving operations. For example, when the network device 700 is used as a first network device to execute the method 600 shown in fig. 14, the transceiving unit 701 may be configured to transmit a first flexible ethernet FlexE overhead frame to a second network device, receive a second FlexE overhead frame transmitted by the second network device, and transmit a third FlexE overhead frame to the second network device. The processing unit 702 may be configured to determine that the second FlexE overhead frame is not a response to the first request information according to the first indication information in the second FlexE overhead frame.

Referring to fig. 16, another network device 800 provided in the embodiments of the present application is described. Network device 800 may be employed in the network architecture shown in fig. 3. For example, the network device 800 may be the network device 1(TX) or the network device 2(RX) described herein, and is configured to perform the operations performed by the network device 1 or the network device 2 in the method according to the embodiment corresponding to any one of the foregoing fig. 6 to 13. The network device 800 may also be a first network device or a second network device described herein, and perform the operations performed by the first network device or the second network device in the method corresponding to fig. 14. The network device 800 includes a communication interface 801 and a processor 802 coupled to the communication interface. The communication interface 801 is used to perform transceiving operations, and the processor 802 is used to perform operations other than transceiving operations. For example, when network device 800 performs method 600 shown in fig. 14 as a first network device, communication interface 801 may be configured to send a first flexible ethernet FlexE overhead frame to a second network device, receive a second FlexE overhead frame sent by the second network device, and send a third FlexE overhead frame to the second network device. The processor 802 can be configured to determine that the second FlexE overhead frame is not a response to the first request message based on the first indication message in the second FlexE overhead frame.

Referring to fig. 17, another network device 900 provided in the embodiments of the present application is described. Network device 900 may be employed in the network architecture shown in fig. 3. For example, the network device 900 may be the network device 1(TX) or the network device 2(RX) described herein, and is configured to perform the operations performed by the network device 1 or the network device 2 in the method according to the embodiment corresponding to any one of the foregoing fig. 6 to 13. Network device 900 may also be a first network device or a second network device described herein, and perform the operations performed by the first network device or the second network device in the method corresponding to fig. 14. Network device 900 includes memory 901 and a processor 902 coupled to the memory. The memory 901 stores instructions that are read by the processor 902 to cause the network device 900 to perform the method performed by the TX or RX in the embodiment corresponding to any of fig. 6-13, which performs the method performed by the first network device or the second network device in the embodiment corresponding to fig. 14.

Next, with reference to fig. 18, another network device 1000 provided in the embodiment of the present application is described. The network device 1000 may be employed in the network architecture shown in fig. 3. For example, the network device 1000 may be the network device 1(TX) or the network device 2(RX) described herein, and is configured to perform the operations performed by the network device 1 or the network device 2 in the method according to the embodiment shown in any one of the foregoing fig. 6 to 13. The network device 1000 may also be a first network device or a second network device described herein, and perform the operations performed by the first network device or the second network device in the method corresponding to fig. 14. As shown in fig. 18, network device 1000 includes a processor 1010, a memory 1020 coupled to the processor, and a communication interface 1030. In one particular embodiment, the memory 1020 has stored therein computer-readable instructions comprising a plurality of software modules, such as a sending module 1021, a processing module 1022, and a receiving module 1023. The processor 1010 can perform corresponding operations according to the instructions of the software modules after executing the software modules. In the present embodiment, the operation performed by a software module actually refers to the operation performed by the processor 1010 according to the instruction of the software module. For example, when the network device 1000 executes the method shown in fig. 14 as a first network device, the sending module 1021 is configured to send a first FlexE overhead frame and a third FlexE overhead frame to a second network device, the receiving module 1023 is configured to receive a second FlexE overhead frame sent by the second network device, and the processing module 1022 is configured to determine, according to indication information in the second FlexE overhead frame, that the second FlexE overhead frame is not a response to first request information carried in the first FlexE overhead frame. Further, processor 1010, upon executing the computer readable instructions in memory 1020, may perform all operations that network device 1, network device 2, the first network device, or the second network device may perform, as indicated by the computer readable instructions. For example, when the network device 1000 is used as the network device 1 or the network device 2, all operations performed by the network device 1 or the network device 2 in the embodiments corresponding to fig. 6 to 13 may be performed, respectively; all operations performed by the first network device or the second network device in the embodiment corresponding to fig. 14 may be performed when the network device 1000 is used as the first network device or the second network device, respectively.

The processor referred to in this application may be a Central Processing Unit (CPU), a Network Processor (NP), or a combination of a CPU and an NP. The processor may also be an application-specific integrated circuit (ASIC), a Programmable Logic Device (PLD), or a combination thereof. The PLD may be a Complex Programmable Logic Device (CPLD), a field-programmable gate array (FPGA), a General Array Logic (GAL), or any combination thereof. The processor 1010 may refer to one processor or may include a plurality of processors. The memory referred to in this application may include volatile memory (RAM), such as random-access memory (RAM); the memory may also include a non-volatile memory (ROM), such as a read-only memory (ROM), a flash memory (flash memory), a hard disk (HDD) or a solid-state drive (SSD); the memory may also comprise a combination of memories of the kind described above. The memory may refer to one memory, or may include a plurality of memories.

An embodiment of the present application further provides a communication system, including a first network device and a second network device, where the first network device and the second network device may be the network devices described in any one of fig. 15 to fig. 18, and are used to perform the method in any one of embodiments corresponding to fig. 6 to fig. 14.

The present application also provides a computer program product comprising a computer program which, when run on a computer, enables the computer to perform the method performed by the network device 1 and/or the network device 2 in any of the embodiments corresponding to fig. 6 to 13.

The present application also provides a computer program product comprising a computer program which, when run on a computer, enables the computer to perform the method performed by the first network device and/or the second network device in the embodiment corresponding to fig. 14.

The present application provides a computer-readable storage medium comprising computer instructions which, when run on a computer, cause the computer to perform the method performed by network device 1 and/or network device 2 in any one of the embodiments corresponding to fig. 6-13.

The present application provides a computer-readable storage medium comprising computer instructions that, when executed on a computer, cause the computer to perform the method performed by the first network device and/or the second network device in the embodiment corresponding to fig. 14.

Those of ordinary skill in the art will appreciate that the various illustrative modules and method operations described in connection with the embodiments disclosed herein may be implemented as electronic hardware, or combinations of computer software and electronic hardware. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the implementation. Skilled artisans may implement the described functionality in varying ways for each particular application.

It can be clearly understood by those skilled in the art that, for convenience and brevity of description, the specific working processes of the system, the apparatus and the module described above may refer to the corresponding processes in the foregoing method embodiments, and are not described herein again.

In the above embodiments, all or part may be implemented by hardware, firmware, or any combination thereof. When software is involved in a particular implementation, it may be embodied in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When loaded and executed on a computer, cause the processes or functions described in accordance with the embodiments of the application to occur, in whole or in part. The computer may be a general purpose computer, a special purpose computer, a network of computers, or other programmable device. The computer instructions may be stored in a computer readable storage medium or transmitted from one computer readable storage medium to another, for example, from one website site, computer, server, or data center to another website site, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, Digital Subscriber Line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.). The computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device, such as a server, a data center, etc., that incorporates one or more of the available media. The usable medium may be a magnetic medium (e.g., floppy Disk, hard Disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., Solid State Disk (SSD)), among others.

All parts of the specification are described in a progressive mode, the same and similar parts among all the embodiments can be referred to each other, and each embodiment is mainly introduced to be different from other embodiments. In particular, as to the apparatus and system embodiments, since they are substantially similar to the method embodiments, the description is relatively simple and reference may be made to the description of the method embodiments in relevant places.

Claims

1. A method of timeslot negotiation performed by a first network device, comprising:

sending a first flexible Ethernet (FlexE) overhead frame to a second network device, wherein the first FlexE overhead frame comprises first request information, and the first request information is used for requesting the second network device to switch a standby time slot allocation table into a main time slot allocation table;

receiving a second Flexe overhead frame sent by the second network equipment;

determining that the second Flexe overhead frame is not a response to the first request information according to first indication information in the second Flexe overhead frame;

and sending a third FLexE overhead frame to the second network device, where the third FLexE overhead frame includes second request information, and the second request information is used to request the second network device to switch the standby timeslot allocation table to the active timeslot allocation table.

2. The method according to claim 1, wherein the first request message is a request packet carried in a management channel of the first FlexE overhead frame.

3. The method according to claim 1 or 2, wherein the first indication information is information indicated by a management channel of the second FlexE overhead frame, the management channel of the second FlexE overhead frame does not carry a first response packet, and the first response packet is used to indicate that the second FlexE overhead frame is a response to the first request information.

4. The method according to claim 1, wherein the first indication information is information indicated by a first field in the second Flexe overhead frame, and the first field is different from a slot allocation table (Slot) switch acknowledgement (CA) field of the second Flexe overhead frame.

5. The method according to claim 1, wherein the first indication information is information indicated by a slot allocation table switch acknowledgement (CA) field of the second Flexe overhead frame, wherein the first indication information is used for indicating that the second Flexe overhead frame is not a response to the first request information, and wherein the first indication information is not used for indicating a slot allocation table.

6. The method of any one of claims 1, 2, 4, or 5, further comprising:

receiving a fourth Flexe overhead frame sent by the second network equipment;

7. The method according to claim 6, wherein the second indication information is information indicated by a management channel of the fourth Flexe overhead frame, and the management channel of the fourth Flexe overhead frame carries a second response packet, where the second response packet is used to indicate that the fourth Flexe overhead frame is a response to the second request information.

8. The method according to claim 6, wherein the second indication information is information indicated by a slot allocation table switching acknowledgement (CA) field of the fourth Flexe overhead frame, wherein the second indication information is used for indicating that the fourth Flexe overhead frame is a response to the second request information, and wherein the second indication information is not used for indicating a slot allocation table.

9. A method of time slot negotiation, performed by a second network device,

receiving a first flexible Ethernet (FlexE) overhead frame sent by first network equipment, wherein the first FlexE overhead frame comprises first request information, and the first request information is used for requesting the second network equipment to switch a standby time slot allocation table into a main time slot allocation table;

10. The method according to claim 9, wherein the first request message is a request packet carried in a management channel of the first FlexE overhead frame.

11. The method according to claim 9 or 10, wherein the first indication information is information indicated by a management channel of the second FlexE overhead frame, the management channel of the second FlexE overhead frame does not carry a first response packet, and the first response packet is used to indicate that the second FlexE overhead frame is a response to the first request information.

12. The method according to claim 9, wherein the first indication information is information indicated by a first field in the second FlexE overhead frame, and the first field is different from a slot allocation table (slotlocking) acknowledgement (CA) field of the second FlexE overhead frame.

13. The method according to claim 9, wherein the first indication information is information indicated by a slot allocation table switch acknowledgement (CA) field of the second Flexe overhead frame, wherein the first indication information is used for indicating that the second Flexe overhead frame is not a response to the first request information, and wherein the first indication information is not used for indicating a slot allocation table.

14. The method of any one of claims 9, 10, 12 or 13, further comprising:

sending a fourth Flexe overhead frame to the first network device;

15. The method according to claim 14, wherein the second indication information is information indicated by a management channel of the fourth FlexE overhead frame, and the management channel of the fourth FlexE overhead frame carries a second response packet, where the second response packet is used to indicate that the fourth FlexE overhead frame is a response to the second request information.

16. The method according to claim 14, wherein the second indication information is information indicated by a timeslot assignment table switch acknowledgement (CA) field of the fourth Flexe overhead frame, wherein the second indication information is used for indicating that the fourth Flexe overhead frame is a response to the second request information, and wherein the second indication information is not used for indicating a timeslot assignment table.

17. A first network device, comprising:

a communication interface;

a processor connected to the communication interface;

through the communication interface and the processor, the first network device is configured to perform the method of any of claims 1-8.

18. A second network device, comprising:

a communication interface;

a processor connected to the communication interface;

through the communication interface and the processor, the second network device is configured to perform the method of any of claims 9-16.

19. A communication system comprising the first network device of claim 17 and the second network device of claim 18.

20. A computer-readable storage medium storing computer instructions which, when executed on a computer, cause the computer to perform the method of any one of claims 1-16.