A method and apparatus for implementing a network configuration protocol based on QUIC

Abstract

The application relates to a method and device for implementing a network configuration protocol based on QUIC, belonging to the technical field of data communication and network, and applied between a network management entity and a network device, comprising the following steps: setting a NoQ cushion layer between an application service layer and a QUIC layer, the NoQ cushion layer realizing mapping of a network configuration protocol message to QUIC; binding multiple network configuration protocol sessions to one QUIC connection through the NoQ cushion layer, and allocating independent QUIC flows to each session to realize entity multiplexing; and maintaining a binding relationship between a network configuration protocol session state and a QUIC connection state through the NoQ cushion layer to realize state management. The method can solve the technical problems of thread blocking, long connection establishment time and difficulty in multiplexing in the prior art.

Description

Technical Field

[0001] This application relates to the fields of data communication and network technology, and specifically to a method and apparatus for implementing a network configuration protocol based on QUIC. Background Technology

[0002] NETCONF (Network Configuration Protocol) aims to connect network management systems and network devices, providing a complete set of protocols for communication between them. Network management systems can use the NETCONF protocol to configure network devices.

[0003] NETCONF uses XML (Extensible Markup Language) to represent corresponding operations and configurations, and uses RPC (Remote Procedure Call) mechanism to realize communication between the network management system and network devices.

[0004] The current NETCONF protocol is mainly divided into four layers: content layer, operation layer, message layer, and secure transport layer. The content layer manages the data exchanged between network management entities and network devices; the operation layer refers to various operations that use the content layer as their object; the message layer refers to RPC operations; and the secure transport layer refers to the fourth layer protocol that implements security mechanisms. Among these, network management entities include network management systems and controllers.

[0005] Current NETCONF implementations of secure transport layer protocols are all based on TCP (Transmission Control Protocol). However, TCP has shortcomings such as long connection establishment time, susceptibility to line-end blocking, and difficulty in reuse. As a result, NETCONF implementations also suffer from these problems, making them difficult to use efficiently, especially in application scenarios such as satellite internet, deep space networks, and low-resource networks. Summary of the Invention

[0006] This application provides a method and apparatus for implementing a network configuration protocol based on QUIC, which can solve the technical problems of wire blockage, long connection establishment time and difficulty in reuse in the prior art.

[0007] In a first aspect, embodiments of this application provide a method for implementing a network configuration protocol based on QUIC, the method being applied between a network management entity and network devices, including: A NoQ padding layer is set between the application service layer and the QUIC layer. The NoQ padding layer realizes the mapping of network configuration protocol messages to QUIC. Multiple network configuration protocol sessions are bound to a QUIC connection through the NoQ padding layer, and an independent QUIC stream is allocated to each session to realize entity multiplexing. The NoQ padding layer maintains the binding relationship between the network configuration protocol session state and the QUIC connection state to realize state management.

[0008] In conjunction with the first aspect, in one implementation, the NoQ pad layer implements the mapping of network configuration protocol messages to QUIC, including: The NoQ layer encapsulates network configuration protocol messages into QUIC streams and into QUIC data packets; other upper-layer application services use the NoQ layer to map application services to QUIC.

[0009] In conjunction with the first aspect, in one implementation, the mapping relationship between the logical entities of the network configuration protocol session, QUIC connection, and QUIC stream in the implementation of entity multiplexing by allocating an independent QUIC stream for each session includes: The mapping between network configuration protocol sessions and QUIC connections is many-to-one; The mapping between network configuration protocol sessions and QUIC streams is one-to-one; The mapping between QUIC streams and network configuration protocol sessions is many-to-one; The mapping between network configuration protocol subscriptions and QUIC streams is one-to-one; The mapping between network configuration protocol interaction and QUIC stream is 1-to-1.

[0010] In conjunction with the first aspect, in one implementation, the method further includes: the NoQ padding layer provides an extended interface to support third-party authentication and application-layer encryption.

[0011] In conjunction with the first aspect, in one embodiment, the method further includes: the NoQ pad layer negotiating transmission parameters using QUIC extended frames.

[0012] In conjunction with the first aspect, in one implementation, the NoQ pad layer negotiates transmission parameters using QUIC extended frames, including: The client and server negotiate an extended frame identifier through an undefined frame; The client and server negotiate to determine two types of extended frames, which are used to negotiate the transmission parameter structure and the transmission extended parameters, respectively. Each extended frame transmission parameter includes type, length and reserved fields. The client is a network management entity and the server is a network device.

[0013] In conjunction with the first aspect, in one implementation, the rules followed for establishing and closing the QUIC connection include: The client initiates a connection, and the server accepts the connection. The client closes the connection, and the server closes the connection via the client's connection request. Normal connection closure requires waiting for all bound sessions to close; Close all sessions before forcibly closing the connection in case of an abnormality. Connection migration supports zero-trust third-party authentication or call home authentication; The client is a network management entity, and the server is a network device.

