WO2021047538A1 - 一种时隙协商的方法和设备 - Google Patents

一种时隙协商的方法和设备 Download PDF

Info

Publication number
WO2021047538A1
WO2021047538A1 PCT/CN2020/114221 CN2020114221W WO2021047538A1 WO 2021047538 A1 WO2021047538 A1 WO 2021047538A1 CN 2020114221 W CN2020114221 W CN 2020114221W WO 2021047538 A1 WO2021047538 A1 WO 2021047538A1
Authority
WO
WIPO (PCT)
Prior art keywords
overhead frame
time slot
flexe overhead
network device
flexe
Prior art date
Application number
PCT/CN2020/114221
Other languages
English (en)
French (fr)
Inventor
易科
李旺乾
胡永健
何向
Original Assignee
华为技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from CN201911008430.7A external-priority patent/CN112491492B/zh
Application filed by 华为技术有限公司 filed Critical 华为技术有限公司
Priority to MX2022002975A priority Critical patent/MX2022002975A/es
Priority to BR112022004518A priority patent/BR112022004518A2/pt
Priority to JP2022516136A priority patent/JP7305882B2/ja
Priority to EP20862916.2A priority patent/EP4024987B1/en
Publication of WO2021047538A1 publication Critical patent/WO2021047538A1/zh
Priority to US17/692,810 priority patent/US20220200722A1/en

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04J—MULTIPLEX COMMUNICATION
    • H04J3/00—Time-division multiplex systems
    • H04J3/02—Details
    • H04J3/14—Monitoring arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04J—MULTIPLEX COMMUNICATION
    • H04J14/00—Optical multiplex systems
    • H04J14/02—Wavelength-division multiplex systems
    • H04J14/0227—Operation, administration, maintenance or provisioning [OAMP] of WDM networks, e.g. media access, routing or wavelength allocation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04J—MULTIPLEX COMMUNICATION
    • H04J3/00—Time-division multiplex systems
    • H04J3/16—Time-division multiplex systems in which the time allocation to individual channels within a transmission cycle is variable, e.g. to accommodate varying complexity of signals, to vary number of channels transmitted
    • H04J3/1605—Fixed allocated frame structures
    • H04J3/1652—Optical Transport Network [OTN]
    • H04J3/1658—Optical Transport Network [OTN] carrying packets or ATM cells
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/24—Multipath
    • H04L45/245—Link aggregation, e.g. trunking
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04J—MULTIPLEX COMMUNICATION
    • H04J2203/00—Aspects of optical multiplex systems other than those covered by H04J14/05 and H04J14/07
    • H04J2203/0001—Provisions for broadband connections in integrated services digital network using frames of the Optical Transport Network [OTN] or using synchronous transfer mode [STM], e.g. SONET, SDH
    • H04J2203/0057—Operations, administration and maintenance [OAM]
    • H04J2203/006—Fault tolerance and recovery
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04J—MULTIPLEX COMMUNICATION
    • H04J2203/00—Aspects of optical multiplex systems other than those covered by H04J14/05 and H04J14/07
    • H04J2203/0001—Provisions for broadband connections in integrated services digital network using frames of the Optical Transport Network [OTN] or using synchronous transfer mode [STM], e.g. SONET, SDH
    • H04J2203/0073—Services, e.g. multimedia, GOS, QOS
    • H04J2203/0082—Interaction of SDH with non-ATM protocols
    • H04J2203/0085—Support of Ethernet
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/66—Layer 2 routing, e.g. in Ethernet based MAN's

