A bandwidth allocation method and device in flexe

Abstract

A bandwidth allocation method and device in FlexE, and relate to the technical field of network communication. The method is applied to an edge network. In a session of an automatic deployment process of each second device, the execution steps of a first device include: receiving a bandwidth configuration request message sent by a second device; judging whether the session identifier is legal; generating signature verification data of the session identifier in the bandwidth configuration request based on a preset root key after determining that the session identifier is legal; determining target bandwidth configuration information corresponding to the service of the second device in the FlexE connection between the second device and the first device after the signature data and the signature verification data are consistent; and configuring the bandwidth for the second device by using the target bandwidth configuration information. The method improves the security of FlexE bandwidth allocation without deploying a central controller.

Description

Technical Field

[0001] This article relates to the field of network communication technology, and in particular to a bandwidth allocation method and apparatus in FlexE. Background Technology

[0002] With the rapid development of technologies such as 5G, Industrial Internet, and edge computing, the network edge is placing higher demands on bandwidth flexibility, service isolation, and deployment efficiency. Flexible Ethernet (Flexible Ethernet) technology, through time slot cross-connection and bonding mechanisms, decouples the physical layer from the MAC layer, enabling the provision of hard-isolated dedicated channels for different services on a single physical link. It has become a key technology for carrying multi-service slices in edge networks.

[0003] In edge network scenarios, the network typically adopts a layered architecture, including a first device located on the core side (such as aggregation devices or Spine devices) and multiple second devices (such as access devices or Leaf devices) connected below it. Data transmission between the first and second devices is carried out through FlexE connections. Different services occupy different sub-time slots in the FlexE group to achieve deterministic bandwidth allocation and physical isolation between services.

[0004] However, in the existing FlexE bandwidth allocation method, the establishment of FlexE connections and bandwidth configuration mainly rely on the following two methods: one is to manually input configuration parameters on each device via command line, and then the operation and maintenance personnel log in to each device to perform operations such as FlexE group creation, PHY binding and time slot allocation; the other is to pre-configure and distribute the configuration through a centralized controller, and then push the configuration template to each device in batches after obtaining it.

[0005] Among the existing methods mentioned above, manual configuration suffers from low efficiency, long cycle, and error susceptibility when the number of edge network nodes is large and they are scattered. The centralized controller method relies on the real-time availability of the controller, which makes it difficult to guarantee the real-time performance and reliability of configuration when the edge network is often under weak control or when the controller has communication delays or single points of failure. Summary of the Invention

[0006] This application provides a bandwidth allocation method and apparatus in FlexE.

[0007] A bandwidth allocation method in FlexE, applied to an edge network, the edge network including a first device and at least one second device connected to the first device, wherein the first device and the second device transmit data via a FlexE connection, wherein each second device is configured to uniquely identify a session between the first device and the second device during automated deployment, wherein the session identifier is determined at least based on the geographical location information of the second device; in each session of the automated deployment process of the second device, the execution steps of the first device include: The device receives a bandwidth configuration request message sent by the second device, wherein the bandwidth configuration request message carries the session identifier and the signature data of the second device, wherein the signature data is obtained by encrypting the session identifier based on the shared key of the second device. Based on the parameter value corresponding to the mapping table entry of the session identifier in the second device, it is determined whether the session identifier is valid. After determining that the session identifier is valid, the signature verification data of the session identifier in the bandwidth configuration request is generated based on the preset root key. After the signature data is consistent with the signature verification data, the target bandwidth configuration information corresponding to the service of the second device in the FlexE connection between the second device and the first device is determined. The target bandwidth configuration information includes the physical port used by the second device and the time slot allocation strategy of each service of the second device. The target bandwidth configuration information is used to configure the bandwidth for the second device.

[0008] A bandwidth allocation method in FlexE, applied to an edge network, the edge network including a first device and at least one second device connected to the first device, wherein the first device and the second device transmit data via a FlexE connection, each second device is configured with a session identifier to uniquely identify a session between the first device and the second device during automated deployment, the session identifier being determined at least based on the geographical location information of the second device; in each session of the automated deployment process of the second device, the steps performed by the second device include: A configuration request message is sent, the configuration request message carrying the session identifier and the signature data of the second device; wherein the session identifier is used by the first device to determine whether the session identifier is valid, and the signature data is obtained by encrypting the session identifier based on the shared key of the second device; Obtain the target bandwidth configuration information determined by the first device. The target bandwidth configuration information is the bandwidth configuration information corresponding to the services of the second device in the FlexE connection between the second device and the first device, including the physical port used by the second device and the time slot allocation strategy for each service. The target bandwidth configuration information is used to configure the bandwidth for the second device.

[0009] A bandwidth allocation device in FlexE includes a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the method described above.

[0010] In this embodiment, by receiving a bandwidth configuration request message carrying session identifier and signature data, a data foundation is provided for subsequent security verification; by verifying the legality of the session identifier and determining the legality of the device based on the root key signature, bandwidth configuration is performed for the second device, thereby improving the security of FlexE bandwidth allocation without deploying a central controller.

[0011] Other features and advantages of this application will be set forth in the following description, and will be apparent in part from the description, or may be learned by practicing the application. Other advantages of this application can be realized and obtained by means of the embodiments described in the description and the accompanying drawings. Attached Figure Description

[0012] The accompanying drawings are used to provide an understanding of the technical solutions of this application and constitute a part of the specification. They are used together with the embodiments of this application to explain the technical solutions of this application and do not constitute a limitation on the technical solutions of this application.

[0013] Figure 1 A flowchart illustrating a bandwidth allocation method in FlexE provided in this application embodiment; Figure 2 This is a flowchart illustrating another bandwidth allocation method in FlexE provided in an embodiment of this application. Detailed Implementation

[0014] This application describes several embodiments, but these descriptions are exemplary and not limiting, and it will be apparent to those skilled in the art that many more embodiments and implementations are possible within the scope of the embodiments described herein. Although many possible combinations of features are shown in the drawings and discussed in the detailed description, many other combinations of the disclosed features are also possible. Unless specifically limited, any feature or element of any embodiment may be used in combination with, or may replace, any feature or element of any other embodiment.

[0015] This application includes and contemplates combinations of features and elements known to those skilled in the art. The embodiments, features, and elements disclosed in this application can also be combined with any conventional features or elements to form unique inventive solutions. Any feature or element of any embodiment can also be combined with features or elements from other inventive solutions to form another unique inventive solution. Therefore, it should be understood that any feature shown and / or discussed in this application can be implemented individually or in any suitable combination. Therefore, the embodiments are not limited except by the limitations imposed by the appended claims and their equivalents. Furthermore, various modifications and changes can be made within the scope of the appended claims.

[0016] Furthermore, in describing representative embodiments, the specification may have presented methods and / or processes as a specific sequence of steps. However, the method or process should not be limited to the specific order of steps described herein, to the extent that it does not depend on such a specific order. As will be understood by those skilled in the art, other sequences of steps are also possible. Therefore, the specific order of steps set forth in the specification should not be construed as a limitation of the claims. Moreover, the claims concerning the method and / or process should not be limited to the steps performed in the written order, and those skilled in the art will readily understand that these orders can be varied and still remain within the spirit and scope of the embodiments of this application.

[0017] The bandwidth allocation method in FlexE provided in this application is applicable to the automated deployment between a first device and at least one second device connected to it in an edge network scenario. The following description uses two typical network architectures as examples.

[0018] One scenario is a three-layer edge-aggregation-core networking system. In wide-area edge network scenarios such as 5G base station backhaul and industrial internet, the network is typically divided into a core layer, an aggregation layer, and an edge layer. Aggregation layer devices (such as aggregation switches and gateway devices) serve as the first layer, while edge layer devices (such as access switches, small base stations, and industrial gateways) serve as the second layer. A single first layer device typically connects to dozens to hundreds of second layer devices, distributed across different physical locations (such as factory workshops, base station sites, road poles, etc.), and connected directly to the first layer via fiber optic cables or high-speed Ethernet, or via transparent transmission equipment.