[0014] In conjunction with the first aspect, in one implementation, the rules followed for establishing, binding, and closing the network configuration protocol session include: The client initiates a network configuration protocol session, and the server accepts the session and assigns an ID; The client closes the network configuration protocol session, and the server closes the session via the client. The NoQ padding layer binds multiple network configuration protocol sessions to a single QUIC connection; The client is a network management entity, and the server is a network device.

[0015] In conjunction with the first aspect, in one implementation, the rules governing the initiation, mapping, and management of the QUIC stream include: The NoQ layer is responsible for bidirectional conversion between network configuration protocol messages and QUIC Streams, bidirectional parsing of QUIC Streams and QUIC packets, and mapping and state maintenance of QUIC Streams and network configuration protocols.

[0016] Secondly, embodiments of this application provide an apparatus for implementing a network configuration protocol based on QUIC. The apparatus is used between a network management entity and network devices. The apparatus includes: The NoQ layer module is located between the application service layer and the QUIC layer. The NoQ layer module is used to map network configuration protocol messages to QUIC; to bind multiple network configuration protocol sessions to a single QUIC connection and allocate an independent QUIC stream to each session to achieve entity reuse; the NoQ layer module is also used to maintain the binding relationship between the network configuration protocol session state and the QUIC connection state to achieve state management.

[0017] The beneficial effects of the technical solutions provided in this application include: By combining QUIC with the Network Configuration Protocol (NETCONF), a new protocol combination and method are formed, which draws on the advantages of QUIC and solves the shortcomings of the current NETCONF implementation.

[0018] A NoQ (NETCONF over QUIC) overlay is set between the application service layer (application services transmitted above the QUIC transport layer, such as NETCONF, HTTP, MIA, etc.) and the QUIC layer. The NoQ overlay implements the mapping of NETCONF messages to QUIC. Multiple NETCONF sessions are bound to a single QUIC connection through the NoQ overlay, and an independent QUIC stream is allocated to each session to achieve entity reuse. Reusing a single QUIC connection avoids repeated connection establishment, which leads to long connection establishment times and solves the technical problem of difficulty in reuse. The NoQ overlay also maintains the binding relationship between the NETCONF session state and the QUIC connection state to achieve state management. The independence of the QUIC stream is adjusted according to transmission requirements to avoid head-of-line congestion. Attached Figure Description

[0019] Figure 1 This is a schematic diagram of the logical hierarchy implemented in the current NETCONF. Figure 2 This is a schematic diagram of the logical hierarchy of NETCONF in an embodiment of this application; Figure 3 This is a schematic diagram of the logical functional structure of an embodiment of this application; Figure 4 A flowchart illustrating the connection and session establishment process in the embodiments of this application; Figure 5 This is a flowchart of the client packet sending process in an embodiment of this application; Figure 6 This is a flowchart of the server-side packet receiving process in an embodiment of this application; Figure 7 This is a flowchart of the client packet receiving process in an embodiment of this application; Figure 8 This is a flowchart of the server-side packet sending process in an embodiment of this application. Detailed Implementation

[0020] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present application.

[0021] like Figure 1As shown, the current implementation of the NETCONF protocol is mainly divided into four layers: Content, Operations, Message, and Secure Transport. The Content layer corresponds to the information exchanged between the network management entity and network devices by the NETCONF management protocol, including configuration information initiated by the network management entity and reporting or notification information initiated by the network devices. The Operations layer corresponds to the configuration copying and modification commands exchanged between the network management entity and network devices. Reporting or notification information initiated by network devices is not specially processed at this layer. The network management entity includes the network management system and the controller, corresponding to the management plane and control plane in the network, respectively. The Message layer encapsulates the information from the Operations layer into a structure supported by RPC. The Secure Transport layer is the transport layer protocol required by NETCONF and is loosely coupled to the NETCONF Message layer. Many secure transport layer protocols are applicable to NETCONF, including SSH, TCL, SOAP, BEEP, etc. However, these protocols are essentially built on TCP. The shortcomings of TCP are present in these protocols.