Definitions

  • This application relates to the field of communications, and in particular to a method, device, system and storage medium for time slot negotiation.
  • Flex Ethernet Flexible Ethernet
  • FlexE Flex Ethernet
  • OIF optical Internet Forum
  • FlexE Shim layer flexible Ethernet protocol layer
  • PHY Physical link interface layer
  • Flex Shim is based on the time division multiplexing (English: Time Division Multiplexing, TDM) distribution mechanism, which schedules and distributes the data of multiple FlexE clients (English: client) to multiple different sub-channels according to the time slot mode, so as to realize the hardening of the transmission pipeline bandwidth. Isolation, a service data stream can be allocated to one or more time slots, realizing the matching of various rate services.
  • TDM Time Division Multiplexing
  • the FlexE Shim layer reflects the time slot mapping relationship between FlexE client and FlexE Group and the work of the calendar by defining overhead frames (English: Overhead Frame, OH Frame) and overhead multiframes (English: OH MultiFrame). mechanism.
  • the sending end sends a time slot table allocation table switching request (also called a time slot negotiation request) to the receiving end, the receiving end due to some reasons (such as device power failure, Related service unicast failure, hard reset of the single board starting from the failure recovery, etc.) restart.
  • a time slot table allocation table switching request also called a time slot negotiation request
  • the receiving end due to some reasons (such as device power failure, Related service unicast failure, hard reset of the single board starting from the failure recovery, etc.) restart.
  • there is a misresponding from the receiving end which causes the service from the sending end to the receiving end to be interrupted. Therefore, how to effectively avoid the impact of the above situation on the FlexE business is called an urgent problem to be solved at present.
  • This application provides a time slot negotiation method, network equipment, communication system, storage medium, and computer program product, which solves the problem of traffic interruption caused by the wrong response of the receiver in the current FlexE overhead frame time slot negotiation mechanism.
  • Using the technical solution of the present application can effectively improve the accuracy of time slot negotiation between network devices and effectively prevent service interruption.
  • the present application provides a time slot negotiation method, which is executed by a first network device, and the method includes: sending a first flexible Ethernet FlexE overhead frame to a second network device, and the first FlexE overhead frame Including first request information, the first request information being used to request the second network device to switch the spare time slot allocation table to the main time slot allocation table; receiving a second FlexE overhead frame sent by the second network device; According to the first indication information in the second FlexE overhead frame, determine that the second FlexE overhead frame is not a response to the first request information; send a third FLexE overhead frame to the second network device, and 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 spare time slot allocation table to the main time slot allocation table.
  • the first network device after the first network device sends the first FlexE overhead frame for the time slot negotiation request to the second network device, it can determine the first FlexE overhead frame according to the first indication information carried in the received second FlexE overhead frame. 2.
  • the FlexE overhead frame is not a response to the time slot negotiation request sent by it. Therefore, the first network device will not perform the active/standby switching of the time slot allocation table.
  • the first network device will re-send the third FLexE overhead frame for the time slot negotiation request to the second network device, wherein the second request information carried in the third FLexE overhead frame is used to request the second network device to allocate time slots Switch between active and standby tables.
  • the first network device can avoid erroneously identifying the second FLexE overhead frame as a response to the time slot negotiation request made by the second network device, and avoid erroneous switching of the time slot allocation table.
  • the above method effectively prevents service interruption caused by misoperation due to the current time slot negotiation mechanism.
  • the method may further include: receiving a fourth FlexE overhead frame sent by the second network device;
  • the fourth FlexE overhead frame is a response to the second request information.
  • the method further includes: in response to determining that the fourth FlexE overhead frame is a response to the second request information, the first network device switches the spare time slot allocation table Allocate a table for the main time slot.
  • the method further includes: the first network device sends a fifth FlexE overhead frame to the second network device, instructing the second network device to switch the spare time slot allocation table to the main Use the time slot allocation table.
  • the present application provides a time slot negotiation method, the method is executed by a second network device, and the method includes: receiving a first FlexE overhead frame sent by the first network device, where 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 spare time slot allocation table to the main time slot allocation table;
  • 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 flexible Ethernet FlexE overhead sent to the first network device.
  • the response of the frame 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 time slot negotiation request sent by it. Therefore, the first network device will not perform the active/standby switching of the time slot allocation table.
  • the second network device will receive the third FLexE overhead frame sent again by the first network device for the time slot negotiation request.
  • the second network device can According to the indication of the second request information carried in the third FLexE overhead frame, the relevant operation for the active/standby switching of the time slot allocation table is performed.
  • the second network device can perform correct time slot negotiation with the first network device. The above method effectively guarantees the time slot negotiation and prevents service interruption caused by the current time slot negotiation mechanism.
  • the method may further include: the second network device sends a fourth FlexE overhead frame to the first network device;
  • 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.
  • the method further includes: the second network device receives a fifth FlexE overhead frame sent by the first network device, and according to an indication of the fifth FlexE overhead frame, The spare time slot allocation table is switched to the main time slot allocation table.
  • the first request information is a first request message carried in a management channel of the first FlexE overhead frame.
  • the first request information is information indicated by the CR field and the CCC field carried in the first FlexE overhead frame.
  • the CR field and the CCC field have different values.
  • the first indication information is information indicated by the management channel of the second FlexE overhead frame, and the management channel of the second FlexE overhead frame does not carry the first response message, so The first response message is used to indicate that the second FlexE overhead frame is a response to the first request information.
  • the first indication information is the information indicated by the first field in the second FlexE overhead frame, and the first field is switched with the time slot allocation table of the second FlexE overhead frame Confirm that the CA field is different.
  • the first indication information is the information indicated by the switch confirmation CA field of the time slot allocation table of the second FlexE overhead frame, and the first indication information is used to indicate the second FlexE
  • the overhead frame is not a response to the first request information, and the first indication information is not used to indicate the time slot allocation table.
  • the second indication information is information indicated by the management channel of the fourth FlexE overhead frame
  • the management channel of the fourth FlexE overhead frame carries a second response message
  • the first The second response message is used to indicate that the fourth FlexE overhead frame is a response to the second request information.
  • the second indication information is the information indicated by the CA field of the time slot allocation table switching confirmation of the fourth FlexE overhead frame, and the second indication information is used to indicate the fourth FlexE
  • the overhead frame is a response to the second request information, and the second indication information is not used to indicate the time slot allocation table.
  • the second indication information is information indicated by a second field in the fourth FlexE overhead frame, and the second field is switched with the time slot allocation table of the fourth FlexE overhead frame Confirm that the CA field is different.
  • the present application provides a first network device, including a transceiver unit and a processing unit, when the first network device executes the method described in the first aspect and any one of the optional designs in the first aspect
  • the transceiving unit is used to perform transceiving operations
  • the processing unit is used to perform operations other than transceiving.
  • the transceiving unit is configured to send a first flexible Ethernet FlexE overhead frame to the second network device, and receive the data sent by 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.
  • the present application provides a second network device, including a transceiver unit and a processing unit, when the second network device executes the second aspect and any one of the optional designs described in the second aspect
  • the transceiving unit is used to perform transceiving operations
  • the processing unit is used to perform operations other than transceiving.
  • the transceiving unit is configured to receive the first flexible Ethernet FlexE overhead frame sent by the first network device, and send it to the first network device A second FlexE overhead frame and receiving a third FlexE overhead frame sent by the first network device.
  • the processing unit is configured to generate the second FlexE overhead frame.
  • the present application provides a first network device, including a memory and a processor connected to the memory. Instructions are stored in the memory, and the processor reads the instructions so that the first network device executes the foregoing first aspect and the method described in any one of the optional designs of the first aspect.
  • the present application provides a second network device, including a memory and a processor connected to the memory. Instructions are stored in the memory, and the processor reads the instructions so that the second network device executes the above-mentioned second aspect and any one of the methods described in the optional design of the second aspect.
  • the present application provides a first network device, including a communication interface and a processor connected to the communication interface.
  • the first network device is configured to execute the foregoing The method described in the first aspect and any one of the first aspect is optionally designed.
  • the communication interface is used to perform transceiving operations
  • the processor is used to perform operations other than transceiving.
  • the communication interface is used to send a first flexible Ethernet FlexE overhead frame to the second network device, and receive the second network device The second FlexE overhead frame sent, and the third FLexE overhead frame sent to the second network device.
  • the processor 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.
  • the present application provides a second network device, including a communication interface and a processor connected to the communication interface.
  • the second network device is configured to execute the foregoing Any one of the second aspect and the second aspect can be optionally designed as described in the method.
  • the communication interface is used to perform transceiving operations
  • the processor is used to perform operations other than transceiving.
  • the communication interface is configured to receive a first flexible Ethernet FlexE overhead frame sent by the first network device, and send it to the first network device. Sending a second FlexE overhead frame and receiving a third FlexE overhead frame sent by the first network device.
  • the processor is configured to generate the second FlexE overhead frame.
  • this application provides a communication system, including the first network device described in any one of the foregoing third aspect, fifth aspect, or seventh aspect, and the foregoing fourth aspect, sixth aspect, or eighth aspect The second network device of any aspect.
  • the present application provides a computer-readable storage medium, including computer-readable instructions, which when run on a computer, cause the computer to execute the first aspect, the second aspect, and any of the first aspects.
  • this application provides a computer program product, including a computer program, which when the program runs on a computer, causes the computer to execute any possible design of the first aspect, the second aspect, and the first aspect Or any of the possible design methods in the second aspect.
  • Figure 1 is a schematic diagram of the FlexE general architecture based on the flexible Ethernet protocol
  • Figure 2 is a schematic diagram of the time slot allocation of FlexE Group across 4 physical link interfaces (aggregating 4 PHYs);
  • Figure 3 is a schematic diagram of an application scenario of the FlexE communication system involved in this application.
  • FIG. 4 is a schematic diagram of the data transmission process using FlexE technology involved in this application.
  • Figure 5 is a schematic diagram of the structure of the overhead frame and overhead multiframe of the 100GE interface given in the OIF IA-FLEXE-02.1 standard;
  • Figure 6 is a schematic flow chart of a time slot negotiation method
  • FIG. 7 is a schematic diagram for explaining the scenario that causes the RX false answer problem
  • FIG. 8 is a schematic diagram of a time slot negotiation method provided by this application.
  • FIG. 9 is a schematic diagram of a message format for extending an overhead frame provided by this application.
  • FIG. 10 is a schematic flowchart of a time slot negotiation processing method provided by this application.
  • FIG. 11 is a schematic flowchart of a time slot negotiation processing method provided by this application.
  • Figure 12a is a schematic diagram of a CR Request message format provided by this application.
  • Figure 12b is a schematic diagram of a CR Ack message format provided by this application.
  • Figure 12c is a schematic diagram of an LLDP message format provided by this application.
  • Figure 12d is a schematic diagram of a CR Request message format provided by this application.
  • Figure 12e is a schematic diagram of a CR Request message format provided by this application.
  • FIG. 13 is a schematic flowchart of a time slot negotiation processing method provided by this application.
  • FIG. 14 is a schematic flowchart of a time slot negotiation method provided by this application.
  • 15 is a schematic structural diagram of a network device provided by an embodiment of this application.
  • FIG. 16 is a schematic structural diagram of a network device provided by an embodiment of this application.
  • FIG. 17 is a schematic structural diagram of a network device provided by an embodiment of this application.
  • FIG. 18 is a schematic structural diagram of a network device provided by an embodiment of this application.
  • the related FlexE technology involved in this application can refer to the relevant descriptions of the FlexE standard IA OIF-FLEXE-01.0, IA OIF-FLEXE-02.0 or IA OIF-FLEXE02.1 formulated by OIF.
  • the above standards are quoted in full Incorporated into this application.
  • Fig. 1 exemplarily shows a schematic diagram of the general architecture of FlexE based on the flexible Ethernet protocol.
  • FlexE Group includes 4 PHYs.
  • FlexE Client represents a client data stream transmitted in a specified time slot (one time slot or multiple time slots) on a FlexE Group.
  • a FlexE Group can carry multiple FlexE Clients, and a FlexE Client can correspond to one to multiple user service data streams. (It can also be called MAC Client), the FlexE Shim layer provides data adaptation and conversion from FlexE Client to MAC Client.
  • FlexE can support the mapping and transmission of any number of different FlexE Clients on any set of PHYs, so as to realize PHY bundling, channelization and sub-rate functions.
  • FlexE group also called FlexE Group in English
  • FlexE Shim layer can divide each 100GE PHY in the FlexE Group into 20 time slots (slots) of data bearer channels, and each slot corresponds to a bandwidth of 5Gbps.
  • Fig. 2 schematically shows a schematic diagram of the time slot allocation of the FlexE Group across 4 physical link interfaces (aggregating 4 PHYs).
  • each PHY has 20 time slots, so the FlexE Group has 20*4 time slots.
  • the FlexE Group in Figure 1 includes 4 PHYs as an example.
  • the 4 PHYs are PHY A 1201, PHY B 1202, PHY C 1203, and PHY D 1204.
  • the time slot allocation table corresponding to the FlexE Group (also called calendar in English); the time slot mapping table corresponding to a single physical link included in a FlexE Group may be called a sub-time slot allocation table (which may be called sub-calendar in English).
  • FlexE calendar can be composed of one or more sub-calendars.
  • Each sub-calendar can indicate how the 20 slots on the single physical link are allocated to the corresponding FlexEclient. In other words, each sub-calendar can indicate the corresponding relationship between the time slot on the single physical link and the FlexE client.
  • each PHY can correspond to 20 time slots, which are represented by slots 0 to 19 in the figure.
  • Fig. 2 respectively shows a schematic diagram of 20 time slots corresponding to each PHY in PHY A 1201, PHY B 1202, PHY C 1203, and PHY D 1204.
  • FIG. 3 shows a schematic diagram of an application scenario of the FlexE communication system involved in this application.
  • 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. At this time, the network device 1 is connected to the user equipment 1 through other network devices.
  • the network device 1 may be an edge node. In this case, the network device 1 is directly connected to the user equipment 1.
  • the network device 1 may be an intermediate node. At this time, the network device 1 is connected to the user equipment 1 through other network devices.
  • the network device 1 may also be an edge node. In this case, the network device 1 is directly connected to the user equipment 1.
  • the network device 2 may be an intermediate node.
  • the network device 2 is connected to the user equipment 2 through other network devices.
  • the network device 2 may also be an edge node.
  • the network device 2 is directly connected to the user equipment 2.
  • the network device 1 includes a FlexE interface 1, and the network device 2 includes a FlexE interface 2. FlexE interface 1 is adjacent to FlexE interface 2.
  • Each FlexE interface includes a sending port and a receiving port.
  • the difference from a traditional Ethernet interface is that one FlexE interface can carry multiple clients, and the FlexE interface as a logical interface can be composed of multiple physical interfaces.
  • the flow of business data in the forward channel shown in FIG. 3 is shown by the solid arrow in FIG. 3, and the flow of business data in the reverse channel is shown by the dashed arrow in FIG. 3.
  • the transmission channel in the embodiment of the present invention takes the forward channel as an example, and the flow direction of the service data in the transmission channel is user equipment 1 network equipment 1 network equipment 2 user equipment 2
  • FIG. 3 only exemplarily shows two network devices and two user equipments, and the network may include any other number of network devices and user equipments, which is not limited in the embodiment 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 in this application is not limited to the scenario shown in FIG. 3.
  • the technical solution provided in this application is applicable to all network scenarios where FlexE technology is applied for data transmission.
  • a FlexE group interface is a logical interface bound by a group of physical interfaces.
  • the FlexE group interface carries a total of 6 clients, client1 to client6. Among them, the data mapping of client1 and client2 is transmitted on PHY1; the data mapping of client3 is transmitted on PHY2 and PHY3; the data mapping of client4 is transmitted on PHY3; the data mapping of client5 and client6 is transmitted on PHY4.
  • Different FlexE clients are mapped and transmitted on the FlexE group to realize the bundling function. among them:
  • FlexE group It can also be called a bundle group.
  • the multiple PHYs included in each FlexE group have a logical bundling relationship.
  • the so-called logical bundling relationship means that there may not be a physical connection relationship between different PHYs. Therefore, multiple PHYs in the FlexE group may be physically independent.
  • the network equipment in FlexE can identify which PHYs are included in a FlexE group through the PHY number, so as to realize the logical bundling of multiple PHYs.
  • the number of each PHY can be identified by a number between 1-254, and 0 and 255 are reserved numbers.
  • the number of a PHY can correspond to an interface on a network device. Two adjacent network devices need to use the same number to identify the same PHY.
  • each PHY included in a FlexE group does not have to be consecutive. Generally, there is a FlexE group between two network devices, but this 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 can be used to carry at least one client, and one client can be transmitted on at least one PHY.
  • FlexE client Corresponds to various user interfaces of the network, consistent with the traditional business interfaces in the existing IP/Ethernet network. FlexE client can be flexibly configured according to bandwidth requirements, and supports Ethernet MAC data streams of various rates (such as 10G, 40G, n*25G data streams, and even non-standard rate data streams). For example, it can be encoded by 64B/66B. The data stream is passed to the FlexE shim layer. FlexE client can be interpreted as an Ethernet stream based on a physical address. Clients sent through the same FlexE group need to share the same clock, and these clients need to adapt according to the allocated time slot rate.
  • FlexE shim As an additional logical layer inserted between the MAC and PHY (PCS sublayer) of the traditional Ethernet architecture, it is the core architecture of FlexE technology based on the time slot distribution mechanism of the calendar.
  • the main function of FlexE shim is to slice data according to the same clock, and encapsulate the sliced data into pre-divided slots. Then, according to the pre-configured time slot allocation table, each divided time slot is mapped to the PHY in the FlexE group for transmission. Among them, each time slot is mapped to a PHY in the FlexE group.
  • the time slot allocation table which can also be called the time slot table.
  • the FlexE Group corresponds to the calendar, and the time slot mapping table corresponding to a single physical link (PHY) included in a FlexE Group may be called a sub-time slot allocation table (English: sub-calendar).
  • FlexE calendar can be composed of one or more sub-calendars. Each sub-calendar can indicate how the 20 time slots (which can be written as slot in English) on the single physical link are allocated to the corresponding FlexEclient. In other words, each sub-calendar can indicate the corresponding relationship between the time slot on the single physical link and the FlexE client.
  • each FlexE overhead frame specifies two Calenders, which are the current primary time slot table (Calender A) and the backup time slot table (Calender B).
  • FlexE constructs a fixed frame format for physical interface transmission and divides TDM time slots.
  • the following is an example of the existing FlexE frame format.
  • the time slot division granularity of FlexE can be 66B, which bears one 64B/66B coding block correspondingly, and each 64/66B coding block is carried in a slot.
  • a FlexE frame contains 8 rows, and the first 64B/66B bit block in each row is the FlexE overhead block. After the overhead block is the payload area for time slot division. With a granularity of 66 bits, it corresponds to 20x1023 66-bit bearing spaces.
  • the bandwidth of a 100GE interface is divided into 20 time slots, and each time slot has a bandwidth of about 5Gbps, which is called a slot.
  • 64B/66B can be understood as a 64-bit bit block and a 66-bit encoding block obtained by encoding it.
  • FlexE implements multiple transmission channels on a single physical interface through interleaving and multiplexing, that is, multiple time slots. FlexE is just an interface technology, and the related switching technology can be based on existing Ethernet packets, or it can be crossed based on FlexE, which will not be repeated here.
  • the FlexE shim layer reflects the time slot mapping relationship between the client and the FlexE group and the calendar working mechanism by defining overhead frames and overhead multiframes.
  • the above-mentioned overhead frame may also be referred to as a flexible Ethernet overhead frame (English: FlexE overhead frame)
  • the above-mentioned overhead multiframe may also be referred to as a flexible Ethernet overhead multiframe (English: FlexE overhead Multiframe).
  • the FlexE shim layer provides an in-band management channel through overhead, supports the transfer of configuration and management information between the two FlexE interfaces that are connected, and realizes the establishment of automatic link negotiation.
  • Data on each PHY of FlexE is aligned by periodically inserting code blocks of FlexE overhead frame (OH) frames, for example, one 66B overhead code can be inserted every 1023 ⁇ 20 payload data code blocks of 66B Block FlexE OH.
  • OH FlexE overhead frame
  • a FlexE Group will send a 64B/66B code block of a FlexE overhead frame to the remote PHY at a predetermined time interval on each PHY, and 8 sequential FlexE overhead frames of 64B/ The 66B code block constitutes a FlexE overhead frame.
  • FlexE defines some fields on the overhead frame to carry the time slot allocation table, and synchronizes the time slot allocation table to the PHY on the remote communication device through the FlexE overhead frame to ensure that the two-terminal communication device uses the same time slot allocation table to receive and Send the data stream corresponding to the FlexE client.
  • an overhead frame has 8 overhead blocks (English: overhead blocks), and the above overhead blocks may also be called overhead slots (English: overhead slots).
  • the overhead block may be, for example, a 64B/66B encoded code block, which appears once every 1023*20 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 the overhead multiframe of the 100GE interface given in the OIFIA-FLEXE-02.1 standard.
  • the structure of the FlexE overhead frame (hereinafter referred to as the overhead frame) is briefly introduced below in conjunction with FIG. 5.
  • one overhead frame includes 8 overhead blocks.
  • the overhead frame specifies the following bit fields (or can also be called fields) in the overhead block 1 (block 1) to the overhead block 3 (block 3), which are used to guide the time slot negotiation between communication devices.
  • the overhead block 4 (block4) to the overhead block 8 (block8) of the overhead frame is the management channel (English: Management Channel).
  • the management channel can be used to carry 1588 packets, synchronous Ethernet packets, DCN packets, and link search packets. Wen etc.
  • the management channel has no restrictions on the types of messages it can carry, and only needs to ensure that the encoding format of the message can be decoded normally by the communication device.
  • C 1bit, used to indicate the current time slot allocation table configuration (Calendar configuration in use).
  • the C bit defines three positions in the overhead, which have the same meaning, mainly to ensure reliability.
  • This bit field is represented by the CCC field in the subsequent description. For example, if the value of CCC is 0, it means that the current primary time slot allocation table is Calendar A; if the value of CCC is 1, it means that the current time slot allocation table is Calendar B. It should be noted that in this application, in the overhead frame, the values of the three C bits are always the same, that is, all 0 or all 1.
  • the value of CCC is 1, which means that all three C bits have a value of 1, and the value of CCC is 0, which means that all three C bits have a value of 0.
  • CR 1bit, used to indicate a time slot negotiation request.
  • the time slot negotiation request can also be called a time slot allocation table switch request (Calendar Switch Request).
  • the value of the CR field is consistent with the value of the CCC field, indicating the current main time slot allocation table.
  • the value of the CR field will be different from the value of the CCC field.
  • the value of the CR field points to the spare time slot allocation table, and the value of the CCC field points to the current main time slot allocation table.
  • CA 1bit, used to indicate the time slot allocation table switch confirmation (Calendar Switch Acknowledge).
  • the semantics of the CA field is ambiguous. It is used to indicate the response of the receiving end device (hereinafter referred to as RX) to the time slot negotiation request sent by the transmitting end device (hereinafter referred to as TX), and is used to indicate the time slot allocation table. . If the value of the CA field carried in the overhead frame of the RX response is consistent with the value of the CR field carried in the overhead frame sent by the received TX, the TX considers this to be the response of the RX to the time slot negotiation request sent by the RX, and the RX It is ready to switch to the time slot allocation table indicated by the CA field.
  • TX switches from the main time slot allocation table to the spare time slot allocation table, and modifies the value of the CCC field to the same value as the CR field when sending the time slot negotiation request, and sends it to the RX along with the overhead frame.
  • network device 1 is identified as TX
  • network device 2 is identified as RX.
  • TX the TX direction initiates the switch from the primary time slot table Calendar A to the backup calendar B.
  • the reason for triggering the time slot table switch can be, for example:
  • FlexE Group in TX and/or RX direction is adding or deleting PHY, or the status of PHY changes
  • the time slot negotiation method 100 is executed between TX and RX, including:
  • TX initiates a time slot negotiation request, requesting RX to switch the spare time slot allocation table to the main time slot allocation table.
  • S101-S103 describe the complete time slot negotiation process under normal conditions.
  • the subsequent switching process from Calendar B to Calendar A initiating the time slot table in the TX direction is also a similar process.
  • Those skilled in the art can understand that after S101, if the TX direction does not receive the RX time slot negotiation response for a long time, the time slot negotiation request will be sent again at regular intervals.
  • the subsequent steps are the same as S102 and S103, and will not be repeated.
  • the FlexE overhead time slot negotiation mechanism described in the method 100 has the problem of RX error response.
  • the scenarios that cause the above-mentioned problems will be described in detail below with reference to FIG. 7.
  • the TX and RX at both ends of the FlexE Group establish a communication connection, and the RX performs the equipment due to some reasons (for example: device power failure, related service board insertion or removal, or single board hard reset triggered by fault self-healing, etc.) Reboot.
  • the RX side all negotiation data about the FlexE Group are cleared, and the main time slot table of the RX is Calendar A by default.
  • the values of the CA, CR, and CCC fields in the overhead frame of the routine refresh sent by the RX are all 0.
  • the current primary time slot allocation table of TX is Calendar B.
  • the preparations for the TX direction include:
  • PHY plus group Add to the management of the corresponding FlexE group according to the FlexE Group number configuration of the PHY.
  • TX time slot refresh the time slot configuration is issued in the TX direction.
  • the specific time slot negotiation method 200 includes:
  • TX direction initiates a time slot negotiation request, requesting to switch the time slot allocation table.
  • RX direction When the RX direction receives the time slot negotiation request, the restart recovery process is still in progress, and the relevant processing data is not ready, and the preparation work in the RX direction is not ready, so there is no response to this time slot negotiation request.
  • Preparations for the RX direction include:
  • PHY plus group According to the FlexE group number configuration of the PHY, it is added to the management of the corresponding FlexE group.
  • FlexE group establishment receives the FlexE overhead frame from the TX opposite end, and parses out the internal Group number and PHY number, and verifies that they are consistent with the local configuration, and then considers that the FlexE group establishment operation is successful.
  • CR interrupt is turned on: When the FlexE group and PHY data are ready, the CR interrupt is turned on to accept the time slot negotiation request in the TX direction.
  • the RX direction depends on the CR interrupt to do the following:
  • the RX direction receives the FlexE overhead and finds that the CR is inconsistent with the CCC, and it is considered as a new time slot negotiation request.
  • RX extracts the time slot allocation table information specified by CR from this 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. (Due to the restart of the RX side device, the main time slot allocation table of the physical Mac on the RX side is empty and invalid)
  • the time slot information of the physical MAC on the RX side will be empty or inconsistent with the time slot configuration on the TX side, resulting in interruption.
  • the RX routinely sends a refreshed FlexE overhead frame to the TX at a fixed periodic interval.
  • the TX When the TX does not re-negotiate the time slot requirement subsequently, the TX will not re-initiate the time slot negotiation request. It can be seen that the FlexE overhead routinely sent by the RX mistakenly responded to the time slot negotiation request sent by the TX.
  • the RX After the RX receives the FlexE overhead frame sent by the TX in S203, even if the RX has done the preparation work as described above, it actually did not correctly process the time slot negotiation request sent by the TX in S201, so the RX cannot obtain the correct time. Slot information, causing the traffic from TX to RX to be interrupted.
  • the method 300 provided by the embodiment of the present application will be described in detail below with reference to FIG. 8.
  • the network architecture of the application method 300 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.
  • network device 1 and network device 2 are connected through a single PHY, or they can be connected through a FlexE group.
  • the network architecture may be, for example, the network architecture shown in FIG. 3.
  • the method 300 will be introduced below in conjunction with FIG. 8 and taking the architecture shown in FIG. 3 as an example.
  • Method 300 includes:
  • the network device 1 sends the FlexE overhead frame 1 to the network device 2.
  • the FlexE overhead frame 1 includes request information 1, which is used to request the network device 2 to perform the active/standby switching of the time slot allocation table, that is, request the network device to switch the standby time slot allocation table to the primary time slot allocation table.
  • the aforementioned request information 1 is the information indicated by the CR field and the CCC field in the FlexE overhead frame 1.
  • the value of the CR field carried in the FlexE overhead frame 1 is 0, and the value of the CCC field is 1.
  • the FlexE overhead frame 1 is used to send the time slot negotiation request 1, which can also be referred to as the time slot allocation table switching request 1.
  • the value of the CCC field is 1, it means that the current main time slot allocation table is time slot allocation table 1.
  • the value of the CR field is 0, it indicates a request to switch the current main time slot allocation table to a spare time slot allocation table, that is, time slot allocation table 2.
  • the time slot allocation table 1 may be Calendar B defined in the standard, and the time slot allocation table 2 is Calendar A defined in the standard.
  • the above-mentioned request information 1 may be the request message 1 carried in the management channel of the first FlexE overhead frame.
  • the request message 1 may also be referred to as a time slot negotiation request message 1.
  • the specific format of the request message carried in the management channel please refer to the specific description given below in conjunction with FIG. 12a) or FIG. 12c and FIG. 12d.
  • the format of the request message carried in the management channel is not limited to the examples given in this application, and this application does not specifically limit the specific format of the request message carried in the management channel.
  • the network device 2 receives the FlexE overhead frame 1.
  • the received FlexE overhead frame 1 can be discarded without actual processing.
  • the network device 2 sends the FlexE overhead frame 2 to the network device 1.
  • the FlexE overhead frame 2 is a FlexE overhead frame routinely sent by the network device 2 to the network device 1 according to 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.
  • the value of the CR field carried in the FlexE overhead frame 1 is 0, and the value of the CA field of the FlexE overhead frame 2 is also 0.
  • the network device 1 receives the FlexE overhead frame 2 sent by the network device 2.
  • 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.
  • FlexE overhead frame 2 is not a response to request information 1, which means that FlexE overhead frame 2 is not a response to time slot negotiation request 1, nor is it a response to 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 the time slot negotiation request 1 sent by the network device 2 Trusted response.
  • the specific description of S305 will be described in detail below, and will not be repeated here.
  • the network device 1 sends the FlexE overhead frame 3 to the network device 2.
  • the FlexE overhead frame 3 includes request information 2, which is used to request the network device 2 to perform the active/standby switching of the time slot allocation table, that is, request the network device 2 to switch the standby time slot allocation table to the main time slot allocation table.
  • request information 2 and request information 1 are the same, and the difference is that they are carried in different FlexE overhead frames. Therefore, for the description of the request information 2, please refer to the description of the request information 1 above, which will not be repeated here.
  • the value of the CR field carried in the FlexE overhead frame 3 is 0, and the value of the CCC field is 1.
  • the network device 1 determines that the FlexE overhead frame 2 is not a response to the request information 1, and the network device 1 sends a time slot negotiation request to the network device 2 again.
  • FlexE overhead frame 3 is used to issue time slot negotiation request 2, that is, time slot allocation table switching request 2. That is, network device 1 again requests time slot negotiation with network device 2, and requests to switch the spare time slot allocation table to the main time slot allocation table.
  • the network device 2 receives the FlexE overhead frame 3.
  • the network device 2 sends a FlexE overhead frame 4 to the network device 1, and responds to the received request information 2.
  • the network device 2 if the network device 2 has completed the device restart and made relevant preparations, the network device 2 turns on the CR interrupt and responds to the time slot negotiation request 2 sent by the network device 1.
  • the network device 1 and the network device 2 continue to perform the operation of switching the time slot allocation table according to the negotiation result.
  • the time slot negotiation request is triggered repeatedly until the network device 1 determines that the network device 2 sends it to it. A valid response was made to the time slot negotiation request.
  • the FlexE overhead frame 4 includes indication information 2, and the indication information 2 is used to indicate that the FlexE overhead frame 4 is a response to the request information 2.
  • the network device 1 receives the FlexE overhead frame 4.
  • the network device 1 determines that the FlexE overhead frame 4 is a response to the request information 2 according to the instruction information 2, and then switches the spare time slot allocation table to the main time slot allocation table.
  • the network device 1 sends a FlexE overhead frame 5 to the network device 2, instructing the network device 2 to switch the spare time slot allocation table to the main time slot allocation table.
  • the value of the CCC field in the FlexE overhead frame 5 is the same as the value of the CR field, and its value is the same as the value of the CR field in the FlexE overhead frame 1.
  • the network device 2 receives the FlexE overhead frame 5, and switches the spare time slot allocation table to the main time slot allocation table.
  • FlexE overhead frame 3 does not mean that it is necessarily an overhead frame adjacent to FlexE overhead frame 2 in time sequence. It can also be that network device 1 sends multiple timeslot negotiation requests to network device 2 One of the following overhead frames.
  • the operation "CR interrupt" mentioned in this application refers to when the network device receives the time slot negotiation request overhead frame (the value of CR and CCC in the received FlexE overhead frame is different, it is considered as a time slot negotiation request) , Read the time slot allocation table information carried in the overhead frame, and refresh the locally saved time slot table configuration.
  • the execution of the CR interrupt can be implemented by software in the processor.
  • the processor reads the overhead frame information stored in the register through the interface connected to the network forwarding chip, and refreshes the configuration of the locally saved time slot allocation table according to the configuration information of the latest time slot allocation table carried in the overhead frame.
  • the execution of the CR interruption may be implemented by a forwarding chip.
  • processing logic can be set in the chip to read the information of the time slot negotiation overhead frame, and refresh 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.
  • the FlexE overhead frame that the RX replies to the TX carries indication information, so that the indication information can indicate whether the FlexE overhead frame is a response to the time slot negotiation request sent by the TX.
  • the TX determines that the received FlexE overhead frame is not a response to the time slot negotiation request sent by the TX according to the instruction information, the TX will resend the time slot negotiation request until the TX confirms that the RX has negotiated the time slot sent by it. The request was responded to.
  • the network device 1 can, but not limited to, determine whether the received FlexE overhead frame is a response to the request information (or a time slot negotiation request) sent by the network device 1 through the following methods 1 to 3 .
  • the indication information 1 and the indication information 2 are the information indicated by the newly expanded field in the FlexE overhead frame, and the newly expanded field is not the CA field. For example, one or more bits are added to the reserved (Reserved) field of the FlexE overhead frame shown in FIG. 5 to identify the indication information 1 and the indication information 2. It is also possible that a new field is added to the FlexE overhead frame management channel to identify the indication information 1 and the indication information 2. Specifically, the newly added at least one bit in FlexE overhead frame 2 is indication information 1, and the newly added at least one bit in FlexE overhead frame 4 is indication information 2. In a specific implementation manner, in the FlexE overhead frame, a new bit is added, and different values of the added bit are used to identify the indication information 1 and the indication information 2 respectively.
  • the value of the newly added bit in the FlexE overhead frame is 1, it is used to indicate that the FlexE overhead frame is a response to the received slot negotiation request; when the value of the newly added bit is 0, it is used for Indicates that the FlexE overhead frame is not a response to the time slot negotiation request.
  • the value of the newly added bit in the FlexE overhead frame 2 is 1, it is used to indicate that the FlexE overhead frame 2 is a response to the request information 1; when the value of the newly added bit is 0 When, it is used to indicate that the FlexE overhead frame 2 is not a response to the request information 1.
  • the indication information 1 and the indication information 2 may also be identified in a bit map manner. For example, in the FlexE overhead frame, two new bits are added, and each bit maps indication information 1 and indication information 2 respectively, and the specific indication method is not repeated here. It should be understood that the present application is not limited to the above-mentioned embodiments.
  • the newly expanded field in the FlexE overhead frame is used to indicate whether the FlexE overhead frame sent by RX is a response to the request information carried in the FlexE overhead frame sent by TX, and the CA field in the FlexE overhead frame is used It is used to indicate the time slot allocation table, not to indicate whether the FlexE overhead frame is a response to the request information.
  • the 1Bit idle bit field is found in the FlexE overhead frame.
  • this application is temporarily referred to as the RR (RX CR Ready Flag) flag. It is understandable that this application does not name the flag as Limited and this.
  • the TX direction initiates a switch from Calendar B to Calendar A in the time slot allocation table based on some of the reasons mentioned above.
  • TX initiates a time slot negotiation request.
  • RX sends a time slot negotiation response to TX.
  • the RX sends a FlexE overhead frame to the TX in response to the time slot negotiation request.
  • the RR flag is set to 1
  • the CA flag is set to 0.
  • TX direction If the TX direction does not receive a valid time slot negotiation response from RX for a long time, it will send the time slot negotiation request again at regular intervals.
  • RR is set to 0 again to wait for the next time slot negotiation request process initiated by TX to be processed.
  • RX has not done the relevant preparation work, it sends FlexE overhead frame to TX routinely, among them, RR is set to 0.
  • the TX receives the FlexE overhead frame with the RR set to 0, and determines that the FlexE overhead is not a response to the time slot negotiation request sent by it.
  • TX sends a time slot negotiation request to RX again.
  • CR is set to 0 and CCC is set to 1.
  • the indication information 1 and indication information 2 may be the information indicated by the CA field in the FlexE overhead frame.
  • the semantics of the CA field defined in the current standard is changed.
  • the semantics of the CA field is ambiguous, and it is used to express the negotiated response and to indicate the time slot allocation table.
  • the ambiguous definition of CA segments in the current standards has led to the technical problems described above in this application.
  • the semantics of the CA is changed so that it is used to indicate the validity of the negotiation response, but not used to indicate the time slot allocation table, in other words, not used to indicate the output of the negotiation.
  • the value of CA has nothing to do with the configuration of the time slot allocation table, that is, it has nothing to do with the negotiated output.
  • the CA field is used to indicate whether the FlexE overhead frame sent by the RX is a response to the time slot allocation table negotiation request sent by the TX.
  • the indication information 1 is the information indicated when the CA field of the FlexE overhead frame 2 is assigned the first value.
  • the indication information 2 is the information indicated when the CA field of the FlexE overhead frame 4 is assigned the second value.
  • the CA field in the FlexE overhead frame 2 is assigned a value of 0, it is used to indicate that the FlexE overhead frame 2 is a response to the time slot negotiation request 1, but is not used to indicate the time slot allocation table.
  • the CA field of the FlexE overhead frame 4 is assigned a value of 1, it is used to indicate that the FlexE overhead frame 4 is a response to the time slot negotiation request 2 and is not used to indicate the time slot allocation table.
  • the RX completes the preparation for switching the time slot allocation table locally.
  • the CA field is no longer used to indicate the time slot allocation table. As long as the TX receives the CA assigned as the second value
  • the FlexE overhead frame means that the negotiation is considered complete, and the switching process of the time slot allocation table is continued.
  • the solution provided by the second mode changes the semantics of the existing CA field, and abandons the semantic characteristics of the CA indicating the time slot allocation table, that is, the semantic characteristics of the CA field used to indicate negotiation output.
  • the CA segment is used to indicate the validity of the negotiation response, not just the negotiation output, which solves the ambiguity problem of the existing CA field and effectively avoids the impact on the service caused by errors in the time slot negotiation process.
  • the TX direction initiates a switch from Calendar B to Calendar A in the time slot allocation table based on some of the reasons mentioned above.
  • S401 The TX initiates a time slot negotiation request.
  • the RX sends a time slot negotiation response to the TX.
  • the RX sends a FlexE overhead frame to the TX in response to the time slot negotiation request.
  • the CA flag is set to 1, which is used to indicate that the FlexE overhead frame is a response to the received time slot negotiation request.
  • TX direction If the TX direction does not receive a valid time slot negotiation response from RX for a long time, it will send the time slot negotiation request again at regular intervals.
  • CA is set to 0 again to wait for the next time slot negotiation request process initiated by the TX to be processed.
  • the TX After sending the time slot negotiation request, the TX receives the FlexE overhead frame with the CA set to 0, and determines that the FlexE overhead is not a response to the time slot negotiation request sent by it.
  • TX sends a time slot negotiation request to RX again.
  • CR is set to 0 and CCC is set to 1.
  • the third method is to add a request message and a response message to the management channel of the FlexE overhead frame to complete the time slot negotiation between the network device 1 and the network device 2.
  • the value of the CA field in the overhead frame can be used to indicate the time slot allocation table, that is, to express the output of the negotiation, but not to express the negotiation The validity of the response.
  • This method expresses by adding a request message (also referred to as a time slot negotiation request message in this application) and a response message (also referred to as a time slot negotiation response message in this application) in the management channel.
  • Time slot negotiation request and response judges whether the received overhead frame is a response to the time slot negotiation request message sent by the overhead frame management channel through whether the time slot negotiation response message is carried in the management channel, and solves the problem.
  • the indication information 1 in S305 is the information indicated by the management channel of the FlexE overhead frame 2
  • the indication information 2 described in S310 is the information indicated by the management channel of the FlexE overhead frame 4.
  • the management channel provided in the FlexE overhead does not limit the types of messages it carries. It only needs to ensure that the messages are transmitted in accordance with the specified encoding format.
  • the management channel described in this application complies with the management channel of the overhead frame defined in the existing standard.
  • the current standard defines the management channel as the 4th to 8th blocks of the overhead frame.
  • the management channel described in this application is compatible with the definition of the management channel in various standards.
  • Figure 12a exemplarily shows the message format of the time slot negotiation request message (CR Request) added to the management channel
  • Figure 12b exemplarily shows the time slot negotiation request message (CR Request) added to the management channel.
  • SMAC Source MAC address
  • the length can be, for example, 6 bits
  • the value can be the MAC address of the source port.
  • DMAC Destination MAC
  • the length can be, for example, 6 bits, and the value can be all ones.
  • TYPE The message type, the length can be 2bit, for example, and the value can be all 0s.
  • GROUP NUM FlexE Group number, the length can be, for example, 2 bits, indicating which FlexE Group it belongs to.
  • Flag The subtype of the message.
  • the length can be 20 bits, for example.
  • the value of the Flag field may be the character string "CR Request"; in the CR Ack message, the value of the Flag field may be the character string "CR Ack”.
  • FIG. 12c to FIG. 12d exemplarily give another specific example of the CR Request message and the CR Ack.
  • the parent TLV field carried in the link layer discovery protocol (English: link layer discovery protocol, LLDP) message payload is extended, and the child TLV type is added to carry CR Request messages and CR Ack Message.
  • the payload of the LLDP message includes multiple concatenated TLVs.
  • Figure 12c shows the parent TLV.
  • the parent TLV includes a type field, a length field, and a value field. Among them, multiple sub-TLVs can be cascaded in the value field.
  • the following takes the parent TLV type 127 (that is, the value of the T field is 127) as an example to illustrate how to carry the CR Request message and the CR Ack message in the parent TLV field of the LLDP message.
  • Figure 12d shows the specific format diagram of the sub-TLV used to represent the CR Request message extended in the Value field shown in Figure 12c
  • Figure 12e shows the extension used to represent the value field shown in Figure 12c) Schematic diagram of the specific format of the sub-TLV of the CR Request message.
  • the sub-TLV field includes a type field, a length field and a value field.
  • the type field is used to indicate that the type of the sub-TLV is a CR Request message, and the length can be, for example, 7 bits;
  • the Length field indicates the length of the V field, and the length can be, for example, 9 bits;
  • the value field is used to carry the FlexE Group number, and the length can be, for example, It is 2bytes.
  • the sub-TLV field includes a type field, a length field and a value field.
  • the type field is used to indicate that the type of the sub-TLV is a CR Ack message, and the length can be, for example, 7 bits;
  • the Length field indicates the length of the V field, and the length can be, for example, 9 bits;
  • the value field is used to carry the FlexE Group number, and the length can be, for example, It is 2bytes.
  • the TX sends a CR Request message to the RX, and sends a time slot negotiation request to the RX.
  • TX sends FlexE overhead frame 1 to RX, and sends slot negotiation request 1.
  • the request information 1 is carried in the management channel of the FlexE overhead frame 1.
  • the request information 1 is a CR Request message 1, requesting the network device 2 to switch from the current time slot allocation table B to the time slot allocation table A.
  • the main time slot allocation table is time slot allocation table B
  • the spare time slot allocation table is time slot allocation table A.
  • the PHY group addition action After judging that the local FlexE Group has completed the group activation action, the PHY group addition action, and the CR time slot negotiation interruption is turned on, it responds to the CR Ack message through the FlexE overhead management channel.
  • the RX direction If the RX direction is not ready to process the time slot negotiation, it does not respond to the CR Request message, that is, does not send the CR Ack message.
  • the RX sends the FlexE overhead frame 2 that is routinely refreshed to the TX.
  • the management channel of FlexE overhead frame 2 does not carry response message 1.
  • response message 1 is CR Ack message 1.
  • 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.
  • the TX determines, according to the management channel of the FlexE overhead frame 2, that the FlexE overhead frame 2 is not a response to the time slot negotiation request 1.
  • TX sends FlexE overhead frame 3 to RX, which is used to send time slot negotiation request 2.
  • the management channel of FlexE overhead frame 3 carries request information 2, that is, negotiation request message 2 (CR Reuest message 2), which is used to send time slot negotiation request 2.
  • request information 2 that is, negotiation request message 2 (CR Reuest message 2), which is used to send time slot negotiation request 2.
  • the RX receives the FlexE overhead frame 3.
  • the management channel of the FlexE overhead frame 4 carries a response message 2, that is, a negotiation response message 2 (CR Ack message 2).
  • 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.
  • the TX receives the FlexE overhead frame 4.
  • the TX determines, according to the indication information 2, that the FlexE overhead frame 4 is a response to the time slot negotiation request 2.
  • TX switches from Calendar B to Calendar A.
  • RX receives FlexE overhead frame 5, and completes the switch from Calendar B to Calendar A.
  • the above S501 to S509 are used as a pre-negotiation process.
  • TX confirms that the pre-negotiation process is successful, and then starts to perform formal negotiation. Process.
  • the existing time slot negotiation process can be guaranteed to remain unchanged.
  • the definition of the CA field complies with the definition in the existing standard, because in the formal negotiation process, the pre-negotiation process has been completed. Only when the pre-negotiation is successful, the formal negotiation will start. Therefore, the problem of the RX from erroneously answering the time slot negotiation request sent by the TX can be avoided, and the normal service forwarding can be effectively ensured.
  • Step A TX initiates a time slot negotiation request 3 to RX.
  • TX After the TX receives the CR Ack message in the direction, it indicates that the RX is ready to negotiate the time slot with the TX.
  • TX sends FlexE overhead frame 6 to RX again to initiate slot negotiation request 3.
  • TX and RX start to negotiate the time slot according to the existing process, and initiate the negotiation of switching the time slot table from Calendar B to Calendar A.
  • TX direction sends the latest Calendar A content to RX through FlexE overhead frame 6.
  • Step B RX sends a response to time slot negotiation request 3 to TX.
  • step C continue to perform the above steps S510-S512, which will not be repeated here.
  • the time slot negotiation method can solve the problem of false response in the FlexE overhead time slot negotiation mechanism defined by the current OIF standard.
  • the essence 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 1 Bit, it is necessary to express the negotiation output and the negotiation response, so there is an ambiguity in semantic expression.
  • the problem of CA bit field ambiguity is effectively resolved, so that TX can accurately determine whether the received FlexE overhead is a response to the time slot negotiation request sent by it, and make a decision based on the result of the determination.
  • FIG. 14 is a schematic flowchart of a time slot negotiation method 600 provided by an embodiment of the present application.
  • the network architecture of the application method 600 includes at least the first network device and the second network device.
  • the first network device may be the network device 1 (TX) shown in FIG. 3
  • the second network device may be the network device 2 (RX) shown in FIG. 3.
  • the method shown in FIG. 14 can specifically implement the method shown in any of the embodiments described in conjunction with FIG. 6 to FIG. 13.
  • the first network device and the second network device in FIG. 14 may be the network device 1 and the network device 2 in the method 300 shown in FIG. 8 respectively.
  • the method 600 shown in FIG. 14 includes the following contents.
  • 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, and the first request information is used to request the second network device to switch the spare time slot allocation table to the main time slot allocation table.
  • the second network device receives the first FlexE overhead frame of the first network device.
  • the second network device sends a second FlexE overhead frame to the first network device.
  • the first network device receives the second FlexE overhead frame sent by the second network device.
  • the first network device determines, 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.
  • the first network device sends a third FLexE overhead frame to the second network device.
  • the second network device receives the third FLexE overhead frame.
  • 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 spare time slot allocation table to the main time slot allocation table.
  • the first request information is a first request message carried in a management channel of the first FlexE overhead frame.
  • the first request message may be, for example, a time slot negotiation request message, which has the message format described in the corresponding embodiments as shown in FIG. 12a and FIG. 12c.
  • the first request information is the information indicated by the CR and CCC fields carried in the first FlexE overhead frame. Where the CR field and the CCC field have different values, it indicates that the first FlexE overhead frame is used for the time slot negotiation request.
  • the second request information is a second request message carried in the management channel of the third FlexE overhead frame.
  • the second request message may be, for example, a time slot negotiation request message, which has the message format described in the corresponding embodiment in FIG. 12a and FIG. 12c.
  • the second request information is the information indicated by the CR and CCC fields carried in the third lexE overhead frame. Where the value of the CR field and the CCC field are different, it indicates that the third lexE overhead frame is used for a time slot negotiation request.
  • the first indication information is a management channel of the second FlexE overhead frame, and the management channel of the second FlexE overhead frame does not carry a first response message, and the first response message It is used to indicate that the second FlexE overhead frame is a response to the first request information.
  • the first indication information is the information indicated by the first field in the second FlexE overhead frame, and the first field and the time slot allocation table switch confirmation of the second FlexE overhead frame
  • the CA field is different.
  • the first indication information is information indicated by the time slot allocation table switching confirmation CA field of the second FlexE overhead frame, and the first indication information is used to indicate the second FlexE overhead
  • the frame is not a response to the first request information, and the first indication information is not used to indicate the time slot allocation table.
  • time slot negotiation method 600 After the first network device sends the first time slot negotiation request to the second network device, after determining that the FlexE overhead frame returned by the second network device is not a response to the time slot negotiation request sent by it, A new time slot negotiation request will be issued again. Therefore, it is possible to effectively avoid service interruption caused by considering the FlexE overhead frame routinely refreshed by the second network device as a response to the time slot negotiation request sent by the second network device.
  • the method may further include:
  • the first network device receives the fourth FlexE overhead frame sent by the second network device;
  • the second indication information carried in the FlexE overhead frame of the first network device determines that the fourth FlexE overhead frame is a response to the second request information.
  • the first network device determines that the fourth FlexE overhead frame is a response to the second request information, it executes the master/backup switch of the time slot allocation table, that is, the switch of the standby time slot allocation table It is the main time slot allocation table.
  • the method 600 may further include:
  • the first network device sends a fifth FlexE overhead frame to the second network device.
  • the CR field in the fifth FlexE overhead frame is different from the CCC field. It is used to issue a third time slot negotiation request and request to switch the spare time slot allocation table to Main time slot allocation table.
  • the second network device receives the fifth FlexE overhead frame, and sends a sixth FlexE overhead frame to the first network device.
  • the sixth FlexE overhead frame is a response to the third time slot negotiation request.
  • the first network device receives the sixth FlexE overhead frame, and determines, according to the CA field of the sixth FlexE overhead frame, that the sixth FlexE overhead frame is a response to the third time slot negotiation request.
  • the first network device executes the main-standby switching of the time slot allocation table, that is, switches the standby time slot allocation table to the main time slot allocation table.
  • 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 message
  • the second response message is used for To indicate that the fourth FlexE overhead frame is a response to the second request information.
  • the second indication information is the information indicated by the time slot allocation table switching confirmation CA field of the fourth FlexE overhead frame, and the second indication information is used to indicate the fourth FlexE
  • the overhead frame is a response to the second request information, and the second indication information is not used to indicate the time slot allocation table.
  • the second indication information is the information indicated by the second field in the fourth lexE overhead frame, and the second section is switched with the time slot allocation table of the fourth lexE overhead frame Confirm that the CA field is different.
  • the above-mentioned first request information and the second request information may, for example, correspond to the request information described in the foregoing method embodiments. 1 and request information 2.
  • the foregoing first indication information and second indication information may, for example, correspond to the indication information 1 and the indication information 2 described in the foregoing method examples.
  • the specific format of the first request information, the second request information, the first instruction information, the second instruction information, and the specific implementation of each step in the method 600 please refer to the relevant description of the corresponding steps in the foregoing method embodiments. I won't repeat it here.
  • the network device 700 can be applied to the network architecture shown in FIG. 3.
  • the network device 700 may be the network device 1 (TX) or the network device 2 (RX) described in this application, and is used to execute the method of the embodiment corresponding to any one of the drawings in FIG. 6 to FIG. 14.
  • the network device 700 may also be the first network device or the second network device described in this application, and is configured to execute the method corresponding to FIG. 14.
  • the network device 700 includes a transceiver unit 701 and a processing unit 702.
  • the transceiving unit 701 is used to perform transceiving operations, and the processing unit is used to perform operations other than transceiving.
  • the transceiving unit 701 may be configured to send the first flexible Ethernet FlexE overhead frame to the second network device, and receive the data sent by the second network device.
  • the processing unit 702 may be 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.
  • the network device 800 can be applied to the network architecture shown in FIG. 3.
  • the network device 800 may be the network device 1 (TX) or the network device 2 (RX) described in this application, and is used to execute the method of the embodiment corresponding to any one of the drawings in FIG. 6 to FIG. 13 by Operation performed by network device 1 or network device 2.
  • the network device 800 may also be the first network device or the second network device described in this application, and executes 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 connected 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.
  • the communication interface 801 may be used to send the first flexible Ethernet FlexE overhead frame to the second network device, and receive the data sent by the second network device.
  • the processor 802 may be 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.
  • the network device 900 can be applied to the network architecture shown in FIG. 3.
  • the network device 900 may be the network device 1 (TX) or the network device 2 (RX) described in this application, and is used to execute the method of the embodiment corresponding to any one of the drawings in FIG. 6 to FIG. 13 by Operation performed by network device 1 or network device 2.
  • the network device 900 may also be the first network device or the second network device described in this application, and executes the operations performed by the first network device or the second network device in the method corresponding to FIG. 14.
  • the network device 900 includes a memory 901 and a processor 902 connected to the memory.
  • Instructions are stored in the memory 901, and the processor 902 reads the instructions so that the network device 900 executes the method executed by the TX or RX in the embodiment corresponding to any of the drawings in FIGS. 6-13, and the latter executes the method corresponding to FIG. 14 The method executed by the first network device or the second network device in the embodiment.
  • the network device 1000 can be applied to the network architecture shown in FIG. 3.
  • the network device 1000 may be the network device 1 (TX) or the network device 2 (RX) described in this application, and is used to execute the method of the embodiment corresponding to any one of the drawings in FIG. 6 to FIG. Operation performed by network device 1 or network device 2.
  • the network device 1000 may also be the first network device or the second network device described in this application, and executes the operations performed by the first network device or the second network device in the method corresponding to FIG. 14.
  • the network device 1000 includes a processor 1010, a memory 1020 coupled to the processor, and a communication interface 1030.
  • computer readable instructions are stored in the memory 1020, and the computer readable instructions include multiple software modules, such as a sending module 1021, a processing module 1022, and a receiving module 1023.
  • the processor 1010 executes each software module, it can perform corresponding operations according to the instructions of each software module.
  • an operation performed by a software module actually refers to an operation performed by the processor 1010 according to an instruction of the software module.
  • the sending module 1021 is configured to send the first FlexE overhead frame and the third FlexE overhead frame to the second network device
  • the receiving module 1023 is configured to receive the first FlexE overhead frame and the third FlexE overhead frame. 2.
  • the second FlexE overhead frame sent by the network device is configured to determine, according to the indication information in the second FlexE overhead frame, that the second FlexE overhead frame is not for the first request information carried in the first FlexE overhead frame the response to.
  • the processor 1010 executes the computer-readable instructions in the memory 1020, it can perform all operations that can be performed by the network device 1, the network device 2, the first network device, or the second network device according to the instructions of the computer readable instructions.
  • the network device 1000 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 FIGS. 6 to 13 can be performed respectively; when the network device 1000 is used as the first network In the case of a device or a second network device, all operations performed by the first network device or the second network device in the embodiment corresponding to FIG. 14 can be performed respectively.
  • the processor mentioned in this application may be a central processing unit (English: central processing unit, abbreviation: CPU), a network processor (English: network processor, abbreviation: NP), or a combination of CPU and NP.
  • the processor may also be an application-specific integrated circuit (English: application-specific integrated circuit, abbreviation: ASIC), a programmable logic device (English: programmable logic device, abbreviation: PLD) or a combination thereof.
  • the above-mentioned PLD can be a complex programmable logic device (English: complex programmable logic device, abbreviation: CPLD), field programmable logic gate array (English: field-programmable gate array, abbreviation: FPGA), general array logic (English: generic array) logic, abbreviation: GAL) or any combination thereof.
  • the processor 1010 may refer to one processor, or may include multiple processors.
  • the memory mentioned in this application may include volatile memory (English: volatile memory), such as random access memory (English: random-access memory, abbreviation: RAM); the memory may also include non-volatile memory (English: volatile memory).
  • Non-volatile memory such as read-only memory (English: read-only memory, abbreviation: ROM), flash memory (English: flash memory), hard disk (English: hard disk drive, abbreviation: HDD) or solid state drive ( English: solid-state drive, abbreviation: SSD); the storage may also include a combination of the above-mentioned types of storage.
  • the memory may refer to one memory, or may include multiple memories.
  • An embodiment of the present application also 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, Use the method in any one of the embodiments corresponding to the pair of FIGS. 6 to 14.
  • This application also provides a computer program product, including a computer program, which when running on a computer, enables the computer to execute any one of the embodiments corresponding to FIGS. 6 to 13 by the network device 1 and/or the network device 2 The method performed.
  • This application also provides a computer program product, including a computer program, which when running on a computer, enables the computer to execute the execution of the first network device and/or the second network device in the embodiment corresponding to FIG. 14 method.
  • the present application provides a computer-readable storage medium, including computer instructions, which when running on a computer, enable the computer to execute any one of the embodiments corresponding to FIGS. 6 to 13 by the network device 1 and/or the network device 2 The method performed.
  • This application provides a computer-readable storage medium, including computer instructions, which, when run on a computer, enable the computer to execute what is executed by the first network device and/or the second network device in the embodiment corresponding to FIG. 14 method.
  • the computer program product includes one or more computer instructions.
  • the computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices.
  • the computer instructions may be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions may be transmitted from a website, computer, server, or data center.
  • the computer-readable storage medium may be any available medium that can be accessed by a computer or a data storage device such as a server or a data center integrated with one or more available media.
  • the usable medium may be a magnetic medium (for example, a floppy disk, a hard disk, and a magnetic tape), an optical medium (for example, a DVD), or a semiconductor medium (for example, a solid state disk (SSD)).

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Small-Scale Networks (AREA)
  • Communication Control (AREA)