[0019] Another scenario is the Leaf-Spine networking system in a data center. In this data center network scenario, the Spine device acts as the primary device, and the Leaf device acts as the secondary device. Each Leaf device connects to multiple servers or storage nodes, and the Spine and Leaf devices are interconnected via high-speed Ethernet (such as 100GE / 400GE). The Leaf devices are distributed across different racks, server rooms, and even floors in the data center, with a large physical geographical span, but all of them need to establish FlexE hard slicing channels with the Spine devices to meet the isolation and carrying requirements of different tenants or different services (such as storage, computing, and AI training).

[0020] In the aforementioned edge network, after the installation and deployment of the second device are completed, the physical location of the second device is usually fixed.

[0021] In traditional automated deployment schemes, session identifiers are typically assigned and managed by a centralized controller or authentication server. However, in the weakly controlled environment of edge networks, centralized servers may experience communication latency or unreachability issues.

[0022] To address the aforementioned issues, this application proposes generating session identifiers based on the geographic location information of the second device, without requiring interaction with any external server. This decentralized generation method ensures that each second device has a unique session identifier during the automated deployment process, without the need for a central controller, thus guaranteeing the normal startup of the automated deployment process.

[0023] Optionally, to further enhance security and timeliness, the session identifier can also be generated by combining at least one of the following information: timestamp information corresponding to the geographic location information, hardware fingerprint of the second device (such as chip eFuse-ID), and random number assigned by the first device to the second device.

[0024] The role of each piece of information on which the session identifier depends is explained below: Geographic location information, as a physical attribute of the device, will not change due to network reconfiguration, device restart, or firmware upgrade. Using geographic location as a factor in generating session identifiers ensures that deployment sessions initiated by the same second device at different times all contain a consistent and verifiable physical location component in their session identifiers, providing a stable basis for identification of the first device.

[0025] Timestamp information, as a time coordinate, combined with address location as a spatial coordinate, can generate a unique spatiotemporal identifier for each session, enabling the first device to clearly distinguish different sessions on the same device and avoid configuration errors or replay attacks caused by session confusion.

[0026] Hardware fingerprints are unique identifiers embedded in the hardware during the chip manufacturing process, possessing device-level uniqueness. The combination of geographic location and hardware fingerprints ensures that even different second devices initiating a session at the same location and time can generate distinct session identifiers.

[0027] Random numbers possess the characteristics of one-time keying and expiration upon session expiration. Since geographical location and hardware fingerprints are inherent attributes of the second device and remain unchanged across multiple sessions, while timestamps can distinguish different times, they are susceptible to prediction or replay. Introducing a random number generated by the first device as a generation factor for the session identifier ensures that the second device must possess this random number to calculate the correct session identifier. This random number is only valid for the current session and expires immediately after the session ends, making it non-reusable. Therefore, even if an attacker intercepts all packets from a session, they cannot forge a legitimate session identifier in a new session, effectively preventing replay attacks and ensuring the independence and security of each automated deployment session.

[0028] The method for obtaining the session identifier is explained below: In one alternative implementation, the session identifier can be generated by an external system (such as a network management system or configuration tool) before the second device is deployed and pre-stored in the storage unit of the second device. After the second device is powered on, it directly reads the session identifier from the local storage unit for subsequent automated deployment sessions.

[0029] In another alternative implementation, the session identifier is dynamically generated through interactions between the second device and the first device. The complete interaction generation process includes the following steps: Step A1: The second device sends an initial position request message to the first device.

[0030] After the second device powers on and initializes, it first completes the PHY link connection, confirming that the optical module is in place and the link is connected. The second device then sends an initial location request message to the first device. This initial location request message carries the following information: device type identifier, hardware fingerprint eFuse-ID, timestamp information T_sat, and geolocation information G_sat.

[0031] Among them, the geographic location information G_sat is the geographic location information of the deployment location of the second device, and the timestamp information T_sat is the timestamp information when the geographic location information was obtained.

[0032] The initial location request message is sent via a link layer frame (such as an LLDP extended frame or a custom layer 2 frame).

[0033] Step A2: The first device generates and sends out a random number N. s .

[0034] After receiving the initial location request message from the second device, the first device does not perform location verification, but instead triggers its internal hardware true random number generator to generate a random number N. s And the random number N s The data is fed back to the second device via the original link layer frame. The dynamic random number N is... s It is only valid for the current second device and the current session, and expires immediately after the interaction is completed. It cannot be reused.

[0035] Step A3: The second device generates a session identifier and notifies the first device.

[0036] The second device receives the random number N sent by the first device. s Then, the hardware fingerprint eFuse-ID embedded in the chip is called, and the geographical location information G_sat, timestamp information T_sat, and random number N are used. s The hardware fingerprint eFuse-ID is concatenated in a fixed order, processed by a one-way hash algorithm to generate a session identifier, and then announced to the first device via a link message.

[0037] In one exemplary implementation, the session identifier is generated as follows: Session ID = SHA-256(G_sat || T_sat || N) s || eFuse-ID) In this context, "||" represents a bit concatenation operation.

[0038] Furthermore, considering the efficiency of subsequent message exchange length, the 32-byte sequence code obtained by the above SHA-256 operation can be further compressed using the MD5 algorithm to obtain a 16-byte session identifier.

[0039] Step A4: The first device establishes a mapping relationship table entry.

[0040] After receiving the session identifier from the second device, the first device establishes a mapping table entry locally. This mapping table entry records the physical port on the first device that received the message from the second device, the geographical location information G_sat, the timestamp information T_sat, and the random number N. s The mapping between session identifiers is established so that session identifier verification can be performed in automated deployments.

[0041] The session identifier obtained through the above interactive generation method has device uniqueness, session uniqueness, and timeliness, and can uniquely identify an automated deployment session between the first device and the second device.

[0042] The following explains how bandwidth is allocated based on session identifiers during automated deployment.

[0043] This application provides a bandwidth allocation method in FlexE. The core of this method is to deeply embed geographic location information into the security verification process of FlexE bandwidth allocation, so that the allocation of bandwidth resources is bound to the physical installation location of the device, thereby improving the accuracy and security of bandwidth allocation.

[0044] See Figure 1 The bandwidth allocation method in FlexE provided in this application embodiment, applied to a first device, specifically includes the following steps in each session of the automated deployment process of the second device: Step 101: Receive the bandwidth configuration request message sent by the second device.

[0045] The bandwidth configuration request message carries key information for security verification and region determination. Specifically, it includes a session identifier and signature data from the second device. The signature data is obtained by encrypting the session identifier using the second device's shared key, and is used by the first device to verify the authenticity and integrity of the session identifier.

[0046] In this step, the first device obtains the session identifier and signature data required for verification during the bandwidth allocation operation by receiving the bandwidth configuration request message.

[0047] Step 102: Generate signature verification data for the session identifier in the bandwidth configuration request based on the preset root key. After the signature data matches the signature verification data, if the address location information corresponding to the session identifier in the bandwidth configuration request is in the reference geographical area of ​​the first device, determine the target bandwidth configuration information corresponding to the service of the second device in the FlexE connection between the second device and the first device.

[0048] The target bandwidth configuration information includes the physical ports used by the second device and the time slot allocation strategy for each service of the second device; In this step, the first device ensures the authenticity and integrity of the session identifier through signature verification, and ensures that the second device is located in a legitimate deployment area through geographical region judgment. After the dual verification is passed, the target bandwidth configuration information is automatically determined.

[0049] Specifically, this step includes steps 121 to 123.

[0050] Step 121: Identifier Validity Verification. The first device determines whether the session identifier is valid based on the parameter value corresponding to the mapping entry of the session identifier in the second device's corresponding mapping table. If the session identifier is valid, it indicates that bandwidth allocation to the second device corresponding to the session identifier is allowed; otherwise, it indicates that bandwidth allocation to the second device corresponding to the session identifier is not allowed.

[0051] Step 122: Signature Verification. The first device, based on a preset root key, performs signature verification calculation on the session identifier carried in the bandwidth configuration request message, generating verification data. The generated verification data is compared with the signature data carried in the message. If they match, it indicates that the session identifier has not been tampered with during transmission and was indeed generated by the second device holding the corresponding shared key; verification passes. If they do not match, the message is discarded or further processing is rejected.