[0022] QUIC is an emerging transport layer protocol designed to make network communication faster and more efficient. It focuses on improving the speed, multiplexing, security, and reliability of network connections, and has the potential to replace TCP in the future. QUIC is built on top of UDP (User Datagram Protocol). Compared to TCP, QUIC has many advantages, some of which are summarized below: Fast connection establishment: (1) 1RTT connection establishment: The QUIC protocol combines reliable transport channel connection establishment with TLS encrypted channel connection establishment, carrying two handshake messages (quic initial + tls client / server hello) in one message, so that reliable encrypted transport channel establishment can be completed in one interaction, taking 1RTT. (2) 0RTT connection establishment: After successful establishment via 1RTT, 0RTT connection establishment can be achieved based on the TLS session multiplexing mechanism. In this mode, the quicinitial negotiation message and the data payload message are sent simultaneously, in which the payload message is encrypted using the established TLS session key. If the other end accepts the session multiplexing negotiation in the quic initial message, it can directly process the payload message.

[0023] Multiplexing: QUIC supports multiplexing, allowing multiple independent streams to be created over the same QUIC connection. These streams are independent and do not interfere with each other. This stream multiplexing mechanism avoids the head-of-line blocking problem found in TCP.

[0024] Connection Migration: When a QUIC connection is established, both ends of the connection assign a connection ID to the connection and synchronize it with each other. Within the QUIC protocol, the connection is identified by the mutually agreed-upon connection ID, rather than the five-tuple information used by other connection-based protocols. This allows the two ends of a connection to be migrated to other physical entities based on the connection ID.

[0025] The existing problems with NETCONF implementations, and the numerous advantages of QUIC, make QUIC very suitable as the secure transport layer protocol for NETCONF. However, while there are no logical problems in using QUIC to implement NETCONF, a series of methods and mechanisms are still required to support it. The following describes the methods and apparatus for implementing a network configuration protocol based on QUIC through different embodiments.

[0026] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0027] In a first aspect, embodiments of this application provide a method for implementing a network configuration protocol based on QUIC, which is applied between a network management entity and network devices, including: A NoQ (NETCONF over QUIC) overlay is set up between the application service layer and the QUIC layer. This NoQ overlay implements the mapping of NETCONF messages to QUIC. Multiple NETCONF sessions are bound to a single QUIC connection through the NoQ overlay, and an independent QUIC stream is allocated to each session to achieve entity multiplexing. The NoQ overlay also maintains the binding relationship between NETCONF session state and QUIC connection state to achieve state management.

[0028] It is understandable that NETCONF Messages are presented in the form of data packets or messages. A NETCONF session is a logical channel for data packet transmission between two communicating entities. Multiple NETCONF Messages can be transmitted in a NETCONF session until the NETCONF session is closed.

[0029] Specifically, the NoQ layer enables the reuse of NETCONF entities to QUIC entities, including the reuse of NETCONF sessions, QUIC connections, and QUIC streams. The NoQ layer also manages state, including NETCONF session state, QUIC connection state, and the binding state between NETCONF and QUIC entities.

[0030] Specifically, the NoQ layer described above implements the mapping from NETCONF messages to QUIC, which is the fundamental function connecting NETCONF and QUIC. The NoQ layer encapsulates NETCONF messages into QUIC streams and then into QUIC data packets, such as configuration operation information between network management entities and network devices, as well as notification or reporting data from network devices to network management entities. Furthermore, other upper-layer application services (such as SNMP, FTP, gRPC, etc.) that need to reuse the same connection as NETCONF also use NoQ to implement the mapping from application services to QUIC.

[0031] The mapping from NETCONF to QUIC is not a one-to-one relationship. For example, multiple NETCONF sessions may share a single QUIC connection, and these NETCONF sessions may correspond to multiple QUIC streams. Multiple upper-layer applications may share a single QUIC connection, and these mechanisms all rely on the NoQ overlay layer for implementation.

[0032] In this embodiment, QUIC and NETCONF are combined to leverage the advantages of QUIC. Entity reuse is achieved through a NoQ layer, avoiding repeated connection establishment and the resulting long connection establishment time, thus solving the technical problem of difficulty in reuse. Furthermore, state management is achieved through the NoQ layer, which can adjust the independence of the QUIC stream according to transmission requirements and avoid head-of-line congestion.

[0033] Furthermore, in one embodiment, the aforementioned NoQ padding layer provides an extension interface to implement extended functions. This extension interface supports third-party authentication and application-layer encryption. Third-party authentication retains enhancements to any authentication method other than network management entities (clients) and network devices (servers). In addition to the error handling and security mechanisms inherent in NETCONF and QUIC, the NoQ padding layer adds new error definitions, error handling, and corresponding operations for security threats. Besides the defined standardized transmission parameters, the QUIC protocol also retains the possibility of extending new transmission parameters. The NoQ padding layer utilizes this mechanism to implement new capability negotiation, new parameter-based data exchange, and other functions. The NoQ padding layer uses QUIC's extended frames to negotiate two or more extended frames, and negotiates transmission parameters based on these extended frames.