Abstract

本申请涉及一种时隙协商方法及设备。该方法包括：发送端网络设备TX向接收端网络设备RX发送第一灵活以太FlexE开销帧，用于请求时隙分配表的主备切换；RX处于重启状态时，对于接收到的第一FlexE开销帧未做响应。并且，RX会向TX发送例行刷新的第二FlexE开销帧，TX根据第二FlexE开销帧携带的指示信息，确定第二FlexE开销帧不是对第一FlexE开销帧的响应。TX发送第三FlexE开销帧，再次请求时隙分配表的主备切换。通过本申请的方法，TX能够确定接收到的FlexE开销帧是否是RX对其发出的时隙协商请求的响应。因此，能够避免由于RX误响应而导致TX侧时隙分配表误切换的操作，有效减少了现有时隙协商机制所可能带来的业务中断。

Description

一种时隙协商的方法和设备
本申请要求于2019年09月12日提交中国专利局、申请号为CN201910867102.6、申请名称为“一种时隙协商的方法和设备”的中国专利申请，以及于2019年10月22日提交中国专利局，申请号为CN201911008430.7，申请名称为“一种时隙协商的方法和设备”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请涉及通信领域，尤其涉及一种时隙协商的方法、设备、***及存储介质。
背景技术
灵活以太网(英文：Flex Ethernet，FlexE)技术是承载网实现业务隔离承载和网络分片的一种接口技术，近两年发展迅速，被各大标准组织广泛接纳。FlexE标准最早起源于光互联网论坛(英文：Optical Internet Forum,OIF)接口物理层标准，具有带宽灵活可调、数据隔离、完美契合5G业务等特点。FlexE技术通过在IEEE802.3基础上引入灵活以太网协议层(英文也可以称之为FlexE Shim层)，实现媒体访问控制(英文：Medium Access Control，MAC)层与物理链路接口层(英文也可以称之为PHY)的解耦，从而实现灵活的速率匹配。Flex Shim基于时分复用(英文：Time Division Multiplexing，TDM)分发机制，将多个FlexE客户(英文：client)的数据按照时隙方式调度并分发至多个不同的子通道，实现传输管道带宽的硬隔离，一个业务数据流可以分配到一个或多个时隙中，实现了对各种速率业务的匹配。
按照当前OIF标准定义，FlexE Shim层通过定义开销帧(英文：Overhead Frame,OH Frame)和开销复帧(英文：OH MultiFrame)的方式体现FlexE client和FlexE Group中的时隙映射关系以及calendar的工作机制。在当前的FlexE开销帧时隙协商机制中，发送端向接收端发送时隙表分配表切换请求(也可以称之为时隙协商请求)时，接收端由于某些原因(例如设备掉电，相关业务单播故障，故障恢复出发的单板硬复位等)重启，此时，存在接收端误响应，从而导致发送端至接收端业务中断的情况。因此，如何能够有效避免上述情况对FlexE业务的影响，称为目前亟待解决的问题。
发明内容
本申请提供一种时隙协商的方法，网络设备，通信***，存储介质以及计算机程序产品，解决当前FlexE开销帧时隙协商机制中由于接收端误应答所导致的流量中断的问题。采用本申请的技术方案，能够有效提高网络设备之间进行时隙协商的准确性，有效防止业务中断。
第一方面，本申请提供了一种时隙协商方法，该方法由第一网络设备执行，所述方法包括：向第二网络设备发送第一灵活以太FlexE开销帧，所述第一FlexE开销帧包括第一请求信息，所述第一请求信息用于请求所述第二网络设备将备用时隙分配表切换为主用时隙分配表；接收所述第二网络设备发送的第二FlexE开销帧；根据所述第二FlexE开销帧中的第一指示信息，确定所述第二FlexE开销帧不是对所述第一请求信息的响应；向 所述第二网络设备发送第三FLexE开销帧，所述第三FLexE开销帧包括第二请求信息，所述第二请求信息用于请求所述第二网络设备将所述备用时隙分配表切换为所述主用时隙分配表。
在上述方法中，第一网络设备向第二网络设备发出用于时隙协商请求的第一FlexE开销帧后，根据接收到的第二FlexE开销帧中携带的第一指示信息，能够确定该第二FlexE开销帧不是对其发出的时隙协商请求的响应。因此，第一网络设备不会执行时隙分配表的主备切换。第一网络设备会向第二网络设备再次发送用于时隙协商请求的第三FLexE开销帧，其中通过第三FLexE开销帧中携带的第二请求信息，来请求第二网络设备进行时隙分配表的主备切换。由此，第一网络设备能够避免将第二FLexE开销帧错误的认定为是第二网络设备对其作出的时隙协商请求的响应，避免时隙分配表误切换。上述方法有效防止了由于当前时隙协商机制而导致误操作所带来的业务中断。
一种可选地设计中，所述方法还可以包括：接收所述第二网络设备发送的第四FlexE开销帧；
根据所述第四FlexE开销帧中携带的第二指示信息，确定所述第四FlexE开销帧是对所述第二请求信息的响应。
一种可选的设计中，所述方法还包括：响应于确定所述第四FlexE开销帧是对所述第二请求信息的响应，所述第一网络设备将所述备用时隙分配表切换为所述主用时隙分配表。
一种可选的设计中，所述方法还包括：所述第一网络设备向第二网络设备发送第五FlexE开销帧，指示第二网络设备将所述备用时隙分配表切换为所述主用时隙分配表。
第二方面，本申请提供了一种时隙协商方法，所述方法由第二网络设备执行，该方法包括：接收第一网络设备发送的第一FlexE开销帧，所述第一FlexE开销帧包括第一请求信息，所述第一请求信息用于请求所述第二网络设备将备用时隙分配表切换为主用时隙分配表；
向所述第一网络设备发送第二FlexE开销帧，所述第二FlexE开销帧包括第一指示信息，用于指示所述第二FlexE开销帧不是对所述第一请求信息的响应；
接收所述第一网络设备发送的第三FlexE开销帧，所述第三FlexE开销帧包括第二请求信息，所述第二请求信息用于请求所述第二网络设备将所述备用时隙分配表切换为所述主用时隙分配表。
在上述方法中，第二网络设备向第一网络设备例行发送的灵活以太FlexE开销帧中，包括指示信息，用于指示该灵活以太FlexE开销帧不是对第一网络设备发送的灵活以太FlexE开销帧的响应。因此，第一网络设备能够根据接收到的第二FlexE开销帧中携带的指示信息，确定该第二FlexE开销帧不是对其发出的时隙协商请求的响应。因而，第一网络设备不会执行时隙分配表的主备切换。第二网络设备会接收到第一网络设备再次发送的用于时隙协商请求的第三FLexE开销帧，此时，如果第二网络设备做好了时隙分配表主备切换的准备，则可以根据第三FLexE开销帧中携带的第二请求信息的指示，来执行用于时隙分配表主备切换的相关操作。由此，第二网络设备可以和第一网络设备执行正确的时隙协商。上述方法有效保证了时隙协商，防止当前时隙协商机制而导致的业务中断。
一种可选地设计中，所述方法还可以包括：所述第二网络设备向所述第一网络设备发送第四FlexE开销帧；
其中，所述第四FlexE开销帧中携带第二指示信息，所述第二指示信息用于指示所述第四FlexE开销帧是对所述第二请求信息的响应。
一种可选的设计中，所述方法还包括：所述第二网络设备接收所述第一网络设备发送的第五FlexE开销帧，并根据所述第五FlexE开销帧的指示，将所述备用时隙分配表切换为所述主用时隙分配表。
一种可选地设计中，所述第一请求信息为所述第一FlexE开销帧的管理通道中携带的第一请求报文。
一种可选地设计中，所述第一请求信息为所述第一FlexE开销帧中携带的CR字段和CCC字段所指示的信息。其中，CR字段和CCC字段的值不同。
一种可选地设计中，所述第一指示信息为为所述第二FlexE开销帧的管理通道所指示的信息，所述第二FlexE开销帧的管理通道未携带第一响应报文，所述第一响应报文用于指示所述第二FlexE开销帧是对所述第一请求信息的响应。
一种可选地设计中，所述第一指示信息为所述第二FlexE开销帧中第一字段所指示的信息，所述第一字段与所述第二FlexE开销帧的时隙分配表切换确认CA字段不同。
一种可选地设计中，所述第一指示信息为所述第二FlexE开销帧的时隙分配表切换确认CA字段所指示的信息，所述第一指示信息用于指示所述第二FlexE开销帧不是对所述第一请求信息的响应，所述第一指示信息不用于指示时隙分配表。
一种可选地设计中，所述第二指示信息为所述第四FlexE开销帧的管理通道所指示的信息，所述第四FlexE开销帧的管理通道携带第二响应报文，所述第二响应报文用于指示所述第四FlexE开销帧是对所述第二请求信息的响应。
一种可选地设计中，所述第二指示信息为所述第四FlexE开销帧的时隙分配表切换确认CA字段所指示的信息，所述第二指示信息用于指示所述第四FlexE开销帧是对所述第二请求信息的响应，所述第二指示信息不用于指示时隙分配表。
一种可选地设计中，所述第二指示信息为所述第四FlexE开销帧中第二字段所指示的信息，所述第二字段与所述第四FlexE开销帧的时隙分配表切换确认CA字段不同。
第三方面，本申请提供了一种第一网络设备，包括收发单元和处理单元，当所述第一网络设备执行上述第一方面以及第一方面任意一种可选地设计中所述的方法时，所述收发单元用于执行收发操作，所述处理单元用于执行收发以外的操作。例如，当所述第一网络设备执行所述第一方面所述的方法时，所述收发单元用于向第二网络设备发送第一灵活以太FlexE开销帧，接收所述第二网络设备发送的第二FlexE开销帧，以及向所述第二网络设备发送第三FLexE开销帧。所述处理单元用于根据所述第二FlexE开销帧中的第一指示信息，确定所述第二FlexE开销帧不是对所述第一请求信息的响应。
第四方面，本申请提供了一种第二网络设备，包括收发单元和处理单元，当所述第二网络设备执行执行上述第二方面以及第二方面任意一种可选地设计中所述的方法时，所述收发单元用于执行收发操作，所述处理单元用于执行收发以外的操作。例如，当所述第二网络设备执行所述第二方面所述的方法时，所述收发单元用于接收第一网络设备发送的第一灵活以太FlexE开销帧，向所述第一网络设备发送第二FlexE开销帧以及接收所述第一网络设备发送的第三FlexE开销帧。所述处理单元，用于生成所述第二FlexE开销帧。
第五方面，本申请提供了一种第一网络设备，包括存储器以及与所述存储器相连的处 理器。所述存储器中存储有指令，所述处理器读取所述指令，使得所述第一网络设备执行上述第一方面以及第一方面任意一种可选地设计中所述的方法。
第六方面，本申请提供了一种第二网络设备，包括存储器以及与所述存储器相连的处理器。所述存储器中存储有指令，所述处理器读取所述指令，使得所述第二网络设备执行上述第二方面以及第二方面任意一种可选地设计中所述的方法。
第七方面，本申请提供了一种第一网络设备，包括通信接口以及与所述通信接口相连的处理器，通过所述通信接口和所述处理器，所述第一网络设备用于执行上述第一方面以及第一方面任意一种可选地设计中所述的方法。其中，所述通信接口用于执行收发的操作，所述处理器用于执行收发以外的操作。例如，例如，当所述第一网络设备执行所述第一方面所述的方法时，所述通信接口用于向第二网络设备发送第一灵活以太FlexE开销帧，接收所述第二网络设备发送的第二FlexE开销帧，以及向所述第二网络设备发送第三FLexE开销帧。所述处理器用于根据所述第二FlexE开销帧中的第一指示信息，确定所述第二FlexE开销帧不是对所述第一请求信息的响应。
第八方面，本申请提供了一种第二网络设备，包括通信接口以及与所述通信接口相连的处理器，通过所述通信接口和所述处理器，所述第二网络设备用于执行上述二方面以及第二方面任意一种可选地设计中所述的方法。其中，所述通信接口用于执行收发的操作，所述处理器用于执行收发以外的操作。例如，例如，当所述第网络设备执行所述第二方面所述的方法时，所述通信接口用于接收第一网络设备发送的第一灵活以太FlexE开销帧，向所述第一网络设备发送第二FlexE开销帧以及接收所述第一网络设备发送的第三FlexE开销帧。所述处理器，用于生成所述第二FlexE开销帧。
第九方面，本申请提供了一种通信***，包括上述第三方面，第五方面或者第七方面任一方面所述的第一网络设备，以及上述第四方面，第六方面或者第八方面任一方面所述的第二网络设备。
第十方面，本申请提供了一种计算机可读存储介质，包括计算机可读指令，当所述指令在计算机上运行时，使得所述计算机执行上述第一方面，第二方面，第一方面任一种可能的设计或者第二方面任一种可能的设计中的方法。
第十一方面，本申请提供了一种计算机程序产品，包括计算机程序，当所述程序在计算机上运行时，使得计算机执行上述第一方面，第二方面，第一方面任一种可能的设计或者第二方面任一种可能的设计中的方法。
附图说明
图1为基于灵活以太网协议的FlexE通用架构示意图；
图2为跨4个物理链路接口(聚合4个PHY)的FlexE Group的时隙分配情况的示意图；
图3为本申请涉及的FlexE通信***的应用场景示意图；
图4为本申请所涉及的采用FlexE技术传输数据的过程的示意图；
图5为OIF IA-FLEXE-02.1标准中给出的100GE接口的开销帧和开销复帧的结构示意图；
图6为一种时隙协商方法的流程示意图；
图7为用于说明引发RX误应答问题的场景说明示意图；
图8为本申请所提供的一种时隙协商方法的示意图；
图9为本申请所提供的一种对开销帧进行扩展的报文格式示意图；
图10为本申请提供的一种时隙协商处理方法的流程示意图；
图11为本申请提供的一种时隙协商处理方法的流程示意图；
图12a为本申请提供的一种CR Request报文格式示意图；
图12b为本申请提供的一种CR Ack报文格式示意图；
图12c为本申请提供的一种LLDP报文格式示意图；
图12d为本申请提供的一种CR Request报文格式示意图；
图12e为本申请提供的一种CR Request报文格式示意图；
图13为本申请提供的一种时隙协商处理方法的流程示意图；
图14为本申请提供的一种时隙协商方法的流程示意图；
图15为本申请实施例提供的一种网络设备的结构示意图；
图16为本申请实施例提供的一种网络设备的结构示意图；
图17为本申请实施例提供的一种网络设备的结构示意图；
图18为本申请实施例提供的一种网络设备的结构示意图。
具体实施方式
本申请中的“1”、“2”、“3”、“4”、“第一”、“第二”、“第三”和“第四”等序数词是用于对不同对象进行区分，不用于限定多个对象的顺序。此外，术语“包括”和“具有”不是排他的。例如，包括了一系列步骤或单元的过程、方法、***、产品或设备没有限定于已列出的步骤或单元，还可以包括没有列出的步骤或单元。
本申请所涉及的相关FlexE的现有技术可以参见OIF所制定的FlexE标准IA OIF-FLEXE-01.0，IA OIF-FLEXE-02.0或者IA OIF-FLEXE02.1的相关说明，上述标准以全文引用的方式并入本申请中。
图1示例性示出了基于灵活以太网协议的FlexE通用架构示意图。如图1所示，FlexE Group包括4个PHY。FlexE Client代表在FlexE Group上指定时隙(一个时隙或多个时隙)传输的客户数据流，一个FlexE Group上可承载多个FlexE Client，一个FlexE Client可对应一个到多个用户业务数据流(也可以称为MAC Client)，FlexE Shim层提供FlexE Client到MAC Client的数据适配和转换。FlexE可以支持任意多个不同FlexE Client在任意一组PHY上的映射和传输，从而实现PHY捆绑、通道化及子速率等功能。多路PHY组合在一起成为一个FlexE组(英文也可以称为FlexE Group)，用于承载通过FlexE Shim层分发、映射来的一路或者多路FlexE client数据流。以100GE PHY为例，FlexE Shim层可以把FlexE Group中的每个100GE PHY划分为20个时隙(slot)的数据承载通道，每个slot对应的带宽为5Gbps。
图2示意性示出了跨4个物理链路接口(聚合4个PHY)的FlexE Group的时隙分配情况的示意图。如图2所示，每个PHY均拥有20个时隙，因此该FlexE Group拥有20*4个时隙。如图2所示，以图1中的FlexE Group包括4个PHY为例介绍，4个PHY分别为PHY A 1201、PHY B 1202、PHY C 1203和PHY D 1204。FlexE Group对应时隙分配表(英 文也可以称为calendar)；一个FlexE Group中包括的单个物理链路对应的时隙映射表可以称为子时隙分配表(英文可以称为sub-calendar)。FlexE calendar可以由一个或多个sub-calendar组成。每个sub-calendar可以指示该单个物理链路上20个时隙(slot)如何分配给相应的FlexEclient。也就是说，每个sub-calendar可以指示该单个物理链路上时隙与FlexE client的对应关系。如图2所示，每个PHY可以对应20个时隙，图中分别用slot 0至slot 19来表示。图2分别示出了PHY A 1201、PHY B 1202、PHY C 1203和PHY D 1204中每个PHY对应的20个时隙的示意图。
图3示出了本申请涉及的FlexE通信***的应用场景示意图。如图3所示，FlexE通信***100包括网络设备1、网络设备2、用户设备1和用户设备2。网络设备1可以是中间节点，此时网络设备1通过其他网络设备与用户设备1连接。网络设备1可以是边缘节点，此时网络设备1直接与用户设备1连接。网络设备1可以是中间节点，此时网络设备1通过其他网络设备与用户设备1连接。网络设备1也可以是边缘节点，此时网络设备1直接与用户设备1连接。网络设备2可以是中间节点，此时网络设备2通过其他网络设备与用户设备2连接。网络设备2也可以是边缘节点，此时网络设备2直接与用户设备2连接。网络设备1包括FlexE接口1，网络设备2包括FlexE接口2。FlexE接口1与FlexE接口2相邻。每个FlexE接口均包括发送端口和接收端口，与传统以太网接口的区别在于一个FlexE接口可以承载多个Client，且作为逻辑接口的FlexE接口可以由多个物理接口组合而成。图3中所示的正向通道中业务数据的流向如图3中实线箭头所示，反向通道中业务数据的流向如图3中虚线箭头所示。本发明实施例的传输通道以正向通道为例，传输通道中业务数据的流向为用户设备1网络设备1网络设备2用户设备2
应理解，图3中仅示例性的示出了2个网络设备和2个用户设备，该网络可以包括任意其它数量的网络设备和用户设备，本申请实施例对此不做限定。图3中所示的FlexE通信***仅是举例说明，本申请提供的FlexE通信***的应用场景不限于图3所示的场景。本申请提供的技术方案适用于所有应用FlexE技术进行数据传输的网络场景。
下面结合图4进一步描述图3中所示网络设备1和网络设备2采用FlexE技术传输数据的过程。
如图4所示，PHY1、PHY2、PHY3和PHY4绑定成为一个FlexE group。网络设备1和网络设备2之间通过FlexE group接口连接，即通过FlexE接口1与FlexE接口2连接。上述FlexE group接口也可以被称之为FlexE接口。FlexE group接口是由一组物理接口绑定而成的逻辑接口。该FlexE group接口共承载有6个client，分别为client1至client6。其中，client1和client2的数据映射在PHY1上传输；client3的数据映射在PHY2和PHY3上传输；client4的数据映射在PHY3上传输；client5和client6的数据映射在PHY4上传输。不同FlexE client在FlexE group上进行映射和传输，实现捆绑功能。其中：
FlexE group：也可称之为捆绑组。每个FlexE group包括的多个PHY具有逻辑上的捆绑关系。所谓的逻辑上捆绑关系，指的是不同的PHY之间可以不存在物理连接关系，因此，FlexE group中的多个PHY在物理上可以是独立的。FlexE中的网络设备可以通过PHY的编号来标识一个FlexE group中包含哪些PHY，来实现多个PHY的逻辑捆绑。例如，每个PHY的编号可用1-254之间的一个数字来标识，0和255为保留数字。一个PHY的编号可对应网络设备上的一个接口。相邻的两个网络设备之间需采用相同的编号来标识同一个 PHY。一个FlexE group中包括的各个PHY的编号不必是连续的。通常情况下，两个网络设备之间具有一个FlexE group，但本申请并不限定两个网络设备之间仅存在一个FlexE group，即两个网络设备之间也可以具有多个FlexE group。一个PHY可用于承载至少一个client，一个client可在至少一个PHY上传输。
FlexE client:对应于网络的各种用户接口，与现有的IP/Ethernet网络中的传统业务接口一致。FlexE client可根据带宽需求灵活配置，支持各种速率的以太网MAC数据流(如10G、40G、n*25G数据流，甚至非标准速率数据流)，例如可以通过64B/66B的编码的方式将数据流传递至FlexE shim层。FlexE client可以被解释为基于一个物理地址的以太网流。通过同一FlexE group发送的客户需要共用同一时钟，且这些客户需要按照分配的时隙速率进行适配。
FlexE shim:作为***传统以太架构的MAC与PHY(PCS子层)中间的一个额外逻辑层，是基于calendar的时隙分发机制实现FlexE技术的核心架构。FlexE shim的主要作用是根据相同的时钟对数据进行切片，并将切片后的数据封装至预先划分的时隙(slot)中。然后，根据预先配置的时隙分配表，将划分好的各时隙映射至FlexE group中的PHY上进行传输。其中，每个时隙映射于FlexE group中的一个PHY。
Calender：时隙分配表，也可以称之为时隙表。FlexE Group对应calendar，一个FlexE Group中包括的单个物理链路(PHY)对应的时隙映射表可以称为子时隙分配表(英文：sub-calendar)。FlexE calendar可以由一个或多个sub-calendar组成。每个sub-calendar可以指示该单个物理链路上20个时隙(英文可以写为slot)如何分配给相应的FlexEclient。也就是说，每个sub-calendar可以指示该单个物理链路上时隙与FlexE client的对应关系。当前标准中定义，每个FlexE开销帧中指定两个Calender，分别是当前的主用时隙表(Calender A)和备用时隙表(Calender B)。
FlexE对物理接口传输构建固定帧格式，并进行TDM的时隙划分。下面，以现有的FlexE帧格式举例说明。FlexE的时隙划分粒度可以为66B，对应承载一个64B/66B编码块，每个64/66B编码块承载在一个slot中。一个FlexE帧包含8行，每行第一个64B/66B比特块位置为FlexE开销块，开销块后为进行时隙划分的净荷区域，以66比特为粒度，对应20x1023个66比特承载空间。以100GE接口为例，100GE接口的带宽划分为20个时隙，每个时隙带宽约为5Gbps，称为一个slot。64B/66B可以理解为64比特的比特块以及由它编码得到的66比特的编码块。FlexE通过交织复用的方式在单个物理接口上实现了多个传输通道，即实现了多个时隙。FlexE只是一种接口技术，相关的交换技术可以基于现有的以太网包进行，也可以基于FlexE交叉进行，此处不再赘述。
如前所述，FlexE shim层通过定义开销帧和开销复帧的方式体现client与FlexE group中的时隙映射关系以及calendar工作机制。需要说明的是，上述的开销帧，也可以称之为灵活以太开销帧(英文：FlexE overhead frame)，上述的开销复帧也可以称之为灵活以太开销复帧(英文：FlexE overhead Multiframe)。FlexE shim层通过开销提供带内管理通道，支持在对接的两个FlexE接口之间传递配置、管理信息，实现链路的自动协商建立。
FlexE的每个PHY上的数据通过周期性***FlexE开销(overhead frame，OH)帧的码块来实现对齐，比如可以是每隔1023x 20个66B的净荷数据码块***1个66B的开销 码块FlexE OH。根据FlexE Implementation Agreement协议，一个FlexE Group在每个PHY上每隔预定时间间隔上就会发出一个FlexE开销帧的64B/66B码块至远端的PHY，8个依次发送的FlexE开销帧的64B/66B码块构成了一个FlexE开销帧。FlexE定义开销帧上的一些字段承载时隙分配表，并通过FlexE开销帧把时隙分配表同步至远端的通信设备上的PHY，以保证双端的通信设备使用相同的时隙分配表接收和发送FlexE客户对应的数据流。具体而言，一个开销帧则有8个开销块(英文：overhead block)，上述开销块也可以称之为开销时隙(英文：overhead slot)。开销块例如可以是一个64B/66B编码的码块，每间隔1023*20blokcs出现一次，但每个开销块所包含的字段是不同的。
图5中示出了OIF IA-FLEXE-02.1标准中给出的100GE接口的开销帧和开销复帧的结构示意图。下面结合图5对FlexE开销帧(下面简称为开销帧)的结构进行简单介绍。如图5所示，一个开销帧包括8个开销块。开销帧在开销块1(block1)至开销块3(block 3)中，指定了如下位域(或者也可以称之为字段)，用于指导通信设备之间的时隙协商。开销帧的开销块4(block4)至开销块8(block8)是管理通道(英文：Management Channel)，管理通道中可以用于承载1588报文，同步以太报文，DCN报文以及链路搜索报文等。管理通道对于其能够承载的报文类型没有限制，仅需要保证报文的编码格式能够被通信设备正常解码即可。
下面对图5所示出的开销帧中涉及时隙协商的一些位域进行介绍。
C：1bit，用于指示当前使用的时隙分配表配置(Calendar configuration in use)。C比特在开销中定义有3个位置，意义相同，主要是为了保证可靠性，此位域在后续描述中采用CCC字段表示。举例来说，如果CCC的值为0，则表示当前主用时隙分配表为Calendar A；如果CCC的值为1，则表示当前工作的时隙分配表为Calendar B。需要注意的是，在本申请中，开销帧中，3个C bit的取值总是相同，即均为0或者均为1。CCC的值为1表示3个C比特均取值为1；CCC的值为0，表示3个C比特的取值均为0。
CR：1bit，用于指示时隙协商请求，时隙协商请求也可以称之为时隙分配表切换请求(Calendar Switch Request)。在发送端设备和接收端设备之间例行的开销帧刷新过程中，CR字段的值与CCC字段的值保持一致，指示当前的主用时隙分配表。在发送端发起时隙协商请求后，CR字段的值将与CCC字段的值不同，此时，CR字段的值指向备用时隙分配表，而CCC字段的值指向当前的主用时隙分配表。本领域技术人员可以理解的是，“时隙协商请求”和“时隙分配表切换请求”可以表达相同的含义，在本申请中，两者经常交替使用。
CA：1bit，用于指示时隙分配表切换确认(Calendar Switch Acknowledge)。在当前标准中，CA字段语义具有二义性，用于指示接收端设备(以下简称RX)对发送端设备(以下简称TX)发送的时隙协商请求的响应，并且用于指示时隙分配表。如果RX回应的开销帧中携带的CA字段的值与接收到的TX发送的开销帧中携带的CR字段的值一致，则TX认为这是RX对其发出的时隙协商请求的响应，并且RX做好了切换到CA字段所指示的时隙分配表的准备。TX从主用时隙分配表切换到备用时隙分配表上，并将CCC字段的值修改为发送时隙协商请求时CR字段相同的值，随开销帧发送给RX。RX收到CR＝CCC的开销帧后，也从主用时隙分配表切换到备用时隙分配表上。
下面结合图6，以图3所示场景为例，对网络设备之间进行时隙协商的方法100进行简单介绍。为描述简便，在图6中，网络设备1标识为TX，网络设备2标识为RX。基于 某些原因，TX方向发起主用时隙表Calendar A向备用Calendar B的切换，触发时隙表切换的原因例如可以是：
a)TX方向修改FlexE Client的时隙带宽；
b)TX和/或RX方向FlexE Group在增删PHY，或PHY的状态发生变化；
c)TX和/或RX方向的设备在重启初始化。
为了完成时隙表切换，TX和RX之间执行时隙协商方法100，包括：
S101、TX方向发起时隙协商请求，请求RX将备用时隙分配表切换为主用时隙分配表。具体来说，将CR置为Calendar B(CR＝1)，而CCC此时为Calendar A(CCC＝0)，通过FlexE开销发送给RX。然后等待RX方向回应CA信息。
S102、RX方向收到TX的时隙协商请求(CR＝1/CCC＝0)，如果RX方向准备就绪，且收到的Calendar B配置信息合法，则设置CA为Calendar B(CA＝1)，通过FlexE开销发送给TX。
S103、TX方向收到RX方向的时隙协商回应后(CA＝1)，切换本地主用时隙表为Calendar B，并修改CCC为Calendar B(CCC＝1)，通过FlexE开销发送给RX。RX收到此FlexE开销(CR＝1/CCC＝1)后，也将本地主用时隙表切换为Calendar B。
S101-S103描述了正常情况下完整的时隙协商流程。后续TX方向发起时隙表Calendar B向Calendar A的切换过程也是类似流程。本领域技术人员可以理解的是，在S101之后，若TX方向长时间没有收到RX的时隙协商回应，将会定时再次发送时隙协商请求。后续的步骤与S102和S103相同，不再赘述。
上述方法100所描述的FlexE开销时隙协商机制存在RX误应答的问题。下面结合附图7，对引发上述问题的场景进行具体描述。
如图7所示，FlexE Group两端的TX和RX建立通信连接，RX由于某些原因(例如：设备掉电、相关业务单板插拔或者故障自愈触发的单板硬复位等)，进行设备重启。RX侧，关于FlexE Group的协商数据全部清零，RX的主用时隙表默认为Calendar A，此时，由RX发出的例行刷新的开销帧中CA，CR以及CCC字段的值均为0。而在TX侧，TX的当前主用时隙分配表为Calendar B。当RX方向在重启过程中恢复FlexE GROUP PHY的PCS层UP后，且TX方向的准备工作就绪后，将会触发时隙协商请求，和RX进行时隙协商。其中，TX方向的准备工作包括：
PHY加组：根据PHY的FlexE Group number配置加入对应的FlexE group的管理中。
TX时隙刷新：TX方向下发时隙配置。
具体的时隙协商方法200包括：
S201、TX方向发起时隙协商请求，请求切换时隙分配表。TX将CR置为Calendar A(CR＝0)，而CCC此时为Calendar B(CCC＝1)，通过FlexE开销帧发送给RX。等待RX方向回应CA信息。
由于RX方向收到时隙协商请求时，重启恢复过程还在进行中，并没有准备好相关处理数据，RX方向的准备工作并没有就绪，故对本次时隙协商请求并没有响应。RX方向的准备工作包括：
PHY加组：根据PHY的FlexE group number配置加入对应的FlexE group的管理中。
FlexE group建立：RX收到TX对端的FlexE开销帧，并解析出内部的Group number 和PHY number，并校验与本地配置一致，才认为FlexE group建立操作成功。
CR中断开启：当FlexE group和PHY的数据准备就绪后，便开启CR中断，用以接受TX方向的时隙协商请求。
RX方向依赖CR中断做如下事情：
a)RX方向收到FlexE开销中发现CR与CCC不一致，便认为是新的时隙协商请求。
b)RX从此FlexE开销中提取CR指定的时隙分配表信息，并根据时隙分配表中的FlexE Client ID配置对应物理Mac的备用时隙分配表信息。(由于RX侧设备重启，RX侧物理Mac的主用时隙分配表为空且无效)
c)根据收到的FlexE开销中的CR值，通过FlexE开销回应TX方向对应的CA。然后等待TX方向回应CR＝CCC。
d)收到TX方向回应CR＝CCC的FlexE开销帧，RX侧将物理Mac的备用时隙分配表切换为主用时隙分配表。
如果RX没有完成步骤a)-d)的操作，将会导致RX侧物理MAC的时隙信息为空或与TX侧时隙配置不一致，从而出现断流。
S202、RX按照固定的周期间隔向TX例行发送刷新的FlexE开销帧。
虽然如上文中描述，RX方向在接收到TX发送的时隙协商请求后，准备工作并未就绪，因此，不会对所述时隙协商请求作出实际有效的响应。但是，RX会按照固有周期向TX例行发送FlexE开销帧。在RX向TX例行发送的FlexE开销帧中，CA取值缺省设置为0。此时，由于TX正在等待RX回应的CA也是0，因此导致TX误以为RX例行发送的FlexE开销帧是对S201中发送的时隙协商请求做出的响应，因此，会继续执行下面所述的S203。后续当TX没有重新协商时隙需求的情况下，TX也不会再重新发起时隙协商请求。由此可见，RX例行发送的FlexE开销误应答了TX发送的时隙协商请求。
S203、TX方向收到RX方向发送的FlexE开销帧后，由于FlexE开销帧中携带的CA＝0，因此，切换本地主用时隙表为Calendar A，并修改CCC为Calendar A(CCC＝0)，通过FlexE开销帧发送给RX。
RX在收到S203中TX发送的FlexE开销帧后，即便RX已经做好如上所述的准备工作，但是由于实际上没有正确处理S201中TX发送的时隙协商请求，因此RX无法获取正确的时隙信息，导致TX到RX的流量中断。
由此可见，当TX和RX进行时隙协商时，如果RX侧刚好由于某些原因处于设备重启状态，此时，RX例行发送的FlexE开销帧，可能错误的应答TX发送的时隙协商请求，从而使得TX误以为RX对时隙协商请求进行了有效的响应。但实际情况是，TX和RX并没有执行有效的时隙协商。如何有效避免上述情况，提高时隙协商的准确性，避免正常业务受到影响，成为需要解决的问题。为了解决上述问题，本申请提供了一种时隙协商方法300。
下面结合图8对本申请实施例提供的方法300进行详细说明。应用方法300的网络架构包括网络设备1和网络设备2。举例来说，网络设备1和网络设备2例如可以是图3所示的网络设备1和网络设备2。其中，网络设备1和网络设备2通过单个PHY连接，也可以通过FlexE group连接。该网络架构例如可以是图3所示的网络架构。下面结合图8，以图3所示的架构为例，对方法300进行介绍。方法300包括：
S301、网络设备1向网络设备2发送FlexE开销帧1。
具体来说，FlexE开销帧1包括请求信息1，所述请求信息1用于请求网络设备2执行时隙分配表的主备切换，即请求网络设备将备用时隙分配表切换为主用时隙分配表。
一个具体的实施方式中，上述请求信息1是FlexE开销帧1中CR字段以及CCC字段所指示的信息。举例来说，FlexE开销帧1中携带的CR字段的值为0，CCC字段的值为1。当CR字段和CCC字段的值不同时，FlexE开销帧1用于发出时隙协商请求1，也可以称之为时隙分配表切换请求1。其中，CCC字段的值为1时，表示当前的主用时隙分配表为时隙分配表1。CR字段的值为0时，表示请求将当前的主用时隙分配表切换为备用时隙分配表，即时隙分配表2。当CR字段为1时，而CCC字段为0时，则表示请求从时隙分配表2切换到时隙分配表1上。当CR字段为0，而CCC字段为1时，则表示请求从时隙分配表1切换到时隙分配表2上。一个具体的实施方式中，根据当前的OIF标准，时隙分配表1可以是标准中定义的Calendar B，时隙分配表2是标准中定义的Calendar A。
在一个具体的实施方式中，上述请求信息1可以是所述第一FlexE开销帧的管理通道中携带的请求报文1。该请求报文1也可以称之为时隙协商请求报文1。关于管理通道中携带的请求报文的具体格式可参见下文中结合图12a)，或图12c以及图12d所做的具体说明。本领域技术人员可以理解的是，在管理通道中携带的请求报文的格式不限于本申请所给出的示例，本申请对于管理通道中携带的请求报文的具体格式不做具体限定。
S302、网络设备2接收所述FlexE开销帧1。
当网络设备2处于设备重启状态时，可以对接收到的FlexE开销帧1执行丢弃操作，而不做实际的处理。
S303、网络设备2向网络设备1发送FlexE开销帧2。
该FlexE开销帧2是网络设备2向网络设备1按照固定时间周期例行发送的FlexE开销帧。FlexE开销帧2中的CA字段的取值与FlexE开销帧1中CR字段的取值相同。例如，FlexE开销帧1中携带的CR字段取值为0，FlexE开销帧2的CA字段值也为0。
S304、网络设备1接收网络设备2发送的FlexE开销帧2。
S305、网络设备1根据FlexE开销帧2中携带的指示信息1，确定该FlexE开销帧2不是对请求信息1的响应。FlexE开销帧2不是对请求信息1的响应，也意味FlexE开销帧2不是对时隙协商请求1的响应，不是对FlexE开销帧1的响应。
网络设备1确定FlexE开销帧2不是对所述请求信息1做出的响应，是指网络设备1能够正确识别接收到的FlexE开销帧不是网络设备2针对其发出的时隙协商请求1所作出的可信响应。关于S305的具体说明在下文中进行具体介绍，此处不再赘述。
S306、网络设备1向网络设备2发送FlexE开销帧3。
和S301类似，FlexE开销帧3中包括请求信息2，用于请求网络设备2执行时隙分配表的主备切换，即请求网络设备2将备用时隙分配表切换为主用时隙分配表。请求信息2和请求信息1的具体格式相同，区别在于携带在不同的FlexE开销帧中。因此，关于请求信息2的说明参见上文中对于请求信息1的说明，此处不再赘述。
FlexE开销帧3中携带的CR字段的值为0，CCC字段的值为1。网络设备1确定FlexE开销帧2不是对所述请求信息1做出的响应，则网络设备1再次向网络设备2发出时隙协商请求。FlexE开销帧3用于发出时隙协商请求2，也就是时隙分配表切换请求2。即网络设备1再次请求和网络设备2进行时隙协商，请求将备用时隙分配表切换为主用时隙分配 表。
S307、网络设备2接收所述FlexE开销帧3。
S308、网络设备2向网络设备1发送FlexE开销帧4，对接收到的请求信息2作出响应。
具体来说，网络设备2已经完成设备重启，并做好了相关的准备工作，则网络设备2开启CR中断，对所述网络设备1发出的时隙协商请求2作出响应。网络设备1和网络设备2根据协商结果，继续执行切换时隙分配表的操作。本领域技术人员可以理解的是，如果此时，网络设备2仍然处于重启状态，或者说没有做好相关准备工作，则重复触发时隙协商请求，直到网络设备1确定网络设备2对其发出的时隙协商请求做出了有效的响应。在FlexE开销帧4中包括指示信息2，指示信息2用于指示FlexE开销帧4是对请求信息2的响应。
S309、网络设备1接收FlexE开销帧4。
S310、网络设备1根据指示信息2，确定所述FlexE开销帧4是对所述请求信息2的响应，则将备用时隙分配表切换为主用时隙分配表。
关于S310的具体说明，将在下文中结合S305一并进行介绍。
S311、网络设备1向网络设备2发送FlexE开销帧5，指示网络设备2将备用时隙分配表切换为主用时隙分配表。
其中，FlexE开销帧5中CCC字段的值与CR字段的值相同，其值与FlexE开销帧1中CR字段的值相同。
S312、网络设备2接收所述FlexE开销帧5，并将备用时隙分配表切换为主用时隙分配表。
本领域技术人员可以理解的是，FlexE开销帧3不意味着其必然是和FlexE开销帧2时序上相邻的开销帧，也可以是网络设备1向网络设备2发送了多次时隙协商请求后的某一个开销帧。本申请中所提及的操作“CR中断”是指，当网络设备接收到时隙协商请求开销帧后(收到的FlexE开销帧中CR与CCC的值不同，便认为是时隙协商请求)，读取开销帧中携带的时隙分配表信息，并且刷新本地保存的时隙表配置。一种具体的实施方式中，执行CR中断可以由软件在处理器实现。处理器通过连接网络转发芯片的接口读取寄存器中保存的开销帧信息，根据开销帧中携带的最新的时隙分配表的配置信息，刷新本地保存的时隙分配表的配置。另一种具体的实施方式中，执行CR中断可以是通过转发芯片实现。例如可以在芯片中设置处理逻辑，读取时隙协商开销帧的信息，根据开销帧中携带的最新的时隙分配表的配置信息，刷新本地保存的时隙分配表的配置。
在本申请所提供的时隙协商方法中，通过在RX回复给TX的FlexE开销帧携带指示信息，使得指示信息能够指示出FlexE开销帧是否是对TX发出的时隙协商请求的响应。当TX根据所述指示信息，确定接收到的FlexE开销帧不是对其发出的时隙协商请求做作出的响应时，TX会重新发送时隙协商请求，直到TX确认RX对其发出的时隙协商请求进行了响应。由此，可以有效避免由于RX误响应TX发出的时隙协商请求而导致流量中断的问题。
下面对上述方法300中的S305和S310中所提及的指示信息1和指示信息2进行具体说明。在本申请中，网络设备1可以但不限于通过以下方式一到方式三来确定接收到的FlexE开销帧是否是对网络设备1发出的请求信息(或者说是时隙协商请求)所作出的响 应。
方式一，指示信息1和指示信息2是FlexE开销帧中新扩展的字段所指示的信息，该新扩展的字段不是CA字段。例如，在图5所示的FlexE开销帧的保留(Reserved)字段增加一个或多个bit,用于标识所述指示信息1和指示信息2。也可以是FlexE开销帧管理通道中新增一个字段来标识所述指示信息1和指示信息2。具体来说，FlexE开销帧2中该新增的至少一个bit为指示信息1，FlexE开销帧4中该新增的至少一个比特为指示信息2。一个具体的实施方式中，在FlexE开销帧中，新增一个bit，以该新增的比特的不同取值来分别标识指示信息1和指示信息2。当FlexE开销帧中所述新增的bit取值为1时，用于指示FlexE开销帧是对接收到的时隙协商请求的响应；当所述新增的bit取值为0时，用于指示FlexE开销帧不是对所述时隙协商请求的响应。具体来说，当FlexE开销帧2中所述新增的bit取值为1时，用于指示FlexE开销帧2是对所述请求信息1的响应；当所述新增的bit取值为0时，用于指示FlexE开销帧2不是对所述请求信息1的响应。同理，当FlexE开销帧4中新增的bit取值为1时，用于指示FlexE开销帧4是对请求信息2的响应；当该新增的bit的取值为0时，用于指示FlexE开销帧4不是对请求信息2的响应。在另一个具体的实施方式中，也可以以比特映射(bit map)的方式来标识所述指示信息1和指示信息2。例如，在FlexE开销帧中，新增两个比特，每个比特分别映射指示信息1和指示信息2，具体指示的方式不再赘述。应理解，本申请不限于上述实施方式。采用方式一的方案，通过FlexE开销帧中新扩展的字段来指示RX发出的FlexE开销帧是否是对TX发出的FlexE开销帧中所携带的请求信息的响应，而FlexE开销帧中的CA字段用于指示时隙分配表，而不用于指示FlexE开销帧是否是对请求信息的响应。通过上述实施方式，能够在不改变现有开销帧格式的情况下，解决了现有CA字段的二义性问题，有效避免上述问题导致的流量中断，保证了业务连续性和稳定性。
下面结合图9和图10，以扩展一个bit为例，对本方式一进行举例说明。
如图9所示，在FlexE开销帧中找出1Bit空闲位域，为方便表述，本申请暂且称之为RR(RX CR Ready Flag)标志位，可以理解，本申请对于该标识为的命名不受限与此。
1)当RX方向FlexEGROUP已经激活且加PHY，并已经处理了TX方向的CR中断时，将此RR标记置为1。RR＝1时，RX回复TX的FlexE开销中的CA内容，用于指示可信的对时隙协商请求作出回应的时隙分配表。
2)如果收到FlexE开销中的RR＝0，TX方向则认为RX方向没有回应时隙协商请求，TX将持续发起时隙协商请求，直到RX方向回应携带RR＝1，CA＝预期值的FlexE开销帧后，才认为协商成功，否则持续保持时隙协商状态。
下面结合图10，对本方式一的具体时隙协商方法3000进行举例介绍。
TX方向基于上文所述的某些原因，发起时隙分配表Calendar B向Calendar A的切换。
S3301、TX发起时隙协商请求。
TX向RX方向发送FlexE开销帧(CR＝0/CCC＝1)，用于发出所述时隙协商请求。其中，TX将最新的Calendar A的配置信息通过FlexE开销帧发送给RX。
S3302、RX向TX发送时隙协商回应。
RX方向做好相关准备工作后(例如：FlexE Group已经完成Group的激活动作、PHY的加组动作、且开启了CR时隙协商中断、并成功接收处理了TX方向的时隙协商请求(CR＝0 /CCC＝1))，向TX发送时隙协商响应。具体来说，RX向TX发送FlexE开销帧，以回应所述时隙协商请求。在该FlexE开销帧中，将RR标志位置为1，CA标志位置为0。
S3303、TX从Calendar B切换为Calendar A。并向RX发送FlexE开销(CR＝0，CCC＝0)，触发RX完成Calendar B到Calendar A的切换。
TX收到FlexE开销帧(其中，CA＝0，RR＝1)的时候，认为是有效回应。TX随后完成时隙协商动作，将时隙分配表由Calendar B切换到Calendar A，并发送FlexE OH开销帧(其中，CR＝0，CCC＝0)给到RX。
若TX方向长时间没有收到RX有效的时隙协商回应，将会定时再次发送时隙协商请求。
S3304、RX收到TX的FlexE开销帧(CR＝0，CCC＝0)后，将时隙分配表由Calendar B切换到Calendar A。
S3304之后，在RX向TX发送的例行刷新的FlexE开销中，RR再置为0，用以等待处理下次TX发起的时隙协商请求流程。
需要说明的是，本实施方式中，在S3301之后，S3302之前，还可以包括以下操作：
如果RX没有做好相关的准备工作，向TX例行发送FlexE开销帧，其中，RR置位为0。
TX接收到RR置位为0的FlexE开销帧，确定该FlexE开销不是对其发出的时隙协商请求作出的响应。
TX向RX重新发出时隙协商请求，在FlexE开销帧中，CR置位为0，CCC置位为1。
方式二、该指示信息1和指示信息2可以是FlexE开销帧中的CA字段所指示的信息。在该方式中，改变当前标准中定义的CA字段的语义。具体来说，在当前OIF标准中，CA字段的语义具有二义性，既用来表达协商的响应，又用来指示时隙分配表。当前标准中关于CA语段的二义性定义，导致本申请上文中所描述的技术问题。在本实施方式中，通过改变CA的语义，使其用于指示协商响应的有效性，而不用于指示时隙分配表，换言之，不用于指示协商的输出。例如：CA＝0时，表示该开销帧不是对时隙协商请求作出的响应，而CA＝1时，表示该开销帧是对时隙协商请求作出的响应。此时，CA的取值和时隙分配表的配置无关，即和协商的输出无关。CA字段用于指示RX发出的FlexE开销帧是否是对TX发出的时隙分配表协商请求所作出的响应。具体来说，在S305中，指示信息1为FlexE开销帧2的CA字段赋值为第一值时所指示的信息。在S310中，指示信息2为FlexE开销帧4的CA字段赋值为第二值时所指示的信息。例如，当FlexE开销帧2中CA字段赋值为0时，用于指示FlexE开销帧2是对时隙协商请求1的响应，而不用于指示时隙分配表。当FlexE开销帧4的CA字段赋值为1时，用于指示FlexE开销帧4是对时隙协商请求2的响应，而不用于指示时隙分配表。在方式二中，RX在本地完成时隙分配表切换的准备，在回复给TX的FlexE开销帧中，CA字段不再用于指示时隙分配表，TX只要接收到了CA赋值为第二值的FlexE开销帧，即认为协商完成，继续时隙分配表的切换流程。
方式二提供的方案改变了现有的CA字段的语义，放弃了CA指示时隙分配表的语义特性，即放弃了CA字段用于指示协商输出的语义特性。通过CA语段用于指示协商响应的有效性，而不只是协商输出，解决了现有CA字段的二义性问题，有效避免由于时隙协商流程出现错误而对业务造成的影响。
下面结合图11对方式二所提供的协商流程400进行举例说明。
TX方向基于上文所述的某些原因，发起时隙分配表Calendar B向Calendar A的切换。
S401、TX发起时隙协商请求。
TX向RX方向发送FlexE开销帧(CR＝0/CCC＝1)，用于发出所述时隙协商请求。其中，TX将最新的Calendar A的配置信息通过FlexE开销发送给RX。
S402、RX向TX发送时隙协商回应。
RX方向做好相关准备工作后(例如：FlexE Group已经完成Group的激活动作、PHY的加组动作、且开启了CR时隙协商中断、并成功接收处理了TX方向的时隙协商请求(CR＝0/CCC＝1))，向TX发送时隙协商响应。具体来说，RX向TX发送FlexE开销帧，以回应所述时隙协商请求。在该FlexE开销帧中，将CA标志位置为1,用于指示该FlexE开销帧是对接收到的时隙协商请求的响应。
S403、TX从Calendar B切换为Calendar A。并向RX发送FlexE开销帧(CR＝0，CCC＝0)，触发RX完成Calendar B到Calendar A的切换。
TX收到FlexE开销帧(其中，CA＝1)的时候，认为是有效回应。TX随后完成时隙协商动作，将时隙分配表由Calendar B切换到Calendar A，并发送FlexE开销帧(其中，CR＝0，CCC＝0)给到RX。
若TX方向长时间没有收到RX有效的时隙协商回应，将会定时再次发送时隙协商请求。
S404、RX收到TX的FlexE开销帧(CR＝0，CCC＝0)后，将时隙分配表由Calendar B切换到Calendar A。
S404之后，在RX向TX发送的例行刷新的FlexE开销帧中，CA再置为0，用以等待处理下次TX发起的时隙协商请求流程。
需要说明的是，本实施方式中，在S401之后，S402之前，还可以包括以下操作：
a)如果RX没有做好相关的准备工作，向TX例行发送FlexE开销，其中，CA置位为0。
b)TX在发送了时隙协商请求后，接收到CA置位为0的FlexE开销帧，确定该FlexE开销不是对其发出的时隙协商请求作出的响应。
c)TX向RX重新发出时隙协商请求，在FlexE开销帧中，CR置位为0，CCC置位为1。
方式三，通过在FlexE开销帧的管理通道中增加请求报文和响应报文，用于完成网络设备1和网络设备2之间的时隙协商。此方式中，通过在管理通道中增加一组报文来指示协商响应的有效性，开销帧中CA字段的值可用于指示时隙分配表，即用于表达协商的输出，但不用于表达协商响应的有效性。本方式通过在管理通道中增加请求报文(本申请中亦称之为时隙协商请求报文)和响应报文(本申请中亦称之为时隙协商响应报文)，以此来表达时隙协商的请求和响应，TX通过开销帧的管理通道中是否携带了时隙协商响应报文来判断接收到的开销帧是否是对其发出的时隙协商请求报文的响应，解决了现有CA字段的二义性问题，有效避免由于时隙协商流程出现错误而对业务造成的影响。具体来说，在方式三中，S305中所述的指示信息1是FlexE开销帧2的管理通道所指示的信息，S310中所述的指示信息2是FlexE开销帧4的管理通道所指示的信息。FlexE开销中提供的管理通道对其承载的报文类型并没有限制，仅需要保证报文是按照指定的编码格式传输即可。上述指定的编码格式是对端设备能够正确解码即可。对于本申请实施方式中增加的报文格式，本申请不作具体限制，以下我们按照以太报文格式举例来对所述报文进行说明，但是用于指示时隙协商有效性的报文格式，但并不限于本申请中举例说明的报文格式。
需要说明的是，本申请中所述的管理通道遵从现有标准中定义的开销帧的管理通道， 例如，当前标准中定义管理通道为开销帧的第4-8个块。在将来的行业标准或者企业标准中，如果管理通道的定义有所变化，本申请中所述的管理通道兼容各类标准对于管理通道的定义。
下面结合图12a至图12e以及图13对上述方式三所涉及的协商流程进行举例说明。
一种具体的实施方式中，图12a示例性给出了在管理通道中增加的时隙协商请求报文(CR Request)的报文格式，图12b示例性给出了在管理通道中增加的时隙协商响应报文(CR Ack)的报文格式。
下面结合图12a和图12b，对CR Request报文以及CR Ack报文的格式进行介绍：
SMAC：源MAC地址，长度例如可以是6bit，值可以为源端口的MAC地址。
DMAC：目的MAC，长度例如可以是6bit,值可以为全1。
TYPE：报文类型，长度例如可以是2bit，值可以为全0。
GROUP NUM:FlexE Group number,长度例如可以是2bit，指示属于哪个FlexE Group。
Flag:报文子类型，长度例如可以是20bit。一个具体的实施方式中，CR Request报文中，Flag字段的值可以为字符串“CR Request”；CR Ack报文中，Flag字段的值可以为字符串“CR Ack”。
在另一种具体的实施方式中，图12c至图12d示例性给出了另一种关于CR Request报文和CR Ack的具体示例。在该示例中，通过对链路层发现协议(英文：link layer discovery protocol，LLDP)报文净荷中携带的父TLV字段进行扩展，增加子TLV类型，用于携带CR Request报文和CR Ack报文。
LLDP报文的净荷里包括多个级联的TLV，图12c所示为父TLV，父TLV包括type字段，length字段和value字段。其中，value字段里可以由多个子TLV级联。例如，厂商保留的TLV类型(TYPE＝127)就是一种父TLV类型。下面以父TLV type127(即T字段取值127)为例，举例说明如何在LLDP报文的父TLV字段里携带CR Request报文和CR Ack报文。
图12d)表示在图12c)所示的Value字段里扩展的用于表示CR Request报文的子TLV的具体格式示意图，图12e)表示在图12c)所示的value字段里扩展的用于表示CR Request报文的子TLV的具体格式示意图。
在图12d)中，子TLV字段包括type字段，length字段和value字段。其中，type字段用于表示该子TLV的类型是CR Request报文，长度例如可以是7bits；Length字段表示V字段的长度，长度例如可以是9bits；value字段用于携带FlexE Group number,长度例如可以是2bytes。
在图12d)中，子TLV字段包括type字段，length字段和value字段。其中，type字段用于表示该子TLV的类型是CR Ack报文，长度例如可以是7bits；Length字段表示V字段的长度，长度例如可以是9bits；value字段用于携带FlexE Group number,长度例如可以是2bytes。
本领域技术人员可以理解，本申请实施例中给出的CR Request报文和CR Ack报文给出的报文格式仅是举例说明，不应理解为对报文格式的限制。
下面结合图13对采用方式三进行时隙协商方法500进行举例说明。
S501、TX向RX发送CR Request报文，向RX发出时隙协商请求。
具体来说，TX向RX发送FlexE开销帧1，发送时隙协商请求1。在FlexE开销帧1的 管理通道中携带请求信息1，具体来说，该请求信息1为CR Request报文1，请求网络设备2从当前的时隙分配表B切换为时隙分配表A。此时，主用时隙分配表为时隙分配表B，备用时隙分配表为时隙分配表A。TX向RX发送请求发送CR Request报文1后，等待RX的回应。
在S501后，可以分为两种情况。
a)如果RX回应了CR Ack报文则认为RX已经准备好，可以进行时隙分配表的切换。则在S501之后继续执行S510-S512。
b)如果RX方向没有回应CR Ack报文，则在S501后执行S502-S512。TX方向将再次发送CR Request报文，用于再次进行时隙协商请求，并等待RX方向回应。
RX方向收到CR Request消息后：
判断本端的FlexE Group已经完成组的激活动作、PHY的加组动作、且开启了CR时隙协商中断等准备工作后，才通过FlexE开销的管理通道回应CR Ack报文。
如果RX方向未准备好处理时隙协商，则不对CR Request报文做出响应，即不发送所述CR Ack报文。
S502、RX向TX发送例行刷新的FlexE开销帧2。
其中，FlexE开销帧2的管理通道未携带响应报文1，该实施方式中，响应报文1为CR Ack报文1。此时，FlexE开销帧2的管理通道即为本申请所述的FlexE开销帧2中携带的指示信息1。
S503、TX接收FlexE开销帧2,。
S504、TX根据FlexE开销帧2的管理通道，确定FlexE开销帧2不是对时隙协商请求1的响应。
S505、TX向RX发送FlexE开销帧3，用于发送时隙协商请求2。
其中，在FlexE开销帧3的管理通道中，携带有请求信息2，即协商请求报文2(CR Reuest报文2)，用于发出时隙协商请求2。
S506、RX接收FlexE开销帧3。
S507、RX向TX发送FlexE开销帧4，对接收到的时隙协商请求2作出响应。
具体来说，在FlexE开销帧4的管理通道中，携带有响应报文2，即协商响应报文2(CR Ack报文2)。此时，FlexE开销帧4的管理通道为本申请所述的FlexE开销帧4中携带的指示信息2。
S508、TX接收FlexE开销帧4。
S509、TX根据指示信息2，确定所述FlexE开销帧4是对所述时隙协商请求2的响应。
S510、TX从Calendar B切换为Calendar A。
S511、向RX发送FlexE开销帧5(CR＝0，CCC＝0)，触发RX完成Calendar B到Calendar A的切换。
S512、RX接收FlexE开销帧5，完成从Calendar B到Calendar A的切换。
在另一个具体的实施方式中，在TX和RX的时隙协商流程中，上述S501至S509作为一个预协商的过程，在S509之后，S510之前，TX确认预协商流程成功，则开始执行正式协商流程。通过该种方式，能够保证现有的时隙协商流程不变，正式协商流程中，对于CA字段的定义遵从现有标准中的定义，因为在正式协商流程中，已经完成了预协商的流程， 只有在预协商成功的情况下，才会开始正式协商，因此，能够避免RX误应答TX发出的时隙协商请求的问题，有效保证正常的业务转发。
下面对于本实施方式中所提及的正式协商流程简单说明如下，关于正式协商流程的说明亦可参见前文中描述的方法100中的具体描述。
步骤A、TX向RX发起时隙协商请求3。
具体来说，TX收到方向的CR Ack消息后，表明RX已经做好准备和TX进行时隙协商。TX再次向RX发送FlexE开销帧6，以发起时隙协商请求3。TX与RX开始按照现有流程协商时隙，发起时隙表Calendar B向Calendar A的切换的协商。TX方向将最新的Calendar A内容通过FlexE开销帧6发送给RX，其中，FlexE开销帧6中CR＝0，CCC＝1，用于和RX协商将当前工作的时隙分配表从时隙分配表B切换至时隙分配表A。
步骤B、RX向TX发送对时隙协商请求3的响应。
RX收到TX的时隙协商请求3(CR＝0/CCC＝1)后，由于之前RX曾经回应过CR Ack给TX，故此时RX已经准备就绪，可以正常处理TX发起的时隙协商请求2。RX开启CR中断，刷新时隙分配表A的配置，并向TX发送FlexE开销帧7，以响应接收到的时隙协商请求3。其中，RX通过向TX发送FlexE开销帧7以发送所述响应，在FlexE开销帧4中，CA字段置位为0。
步骤C、TX将本地的主用时隙分配表由Calendar B切换为Calendar A，并向RX发送FlexE开销(CR＝0，CCC＝0)，触发RX完成Calendar B到Calendar A的切换。
在步骤C之后，继续执行上述步骤S510-S512，此处不再赘述。
综上所述，本申请所提供的时隙协商方法能够解决当前OIF标准定义的FlexE开销时隙协商机制存在误应答问题，此种误应答问题的本质是FlexE开销时隙协商的回应消息仅仅看CA位域的表达，但由于CA位域仅为1Bit，既要表达协商的输出，又要表达协商响应，故存在语义表达的二义性。通过本申请上述的方案，有效解除了CA位域二义性的问题，使得TX能够准确的判断接收到的FlexE开销是否是对其发出的时隙协商请求所作出的响应，并基于判断结果决定是否重新触发时隙协商请求或者进行时隙分配表的切换，由此确保了TX和RX能够进行正确的时隙协商，确保时隙协商结果的准确性。有效提高时隙协商的成功率，减少由于现有技术中由于RX误响应所导致的时隙协商错误对正常的灵活以太业务所造成的影响。
图14是本申请实施例提供的一种时隙协商方法600的流程示意图。其中，应用方法600的网络架构至少包括所述第一网络设备和第二网络设备。举例来说，第一网络设备可以是图3所示的网络设备1(TX)，第二网络设备可以是图3所示的网络设备2(RX)。图14所示的方法可以具体实现结合图6-图13所描述的任一实施例所示的方法。例如，图14中第一网络设备和第二网络设备可以分别是图8所示方法300中网络设备1和网络设备2。图14所示的方法600包括以下内容。
S601、第一网络设备向第二网络设备发送第一灵活以太FlexE开销帧。
所述第一FlexE开销帧包括第一请求信息，所述第一请求信息用于请求所述第二网络设备将备用时隙分配表切换为主用时隙分配表。
S602、第二网络设备接收第一网络设备所述第一FlexE开销帧。
S603、第二网络设备向第一网络设备发送第二FlexE开销帧。
S604、第一网络设备接收所述第二网络设备发送的第二FlexE开销帧。
S605、第一网络设备根据所述第二FlexE开销帧中的第一指示信息，确定所述第二FlexE开销帧不是对所述第一请求信息的响应。
S606、第一网络设备向所述第二网络设备发送第三FLexE开销帧。
S607、第二网络设备接收所述第三FLexE开销帧。
所述第三FLexE开销帧包括第二请求信息，所述第二请求信息用于请求所述第二网络设备将所述备用时隙分配表切换为主用时隙分配表。
一个具体的实施方式中，所述第一请求信息为所述第一FlexE开销帧的管理通道中携带的第一请求报文。该第一请求报文例如可以是时隙协商请求报文，具有如图12a，图12c对应实施例所描述的报文格式。
一个具体的实施方式中，所述第一请求信息是第一FlexE开销帧所携带的CR和CCC字段所指示的信息。其中，CR字段和CCC字段取值不同，则表示第一FlexE开销帧是用于时隙协商请求。
一个具体的实施方式中，所述第二求信息为所述第三FlexE开销帧的管理通道中携带的第二求报文。该第二求报文例如可以是时隙协商请求报文，具有如图12a，图12c对应实施例所描述的报文格式。
一个具体的实施方式中，所述第二求信息是第三lexE开销帧所携带的CR和CCC字段所指示的信息。其中，CR字段和CCC字段取值不同，则表示第三lexE开销帧是用于时隙协商请求。
一个具体的实施方式中，所述第一指示信息为所述第二FlexE开销帧的管理通道，所述第二FlexE开销帧的管理通道未携带第一响应报文，所述第一响应报文用于指示所述第二FlexE开销帧是对所述第一请求信息的响应。
一个具体的实施方式中，所述第一指示信息为所述第二FlexE开销帧中第一字段所指示的信息，所述第一字段与所述第二FlexE开销帧的时隙分配表切换确认CA字段不同。
一个具体的实施方式中，所述第一指示信息为所述第二FlexE开销帧的时隙分配表切换确认CA字段所指示的信息，所述第一指示信息用于指示所述第二FlexE开销帧不是对所述第一请求信息的响应，所述第一指示信息不用于指示时隙分配表。
通过时隙协商方法600，第一网络设备向第二网络设备发送第一次时隙协商请求后，通过确定第二网络设备返回的FlexE开销帧不是对其发出的时隙协商请求的响应后，会再次发出新的时隙协商请求。因此，能够有效避免将第二网络设备例行刷新的FlexE开销帧认定为对其发出的时隙协商请求的响应，而导致的业务中断。
方法600中，在S607之后，还可以包括：
a)第一网络设备接收所述第二网络设备发送的第四FlexE开销帧；
第一网络设备FlexE开销帧中携带的第二指示信息，确定所述第四FlexE开销帧是对所述第二请求信息的响应。
b)在一个具体的实施方式中，当第一网络设备确定所述第四FlexE开销帧是对第二请求信息的响应，则执行时隙分配表的主备切换，即将备用时隙分配表切换为主用时隙分配表。
在另一个具体的方式中，当方法600采用在FlexE开销帧的管理通道中增加请求报文 和响应报文来进行时隙协商时，在步骤b)以后，所述方法600还可以包括：
c)第一网络设备向第二网络设备发出第五FlexE开销帧，第五FlexE开销帧中CR字段与CCC字段不同，用于发出第三时隙协商请求，请求将备用时隙分配表切换为主用时隙分配表。
d)第二网络设备接收所述第五FlexE开销帧，并向第一网络设备发送第六FlexE开销帧。
第六FlexE开销帧是对所述第三时隙协商请求的响应。
e)第一网络设备接收所述第六FlexE开销帧，根据所述第六FlexE开销帧的CA字段，确定所述第六FlexE开销帧是对第三时隙协商请求的响应。
f)第一网络设备执行时隙分配表的主备切换，即将备用时隙分配表切换为主用时隙分配表。
一个具体的实施方式中，所述第二指示信息为所述第四FlexE开销帧的管理通道，所述第四FlexE开销帧的管理通道携带第二响应报文，所述第二响应报文用于指示所述第四FlexE开销帧是对所述第二请求信息的响应。
另一个具体的实施方式中，所述第二指示信息为所述第四FlexE开销帧的时隙分配表切换确认CA字段所指示的信息，所述第二指示信息用于指示所述第四FlexE开销帧是对所述第二请求信息的响应，所述第二指示信息不用于指示时隙分配表。
另一个具体的实施方式中，所述第二指示信息为所述第四lexE开销帧中第二字段所指示的信息，所述第二段与所述第四lexE开销帧的时隙分配表切换确认CA字段不同。
当图14所示的方法600用于实现图6-图13任一附图所对应的方法时，上述第一请求信息和第二请求信息例如可以对应前述各方法实施例中所描述的请求信息1和请求信息2。上述第一指示信息和第二指示信息，例如可以对应前述各方法实例中所描述的指示信息1和指示信息2。关于第一请求信息，第二请求信息，第一指示信息，第二指示信息的具体格式，以及方法600中各步骤的具体实现方式，可参见前述各方法实施例中对应步骤的相关说明，此处不再赘述。
下面结合图15，对本申请实施例所提供的一种网络设备700进行介绍。网络设备700可以应用于图3所示的网络架构中。举例来说，网络设备700可以是本申请所述网络设备1(TX)或者网络设备2(RX)，用于执行前述图6-图14任一附图所对应的实施例的方法。网络设备700还可以是本申请所述的第一网络设备或第二网络设备，用于执行图14所对应的方法。网络设备700包括收发单元701和处理单元702。收发单元701用于执行收发操作，处理单元用于执行收发以外的操作。例如，当网络设备700作为第一网络设备执行图14所示的方法600时，收发单元701可以用于向第二网络设备发送第一灵活以太FlexE开销帧，接收所述第二网络设备发送的第二FlexE开销帧，以及向所述第二网络设备发送第三FlexE开销帧。处理单元702可以用于根据所述第二FlexE开销帧中的第一指示信息，确定所述第二FlexE开销帧不是对所述第一请求信息的响应。
下面结合图16，对本申请实施例所提供的另一种网络设备800进行介绍。网络设备800可以应用于图3所示的网络架构中。举例来说，网络设备800可以是本申请所述的网络设备1(TX)或者网络设备2(RX)，用于执行前述图6-图13任一附图所对应的实施例的方法中由网络设备1或网络设备2所执行的操作。网络设备800还可以是本申请所述的 第一网络设备或第二网络设备，执行图14所对应的方法由第一网络设备或第二网络设备所执行的操作。网络设备800包括通信接口801以及与通信接口相连的处理器802。通信接口801用于执行收发操作，处理器802用于执行收发以外的操作。例如，当网络设备800作为第一网络设备执行图14所示的方法600时，通信接口801可以用于向第二网络设备发送第一灵活以太FlexE开销帧，接收所述第二网络设备发送的第二FlexE开销帧，以及向所述第二网络设备发送第三FlexE开销帧。处理器802可以用于根据所述第二FlexE开销帧中的第一指示信息，确定所述第二FlexE开销帧不是对所述第一请求信息的响应。
下面结合图17，对本申请实施例提供的另一种网络设备900进行介绍。网络设备900可以应用于图3所示的网络架构中。举例来说，网络设备900可以是本申请所述的网络设备1(TX)或者网络设备2(RX)，用于执行前述图6-图13任一附图所对应的实施例的方法中由网络设备1或网络设备2所执行的操作。网络设备900还可以是本申请所述的第一网络设备或第二网络设备，执行图14所对应的方法由第一网络设备或第二网络设备所执行的操作。网络设备900包括存储器901和与所述存储器相连的处理器902。存储器901中存储有指令，处理器902读取所述指令，使得网络设备900执行图6-图13任意附图对应的实施例中由TX或RX所执行的方法，后者执行图14对应的实施例中由第一网络设备或第二网络设备所执行的方法。
下面结合图18，对本申请实施例提供的另一种网络设备1000进行介绍。网络设备1000可以应用于图3所示的网络架构中。举例来说，网络设备1000可以是本申请所述的网络设备1(TX)或者网络设备2(RX)，用于执行前述图6-图13任一附图所对应的实施例的方法中由网络设备1或网络设备2所执行的操作。网络设备1000还可以是本申请所述的第一网络设备或第二网络设备，执行图14所对应的方法由第一网络设备或第二网络设备所执行的操作。如图18所示，网络设备1000包括处理器1010，与所述处理器耦合连接的存储器1020以及通信接口1030。在一个具体的实施方式中，存储器1020中存储有计算机可读指令，所述计算机可读指令包括多个软件模块，例如发送模块1021，处理模块1022和接收模块1023。处理器1010执行各个软件模块后可以按照各个软件模块的指示进行相应的操作。在本实施例中，一个软件模块所执行的操作实际上是指处理器1010根据所述软件模块的指示而执行的操作。例如，当网络设备1000作为第一网络设备执行图14所示的方法时，发送模块1021用于向第二网络设备发送第一FlexE开销帧以及第三FlexE开销帧，接收模块1023用于接收第二网络设备发送的第二FlexE开销帧，处理模块1022用于根据第二FlexE开销帧中的指示信息，确定所述第二FlexE开销帧不是对第一FlexE开销帧中所携带的第一请求信息的响应。此外，处理器1010执行存储器1020中的计算机可读指令后，可以按照计算机可读指令的指示，执行网络设备1，网络设备2，第一网络设备或者第二网络设备可以执行的全部操作。例如，当网络设备1000作为网络设备1或网络设备2时，可以分别执行图6-图13对应的实施例中由网络设备1或网络设备2执行的所有操作；当网络设备1000作为第一网络设备或第二网络设备时，可以分别执行图14对应的实施例中由第一网络设备或第二网络设备执行的所有操作。
在本申请中所提到的处理器可以是中央处理器(英文：central processing unit，缩写：CPU)，网络处理器(英文：network processor，缩写：NP)或者CPU和NP的组合。处理器还可以是专用集成电路(英文：application-specific integrated circuit，缩 写：ASIC)，可编程逻辑器件(英文：programmable logic device，缩写：PLD)或其组合。上述PLD可以是复杂可编程逻辑器件(英文：complex programmable logic device，缩写：CPLD)，现场可编程逻辑门阵列(英文：field-programmable gate array，缩写：FPGA)，通用阵列逻辑(英文：generic array logic,缩写：GAL)或其任意组合。处理器1010可以是指一个处理器，也可以包括多个处理器。本申请中所提到的存储器可以包括易失性存储器(英文：volatile memory)，例如随机存取存储器(英文：random-access memory，缩写：RAM)；存储器也可以包括非易失性存储器(英文：non-volatile memory)，例如只读存储器(英文：read-only memory，缩写：ROM)，快闪存储器(英文：flash memory)，硬盘(英文：hard disk drive，缩写：HDD)或固态硬盘(英文：solid-state drive，缩写：SSD)；存储器还可以包括上述种类的存储器的组合。存储器可以是指一个存储器，也可以包括多个存储器。
本申请实施例还提供了一种通信***，包括第一网络设备和第二网络设备，其中，第一网络设备和第二网络设备可以是图15至图18任一项所述的网络设备，用与执行图6至图14对对应的任意一个实施例中的方法。
本申请还提供了一种计算机程序产品，包括计算机程序，当其在计算机上运行时，使得计算机可以执行执行图6至图13对应的任意一个实施例中由网络设备1和/或网络设备2所执行的方法。
本申请还提供了一种计算机程序产品，包括计算机程序，当其在计算机上运行时，使得计算机可以执行执行图14对应的实施例中由第一网络设备和/或第二网络设备所执行的方法。
本申请提供了一种计算机可读存储介质，包括计算机指令，当其在计算机上运行时，使得计算机可以执行图6至图13对应的任意一个实施例中由网络设备1和/或网络设备2所执行的方法。
本申请提供了一种计算机可读存储介质，包括计算机指令，当其在计算机上运行时，使得计算机可以执行图14对应的实施例中由第一网络设备和/或第二网络设备所执行的方法。
本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的模块及方法操作，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能。
所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的***、装置和模块的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
在上述实施例中，可以全部或部分地通过硬件、固件或者其任意组合来实现。当具体实现过程中涉及软件时，可以全部或部分地体现为计算机程序产品的形式。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、 光纤、数字用户线(DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，DVD)、或者半导体介质(例如固态硬盘Solid State Disk(SSD))等。
本说明书的各个部分均采用递进的方式进行描述，各个实施方式之间相同相似的部分互相参见即可，每个实施方式重点介绍的都是与其他实施方式不同之处。尤其，对于装置和***实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例部分的说明即可。
以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以所述权利要求的保护范围为准。