[0052] Step 123: Determine the target bandwidth configuration information. After the identity validity and signature verification are both passed, the first device determines the target bandwidth configuration information corresponding to the services of the second device in the FlexE connection between the second device and the first device. The target bandwidth configuration information includes the physical port used by the second device and the time slot allocation strategy for each service of the second device. Among them, the physical port is used to specify the physical interface carrying the FlexE connection; the time slot allocation strategy is used to specify the sub-time slot range occupied by each service in the FlexE Shim layer calendar time slot table.

[0053] This step verifies the legitimacy of the session identifier through the mapping relationship table entries, which can reject illegal requests; the signature verification ensures the authenticity of the configuration request source, preventing unauthorized devices from accessing the site by forging identities. This constitutes a verification mechanism for the legitimacy of the identifier and identity authentication, thereby improving the security of bandwidth allocation operations.

[0054] Step 103: Configure the bandwidth for the second device using the target bandwidth configuration information.

[0055] In this step, the first device applies the determined target bandwidth configuration information to the second device to complete the bandwidth allocation for the FlexE connection.

[0056] The method provided in this application provides a data foundation for subsequent security verification by receiving a bandwidth configuration request message carrying session identifier and signature data; by verifying the legality of the session identifier and determining the legality of the device based on the root key signature, bandwidth configuration is performed for the second device after the dual verification is passed, so that the allocation of bandwidth resources is bound to the physical location of the device, thereby improving the security of FlexE bandwidth allocation without deploying a central controller.

[0057] In edge network scenarios, after the second device completes automated deployment and establishes a FlexE connection, its service traffic is transmitted through the physical hard pipe of the FlexE Shim layer. Since FlexE provides a physically isolated hard channel, service traffic is directly scheduled and forwarded at the Shim layer according to a calendar time slot table, bypassing upper-layer security devices such as firewalls or access control lists. While this approach ensures deterministic bandwidth and low latency, it also introduces security vulnerabilities: if the second device is illegally moved to an unauthorized area, the established FlexE channel can still continue transmitting service data, potentially leading to data leakage. Therefore, a real-time security control mechanism based on geographical location changes needs to be established at the FlexE physical layer.

[0058] Therefore, the embodiments of this application propose the following solution: After the target bandwidth configuration information takes effect, if the geographical location of the second device changes and the changed geographical location deviates from the fence area corresponding to the second device, then the bandwidth configuration information controlling at least some services in the second device will become invalid.

[0059] In this solution, the fenced area is a geographically defined area within the baseline geographic area, specifically designated for each second device, used for location offset monitoring during the operational phase. The baseline geographic area is a pre-defined geographic area within the first device, used for access legitimacy verification during the automated deployment phase. The fenced area is located within the baseline geographic area, and its extent is typically smaller than or equal to the baseline geographic area.

[0060] The geographical location of the second device can be obtained through the satellite positioning module (such as the Beidou positioning module or the GPS module) built into the second device.

[0061] In one specific implementation, geographic location monitoring and offset determination can be performed by the second device itself. The second device periodically obtains its own real-time geographic location coordinates and compares them with the fenced area range pre-stored locally or issued by the first device. When the real-time coordinates exceed the fenced area, the second device proactively performs invalidation processing on its local service bandwidth configuration information.

[0062] In another specific implementation, geolocation monitoring and offset determination can be performed by the first device. The second device periodically reports its real-time geolocation information to the first device, which compares it with the fenced area corresponding to the second device stored locally. When an offset is determined, the first device issues a failure control command to the second device, and the second device performs failure handling of the service bandwidth configuration information according to the command.

[0063] When managing bandwidth, the bandwidth configuration information corresponding to the service channel carrying data services (such as industrial control data and video backhaul data) can be invalidated, while the bandwidth configuration information corresponding to the management channel carrying management messages can be retained. This can cut off the transmission of sensitive service data and prevent unauthorized areas from sending and receiving service data through the established FlexE channel, while maintaining the connectivity of the management channel, so that network administrators can still perform remote diagnostics, location tracking and security auditing of the device.

[0064] This application provides three optional control methods, all of which are based on directly manipulating the hardware mechanism of the FlexEShim layer to prevent the sub-time slots carrying service data from continuing to transmit data at the physical layer, thereby achieving precise blocking of the service channel.

[0065] Method 1: Delete the time slot allocation information corresponding to the service or delete the physical port used by the service.

[0066] The Calendar Bitmap in the FlexE Shim layer is the core mapping table that determines which client interface each sub-slot belongs to. Within each clock cycle, the FlexE scheduler sends the data for each sub-slot to the corresponding client interface sequentially, according to the configuration of the Calendar Bitmap.

[0067] Specifically, each sub-slot in the calendar slot table stores a Client ID. After reading this Client ID, the scheduler sends the data of the current sub-slot to the corresponding Client's client-side interface. If the Client ID stored in a sub-slot is modified to a non-existent Client ID, or if the mapping bit of the corresponding physical interface in the slot mapping is cleared, the scheduler will not be able to find a valid Client mapping when polling that sub-slot. The data in that sub-slot will be discarded by the hardware and will not be sent to any Client interface.

[0068] Similarly, if the physical port carrying the service is directly removed from the binding list of the FlexE group, all sub-time slots corresponding to the physical port will be removed from the calendar time slot table, the scheduler will no longer schedule these sub-time slots, and the service data will be completely blocked at the physical layer.

[0069] This method decouples service time slots from scheduling at the scheduling level, allowing them to be completed independently without relying on the cooperation of peer devices, and has the advantage of being easy to operate.

[0070] Method 2: Set the remote fault indication bit in the physical interface overhead corresponding to the service time slot.

[0071] The FlexE standard defines the Remote PHYFault (RPF) bit in the overhead frame to transmit link failure information at the physical layer.

[0072] Specifically, each PHY in the FlexE overhead frame corresponds to a set of overhead fields, which includes an RPF indicator bit. When this bit is set, it indicates that the PHY has detected a remote fault. After receiving this indication, the receiver on the link side will mark all time slots of the corresponding PHY as faulty and will no longer extract data from these time slots.

[0073] In this method, the device actively sets the RPF bit in the physical interface overhead corresponding to the target service timeslot to simulate a remote fault signal. After receiving this overhead frame, the peer device automatically marks all sub-time slots of the corresponding PHY as failed according to the processing logic of the FlexE standard protocol, thereby cutting off the transmission of service data.

[0074] This method utilizes the existing fault propagation mechanism of the FlexE standard, without requiring modification to the calendar time slot table structure, making it relatively simple to implement, and the peer device can automatically detect the fault status.

[0075] Method 3: Modify the overhead frame content corresponding to the service time slot without updating the CRC check field.

[0076] The integrity of FlexE overhead frames relies on the Cyclic Redundancy Check (CRC) mechanism. When constructing an overhead frame, the sender calculates the CRC value based on the frame content and fills it into the check field. After receiving the overhead frame, the receiver recalculates the CRC value and compares it with the value in the check field. If the two do not match, the receiver determines that an error has occurred in the overhead frame during transmission and discards the configuration information corresponding to the overhead frame.

[0077] Specifically, the FlexE overhead frame carries the configuration parameters of the FlexE group, including the mapping relationship of the calendar time slot table. The receiving end will only apply the configuration parameters carried in the overhead frame to its local scheduler after the overhead frame passes CRC verification.

[0078] In this approach, the device intentionally modifies the overhead frame content corresponding to the target service time slot (e.g., changing the values ​​of some fields), but intentionally fails to update the checksum value in the CRC check field. Thus, when the receiver receives this overhead frame, the recalculated CRC value will be inconsistent with the original value in the checksum field, resulting in a checksum failure. According to the processing logic of the FlexE standard protocol, the receiver will determine that the overhead frame is invalid, the configuration of the corresponding time slot will not be adopted, and the scheduler will not extract data from these time slots, thereby achieving failure control of the service time slot.

[0079] This method indirectly causes time slot failure by disrupting the protocol verification mechanism. It does not require modification of the standard data structure, making it relatively covert. Moreover, the peer device can automatically complete the failure determination at the protocol level.

[0080] In actual deployment, one or more of the above methods can be selected and used in combination, depending on the equipment hardware capabilities and security policy requirements. Regardless of the method used, the common technical effect is to precisely cut off the transmission channel of sensitive business data at the physical layer, while not affecting the time slot configuration of the management channel, thus achieving precise isolation of business slices and complete preservation of management slices.