[0034] The aforementioned NoQ padding layer uses QUIC extended frames to negotiate transmission parameters, and the method includes: Step a: The client and server negotiate an extended frame identifier through an undefined frame. This embodiment specifically includes: a1. The client sends an undefined frame 1 to the server. The frame type is A, the frame length is 4*l (l is the number of extended transmission parameters), and the frame data is 0xffff0000.

[0035] a2. The server sends an undefined frame 1 back to the client. The frame type is A, the frame length is 4*l, and the frame data is 0x0000ffff.

[0036] a3. The client sends an undefined frame 2 to the server. The frame type is B, the frame length is L (the length of the transmission parameters that need to be extended), and the frame data is 0xf0*L.

[0037] a4. The server sends an undefined frame 2 back to the client. The frame type is B, the frame length is L (the length of the transmission parameters that need to be extended), and the frame data is 0x0f*L.

[0038] Step b: The client and server negotiate to determine two types of extended frames, used to negotiate the transmission parameter structure and transmission extended parameters, respectively. Each extended frame transmission parameter includes type, length, and reserved fields. The client is a network management entity, and the server is a network device. This embodiment specifically includes: b1. The client and server negotiate the transmission parameter structure through the extended frame 1 determined by negotiation. Each extended transmission parameter includes type (1 byte), length (2 bytes), and reserved field (1 byte).

[0039] b2. The client and server transmit extended parameters through extended frame 2, which is determined through negotiation. The transmission of extended parameters follows the structure negotiated in step b1.

[0040] Furthermore, in one embodiment, the aforementioned NoQ padding layer provides an extension interface to implement extended functionality. This extension interface supports third-party authentication and application-layer encryption. The third-party authentication retains enhancements to any authentication method other than network management entities (clients) and network devices (servers). In addition to the error handling and security mechanisms inherent in NETCONF and QUIC, the NoQ padding layer adds new error definitions, error handling, and corresponding operations for security threats.

[0041] In this embodiment, the NoQ padding layer adds new error definitions, error handling, and operations corresponding to security threats, and has the following extended mechanisms for security and trust: Define new QUIC extended transmission parameters to exchange information on implementable application-layer encryption algorithms between NETCONF CS (Client-Server); define new QUIC extended frames to negotiate between NETCONF CS to determine the application-layer encryption algorithm currently used; define new QUIC extended transmission parameters to exchange candidate third-party authentication methods between NETCONF CS; define new QUIC extended frames to negotiate between NETCONF CS to determine the third-party authentication method currently used.

[0042] In this embodiment, QUIC's extended parameters are used to exchange information including QUIC connections, QUIC streams, and NETCONF sessions, making NETCONF implementation more flexible and scalable. Furthermore, extended mechanisms such as third-party authentication and application-layer security are introduced, making QUIC's support for NETCONF more comprehensive and robust.

[0043] In many application scenarios, such as satellite internet, IoT, deep space networks, and low-resource-constraint networks, resources and QoS are limited. Providing independent channels for multiple application-layer services is not a scientific solution. There is a need for multiple application services to share and reuse lower-layer resources. For example, this could be when the lower-layer resources share the same QUIC connection. Additionally, on ordinary network devices, there are situations where it is necessary to simultaneously support application services such as CLI, SNMP, NETCONNECT, GRPC, and FTP. Sharing the same QUIC connection for these services is an economical and efficient solution.

[0044] This method supports the two main categories of application scenarios mentioned above. The mechanism for implementing this function in this embodiment is as follows: Define new QUIC extended transport parameters to negotiate connections between NETCONF CSs to support multiple application services; Define new QUIC extended transport parameters to exchange currently reusable application service identifiers between NETCONF CSs; Different application services are mapped to different streams or different frames, and the first byte of the extended stream serves as the identifier of a specific application service corresponding to the stream.

[0045] This embodiment proposes a mechanism and method for supporting heterogeneous upper-layer services over QUIC connections. This makes the connection between NETCONF and QUIC more adaptable to application scenarios such as satellite internet, the Internet of Things, and low-resource networks.

[0046] like Figure 2As shown, a basic architecture embodiment of a method for implementing NETCONF based on QUIC is provided. This embodiment can be viewed as a four-and-a-half-layer model. The content layer, operation layer, and message layer of NETCONF remain essentially unchanged, but the secure transport layer uses QUIC. Simultaneously, to achieve multiplexing within NETCONF, multiplexing between NETCONF and other services, logical entity mapping, transmission parameter extension, and application layer function extension, a NoQ pad layer is added. The NoQ pad layer can be considered a half-layer; it does not introduce new message headers. The NoQ pad layer acts as a bridge, adapting to the NETCONF message layer and other service layers above, and connecting to the QUIC protocol layer below. Any functionality not implemented in NETCONF and QUIC, but required for QUIC to carry NETCONF, can be added to the NoQ pad layer. In practice, QUIC can be implemented in operating system manager mode or user mode, while the NoQ pad layer is implemented in user mode.