Claims (21)

  1. 一种时隙协商的方法，由第一网络设备执行，其特征在于，包括：
    向第二网络设备发送第一灵活以太FlexE开销帧，所述第一FlexE开销帧包括第一请求信息，所述第一请求信息用于请求所述第二网络设备将备用时隙分配表切换为主用时隙分配表；
    接收所述第二网络设备发送的第二FlexE开销帧；
    根据所述第二FlexE开销帧中的第一指示信息，确定所述第二FlexE开销帧不是对所述第一请求信息的响应；
    向所述第二网络设备发送第三FLexE开销帧，所述第三FLexE开销帧包括第二请求信息，所述第二请求信息用于请求所述第二网络设备将所述备用时隙分配表切换为所述主用时隙分配表。
  2. 根据权利要求1所述的方法，其特征在于，所述第一请求信息为所述第一FlexE开销帧的管理通道中携带的请求报文。
  3. 根据权利要求1或2所述的方法，其特征在于，所述第一指示信息为所述第二FlexE开销帧的管理通道所指示的信息，所述第二FlexE开销帧的管理通道未携带第一响应报文，所述第一响应报文用于指示所述第二FlexE开销帧是对所述第一请求信息的响应。
  4. 根据权利要求1所述的方法，其特征在于，所述第一指示信息为所述第二FlexE开销帧中第一字段所指示的信息，所述第一字段与所述第二FlexE开销帧的时隙分配表切换确认CA字段不同。
  5. 根据权利要求1所述的方法，其特征在于，所述第一指示信息为所述第二FlexE开销帧的时隙分配表切换确认CA字段所指示的信息，所述第一指示信息用于指示所述第二FlexE开销帧不是对所述第一请求信息的响应，所述第一指示信息不用于指示时隙分配表。
  6. 根据权利要求1-5任一项所述的方法，其特征在于，所述方法还包括：
    接收所述第二网络设备发送的第四FlexE开销帧；
    根据所述第四FlexE开销帧中携带的第二指示信息，确定所述第四FlexE开销帧是对所述第二请求信息的响应。
  7. 根据权利要求6所述的方法，其特征在于，所述第二指示信息为所述第四FlexE开销帧的管理通道所指示的信息，所述第四FlexE开销帧的管理通道携带第二响应报文，所述第二响应报文用于指示所述第四FlexE开销帧是对所述第二请求信息的响应。
  8. 根据权利要求6所述的方法，其特征在于，所述第二指示信息为所述第四FlexE开销帧的时隙分配表切换确认CA字段所指示的信息，所述第二指示信息用于指示所述第四FlexE开销帧是对所述第二请求信息的响应，所述第二指示信息不用于指示时隙分配表。
  9. 一种时隙协商方法，由第二网络设备执行，其特征在于，
    接收第一网络设备发送的第一灵活以太FlexE开销帧，所述第一FlexE开销帧包括第一请求信息，所述第一请求信息用于请求所述第二网络设备将备用时隙分配表切换为主用时隙分配表；
    向所述第一网络设备发送第二FlexE开销帧，所述第二FlexE开销帧包括第一指示信息，用于指示所述第二FlexE开销帧不是对所述第一请求信息的响应；
    接收所述第一网络设备发送的第三FlexE开销帧，所述第三FlexE开销帧包括第二请求信息，所述第二请求信息用于请求所述第二网络设备将所述备用时隙分配表切换为主用时隙分配表。
  10. 根据权利要求9所述的方法，其特征在于，所述第一请求信息为所述第一FlexE开销帧的管理通道中携带的请求报文。
  11. 根据权利要求9或10所述的方法，其特征在于，所述第一指示信息为所述第二FlexE开销帧的管理通道所指示的信息，所述第二FlexE开销帧的管理通道未携带第一响应报文，所述第一响应报文用于指示所述第二FlexE开销帧是对所述第一请求信息的响应。
  12. 根据权利要求9所述的方法，其特征在于，所述第一指示信息为所述第二FlexE开销帧中第一字段所指示的信息，所述第一字段与所述第二FlexE开销帧的时隙分配表切换确认CA字段不同。
  13. 根据权利要求9所述的方法，其特征在于，所述第一指示信息为所述第二FlexE开销帧的时隙分配表切换确认CA字段所指示的信息，所述第一指示信息用于指示所述第二FlexE开销帧不是对所述第一请求信息的响应，所述第一指示信息不用于指示时隙分配表。
  14. 根据权利要求9-13任一项所述的方法，其特征在于，所述方法还包括：
    向所述第一网络设备发送第四FlexE开销帧；
    其中，所述第四FlexE开销帧中携带第二指示信息，所述第二指示信息用于指示所述第四FlexE开销帧是对所述第二请求信息的响应。
  15. 根据权利要求14所述的方法，其特征在于，所述第二指示信息为所述第四FlexE开销帧的管理通道所指示的信息，所述第四FlexE开销帧的管理通道携带第二响应报文，所述第二响应报文用于指示所述第四FlexE开销帧是对所述第二请求信息的响应。
  16. 根据权利要求14所述的方法，其特征在于，所述第二指示信息为所述第四FlexE开销帧的时隙分配表切换确认CA字段所指示的信息，所述第二指示信息用于指示所述第四FlexE开销帧是对所述第二请求信息的响应，所述第二指示信息不用于指示时隙分配表。
  17. 一种第一网络设备，其特征在于，包括：
    通信接口；
    与所述通信接口相连的处理器；
    通过所述通信接口和所述处理器，所述第一网络设备用于执行权利要求1-8任一项所述的方法。
  18. 一种第二网络设备，其特征在于，包括：
    通信接口；
    与所述通信接口相连的处理器；
    通过所述通信接口和所述处理器，所述第二网络设备用于执行权利要求9-16任一项所述的方法。
  19. 一种通信***，包括权利要求17所述第一网络设备以及权利要求18所述的第二网络设备。
  20. 一种计算机可读存储介质，包括计算机指令，当所述指令在计算机上运行时，使得所述计算机执行权利要求1-16任一项所述的方法。
  21. 一种计算机程序产品，包括程序，当所述程序在计算机上运行时，使得所述计算机执行权利要求1-16任一项所述的方法。