[0081] In an optional implementation, in step 102, after signature verification and geographical region determination are passed but before determining the target bandwidth configuration information, the first device also needs to perform a compatibility check between the second device's FlexE capability set and the first device's FlexE capability set, and send the check result back to the second device via an Acknowledge (ACK) message. The specific process is as follows: The first device compares the second device's FlexE capability set with its local FlexE capability set to confirm whether the two devices are compatible in key capability parameters. This compatibility check includes: whether there is an overlap in the maximum group rates supported by both devices, whether there is an overlap in the sub-slot granularity supported by both devices, and whether the two devices are consistent in terms of lossless handover capabilities.

[0082] If the capability compatibility check passes, the first device replies to the second device with an ACK packet indicating successful verification. The payload of this ACK packet contains verification result information (result info), with a value of 0x00, indicating successful verification. Upon receiving this ACK packet, the second device confirms the capability compatibility of both devices and awaits the target bandwidth configuration information subsequently sent by the first device.

[0083] If the capability compatibility check fails, the first device replies to the second device with an ACK packet indicating capability incompatibility. The payload of this ACK packet contains verification result information, with a value of 0x02, indicating a resource mismatch. Upon receiving this packet, the second device can adjust its configuration parameters or report an anomaly based on the specific reason for the incompatibility.

[0084] Furthermore, if, during the aforementioned geographic region determination phase, the first device determines that the geographic location corresponding to the second device's session identifier is not within the baseline geographic region, the first device will reply to the second device with an ACK packet indicating an invalid geographic location. The verification result information in the payload of this ACK packet will be 0x01, indicating an invalid address location. The first device may reject the second device's bandwidth allocation request, or allocate only limited management bandwidth to it.

[0085] If other abnormal situations occur, the first device will reply to the second device with an ACK message containing a verification result value of 0x03, indicating other types of errors.

[0086] The aforementioned ACK message is sent from the first device to the second device in unicast format. Through this ACK feedback mechanism, the second device can promptly obtain the processing status of the first device's bandwidth configuration request, including verification success, invalid geographical location, resource mismatch, or other abnormal situations. Based on different feedback results, the second device can take corresponding processing measures, improving the transparency and reliability of the automated deployment process.

[0087] The prerequisites for determining the target bandwidth configuration information in step 102 are explained below: The determination of the legality of the identifier in step 121 is obtained through the following methods: After receiving the bandwidth configuration request message, the first device first looks up the parameter value corresponding to the session identifier in the mapping table stored locally based on the session identifier carried in the message, and then determines whether to allow bandwidth to be allocated to the second device corresponding to the session identifier based on the parameter value.

[0088] The mapping table entry is established by the first device during the session identifier generation phase and is used to record key information related to the session identifier. This mapping table entry records at least one of the following: the base port for receiving the session identifier, the input values ​​used to generate the session identifier, and the generation strategy. The base port for receiving the session identifier refers to the physical port used by the first device when receiving the session identifier announced by the second device during the session identifier generation phase. The input values ​​and generation strategy used to generate the session identifier refer to the original input parameters used to calculate the session identifier and the generation algorithm employed.

[0089] Depending on the parameter value, the verification in this step includes the following two methods.

[0090] Method 1: Port Consistency Verification. When the parameter value recorded in the mapping table is the base port for receiving the session identifier, the first device will compare the physical port on which it receives the current bandwidth configuration request message with the base port recorded in the mapping table. If the current receiving port matches the base port, it indicates that the bandwidth configuration request message was received from the same physical link as during initial registration, and no port drift or bypass access has occurred. Therefore, bandwidth allocation to the second device corresponding to the session identifier is permitted. If the current receiving port does not match the base port, it indicates that the session identifier may be replayed on other ports by unauthorized devices, posing a security risk. The first device will refuse to allocate bandwidth to the second device.

[0091] Method 2: Baseline Identifier Comparison and Verification. When the parameter value recorded in the mapping table is the input value and generation strategy used to generate the session identifier, the first device processes the input value according to the generation strategy and recalculates a baseline identifier. The first device compares the calculated baseline identifier with the session identifier carried in the bandwidth configuration request message. If they match, it indicates that the session identifier was indeed generated through a legitimate interaction process and completely matches the local record, thus allowing bandwidth allocation to the second device corresponding to the session identifier. If they do not match, it indicates that the session identifier did not go through a legitimate interaction process, and the first device refuses to allocate bandwidth.

[0092] Through the above verification based on mapping table entries, the first device can quickly filter out illegal session identifiers that do not match the mapping table entries, or detect abnormal access behaviors such as port drift, before entering the subsequent signature verification stage, thereby improving the efficiency and level of security verification.

[0093] In addition, after completing the signature verification, step 124 can be executed.

[0094] Step 124: Geographical Region Determination. After successful signature verification, the first device determines whether the geographic location corresponding to the session identifier is within a preset baseline geographic area. This baseline geographic area is a legal geographical range pre-configured by the first device that allows the second device to access and allocate bandwidth. If the geographic location corresponding to the session identifier is within the baseline geographic area, the determination is successful; otherwise, the first device rejects bandwidth allocation or only allocates limited management bandwidth.

[0095] Through steps 121, 122, and 124 above, this embodiment of the application constructs a multi-layered security verification mechanism encompassing pre-verification of mapping relationship entries, signature verification, and geographical region determination. Specifically, it utilizes locally stored baseline ports or generation strategies to quickly verify the legitimacy of session identifiers, rejecting illegal requests that do not match mapping entries and effectively preventing port drift attacks. It also ensures the authenticity and integrity of session identifiers based on cryptographic mechanisms. Geographical region determination binds bandwidth resource allocation to the physical installation location of devices, ensuring that only devices located within legitimate areas can obtain service bandwidth configurations.

[0096] The following explains how to determine the target bandwidth configuration information in steps 1, 2, and 3.

[0097] In one optional implementation, the first device can directly determine the target bandwidth configuration information based on preset information. Specifically, the first device pre-stores the correspondence between the second device and the target bandwidth configuration information. After the second device passes signature verification and geographical region determination, the first device searches for the matching target bandwidth configuration information in the preset correspondence based on the second device's session identifier or device identifier. This includes the physical port that the second device should use and the time slot allocation strategy for each service. This method is suitable for scenarios where the network topology and service requirements are relatively fixed, and the type and deployment location of the second device are regular. The configuration process is the simplest and most efficient.

[0098] In another optional embodiment, the target bandwidth configuration information can be dynamically determined based on the target capability set supported by both the first and second devices, as well as the service requirements of the second device. This approach can adapt to deployment scenarios where there are differences in hardware capabilities and diverse service requirements between the first and second devices, offering better flexibility and compatibility. Target configuration information can be provided based on preset information.

[0099] This method includes steps 1231 and 1232.

[0100] Step 1231: Based on the FlexE capability set of the second device and the FlexE capability set of the first device, determine the target capability set that both the first device and the second device can support.

[0101] The FlexE capability set describes the device's hardware support capabilities for FlexE technology. In this embodiment, the FlexE capability set includes at least one of the following: Maximum supported Group rate: Indicates the maximum transfer rate of the FlexE Group supported by the device, such as 50G, 100G, 200G or 400G; Supported Sub-slot Granularity: Indicates the smallest sub-slot granularity supported by the device in the FlexE Shim layer calendar slot table, such as 1G or 5G; Hitless Adjustment: Indicates whether the device supports dynamically adjusting the member configuration or time slot allocation of the FlexE group without interrupting services.

[0102] Step 1232: Determine the target bandwidth configuration information based on the target capability set and the service requirement information of the second device.

[0103] The service requirement information describes the types of services the second device needs to support and their bandwidth resource requirements. In this embodiment, the service requirement information may include the identification information of the service template requested by the second device. This service template is one of multiple pre-configured service templates in the first device, and each service template defines the FlexE bandwidth configuration strategy required for a certain type of service (such as low-latency industrial control, high-definition video backhaul, etc.).

[0104] Based on the service requirements information of the second device, the first device determines the corresponding target service template from a set of preset service templates. Under this target service template, corresponding bandwidth configuration information is preset for different capability sets. Based on the target capability set determined in the preceding steps, the first device searches for bandwidth configuration information matching the target capability set under this target service template, and uses this as the target bandwidth configuration information. This target bandwidth configuration information includes the physical ports used by the second device and the time slot allocation strategy for each service.