[0047] In one embodiment, the above-mentioned binding of multiple NETCONF sessions to a single QUIC connection via a NoQ overlay and allocation of an independent QUIC stream to each session to achieve entity reuse involves logically different logical entities that need to establish collaborative relationships between NETCONF sessions and QUIC, including NETCONF sessions, QUIC connections, QUIC streams, NETCONF subscriptions, and NETCONF interactions. The mapping and correspondence between these logical entities are as follows: The mapping between network configuration protocol sessions and QUIC connections is many-to-one (n:1). The mapping between network configuration protocol sessions and QUIC streams is 1 to 1 (1:1). The mapping between QUIC streams and network configuration protocol sessions is many-to-one (n:1). The mapping between network configuration protocol subscriptions and QUIC streams is 1-to-1 (1:1). The mapping between network configuration protocol interaction and QUIC stream is 1 to 1 (1:1).

[0048] Furthermore, it is necessary to design specific mechanisms suitable for NETCONF and QUIC for QUIC connections, NETCONF sessions, and QUIC streams. For QUIC connections, the rules for establishing and closing connections include: The client initiates a connection, and the server accepts the connection. The client closes the connection, and the server closes the connection through the client; that is, only the client closes the connection. If the server wants to close the connection, it needs to notify the client, and the client closes the connection.

[0049] Normal connection closure requires waiting for all bound sessions to close; Close all sessions before forcibly closing the connection in case of an abnormality. Connection migration supports zero-trust third-party authentication or call home authentication.

[0050] For NETCONF sessions, the rules governing the creation, binding, and closure of NETCONF sessions include: The client initiates a NETCONF session, and the server accepts the session and assigns an ID. The client closes the NETCONF session, and the server closes the session through the client; that is, only the client closes the NETCONF session. If the server wants to close the NETCONF session, it needs to notify the client, and the client closes the NETCONF session.

[0051] The NoQ pad binds multiple NETCONF sessions to a single QUIC connection.

[0052] For QUIC streams, the rules governing stream initiation, mapping, and management include: The NoQ overlay is responsible for bidirectional conversion between NETCONF Messages and QUIC Streams; The NoQ overlay is responsible for bidirectional parsing of QUIC Stream and QUIC data packets; The NoQ padding layer is also responsible for mapping and state maintenance of QUIC Stream and NETCONF.

[0053] In this embodiment, the mapping of the three protocol bodies, namely QUIC connection, QUIC stream, and NETCONF session, can achieve full coverage without omission, and is efficient and economical. Compared with TCP-based solutions, this embodiment is a more optimized solution.

[0054] like Figure 3 As shown, a logical functional structure diagram of this method is provided, and... Figure 2 different, Figure 3 It explicitly adds support for other application services. Figure 3 It is the basic logical functional structure for implementing NoQ, not the specific protocol stack layer. Figure 3 This method is abstracted into three logical layers: the application business layer, the NoQ layer, and the QUIC layer. NETCONF only represents one or two types of application business logic. The three sub-layers of NETCONF are... Figure 3Not explicitly described. In this embodiment, the application services supported by NoQ include, but are not limited to: NETCONF configuration, NETCONF notification, gRPC, FTP, SNMP, and CLI. The functions implemented by NoQ include, but are not limited to: connection management, session management, mapping mechanism, security mechanism, transmission parameter extension mechanism, and extension mechanism. In addition to implementing the basic functions of NETCONF, NoQ also supports the following extended functions: third-party authentication, application layer encryption, third-party extended functions, and device manufacturer extended functions.

[0055] like Figure 4 As shown, the connection and session establishment process of this method is illustrated through a specific embodiment. Since the QUIC connection to the NETCONF session and other application service sessions occur between the network management entity (client) and the network device (server), this process requires the participation of both the client and the server.

[0056] S1: The client initiates a QUIC connection establishment request, and the server accepts the connection request. A QUIC connection must be established by the client; once confirmed by the server, the QUIC connection is established.

[0057] S2: The client initiates QUIC connection parameter negotiation, and the server confirms the transmission parameters. After the QUIC connection is established, the client and server need to negotiate the parameters applicable to the transmission protocol. The server cooperates with the client to complete the negotiation of the parameters applicable to the transmission protocol.

[0058] S3: The client initiates a NETCONF configuration session, and the server confirms the configuration session and returns the ID. This step establishes the NETCONF session based on the existing QUIC connection. NETCONF information exchange is accomplished using NETCONF. Although the client initiates the NETCONF session, the session establishment is only completed after confirmation from the server, and the session ID is assigned by the server.