PCT/CN2020/114221 2019-09-12 2020-09-09 一种时隙协商的方法和设备 WO2021047538A1 (zh)

Priority Applications (5)

Application Number Priority Date Filing Date Title
MX2022002975A MX2022002975A (es) 2019-09-12 2020-09-09 Metodo de negociacion de intervalos y dispositivo.
BR112022004518A BR112022004518A2 (pt) 2019-09-12 2020-09-09 Método de negociação de slot e dispositivo
JP2022516136A JP7305882B2 (ja) 2019-09-12 2020-09-09 スロットネゴシエーション方法およびデバイス
EP20862916.2A EP4024987B1 (en) 2019-09-12 2020-09-09 Timeslot negotiation method and device
US17/692,810 US20220200722A1 (en) 2019-09-12 2022-03-11 Slot negotiation method and device

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
CN201910867102 2019-09-12
CN201910867102.6 2019-09-12
CN201911008430.7 2019-10-22
CN201911008430.7A CN112491492B (zh) 2019-09-12 2019-10-22 一种时隙协商的方法和设备

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US17/692,810 Continuation US20220200722A1 (en) 2019-09-12 2022-03-11 Slot negotiation method and device

Publications (1)

Publication Number Publication Date
WO2021047538A1 true WO2021047538A1 (zh) 2021-03-18