[0105] When the first device receives a bandwidth configuration request message from the second device, it retrieves the second device's FlexE capability set carried in the message. The first device compares the second device's FlexE capability set with its own FlexE capability set, and takes the intersection of various capability parameters as the target capability set that both devices can support. For example, if the second device supports maximum group rates of 100G and 200G, and the first device supports maximum group rates of 200G and 400G, then the target capability set supports a maximum group rate of 200G; if the second device supports sub-slot granularities of 1G and 5G, and the first device supports a sub-slot granularity of 5G, then the target capability set supports a sub-slot granularity of 5G.

[0106] In the above approach, the FlexE capability set and service requirement information play different roles in determining the target bandwidth configuration information, and the two work together to complete the matching from hardware capabilities to service strategies.

[0107] The methods for obtaining at least one of the FlexE capability set and business requirement information of the second device include: In one alternative implementation, at least one of the FlexE capability set and business requirement information of the second device can be pre-stored in the first device before the second device is deployed.

[0108] Specifically, when planning an edge network, network administrators can pre-configure the FlexE capability sets and service requirements information of each second device in the local storage unit of the first device, and establish a mapping relationship between the device identifier, session identifier, FlexE capability set, and service requirements information of the second device. When a second device initiates an automated deployment session, after completing the signature verification of the session identifier and the geographical region determination, the first device searches for the FlexE capability set and service requirements information of the second device in the pre-stored mapping relationship based on the session identifier or device identifier of the second device.

[0109] This approach is suitable for deployment scenarios where the network topology and business requirements are relatively fixed. The capability information and business requirements of the second device are already clear before deployment, eliminating the need for real-time negotiation during automated deployment and making the configuration process more efficient.

[0110] In another alternative implementation, at least one of the second device's FlexE capability set and service requirement information is carried and sent by the second device to the first device via a bandwidth configuration request message. For example, the service requirement information may be the identification information of the target service template requested by the second device.

[0111] This approach is suitable for deployment scenarios where the hardware capabilities of the second device differ and business requirements are diverse. Real-time reporting via message transmission allows the first device to dynamically adapt to the actual capabilities of the second device, offering excellent flexibility.

[0112] In one preferred implementation, the target bandwidth configuration information is automatically determined based on the combination and matching mechanism of service templates and capability sets.

[0113] The first device has at least two pre-set service templates, each corresponding to the FlexE bandwidth configuration policy required for a specific service type. These service templates are pre-configured by the network administrator based on the service needs of different geographical areas in the edge network before deployment.

[0114] Before automated deployment, the first device has at least one service template pre-set. Each service template defines a FlexE bandwidth configuration policy for a certain type of business scenario and associates the policy with the corresponding FlexE configuration template parameters.

[0115] Based on the aforementioned three-layer nested structure, the configuration parameters of each business template are divided into the Group layer, the Physical (PHY) layer, and the Client layer.

[0116] At the Group layer, the service template includes the following preset attributes: FlexE Group ID, a global identifier for the FlexE group used to uniquely identify a FlexE group object between the first and second devices; Group Number, an internal number for the FlexE group used for local management and configuration reference within the device; and Time Slot Allocation Mode, indicating whether the FlexE group uses dynamic or static time slot allocation. These Group layer attributes are preset by the service strategy of the service template and do not change with variations in the hardware capability set.

[0117] At the PHY layer, the business template defines the list of physical interfaces bound to the FlexE group, including the number of bound interfaces and each physical interface item. Each physical interface item contains two subfields: Physical Interface ID and PHY Number. The values ​​of the number of bound interfaces and the specific physical interface item are determined by the maximum Group rate supported by the target capability set, and these parameters differ across different capability set versions.

[0118] At the Client layer, the business template defines the list of clients hosted by the FlexE group, including the number of clients and each client entry. Each client entry contains a Client ID (client global identifier), a Client Number (client internal number), a bandwidth mode (dynamic or static), and a time slot bitmap (in static mode, indicating the range of sub-time slots occupied by the client in the calendar time slot table). The number of clients, Client ID, Client Number, and bandwidth mode are preset by the business strategy of the business template and do not change with the capability set; however, the specific values ​​of the time slot information are determined by the sub-slot granularity of the target capability set and the client's business bandwidth requirements. The range of the time slot bitmap differs across capability set versions. Specifically, in dynamic mode, the time slot information represents the bandwidth size; in static mode, it corresponds to the time slot bitmap occupied by the client in the calendar time slot table.

[0119] When setting up the template, one of the Clients is fixed as the management channel template, and a separate sub-time slot is allocated to carry management messages. For example, the Client item with Client ID 0xFF is used as the management channel and a separate time slot bitmap is allocated. This design enables time slot-level isolation between the management channel and the service channel at the physical layer, providing a foundation for subsequent geofencing security controls (such as retaining the management channel and cutting off the service channel).

[0120] Since the same service requirement requires different configuration parameters under different hardware capabilities, the first device presets multiple sets of bandwidth configuration information corresponding to the same service template under different capability sets when presetting the service template.

[0121] For example, taking service template ID 0x001 (low-latency industrial control) as an example, the service strategy of this template is: the industrial control service bandwidth requirement is 100Mbps, an independent management channel of 10Mbps is required, and a static time slot allocation mode is adopted. The Group layer is preset with FlexE Group ID 1, Group Number 1, and time slot allocation mode as static; the Client layer is preset with two Clients, Client 0x01 is the industrial control service channel, and Client 0xFF is the management channel.

[0122] For this service template, the first device has two pre-set capability set versions: In capability set version A (maximum group rate 100G, sub-slot granularity 5G, supports lossless switching), since the single PHY rate is 50G, two PHYs need to be bound to achieve a total rate of 100G. The number of binding interfaces in the PHY layer is 2, and the specific physical interface items are allocated according to the actual ports. In the Client layer, each Client is configured with a corresponding number of time slots.

[0123] In capability set version B (maximum group rate 400G, sub-slot granularity 1G, supports lossless switching), since the single PHY rate is 100G, four PHYs need to be bound to achieve a total rate of 400G. The number of binding interfaces in the PHY layer is four. In the Client layer, each Client is configured with a corresponding number of time slots.

[0124] Therefore, under the same business template, the Group ID, Group Number, time slot allocation mode, number of Clients, Client ID, Client Number, and bandwidth mode remain unchanged; while the number of interfaces bound to the PHY layer, physical interface items, and the time slot bitmap of the Client layer automatically adapt to different capability set versions.

[0125] In step 1232, the first device finds the required configuration information based on the matched capability sets of both parties through the following steps, specifically including: Step 1232A: Based on the service requirement information of the second device, determine the target service template corresponding to the second device in the service template of the first device.

[0126] The first device obtains the service template ID carried by the second device from the bandwidth configuration request message, and matches the corresponding target service template in the local preset service template library.

[0127] Step 1232B: Determine the target bandwidth configuration information corresponding to the target capability set based on the bandwidth configuration information corresponding to different capability sets under the target service template.

[0128] The first device uses the target capability set as an index to search for bandwidth configuration information that matches the target capability set among multiple preset capability set versions under the target service template.

[0129] The search process is an exact match: each parameter in the target capability set (maximum group rate, sub-slot granularity) is compared one by one with the corresponding parameters of each preset capability set version. Once a version that matches exactly is found, all configuration parameters for that version are extracted.

[0130] Since the Group layer attributes (FlexE Group ID, Group Number, time slot allocation mode) and some attributes of the Client layer (Client quantity, Client ID, Client Number, bandwidth mode) of the target business template do not change with the capability set, these fields are directly inherited from the target business template. However, the number of bound interfaces and specific physical interface items in the PHY layer, as well as the time slot bitmap in the Client layer, are extracted from the matched capability set version.

[0131] The first device combines the fixed parameters inherited from the target service template and the variable parameters extracted from the matching capability set version to generate complete target bandwidth configuration information.