[0059] S4: Configure the NoQ bedding layer binding session and QUIC connection on the client side, and on the server side as well. After the QUIC connection and NETCONF session are established, it is necessary to establish and maintain the mapping relationship between the NETCONF session and the QUIC connection for subsequent QUIC connection management and NETCONF session management.

[0060] S5: The client initiates NETCONF capability negotiation, and the server confirms the NETCONF capability negotiation. After the NETCONF session is established, the client and server need to negotiate and confirm the capabilities supported by the NETCONF session. This operation is completed after the server confirms the agreement.

[0061] S6: The client initiates a NETCONF subscription session, and the server confirms the subscription session and returns the ID. The NETCONF subscription session used for NETCONF reporting and notification is a different session from the NETCONF configuration session. The establishment of the NETCONF subscription session also requires confirmation from the server before it is completed.

[0062] S7: The client-side NoQ bedding layer binds the subscription session and QUIC connection; the server-side NoQ bedding layer also binds the subscription session and QUIC connection. Establish and maintain the mapping between NETCONF subscription sessions and QUIC connections for subsequent QUIC connection management and NETCONF session management.

[0063] S8: The client initiates a notification stream subscription, and the server confirms the notification stream subscription negotiation. This prepares the ground for subsequent mapping of NETCONF notifications to QUIC unidirectional streams, and the correspondence between subscription and stream is only established after confirmation on the server side.

[0064] S9: The client initiates a session for another application service, and the server confirms the session. This method supports not only the reuse of sessions within NETCONF, but also the reuse of NETCONF and other application services. This step establishes a mechanism that supports sessions or equivalent sessions for other application services. Similar to the NETCONF session establishment operation, other application sessions also require server confirmation before completion.

[0065] S10: The client-side NoQ bedding layer binds business sessions and QUIC connections, and the server-side NoQ bedding layer also binds business sessions and QUIC connections. The mapping between other application business sessions and QUIC connections also needs to be maintained for future use in QUIC connection management and NETCONF session management.

[0066] S11: The client initiates application service capability negotiation, and the server confirms the negotiation. After other application service sessions are established, the capabilities supported by these application service sessions need to be negotiated and confirmed between the client and server. Once the server confirms, the capabilities supporting the application services between the client and server are determined.

[0067] In the above steps, steps S9-S11 are executed cyclically. This means that if multiple application services need to be supported, steps S9-S11 need to be executed for each application service. Additionally, some steps correspond to client-initiated operations, and subsequent operations can only proceed after confirmation on the server side.

[0068] like Figure 5 The diagram shown illustrates the client's packet sending process, including the following steps: S51: The client NETCONF generates a Message according to the configuration requirements. This step mainly processes the configuration data between the NETCONF client and the server.

[0069] S52: The client-side NoQ overlay maps Messages to Streams, mapping NETCONF configuration operation data to QUIC streams.

[0070] S53: Other client applications generate data to be sent, process data that other applications need to send, and can reuse QUIC connections and QUIC data packets with NETCONF data.

[0071] S54: The client-side NoQ overlay maps Messages to Streams, and similarly, data from other application services needs to be mapped to QUIC streams.

[0072] S55: The client encapsulates all Streams into QUIC packets. This step requires processing all mapped QUIC streams and mapping them to one or more packets.

[0073] S56: The client sends the encapsulated data packet via the connection ID to complete the transmission of the processed data.

[0074] In the above steps, S53 and S54 can be executed cyclically according to the type of application service. That is, each type of application service needs to execute steps S53 and S54 once. After all application services are executed, S55 is then performed.

[0075] like Figure 6 The diagram shows the server-side packet receiving process, which corresponds to the client-side packet sending process described above. The server receives data packets from the client, and the specific processing steps include: S61: The server receives the QUIC data packet sent by the client. This step marks the beginning of processing the QUIC data packet sent by the client.

[0076] S62: The server-side NoQ parses the Stream in the QUIC data packet, and the server decomposes the QUIC data packet into independent QUIC streams.

[0077] S63: The server-side NoQ parses the NETCONF Stream data. NETCONF is the main application service supported in this embodiment, so it is processed first.

[0078] S64: The NoQ server transforms and submits the NETCONF data, completing the processing of the data sent by the NETCONF client, and then sends it to the NETCONF server for further processing.

[0079] S65: The server-side NoQ parses the Stream data of other application services, processes the NETCONF stream, and then processes the corresponding streams of other application services.

[0080] S66: The server-side NoQ submits other business data to the corresponding application and submits the processed data to the corresponding application business for further processing.

[0081] Similarly, in the above steps, if there are multiple application services, each application service needs to execute steps S65 and S66 once.