Family

ID=74865665

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2020/114221 WO2021047538A1 (zh) 2019-09-12 2020-09-09 一种时隙协商的方法和设备

Country Status (6)

Country Link
US (1) US20220200722A1 (zh)
EP (1) EP4024987B1 (zh)
JP (1) JP7305882B2 (zh)
BR (1) BR112022004518A2 (zh)
MX (1) MX2022002975A (zh)
WO (1) WO2021047538A1 (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114615136A (zh) * 2022-03-04 2022-06-10 浙江国盾量子电力科技有限公司 一种5G智能电网切片的FlexE接口管理方法
EP4344147A4 (en) * 2021-10-28 2024-05-15 Huawei Tech Co Ltd TIME SLOT NEGOTIATION PROCEDURE AND DEVICE

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180013511A1 (en) * 2016-07-07 2018-01-11 Infinera Corp. Flexe gmpls signaling extensions
CN109688016A (zh) * 2019-01-25 2019-04-26 中兴通讯股份有限公司 灵活以太网协议中切换时隙配置的方法及相关设备
CN109729588A (zh) * 2017-10-31 2019-05-07 华为技术有限公司 业务数据传输方法及装置
CN109962798A (zh) * 2017-12-22 2019-07-02 华为技术有限公司 灵活以太网的带宽分配配置切换方法、相关装置及***

Family Cites Families (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10135760B2 (en) * 2015-06-30 2018-11-20 Ciena Corporation Flexible Ethernet chip-to-chip inteface systems and methods
US9838290B2 (en) * 2015-06-30 2017-12-05 Ciena Corporation Flexible ethernet operations, administration, and maintenance systems and methods
US10097480B2 (en) * 2015-09-29 2018-10-09 Ciena Corporation Time transfer systems and methods over flexible ethernet
JP2018046373A (ja) * 2016-09-13 2018-03-22 富士通株式会社 伝送装置及び伝送方法
CN108156074B (zh) 2016-12-02 2020-10-23 华为技术有限公司 保护倒换方法、网络设备及***
US10382167B2 (en) * 2016-12-13 2019-08-13 Ciena Corporation Flexible ethernet enhanced forward error correction
CN111953450A (zh) * 2017-02-16 2020-11-17 华为技术有限公司 一种灵活以太网中传输数据的方法及设备
CN111106964A (zh) * 2017-04-28 2020-05-05 华为技术有限公司 配置链路组的方法和设备
CN109428840B (zh) 2017-08-31 2022-05-06 华为技术有限公司 一种通信方法、设备及存储介质
US11018792B2 (en) * 2017-12-22 2021-05-25 Telefonaktiebolaget Lm Ericsson (Publ) Methods and apparatus for configuring a flex ethernet node
CN109981208B (zh) * 2017-12-27 2021-02-09 华为技术有限公司 基于灵活以太网FlexE传输业务流的方法和装置
CN111585778B (zh) * 2019-02-19 2022-02-25 华为技术有限公司 一种灵活以太网通信方法及网络设备
US20220158938A1 (en) * 2019-03-20 2022-05-19 Telefonaktiebolaget Lm Ericsson (Publ) Routing flexe data in a network
US11082367B2 (en) * 2019-05-10 2021-08-03 Ciena Corporation FlexE frame format using 256b/257b block encoding
CN112118197B (zh) * 2019-06-19 2021-07-09 深圳市中兴微电子技术有限公司 一种开销监控方法和装置、计算机可读存储介质

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180013511A1 (en) * 2016-07-07 2018-01-11 Infinera Corp. Flexe gmpls signaling extensions
CN109729588A (zh) * 2017-10-31 2019-05-07 华为技术有限公司 业务数据传输方法及装置
CN109962798A (zh) * 2017-12-22 2019-07-02 华为技术有限公司 灵活以太网的带宽分配配置切换方法、相关装置及***
CN109688016A (zh) * 2019-01-25 2019-04-26 中兴通讯股份有限公司 灵活以太网协议中切换时隙配置的方法及相关设备

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
Y. ZHAO (HUAWEI), H. YANG (HUAWEI): "Non-CE6: Simplification on LFNST", 15. JVET MEETING; 20190703 - 20190712; GOTHENBURG; (THE JOINT VIDEO EXPLORATION TEAM OF ISO/IEC JTC1/SC29/WG11 AND ITU-T SG.16 ), 3 July 2019 (2019-07-03), XP030218818 *

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP4344147A4 (en) * 2021-10-28 2024-05-15 Huawei Tech Co Ltd TIME SLOT NEGOTIATION PROCEDURE AND DEVICE
CN114615136A (zh) * 2022-03-04 2022-06-10 浙江国盾量子电力科技有限公司 一种5G智能电网切片的FlexE接口管理方法
CN114615136B (zh) * 2022-03-04 2023-10-27 浙江国盾量子电力科技有限公司 一种5G智能电网切片的FlexE接口管理方法

Also Published As

Publication number Publication date
EP4024987B1 (en) 2023-11-08
US20220200722A1 (en) 2022-06-23
EP4024987A1 (en) 2022-07-06
EP4024987A4 (en) 2022-11-16
MX2022002975A (es) 2022-04-06
JP7305882B2 (ja) 2023-07-10
BR112022004518A2 (pt) 2022-05-31
JP2022547591A (ja) 2022-11-14

Similar Documents

Publication Publication Date Title
CN112491492B (zh) 一种时隙协商的方法和设备
WO2020156591A1 (zh) 一种多链路数据传输方法及装置和存储介质
WO2019128467A1 (zh) 基于灵活以太网FlexE传输业务流的方法和装置
US20220200722A1 (en) Slot negotiation method and device
CN113452623B (zh) 基于FlexE传输业务流的方法及设备
US11838181B2 (en) Flexible ethernet group management method, device, and computer-readable storage medium
EP4072043A1 (en) Flexible ethernet overhead multiframe receiving method, apparatus, device, and medium
WO2019029286A1 (zh) 一种通信方法、设备及存储介质
WO2019076046A1 (zh) 传输路径配置方法、装置及设备
US20230388984A1 (en) Communication Method and Device, and Chip System
CN109981235B (zh) 一种FlexE Group协商方法及网元
EP2634978A1 (en) Message forwarding method and network device
WO2021129839A1 (zh) 接口信息的发送方法及设备
EP3823212A1 (en) Link capacity adjustment method and device
CN111447078A (zh) 一种基于组播协议的以太网热备热切换的冗余方法
EP3232617A1 (en) Protection switching method and system, and nodes
CN114760193A (zh) 一种主备协商方法及设备
EP2953294B1 (en) Protection switching method, system, and node
WO2023226878A1 (zh) 一种带宽调整方法、装置及存储介质
EP4344147A1 (en) Time slot negotiation method and apparatus
WO2023116284A1 (zh) 一种灵活以太网FlexE中小颗粒业务的时隙协商及装置
JP7478851B2 (ja) Ｏａｍメッセージ伝送方法、装置、関連機器及び記憶媒体
EP3979570A1 (en) Method for achieving network communication based on neighbor negotiation and device
CN112865899B (zh) 一种调整物理层phy主从模式的方法及装置
WO2023202565A1 (zh) 一种通信方法及装置

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 20862916

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2022516136

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

REG Reference to national code

Ref country code: BR

Ref legal event code: B01A

Ref document number: 112022004518

Country of ref document: BR

ENP Entry into the national phase

Ref document number: 2020862916

Country of ref document: EP

Effective date: 20220330

ENP Entry into the national phase

Ref document number: 112022004518

Country of ref document: BR

Kind code of ref document: A2

Effective date: 20220311