[0132] If the first device does not find a template in its local preset service template library that completely matches the service template ID carried by the second device, the first device can generate a minimum common configuration set based on the service requirements and capabilities of all participating devices. Specifically, the first device extracts key parameters (such as bandwidth requirements and latency levels) from the second device's service requirement information, combines them with the capability range of each locally preset service template, determines a minimum common configuration set that can best meet the service requirements, and generates a complete FlexE service configuration template based on the parameter relationship between the preset services and the FlexE configuration template, which serves as the target bandwidth configuration information.

[0133] Using the above method, the first device can automatically and accurately locate the bandwidth configuration information that matches the current hardware conditions from among multiple preset configurations.

[0134] The following explains the process of the target bandwidth configuration information taking effect in step 103.

[0135] In one optional implementation, the first device sends the target bandwidth configuration information to the second device, enabling the second device to configure the FlexE Shim layer parameters according to this information, including physical port binding and time slot allocation in the calendar time slot table. After the second device completes the configuration, the FlexE connection between the first and second devices transmits data according to the target bandwidth configuration information, with different services occupying different sub-time slots, achieving hard isolation and deterministic bandwidth allocation. This process requires no manual intervention, significantly reducing the configuration workload and error probability during large-scale edge network deployments.

[0136] In another alternative implementation, step 103 includes steps 131 to 133. Wherein: Step 131: Send a configuration announcement message carrying the target bandwidth configuration information to the second device.

[0137] The target bandwidth configuration information includes the physical ports used by the second device and the time slot allocation policy for each service. The first device encapsulates this target bandwidth configuration information into a configuration announcement message and sends it to the second device in unicast form.

[0138] Step 132: The first device receives a configuration confirmation message sent by the second device, which carries a verification result.

[0139] After receiving the configuration notification message, the second device performs a matching and verification of the target bandwidth configuration information based on its local resources. This verification process includes: confirming whether there are any conflicts with the FlexE Group ID locally; confirming whether the specified physical interface and PHY are available locally; confirming whether the Client ID is within the locally supported range; and confirming whether the allocation of the time slot bitmap matches the capacity of the local calendar time slot table. Based on the verification results, the second device generates a configuration confirmation message and sends it to the first device.

[0140] The first device receives the configuration confirmation message, parses out the verification result, and determines whether the local resources of the second device match the target bandwidth configuration information.

[0141] Step 133: When the verification result indicates that the match is successful, the first device sends a configuration execution message to the second device to indicate that the target bandwidth configuration information has taken effect.

[0142] After the first device sends the configuration execution message, it immediately completes the local configuration switch and writes the target bandwidth configuration information into its local FlexE Shim layer hardware. Upon receiving the configuration execution message, the second device immediately follows the actions of the first device, writing the target bandwidth configuration information into its local FlexE Shim layer hardware, including physical port binding and time slot mapping of the calendar time slot table, thus completing the configuration distribution.

[0143] If the verification result indicates a resource conflict or unsupported parameters, the first device may not send a configuration execution message. Instead, it may adjust the target bandwidth configuration information according to the specific indication of the verification result and re-initiate the configuration notification process, or record an error log.

[0144] This approach avoids configuration failures or service interruptions caused by mismatches between configuration parameters and device capabilities by introducing a local resource verification and confirmation feedback mechanism on the second device. The first device can confirm the feasibility of the configuration based on the feedback from the second device before the configuration officially takes effect, thus improving the reliability and success rate of configuration distribution.

[0145] In one optional implementation, the verification process performed by the second device after receiving the configuration notification message includes steps B1 to B4.

[0146] Step B1: The second device performs integrity and security verification on the configuration announcement message. Integrity verification confirms that the message has not been tampered with during transmission; security verification includes verifying the message source and signature to ensure that the configuration announcement message originates from the legitimate first device.

[0147] Step B2: After successful verification, the second device parses the target bandwidth configuration information in the configuration announcement message and extracts key parameters, including FlexE Group ID, time slot allocation mode, list of bound physical interfaces, and configuration parameters of each Client.

[0148] Step B3: The second device checks the compatibility of the target bandwidth configuration information with local resources. Specifically, this includes: confirming whether there is a conflict with the FlexE Group ID locally, confirming whether the specified physical interface and PHY are available locally, confirming whether the Client ID is within the locally supported range, and confirming whether the allocation of the time slot bitmap matches the capacity of the local calendar time slot table.

[0149] Step B4: The second device generates a status code based on the verification result and encapsulates it in a configuration confirmation message. The message type identifier for the configuration confirmation message is 0x04, and the message payload includes a status code field. A status code value of 0x00 indicates successful pre-configuration, 0x01 indicates a resource conflict, and 0x02 indicates that the parameter is not supported.

[0150] After receiving the configuration confirmation message, the first device parses the status code. If the status code is 0x00, it proceeds to the configuration execution step; if the status code is 0x01 or 0x02, the first device can adjust the target bandwidth configuration information according to the status code and re-initiate the configuration notification process, or record an error log.

[0151] In one optional implementation, the message payload of the configuration execution message includes an execution indicator bit and a calendar selection indicator bit. The execution indicator bit indicates whether to execute the configuration switch; a value of 1 indicates execution, and a value of 0 indicates no execution. The calendar selection indicator bit indicates whether to select calendar 1 or calendar 2 for the configuration to take effect; a value of 0 selects calendar 1, and a value of 1 selects calendar 2. By alternating between calendar 1 and calendar 2, a seamless switch can be achieved during configuration updates, ensuring the continuity of business traffic.

[0152] After sending the configuration execution message, the first device immediately completes the local configuration switch and writes the target bandwidth configuration information into its local FlexE Shim layer hardware. Upon receiving the configuration execution message, the second device immediately follows the actions of the first device and writes the target bandwidth configuration information into its local FlexE Shim layer hardware, including physical port binding and time slot mapping of the calendar time slot table.

[0153] Optionally, after the configuration is distributed, the first and second devices can each start self-healing monitoring to verify the FlexE configuration status on their respective ends, ensuring that the configuration has taken effect correctly and that the connectivity between the two ends is normal.

[0154] Specifically, the first step is to perform an alarm check. The device checks for any abnormal alarms in the local FlexE group and Client status. Abnormal alarms include PHY negotiation errors, inconsistent Client Numbers, and inconsistent timeslots. Simultaneously, it confirms that the link status of each Client is normal. If an abnormal alarm occurs, the configuration verification is deemed to have failed, and a state rollback is triggered directly.

[0155] Secondly, a continuity check is performed. The device sends a CCM (Continuity Check Message) to verify end-to-end connectivity via the FlexE OAM mechanism. If no CCM response is received from the other end within a specified time (e.g., 5 seconds), the connectivity verification is deemed to have failed, triggering an alarm.

[0156] If connectivity verification fails, the device automatically performs a configuration rollback, reverting the local FlexE configuration to its initial Ethernet mode state, restoring the port state before the configuration was issued, and reporting the error log. If connectivity verification succeeds, the FlexE connection between the first and second devices enters normal operation, and each service transmits data according to the allocated time slots.

[0157] See Figure 2 The bandwidth allocation method in FlexE provided in this application embodiment is applied to a second device, and specifically includes the following steps in each session of the automated deployment process of the second device: Step 201: Send a bandwidth configuration request message.

[0158] In this step, the second device sends a bandwidth configuration request message to the first device. This message carries key information for security verification and area determination. Specifically, the bandwidth configuration request message carries a session identifier and the second device's signature data. The signature data is obtained by encrypting the session identifier using the second device's shared key, and is used by the first device to verify the authenticity and integrity of the session identifier.

[0159] By sending the bandwidth configuration request message, the second device provides its own session identifier and signature data to the first device, enabling the first device to perform identifier validity verification and region determination, thus providing a basis for subsequent bandwidth configuration decisions.

[0160] Step 202: Obtain the target bandwidth configuration information determined by the first device.

[0161] The target bandwidth configuration information refers to the bandwidth configuration information corresponding to the services of the second device in the FlexE connection between the second device and the first device, including the physical port used by the second device and the time slot allocation strategy for each service. The physical port specifies the physical interface carrying the FlexE connection; the time slot allocation strategy specifies the range of sub-time slots occupied by each service in the FlexE Shim layer calendar time slot table.