[0082] like Figure 7 The diagram shows the client's packet receiving process. The client's initial packet receiving process corresponds to the server's packet sending process, and specifically includes: S71: The client receives the QUIC data packet sent by the server. The QUIC sent by the server activates this process, which is the first step of the process.

[0083] S72: The client NoQ parses the Stream in the QUIC data packet, processes the QUIC data packet, and obtains the Stream frame carried by the QUIC data packet.

[0084] S73: The client NoQ parses the NETCONF configuration response stream and prioritizes the stream corresponding to the NETCONF configuration response data.

[0085] S74: The client NoQ will convert and submit the NETCONF configuration response, extract the data corresponding to the Stream in S73, and submit it to the client NETCONF for processing.

[0086] S75: The client-side NoQ parses the NETCONF subscription stream and then processes the NETCONF notifications or reported data streams from the server.

[0087] S76: The NoQ client transforms and submits the NETCON subscription, retrieves the corresponding data from the NETCONF notification or report, and submits it to the NETCONF client for processing.

[0088] S77: The client-side NoQ parses other business streams and finally processes the QUIC streams (Streams) corresponding to other application businesses.

[0089] S78: The client NoQ submits other business data to the corresponding application and submits the data processed in the previous step to the corresponding application business processing.

[0090] In the above process, steps S77 and S78 need to be executed according to the type of application service. Each type of application service executes steps S77 and S78.

[0091] like Figure 8 The diagram shows the packet sending process on the server side. The packet sending process on the server side corresponds to the initial maintenance process on the client side. The packets sent by the server side are received by the client side.

[0092] S81: Server-side NoQ overlay query RPC response. Again, NETCONF related information is processed first, with configuration-related parts processed first. After the server-side NETCONF completes the client's configuration operations, it will generate RPC response information. This step queries this RPC response information.

[0093] S82: The server-side NoQ converts RPC responses into Streams and maps NETCONF configuration operation feedback data to QUIC streams.

[0094] S83: Server-side NoQ overlay query subscription notifications. Next, process NETCONF notifications and related reporting. When the server-side NETCONF has information that needs to be reported, it will generate a notification message. This step queries that notification message.

[0095] S84: The server-side NoQ bedding layer converts the subscription to the Stream, mapping the notification reporting data already subscribed to by the client's NETCONF to the QUIC stream.

[0096] S85: The server-side NoQ overlay queries other application business data in a manner similar to the client-side operation of sending other application business data.

[0097] S86: The server-side NoQ overlay transforms business data into a Stream, similar to the client's operation of sending other application business data.

[0098] S87: The server encapsulates multiple Streams into QUIC data packets, similar to the client-side packet encapsulation operation.

[0099] S88: The server sends the encapsulated data packet via the connection ID. This step completes the transmission of the processed data.

[0100] Similar to the client, the S85 and S86 mentioned above need to be executed for each application service.

[0101] Secondly, a device for implementing a network configuration protocol based on QUIC is provided, which is applied between network management entities and network devices. The device includes a NoQ layer module, which is positioned between the application service layer and the QUIC layer. The NoQ layer is used to map network configuration protocol messages to QUIC; it also binds multiple network configuration protocol sessions to a single QUIC connection and allocates an independent QUIC stream to each session to achieve entity multiplexing; furthermore, it maintains the binding relationship between the network configuration protocol session state and the QUIC connection state to achieve state management.

[0102] This embodiment combines the emerging transport protocol QUIC with the mainstream management protocol NETCONF to form a new protocol combination and method. It draws on the advantages of QUIC and addresses the shortcomings of the current NETCONF implementation. Through the NoQ underlay module, the functional characteristics of the NETCONF implementation are enhanced without affecting the integrity of the standardized protocol.

[0103] It should be noted that the sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0104] The terms "comprising" and "having," and any variations thereof, in the specification, claims, and accompanying drawings of this application are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to such process, method, product, or apparatus. The terms "first," "second," and "third," etc., are used to distinguish different objects, etc., and do not indicate a sequence, nor do they limit "first," "second," and "third" to different types.

[0105] In the description of the embodiments of this application, terms such as "exemplary," "for example," or "for instance" are used to indicate examples, illustrations, or explanations. Any embodiment or design described as "exemplary," "for example," or "for instance" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of terms such as "exemplary," "for example," or "for instance" is intended to present the relevant concepts in a concrete manner.

[0106] In the description of the embodiments of this application, unless otherwise stated, " / " means "or". For example, A / B can mean A or B. The "and / or" in the text is merely a description of the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can mean: A exists alone, A and B exist simultaneously, and B exists alone. In addition, in the description of the embodiments of this application, "multiple" means two or more.