[0162] The target bandwidth configuration information is determined by the first device after completing the signature verification of the session identifier and the geographical region determination. Specifically, after receiving the bandwidth configuration request message, the first device verifies the session identifier based on the preset root key. After the signature verification is successful, it determines whether the geographical location corresponding to the session identifier is located within the preset baseline geographical region of the first device. After both verifications are successful, the target bandwidth configuration information is automatically determined and sent to the second device.

[0163] In this step, the second device obtains the target bandwidth configuration information determined by the first device after dual verification, thus binding the allocation of bandwidth resources to the physical installation location of the second device, ensuring that only devices located within the legal area can obtain the corresponding service bandwidth configuration.

[0164] Step 203: Configure the bandwidth for the second device using the target bandwidth configuration information.

[0165] In this step, the second device uses the acquired target bandwidth configuration information to configure its own bandwidth and complete the bandwidth allocation for the FlexE connection.

[0166] Specifically, the second device writes the target bandwidth configuration information into its local FlexE Shim layer hardware and sets parameters according to the physical port and time slot allocation strategy in the configuration information, including physical port binding and time slot mapping in the calendar time slot table. After the second device completes the configuration, the FlexE connection between the first and second devices transmits data according to the target bandwidth configuration information, with different services occupying different sub-time slots, achieving hard isolation and deterministic bandwidth allocation. The entire process requires no manual intervention, significantly reducing the configuration workload and error probability during large-scale deployment of edge networks.

[0167] The method provided in this application provides the data foundation required for security verification for the first device by sending a bandwidth configuration request message carrying session identifier and signature data. This enables the first device to determine the legitimacy of the device based on the root key signature verification and to determine the legitimacy of the installation area based on the geographical location information in the session identifier. By obtaining the target bandwidth configuration information determined by the first device after the dual verification is passed, the allocation of bandwidth resources is bound to the physical location of the device. By using the target bandwidth configuration information to complete the local configuration, the security of FlexE bandwidth allocation is improved without deploying a central controller.

[0168] In one specific implementation, the second device constructs a discovery message (GFDF, Geo FlexE Discover Frame) and sends it to the first device as a bandwidth configuration request message. The message structure is as follows.

[0169] The header of the discovery message contains the following fields: Destination MAC address: Use multicast address 01:80:C2:00:00:0E to ensure that the packet is received by the relevant devices in the Layer 2 network.

[0170] Source MAC address: The source MAC address of the sending port, used to identify the sender of the packet.

[0171] EtherType: Uses a custom private protocol type, such as a non-standard string, to identify the message as a GFDF discovery message, distinguishing it from a standard Ethernet frame.

[0172] The payload of this discovery message contains the following fields: Version number: Occupies 1 byte and indicates the version information of the GFDF protocol, used for protocol version compatibility verification between the sender and receiver.

[0173] Session Identifier (Geo-ID): Occupies 16 bytes. It is a geolocation hash value generated by hashing factors such as the geolocation information of the second device, timestamp information, hardware fingerprint, and random number assigned by the first device. It is used to uniquely identify this session.

[0174] Device Role: Occupies 1 byte and indicates the role of the sending device. A value of 0 indicates the first device, and a value of 1 indicates the second device.

[0175] Message Type (MsgType): Occupies 1 byte and indicates the type of message. A value of 0x01 indicates a Hello message, used to initiate discovery and configuration requests; a value of 0x02 indicates a Capability ACK message; a value of 0x03 indicates a Configuration Announcement message; a value of 0x04 indicates a Configuration Acknowledgment message; and a value of 0x05 indicates a Configuration Execution message.

[0176] Message Length (MsgLength): Indicates the length of the data content in the message payload.

[0177] Message data (MsgValue): The specific data content that carries the message; its structure and meaning are determined by the message type.

[0178] Timestamp: Occupies 8 bytes, is a nanosecond-level timestamp, used to record the time when the message was sent, and can be used to prevent replay attacks and determine session timeliness.

[0179] Signature data (HMAC-SHA256): Occupies 32 bytes. The HMAC-SHA256 signature is generated based on the session identifier and the device's pre-shared key, ensuring that the message has not been tampered with during transmission and comes from a device in a legitimate geographical area.

[0180] When the message type is 0x01 (Hello message), the message data (MsgValue) carries the following key information: FlexE Capability Bitmap: Occupying 4 bytes, this bitmap describes the FlexE hardware capabilities of the second device. Bits 0 to 3 indicate the maximum supported group rate, corresponding to 50G, 100G, 200G, and 400G respectively; Bits 4 to 7 indicate the supported sub-slot granularity, corresponding to 1G and 5G respectively; and Bit 8 indicates whether hitless adjustment is supported.

[0181] Service Template Identifier (SLA-Profile-ID): Occupies 2 bytes and is the identification information for the preset service template. Various service templates can be defined according to specific application scenarios. For example, 0x001 represents a low-latency industrial control template, and 0x002 represents a high-definition video transmission template. In a specific scenario, service templates can be preset into two categories: management channel templates and service channel templates, which are used to carry management messages and service data, respectively.

[0182] The second device sends the discovery message at preset time intervals. In one specific implementation, the second device sends three discovery messages consecutively at 1-second intervals. If no response message is received from the first device after sending, the sending interval is increased by a backoff exponential, for example, to 5 seconds or 10 seconds, to avoid network storms caused by network congestion or when the first device is not ready. If no response is received within the preset maximum number of retries or the maximum waiting time, the second device can determine that the automated deployment session has failed and record an error log.

[0183] Through the above message structure, the second device encapsulates its own session identifier, signature data, FlexE capability set, and business requirement information into a unified discovery message, providing the first device with all the initial information required for automated deployment at once, thereby improving negotiation efficiency and reducing the number of message interaction rounds.

[0184] It should be noted that the above GFDF message structure is not only applicable to the Hello message (MsgType 0x01) sent by the second device, but also to all kinds of messages exchanged between the first device and the second device during the automated deployment process of this application embodiment.

[0185] Specifically, different message types are distinguished by the MsgType field, while the MsgValue field for each type carries corresponding data content based on the message's function. The following explains the MsgType values ​​and MsgValue content for various message types: When MsgType is 0x01, it indicates a Hello message sent by the second device to initiate discovery and configuration requests. In this case, MsgValue carries the second device's FlexE capability set bitmap and service template identifier.

[0186] When MsgType is 0x02, it indicates a capability confirmation message sent by the first device to provide feedback on the capability compatibility verification result to the second device. In this case, MsgValue carries the verification result information; for example, a value of 0x00 indicates successful verification, 0x01 indicates an invalid geographical location, 0x02 indicates resource mismatch, and 0x03 indicates other exceptions.

[0187] When MsgType is 0x03, it indicates a configuration announcement message sent by the first device to distribute target bandwidth configuration information to the second device. In this case, MsgValue carries complete FlexE configuration parameters, including FlexE Group ID, time slot allocation mode, Group Number, a list of bound physical interfaces and their respective interface IDs and PHY numbers, the number of clients and their respective client IDs, client numbers, bandwidth mode, and time slot information.

[0188] When MsgType is 0x04, it indicates a configuration confirmation message sent by the second device to provide feedback to the first device on the verification result of the target bandwidth configuration information. In this case, MsgValue carries a status code; for example, a value of 0x00 indicates successful pre-configuration, 0x01 indicates a resource conflict, and 0x02 indicates that the parameter is not supported.

[0189] When MsgType is 0x05, it indicates a configuration execution message sent by the first device to instruct the second device to apply the target bandwidth configuration information. In this case, MsgValue carries an execution indicator bit and a calendar selection indicator bit. A value of 1 for the execution indicator bit indicates execution of the configuration switch, while a value of 0 indicates no execution. A value of 0 for the calendar selection indicator bit selects calendar 1, and a value of 1 selects calendar 2.

[0190] Through the unified message structure and message type differentiation design described above, the first and second devices only need to identify messages with the same Ethernet type identifier. The message function can be distinguished and the corresponding MsgValue content parsed based on the MsgType field. This design simplifies the protocol implementation complexity during automated deployment and improves the efficiency and consistency of message processing.

[0191] This application embodiment also provides a storage medium storing a computer program, wherein the computer program is configured to execute the method described above when running.