[0107] In some processes described in the embodiments of this application, multiple operations or steps are included in a specific order. However, it should be understood that these operations or steps may not be executed in the order they appear in the embodiments of this application, or they may be executed in parallel. The sequence number of the operation is only used to distinguish different operations, and the sequence number itself does not represent any execution order. In addition, these processes may include more or fewer operations, and these operations or steps may be executed sequentially or in parallel, and these operations or steps may be combined.

[0108] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) as described above, and includes several instructions to cause a terminal device to execute the methods described in the various embodiments of this application.

[0109] The above are merely preferred embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

Claims

1. A method for implementing a network configuration protocol based on QUIC, characterized in that, The method is applied between network management entities and network devices, including: A NoQ padding layer is set between the application service layer and the QUIC layer. The NoQ padding layer realizes the mapping of network configuration protocol messages to QUIC. Multiple network configuration protocol sessions are bound to a QUIC connection through the NoQ padding layer, and an independent QUIC stream is allocated to each session to realize entity multiplexing. The NoQ padding layer maintains the binding relationship between the network configuration protocol session state and the QUIC connection state to realize state management.

2. The method for implementing a network configuration protocol based on QUIC as described in claim 1, characterized in that, The NoQ underlay layer implements the mapping of network configuration protocol messages to QUIC, including: The NoQ layer encapsulates network configuration protocol messages into QUIC streams and into QUIC data packets; other upper-layer application services use the NoQ layer to map application services to QUIC.

3. The method for implementing a network configuration protocol based on QUIC as described in claim 1, characterized in that, In the entity reuse mechanism of allocating independent QUIC streams for each session, the mapping relationship between the logical entities of network configuration protocol sessions, QUIC connections, and QUIC streams includes: The mapping between network configuration protocol sessions and QUIC connections is many-to-one; The mapping between network configuration protocol sessions and QUIC streams is one-to-one; The mapping between QUIC streams and network configuration protocol sessions is many-to-one; The mapping between network configuration protocol subscriptions and QUIC streams is one-to-one; The mapping between network configuration protocol interaction and QUIC stream is 1-to-1.

4. The method for implementing a network configuration protocol based on QUIC as described in claim 1, characterized in that, The method further includes: the NoQ padding layer provides an extended interface to support third-party authentication and application-layer encryption.

5. The method for implementing a network configuration protocol based on QUIC as described in claim 1, characterized in that, The method also includes: the NoQ padding layer using QUIC extended frames to negotiate transmission parameters.

6. The method for implementing a network configuration protocol based on QUIC as described in claim 5, characterized in that, The NoQ padding layer uses QUIC extended frames to negotiate transmission parameters, including: The client and server negotiate an extended frame identifier through an undefined frame; The client and server negotiate to determine two types of extended frames, which are used to negotiate the transmission parameter structure and the transmission extended parameters, respectively. Each extended frame transmission parameter includes type, length and reserved fields. The client is a network management entity and the server is a network device.

7. The method for implementing a network configuration protocol based on QUIC as described in claim 1, characterized in that, The rules governing the establishment and closure of the QUIC connection include: The client initiates a connection, and the server accepts the connection. The client closes the connection, and the server closes the connection via the client's connection request. Normal connection closure requires waiting for all bound sessions to close; Close all sessions before forcibly closing the connection in case of an abnormality. Connection migration supports zero-trust third-party authentication or call home authentication; The client is a network management entity, and the server is a network device.

8. The method for implementing a network configuration protocol based on QUIC as described in claim 1, characterized in that, The rules governing the establishment, binding, and closure of the network configuration protocol sessions include: The client initiates a network configuration protocol session, and the server accepts the session and assigns an ID; The client closes the network configuration protocol session, and the server closes the session via the client. The NoQ padding layer binds multiple network configuration protocol sessions to a single QUIC connection; The client is a network management entity, and the server is a network device.

9. The method for implementing a network configuration protocol based on QUIC as described in claim 1, characterized in that, The rules governing the initiation, mapping, and management of QUIC streams include: The NoQ layer is responsible for bidirectional conversion between network configuration protocol messages and QUIC Streams, bidirectional parsing of QUIC Streams and QUIC packets, and mapping and state maintenance of QUIC Streams and network configuration protocols.

10. An apparatus for implementing a network configuration protocol based on QUIC, characterized in that, The device is used between a network management entity and network devices, and the device includes: The NoQ layer module is located between the application service layer and the QUIC layer. The NoQ layer module is used to map network configuration protocol messages to QUIC; to bind multiple network configuration protocol sessions to a single QUIC connection and allocate an independent QUIC stream to each session to achieve entity reuse; the NoQ layer module is also used to maintain the binding relationship between the network configuration protocol session state and the QUIC connection state to achieve state management.

Images