[0192] Specifically, this storage medium is used to host and distribute software programs that execute the bandwidth allocation method in FlexE described above. In edge network deployment scenarios, this storage medium can be a device firmware upgrade package, a software distribution image, or a network device configuration file storage disk. After engineers or network administrators load it onto the first or second device, the device can run the method of this solution to complete the bandwidth allocation of the FlexE connection during automated deployment. For example, in distributed edge scenarios such as industrial internet or 5G small base stations, software programs containing the method of this solution can be deployed in batches to various edge nodes through this storage medium to achieve rapid deployment and zero-configuration startup of large-scale nodes.

[0193] This application also provides a bandwidth allocation device in FlexE, including a memory and a processor. The memory stores a computer program, and the processor is configured to run the computer program to perform the method described above.

[0194] Specifically, the device, serving as the physical execution carrier of the method in this scheme, can be either the first device or the second device itself. Wherein: The first device is typically an aggregation switch, gateway device, or data center Spine switch, equipped with a processor and storage space that meet the processing capabilities of the edge network aggregation layer. It is connected to the second device below it via a high-speed Ethernet interface (such as 100GE / 400GE) and is responsible for performing session identification authentication, geographical area determination, and determination and distribution of target bandwidth configuration information.

[0195] The second device is typically an access switch, industrial gateway, or data center Leaf switch. It connects to the first device via a FlexE interface and is responsible for generating session identifiers, sending bandwidth configuration request messages, and receiving and applying target bandwidth configuration information.

[0196] In edge network scenarios, this device can be deployed in physical locations such as industrial parks, base station sites, or data center rooms. It can obtain its own geographical location information through a built-in GNSS module or other positioning methods to achieve the automatic allocation of FlexE bandwidth based on geographical location awareness as described in this solution.

[0197] It will be understood by those skilled in the art that all or some of the steps, systems, or apparatuses disclosed above, and their functional modules / units, can be implemented as software, firmware, hardware, or suitable combinations thereof. In hardware implementations, the division between functional modules / units mentioned above does not necessarily correspond to the division of physical components; for example, a physical component may have multiple functions, or a function or step may be performed collaboratively by several physical components. Some or all components may be implemented as software executed by a processor, such as a digital signal processor or microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit (ASIC). Such software may be distributed on a computer-readable medium, which may include computer storage media (or non-transitory media) and communication media (or transient media). As is known to those skilled in the art, the term "computer storage medium" includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information (such as computer-readable instructions, data structures, program modules, or other data). Computer storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technologies, CD-ROM, digital versatile disc (DVD) or other optical disc storage, magnetic cartridges, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and can be accessed by a computer. Furthermore, it is well known to those skilled in the art that communication media typically contain computer-readable instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other transmission mechanisms, and may include any information delivery medium.

Claims

1. A bandwidth allocation method in FlexE, characterized in that, Applied to an edge network, the edge network includes a first device and at least one second device connected to the first device, wherein the first device and the second device transmit data via a FlexE connection, wherein each second device is configured with a session identifier to uniquely identify a session between the first device and the second device during automated deployment, wherein the session identifier is determined at least based on the geographical location information of the second device; in each session of the automated deployment process of the second device, the execution steps of the first device include: The device receives a bandwidth configuration request message sent by the second device, wherein the bandwidth configuration request message carries the session identifier and the signature data of the second device, wherein the signature data is obtained by encrypting the session identifier based on the shared key of the second device. Based on the parameter value corresponding to the mapping table entry of the session identifier in the second device, it is determined whether the session identifier is valid. After determining that the session identifier is valid, the signature verification data of the session identifier in the bandwidth configuration request is generated based on the preset root key. After the signature data is consistent with the signature verification data, the target bandwidth configuration information corresponding to the service of the second device in the FlexE connection between the second device and the first device is determined. The target bandwidth configuration information includes the physical port used by the second device and the time slot allocation strategy of each service of the second device. The target bandwidth configuration information is used to configure the bandwidth for the second device.

2. The method according to claim 1, characterized in that, The method further includes: After the target bandwidth configuration information takes effect, if the geographical location of the second device changes and the changed geographical location deviates from the fence area corresponding to the second device, then the bandwidth configuration information controlling at least some services in the second device will become invalid.

3. The method according to claim 2, characterized in that, Controlling service time slot failure in at least one of the following ways, causing the bandwidth configuration information of at least some services in the second device to become invalid, includes: The time slot allocation information corresponding to the service will be deleted from the target bandwidth configuration information; or, the physical port used by the service will be deleted. Set the value of the remote fault indicator bit in the overhead of the physical interface corresponding to the service time slot to mark all time slots of the physical interface as failed; Modify the overhead frame content corresponding to the service time slot, but do not update the cyclic redundancy check field, so that the corresponding time slot is deemed invalid after the receiving end fails the check.

4. The method according to claim 1, characterized in that: The mapping relationship table entry record has at least one of the following: The base port for receiving the session identifier; The input values ​​and generation strategy used to generate the session identifier; The validity of the session identifier is determined based on the parameter value corresponding to the mapping table entry of the session identifier in the second device, including: When the parameter value is the base port for receiving the session identifier, if the port for receiving the bandwidth configuration request is the same as the base port for receiving the session identifier, then the session identifier is determined to be valid. When the parameter value is the input value and generation strategy used to generate the session identifier, a baseline identifier corresponding to the input value is generated according to the generation strategy. If the baseline identifier and the session identifier are consistent, the session identifier is determined to be valid.

5. The method according to claim 1 or 4, characterized in that: If the address location information corresponding to the session identifier in the bandwidth configuration request is in the baseline geographic area of ​​the first device, determine the target bandwidth configuration information corresponding to the service of the second device in the FlexE connection between the second device and the first device.

6. The method according to claim 1, characterized in that, The step of determining the target bandwidth configuration information corresponding to the FlexE service of the second device includes: Based on the FlexE capability set of the second device and the FlexE capability set of the first device, determine the target capability set that both the first device and the second device can support. The target bandwidth configuration information is determined based on the target capability set and the service requirement information of the second device.

7. The method according to claim 6, characterized in that: The first device has at least two service templates, wherein each service template corresponds to bandwidth configuration information for at least two capability sets; The method for determining the target bandwidth configuration information includes: Based on the service requirement information of the second device, determine the target service template corresponding to the second device in the service template of the first device; Based on the bandwidth configuration information corresponding to different capability sets under the target service template, determine the target bandwidth configuration information corresponding to the target capability set.

8. The method according to claim 1, characterized in that, The step of configuring bandwidth for the second device using the target bandwidth configuration information includes: Send a configuration announcement message carrying the target bandwidth configuration information to the second device; The device receives a configuration confirmation message carrying a verification result from the second device, wherein the verification result is obtained by matching the target bandwidth configuration information with the local resources of the second device. When the verification result indicates a successful match, a configuration execution message is sent to the second device to indicate that the target bandwidth configuration information has taken effect.

9. A bandwidth allocation method in FlexE, characterized in that, The device is applied to an edge network, which includes a first device and at least one second device connected to the first device. The first device and the second device transmit data via a FlexE connection. Each second device is configured with a session identifier to uniquely identify a session between the first device and the second device during automated deployment. The session identifier is determined at least based on the geographical location information of the second device. In each session of the automated deployment process for the second device, the steps performed by the second device include: A configuration request message is sent, the configuration request message carrying the session identifier and the signature data of the second device; wherein the session identifier is used by the first device to determine whether the session identifier is valid, and the signature data is obtained by encrypting the session identifier based on the shared key of the second device; Obtain the target bandwidth configuration information determined by the first device. The target bandwidth configuration information is the bandwidth configuration information corresponding to the services of the second device in the FlexE connection between the second device and the first device, including the physical port used by the second device and the time slot allocation strategy for each service. The target bandwidth configuration information is used to configure the bandwidth for the second device.

10. The method according to claim 9, characterized in that, The session identifier is also determined based on at least one of the following information: The timestamp information corresponding to the geographical location information of the second device; Hardware fingerprint in the second device; The first device assigns a random number to the second device.

11. The method according to claim 9 or 10, characterized in that: The bandwidth configuration request message also carries at least one of the FlexE capability set of the second device and the service requirement information of the second device.

12. A bandwidth allocation device in FlexE, comprising a memory and a processor, characterized in that, The memory stores a computer program, and the processor is configured to run the computer program to perform the method according to any one of claims 1 to 11.

Images