Message processing method and device and storage medium

Abstract

Provided in an embodiment of the present invention are a message processing method and device, and a storage medium, the message processing method comprising: acquiring a service aware network identifier corresponding to a user message to be sent, the user message being a message using an Internet protocol version 6 (IPv6) encapsulation format, the user message comprising a first IPv6 basic message header; encapsulating the service aware network identifier in a first I Pv6 basic message header to obtain an encapsulated user message; and sending the packaged user message to a network edge device. According to the embodiment of the invention, the fault processing scheme is determined by matching the event mode with the aggregation event, so that the fault processing efficiency is improved.

Description

Technical Field

[0001] The present invention relates to the field of communication technology, and in particular to a message processing method, device and storage medium. Background Art

[0002] Service Aware Network (SAN) is an architecture and concept for end-to-end, network-to-cloud integrated service scheduling, which aims to provide optimized network transmission and resource allocation according to the needs of applications and services. Service Aware Network Identifier (SAN-ID) is a key technology used in SAN to characterize computing network service requirements and network service requirements. SAN-ID can realize the external flexible supply of computing network and pure network services, thereby achieving the purpose of flexible scheduling of application-aware network and computing network resources.

[0003] At present, when implementing the message processing method for integrated scheduling of computing network or pure network service, the relevant technology sets the SAN-ID in the Internet Protocol Version 6 (IPv6) message and extends it based on the extended header option (SRV6 option) of the segment routing (Segment Routing IPv6, SRV6) of the IPv6 forwarding plane. Among them, the SRV6 option includes the destination options extended message header (Destination Options Header, DOH), the hop-by-hop options extended message header (Hop-by-Hop Options Header, HBH), the segment routing header (SegmentRouting Head, SRH), etc. However, this method has some disadvantages. For example, since the option adopts a fixed type-length-value (Type-Length-Value, TLV) data encoding format and a fixed header, the message overhead is large and the bandwidth resource utilization is low. In addition, since the device needs to deeply parse the fields in the TLV, the forwarding efficiency is low. Summary of the invention

[0004] An embodiment of the present invention provides a message processing method, device and storage medium. The message processing method reduces message overhead, improves bandwidth resource utilization, and enhances the message forwarding efficiency of the terminal device by encapsulating a service-aware network identifier in a first IPv6 basic message header.

[0005] In a first aspect, an embodiment of the present invention provides a message processing method, which is applied to a terminal and includes the following steps:

[0006] Obtaining a service-aware network identifier corresponding to a user message to be sent, wherein the user message is a message encapsulated in an Internet Protocol version 6 (IPv6) format, and the user message includes a first IPv6 basic message header;

[0007] Encapsulating the service-aware network identifier in the first IPv6 basic message header to obtain the encapsulated user message;

[0008] The encapsulated user message is sent to a network edge device.

[0009] In a second aspect, an embodiment of the present invention provides a message processing method, which is applied to a network edge device, and the method comprises the following steps:

[0010] Receiving a user message sent by a terminal, wherein the user message is a message encapsulated in an Internet Protocol version 6 (IPv6) format;

[0011] Determining a service-aware network identifier corresponding to the user message;

[0012] Encapsulating a tunnel message header in the user message to obtain a tunnel message, wherein the tunnel message header includes a second IPv6 basic message header;

[0013] Encapsulating the service-aware network identifier in the second IPv6 basic message header to obtain the encapsulated tunnel message;

[0014] The encapsulated tunnel message is sent to the next-hop network device.

[0015] In a third aspect, an embodiment of the present invention provides an electronic device, including:

[0016] one or more processors;

[0017] A memory having one or more programs stored thereon, wherein when the one or more programs are executed by the one or more processors, the one or more processors implement the message processing method as described in the first aspect above; or, the message processing method as described in the second aspect above.

[0018] In a fourth aspect, an embodiment of the present invention provides a computer-readable storage medium having a computer program stored thereon, wherein when the program is executed by a processor, the message processing method as described in the first aspect above is implemented; or, the message processing method as described in the second aspect above is implemented.

[0019] In an embodiment of the present invention, first, a service-aware network identifier corresponding to a user message to be sent is obtained, wherein the user message is a message encapsulation format using the sixth version of the Internet Protocol (IPv6), and the user message includes a first IPv6 basic message header. Then, the service-aware network identifier is encapsulated in the first IPv6 basic message header to obtain an encapsulated user message. At this time, the encapsulated user message can conveniently use a fixed TLV and a fixed header, thereby avoiding the need for deep parsing of the fields in the TLV. Thereafter, the encapsulated user message is sent to a network edge device. In an embodiment of the present invention, by encapsulating the service-aware network identifier in the first IPv6 basic message header, message overhead is reduced, bandwidth resource utilization is improved, and message forwarding efficiency of the terminal device is improved. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] The accompanying drawings are used to provide a further understanding of the technical solution of the present invention and constitute a part of the specification. Together with the embodiments of the present invention, they are used to explain the technical solution of the present invention and do not constitute a limitation on the technical solution of the present invention.

[0021] Figure 1 It is a schematic diagram of the structure of an IPv6 message provided by an embodiment of the present invention;

[0022] Figure 2A It is a schematic diagram of the structure of the SAN Header provided by an embodiment of the present invention;

[0023] Figure 2B It is a schematic diagram of encapsulating a SAN Header using an IPv6-based HBH option header according to an embodiment of the present invention;

[0024] Figure 2C It is a schematic diagram of encapsulating a SAN Header using a DOH option header based on IPv6 provided by an embodiment of the present invention;

[0025] Figure 3 is a schematic diagram of an application example of the computing network service provided by an embodiment of the present invention;

[0026] Figure 4 is a schematic diagram of an application example of a pure network-level service provided by an embodiment of the present invention;

[0027] Figure 5 It is a first flow chart of the message processing method provided by an embodiment of the present invention;

[0028] Figure 6 This is a schematic diagram of encapsulating a SAN-ID in a destination address field of a first IPv6 basic message header provided by an embodiment of the present invention;

[0029] Figure 7It is a schematic diagram of the encapsulation position of the SAN-ID encapsulated in the destination address field of the first IPv6 basic message header provided by an embodiment of the present invention;

[0030] Figure 8 It is a schematic diagram of the encapsulation position of the SAN-ID encapsulated in the flow label field of the first IPv6 basic message header provided by an embodiment of the present invention;

[0031] Fig. 9 is a second flow chart of the message processing method provided by an embodiment of the present invention;

[0032] Fig.10 It is a schematic diagram of the structure in which a SAN-ID is encapsulated in a source address field of a second IPv6 basic message header provided by an embodiment of the present invention;

[0033] Fig.11 It is a schematic diagram of the encapsulation position of the SAN-ID encapsulated in the source address field of the second IPv6 basic message header provided by an embodiment of the present invention;

[0034] Fig.12 It is a schematic diagram of an end-to-end service process implemented by SAN-ID encapsulation at a terminal according to an embodiment of the present invention;

[0035] Fig.13 It is a schematic diagram of implementing an end-to-end service process by performing message encapsulation of a SAN-ID at a network end provided by an embodiment of the present invention;

[0036] Fig.14 It is a schematic diagram of the device structure of an electronic device provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0037] In order to make the purpose, technical solution and advantages of the present invention more clearly understood, the present invention is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not used to limit the present invention.

[0038] It should be understood that in the description of the embodiments of the present invention, if there is a description of "first", "second", etc., it is only used for the purpose of distinguishing technical features, and cannot be understood as indicating or implying relative importance or implicitly indicating the number of indicated technical features or implicitly indicating the order of the indicated technical features. "At least one" means one or more, and "plurality" means two or more. "And / or" describes the association relationship of associated objects, indicating that three relationships may exist. For example, A and / or B can represent the situation where A exists alone, A and B exist at the same time, and B exists alone. Among them, A and B can be singular or plural. The character " / " generally indicates that the previous and next associated objects are in an "or" relationship. "At least one of the following" and similar expressions refer to any group of these items, including any group of single or plural items. For example, at least one of a, b and c can represent: a, b, c, a and b, a and c, b and c, or a and b and c, where a, b, c can be single or multiple.

[0039] In addition, the technical features involved in the various embodiments of the present invention described below can be combined with each other as long as they do not conflict with each other.

[0040] In order to facilitate understanding of the solutions of the embodiments of the present application and to make the description of the following embodiments clear and concise, a brief introduction to the relevant technologies is first given:

[0041] Service Aware Network (SAN): is an architecture and concept for end-to-end, network-to-cloud integrated service scheduling, which aims to provide optimized network transmission and resource allocation according to the needs of applications and services. Service Aware Network Identify (SAN-ID) is a key technology used in SAN to characterize computing network service requirements and network service requirements. SAN-ID can realize the external flexible supply of computing network and pure network services, thereby achieving the purpose of application-aware network and flexible scheduling of computing network resources.

[0042] Computing network: also known as computing power network or computing power network, refers to a network model based on distributed computing. The computing network uses a collection of numerous computing resources on the Internet to solve complex computing problems through distributed computing. The core of the computing network is to decompose computing tasks into multiple subtasks and assign these subtasks to different computing nodes for parallel computing. These computing nodes can be terminals with computing capabilities such as personal computers, servers, and mobile devices. Computing nodes communicate and collaborate through the network to jointly complete the entire computing task.

[0043] Segment Routing IPv6 (SRV6) is a network addressing and routing technology. SRV6 indicates the path of a data packet by adding a Segment Routing Header (SRH) to the header of an Internet Protocol Version 6 (IPv6) data packet.

[0044] SRV6 extended header option (SRV6 option): is a concept used to define the path and forwarding behavior of a data packet. In SRV6, the path of a data packet consists of a series of "Segments", each of which corresponds to a node or link in the network. The SRV6 option defines the information of these segments, including the IPv6 address of the segment, forwarding behavior, etc. By adding SRH to the IPv6 header of the data packet, the data packet can be instructed to be forwarded along a pre-defined path.

[0045] Destination Options Header (DOH): It is an extended header in the IPv6 protocol, used to carry additional option information in IPv6 packets. It can be used to provide some additional functions or services during packet transmission.

[0046] Hop-by-Hop Options Header (HBH): An extended header in the IPv6 protocol, used to transmit option information in IPv6 packets. Unlike DOH, HBH options must be processed by each router along the way.

[0047] SRH: It is an extended message header in the IPv6 protocol, which is used to implement segment routing (SR) technology. Segment routing is an emerging routing architecture that sets a series of segment identifiers on the predefined routing path in the data packet to guide the transmission path of the data packet in the network. SRH is located in the extended message header of the IPv6 data packet, immediately following the IPv6 fixed message header. It contains a series of segment identifiers, each of which corresponds to a node or link in the network. During the transmission process, the data packet is forwarded according to the path indicated by the segment identifier in the SRH, and the nodes on the path are accessed one by one in the set order.

[0048] Berkeley Packet Filter (BPF): is an encapsulation method used to implement network packet filtering and packet capture functions in the operating system kernel. The BPF encapsulation method adds a BPF encapsulation header to the header of the data packet to pass filtering rules and packet capture configuration during network transmission.

[0049] Figure 1 The schematic diagram of the structure of the IPv6 message is shown. The IPv6 message consists of three parts: the IPv6 basic message header, the IPv6 extended message header and the upper layer protocol data unit. The upper layer protocol data unit is generally composed of the upper layer protocol header and its payload. The payload refers to the data packet following the IPv6 basic message header, including the IPv6 extended message header. The extended message header is placed between the IPv6 header and the upper layer protocol data unit. An IPv6 message can contain 0, 1 or more extended message headers. Only when the device or destination node needs to do some special processing, the sender will add one or more extended headers. Unlike IPv4, the IPv6 extension header has an arbitrary length and is not limited to 40 bytes. For example, the payload can be an ICMPv6 message, a TCP6 message or a UDP6 message. The IPv6 basic message header has 8 fields with a fixed size of 40 bytes. Each IPv6 datagram must contain a message header.

[0050] The basic header provides basic information for message forwarding and will be parsed by all devices on the forwarding path. The basic header includes version number (Version), traffic class (Traffic Class), flow label (Flow Label), payload length (Payload Length), next header (Next Header), hop limit (Hop Limit), source address (Source Address, SA), and destination address (Destination Address, DA).

[0051] It should be noted that the IPv6 address length is 128 bits and can be written as eight hexadecimal strings. For example, 2001:0DB8:0000:1111:0000:0000:0000:0200. Since IPv6 has no subnet mask but a prefix length, 2001:0DB8:0000:1111 represents the IPv6 prefix, and the remaining 0000:0000:0000:0200 corresponds to the interface ID (i.e., interface identification) part (similar to the host part of IPv4).

[0052] At present, when implementing the message processing method for integrated scheduling of computing network or pure network services, the related technologies set the SAN-ID in the extended message header of IPv6, that is, the related technologies all encapsulate the SAN header in the SRV6 option of IPv6. Since the current option encapsulation scheme mainly includes the SRH header, HBH header, and DOH header, the SAN Header can be encapsulated in the DOH, HBH, and SRH of the extended message header. Figure 2 shows a structural schematic diagram of the SAN Header. The SAN Header contains Indicator, T, and Flag fields. The Indicator field is used to indicate the length of the SAN-ID; the T tag field is used to indicate the service type of the currently requested service, and the service type includes computing network service or pure network service; the Flag field is used to indicate the identification of the application extension.

[0053] Figure 2B A schematic diagram of SAN Header encapsulation based on IPv6 HBH option header is shown. The IPv6 HBH option header includes: Next Header, Header Extension Length (Hdr Ext Len), Option Type (Option Type, Opt Type) (where TAB1 is an example type tag), Option Data Length (Option Data Length, Opt Data Len) and SAN Header.

[0054] Figure 2C A schematic diagram of the DOH option header encapsulation of the SAN Header based on IPv6 is shown, wherein the DOH option header of IPv6 includes: Opt Type, Opt Data Len and SAN Header.

[0055] However, this approach has some disadvantages. For example, since the option uses a fixed type-length-value (TLV) data encoding format and a fixed header, it leads to high message overhead and low bandwidth resource utilization. In addition, since the device needs to deeply parse the fields in the TLV, the forwarding efficiency is low.

[0056] In order to solve the above problems, an embodiment of the present invention provides a message processing method, which reduces message overhead, improves bandwidth resource utilization, and improves the message forwarding efficiency of the terminal device by encapsulating the service-aware network identifier in the first IPv6 basic message header.

[0057] The embodiments described in the present invention may be implemented in a communication system, such as in at least one of the following systems: Global System for Mobile Communications (GSM) or any other second generation cellular communication system, Universal Mobile Telecommunications System (UMTA, 3G) based on basic Wideband Code Division Multiple Access (W-CDMA), High-Speed ​​Packet Access (HSPA), Long Term Evolution (LTE), Advanced LTE, systems based on IEEE 802.11 specifications, systems based on IEEE 802.15 specifications and / or fifth generation (5G) mobile or cellular communication systems; and future mobile communication systems. However, the embodiments are not limited to the systems given in the above examples, but those skilled in the art may apply the solutions to other communication systems having the necessary attributes.

[0058] The embodiments of the present invention are mainly used in SAN scenarios, specifically computing network service scenarios and pure network-level service scenarios, wherein the specific message processing method can be applied to various types of networks, including but not limited to the following networks, such as Internet Protocol (IP) network, Synchronous Digital Hierarchy (SDH) network, Packet Transport Network (PTN), IP Radio Access Network, etc.

[0059] As information networks are transforming from network infrastructure centered on information transmission to intelligent cloud network infrastructure that integrates computing, storage, and transmission resources, computing power network is a best practice and application of cloud-network integration. In the process of cloud-based services, it is necessary to comprehensively select computing power resource pools that meet the requirements based on network factors (latency, bandwidth, packet loss rate, etc.) and computing power factors (cost, etc.) to meet the requirements of various new applications and vertical industries.

[0060] Figure 3The schematic diagram of an application example of the computing network service is shown. The terminal device 311 of the terminal 310, which can also be called user equipment (UE), mobile station (MS), mobile terminal (MT), terminal, etc., is a device that provides voice and / or data connectivity to users, or a chip set in the device, for example, a handheld device with wireless connection function, a vehicle-mounted device, etc. At present, some examples of terminal devices are: mobile phones, desktop computers, tablet computers, laptops, PDAs, mobile Internet devices (MID), wearable devices, virtual reality (VR) devices, augmented reality (AR) devices, wireless terminals in industrial control (Industrial Control), wireless terminals in self-driving (Self Driving), wireless terminals in remote medical surgery (Remote Medical Surgery), wireless terminals in smart grid (Smart Grid), wireless terminals in transportation safety (Transportation Safety), wireless terminals in smart cities (Smart City), wireless terminals in smart homes (Smart Home), home gateway devices (5G-Residential Gateway, 5G-RG) supporting 5G access, etc.

[0061] The terminal device 311 has an application client installed. Application, also known as application software (APP), is a computer program for completing one or more specific tasks, usually requiring interaction with users, such as video applications, game applications, social applications, etc.

[0062] The network edge devices in the network end 320 can be, for example, base stations, customer premises equipment (Customer Premise equipment, CPE), access points (Access Point, AP), home gateways (Residential Gateway) and other devices. The network edge devices include ingress edge devices 321 (Ingress Provider Edge, Ingress PE) and egress edge devices 322 (Egress Provider Edge, Egress PE). Among them, the ingress edge device 321 is a network device or node, located at the boundary of the edge network, responsible for introducing the external traffic of the terminal device 311 into the network. The ingress edge device 321 is a key component in the service provider network, which is used to connect the external network and the service provider network, and introduce the external traffic into the service provider network for further routing and transmission. The ingress edge device 321 can be a physical device such as a router, a switch, or a server that deploys a virtual router or a virtual switch. The egress edge device 322 is used in pairs with the ingress edge device 321, and can form an edge router pair together. The egress edge device 322 is used to transmit the traffic in the network to the external network. The egress edge device 322 is connected to the cloud 330 for communication. The network end 320 is a computing example network or a pure network, which is not specifically limited here. The terminal device 311 is communicatively connected with the inlet edge device 321 of the network edge device.

[0063] The service points in the cloud 330 that can provide a certain type of computing power network include multiple service instances 331, and each service instance is located in a different cloud resource pool of the cloud network 130. Among them, each service instance 331 includes a cloud load balancer 332 (Loader balance, LB) and a server 333. For example, if a user of a terminal device 311 wants to access a certain service, it is necessary to comprehensively consider network factors and computing power factors to allocate and select the computing power resource pool. The selection of service instances in this computing power resource pool is no longer something that can be accomplished by traditional IP routing. It is necessary to address and select service instances based on service + routing. This service that requires comprehensive computing network is a computing network service.

[0064] In the embodiment of the present application, the IPv6-based user message reaches the server 333 through the forwarding path between the ingress edge device 321 and the egress edge device 322 .

[0065] Figure 4A schematic diagram of an application example of a pure network-level service is shown. With the rise of vertical industries, the traffic into and between clouds is increasing, and the requirements for network quality are getting higher and higher and the demands are different. The current network can provide certain slices or dedicated line capabilities, but the slice granularity is relatively coarse, resulting in large bandwidth, low latency, etc. The terminal device 311 is communicated with the network operation platform 410 and the underlay network 420 respectively. The network operation platform 410 is communicated with the network orchestrator 430, and the network orchestrator 430 is communicated with the underlay network 420. Among them, the network orchestrator 430 orchestrates multiple service instances in the underlying network. The network operation platform 410 generates a corresponding SAN-ID for each service instance and publishes the SAN-ID to the client. Afterwards, the terminal device 311 consumes the service and carries the SAN-ID corresponding to the consumed service in the service request.

[0066] It should be noted that the underlay network refers to the underlying network infrastructure that supports the operation of the upper-layer network. It provides a physical or virtual network connection for transmitting data packets. The underlay network is usually composed of network devices, links, transmission protocols, etc., and is used to provide reliable data transmission to ensure that data can be correctly transmitted to the destination in the network. In software-defined networks, the underlay network can be a physical network or a virtual network.

[0067] like Figure 5 As shown, it is a flow chart of a message processing method provided by an embodiment of the present invention, which is applied to a terminal. The implementation process of the method may include but is not limited to the following steps S510-S530. Each step is introduced in turn below:

[0068] Step S510, obtaining a service-aware network identifier corresponding to a user message to be sent, wherein the user message is a message encapsulation format using Internet Protocol version 6 (IPv6), and the user message includes a first IPv6 basic message header.

[0069] It should be noted that, no matter it is a computing network service or a pure network-level service, a SAN-ID is required. The SAN-ID refers to an identifier that uniquely identifies a device in a SAN in a computing network service or a pure network-level service.

[0070] Step S520: encapsulate the service-aware network identifier in the first IPv6 basic message header to obtain an encapsulated user message.

[0071] It can be understood that the embodiment of the present invention encapsulates the SAN-ID in the first IPv6 basic message header, which can effectively avoid deep parsing of the option. Compared with the SAN header format used in the past, only the SAN ID is carried in the IPv6 basic message header, and the original Indicator, T tag, and Flag fields are removed, thereby realizing a lightweight structure of the SAN-ID, reducing message overhead, improving bandwidth resource utilization, and enhancing the message forwarding efficiency of the terminal device.

[0072] In some embodiments, the length of the service-aware network identifier is 16 bits or 32 bits.

[0073] In some embodiments, the first IPv6 basic message header includes a destination address field, and the service-aware network identifier is encapsulated in the destination address field.

[0074] In some embodiments, the destination address field includes a function field, and the service-aware network identifier is encapsulated in the Function field.

[0075] It should be noted that, since the Function field of the destination address itself is a programmable function field, encapsulating the SAN-ID in the Function of the destination address can improve the flexibility of the SAN-ID.

[0076] For example, Figure 6 As shown, Figure 6 The encapsulation diagram of SAN-ID encapsulation in the destination address field of the first IPv6 basic message header is shown. SAN-ID is encapsulated in the destination address field of the first IPv6 basic message header, that is, encapsulated in the segment identifier (Segment Routing IPv6 Segment Identifier, SRV6SID) of the segment routing based on the IPv6 forwarding plane. SRV6 SID refers to an identifier used to uniquely identify a segment. The format of SRV6 SID is usually a 128-bit IPv6 address, which contains some specific fields for indicating the type and operation of the segment. When the length of the destination address field 610 of the first IPv6 basic message header is 16 bytes, that is, 128 bits. The destination address field 610 is used to indicate the field for storing the recipient address. The destination address field 610 includes a locator field, a function field, and a specified arguments field. The locator field is used to indicate the IPv6 address of the next hop node or link on the path. The function field is used to indicate the operation or service on the path. The Arguments field is used to specify the requested operation type, requested resources, or other required parameters.

[0077] It should be noted that the Locator field includes provincial location information and node information. Among them, the provincial location information includes the unified planning prefix field and the SRV6 reserved field; the node information includes the network level identification field and the node number field. The Function field includes the type field and the assigned value field. The type field is used to indicate the service type of the currently requested service. The assigned value field is used to store the SAN-ID.

[0078] For example, Figure 7 As shown, Figure 7 The diagram shows the encapsulation position of SAN-ID encapsulated in the destination address field of the first IPv6 basic message header. The first IPv6 basic message header includes Version, Traffic Class, FlowLabel, Payload Length, Next Header, Hop Limit, SA, and DA. The DA includes the Locator field, the Function field, and the Arguments field.

[0079] It should be noted that the length of the Locator field is 32-bit to 80-bit, the length of the Function field is 32-bit, and the length of the Arguments field is 16-bit. In addition, the Function field is used to encapsulate the SAN-ID.

[0080] It should be noted that the field length of the version number is 4 bits, and for IPv6, the field length can be 6 bits.

[0081] It should be noted that the flow category field length is 8 bits, and the flow category field is equivalent to the Type of Service (TOS) field in IPv4, which is used to indicate the class or priority of the IPv6 datagram.

[0082] It should be noted that the length of the flow label field is 20 bits. The flow label field is a new field in IPv6, which is used to distinguish real-time traffic. Different flow labels + source addresses can uniquely identify a data flow. Network edge devices can distinguish data flows more efficiently based on this information.

[0083] It should be noted that the length of the payload length field is 16 bits. The payload refers to the other parts of the datagram that follow the IPv6 header (i.e., the extension header and the upper-layer protocol data unit). This field can only represent a payload with a maximum length of 65535 bytes. If the payload length exceeds this value, the field will be set to 0, and the payload length will be indicated by the oversized payload option in the Hop-by-Hop Options extension header.

[0084] It should be noted that the length of the Next Header field is 8 bits. This field defines the type of the first extension header (if any) immediately following the IPv6 header, or the protocol type in the upper layer protocol data unit.

[0085] It should be noted that the length of the hop limit field is 8 bits. This field is similar to the Time to Live field in IPv4. It defines the maximum number of hops that an IPv6 datagram can go through. The value is reduced by 1 for each device it passes through. When the value of this field is 0, the datagram will be discarded.

[0086] It should be noted that the length of the SA field is 128 bits, which is used to indicate the address of the sender. The length of the DA field is 128 bits, which is used to indicate the address of the receiver.

[0087] In some embodiments, the first IPv6 basic message header includes a flow label field, and the terminal may encapsulate the service-aware network identifier in the flow label field.

[0088] It is understandable that in the related technical solution, the SAN header occupies more space, resulting in low bandwidth utilization. In addition, the related technical solution requires the terminal to support SRv6, but in fact some terminals do not support SRv6. Therefore, if the SAN-ID is encapsulated in the flow label, the solution only requires the terminal to support IPv6, which can effectively solve the limitations of the related technology in practical applications.

[0089] For example, Figure 8 As shown, Figure 8 The diagram shows the encapsulation position of SAN-ID encapsulated in the flow label field of the first IPv6 basic message header. The first IPv6 basic message header includes Version, Traffic Class, FlowLabel, Payload Length, Next Header, Hop Limit, SA, and DA. In addition, SAN-ID is encapsulated in the flow label field Flow Label.

[0090] It should be noted that, since the source address on the terminal side involves the routing function, the terminal side cannot use the source address to encapsulate the SAN-ID, and can only use the destination address and flow label for encapsulation. In addition, if encapsulated in the destination address, since the destination address itself has a Function field (programmable function field), the SAN-ID can be encapsulated in the Function of the destination address, while the source address does not have a Function field.

[0091] Step S530: Send the encapsulated user message to the network edge device.

[0092] It can be understood that the terminal device 311 sends the encapsulated user message to the ingress edge device of the network edge device.

[0093] In some embodiments, the message processing method of an embodiment of the present invention also includes: receiving encapsulation indication information transmitted in an out-of-band transmission manner, the encapsulation indication information including at least one of the following information: encapsulation position indication information of the service-aware network identifier, and encapsulation length indication information of the service-aware network identifier.

[0094] It is understandable that, for a terminal, the encapsulation position and encapsulation length information can be transmitted to the terminal through an out-of-band transmission mode to pre-configure the encapsulation position and encapsulation length. The encapsulation position indication information of the terminal is used to indicate the parameters for encapsulating the SAN-ID into the destination address field or the flow label field of the first IPv6 basic message header. The encapsulation length indication information of the terminal is used to indicate the data length parameter occupied by encapsulating the SAN-ID into the destination address field or the flow label field of the first IPv6 basic message header.

[0095] In some embodiments, Fig. 9 As shown, another flow chart of a message processing method provided by an embodiment of the present invention is shown. The method is applied to a network edge device. The implementation process of the method may include but is not limited to the following steps S910-S950. Each step is introduced in turn below:

[0096] Step S910: receiving a user message sent by a terminal, wherein the user message is a message encapsulated in an Internet Protocol version 6 (IPv6) format.

[0097] It is understandable that the network edge device receives the user message sent by the terminal in the IPv6 encapsulation format. In addition, the specific encapsulation process of the user message is referred to the above steps S510 to S530, which will not be repeated here.

[0098] Step S920: determine the service-aware network identifier corresponding to the user message.

[0099] It is understandable that, since the user message can encapsulate the SAN-ID in the function field of the destination address field of the first IPv6 basic message header, or encapsulate the service-aware network identifier SAN-ID in the flow label field, the encapsulated SAN-ID can be obtained from the corresponding position of the encapsulation.

[0100] In some embodiments, the user message received by the network edge device may not carry the SAN-ID, and the network edge device determines the SAN-ID according to the user identifier.

[0101] In some embodiments, the length of the SAD-ID determined by the network edge device is 16 bits or 32 bits.

[0102] Step S930: encapsulate a tunnel message header in the user message to obtain a tunnel message, wherein the tunnel message header includes a second IPv6 basic message header.

[0103] It can be understood that a tunnel message is a message generated by a data packet encapsulation technology in network communication. Tunnel messages are transmitted in the network by adding an additional encapsulation header to the header of the original data packet, so as to encapsulate a data packet of one network protocol into another network protocol. Tunnel messages can be used to solve intercommunication problems in different network environments, such as transmitting IPv6 data packets in an IPv4 network, or transmitting data packets of a private network in a public network. By adding additional information to the encapsulation header of the original data packet, tunnel messages can hide the details of the underlying protocol, allowing different networks to communicate with each other.

[0104] In some embodiments, the tunnel message header further includes a segment routing header SRH. The segment routing header SRH can be used to indicate the path of the data packet and can be used to implement functions such as flexible traffic engineering, path optimization and network quality of service (QoS).

[0105] Step S940: encapsulate the service-aware network identifier in the second IPv6 basic message header to obtain an encapsulated tunnel message.

[0106] In some embodiments, the second IPv6 basic message header includes a destination address field, and the service-aware network identifier is encapsulated in the destination address field.

[0107] In some embodiments, the destination address field of the second IPv6 basic message header includes a function field, and the service-aware network identifier is encapsulated in the Function field.

[0108] It should be noted that the process of encapsulating the SAN-ID in the destination address field of the second IPv6 basic message header in the network edge device can refer to the process of encapsulating the SAN-ID identifier in the destination address field of the first IPv6 basic message header in the terminal in the above embodiment, and will not be repeated here.

[0109] In some embodiments, the second IPv6 basic message header includes a source address field, and the service-aware network identifier is encapsulated in the source address field.

[0110] In some embodiments, the source address field includes a prefix field and an interface identification field, and the service-aware network identification is encapsulated in the interface identification field.

[0111] It is understandable that, since the IPv6 address is composed of prefix + interface address, the source address on the terminal side needs to be used for routing, while the source address on the network side is generally only used as a tunnel identifier, so only the prefix needs to be retained on the network side, and the subsequent interface address part can be programmed. Therefore, the network side can encapsulate the SAN-ID in the interface identifier field of the source address.

[0112] For example, Fig.10 The schematic diagram of the structure of the second IPv6 basic message header encapsulating the SAN-ID in the source address field is shown. The source address field 1010 of the second IPv6 basic message header after encapsulation includes a prefix address field, a NodeID field, a SAN-ID field, and a Padding field. Among them, the field length of the prefix address field is 48 bits, and the field length of the NodeID field is 32 bits. The field length occupied by the SAN-ID encapsulation in the interface identification part of the source address is 16 bits or 32 bits, and the field length of the Padding field is 16 bits or 32 bits.

[0113] It should be noted that the NodeID field in the source address field refers to a unique identifier of a network node. The NodeID field is used to identify a device, router or server in the network.

[0114] It should be noted that the Padding field refers to the extra data used to fill the blank part in the data packet. In network communication, the size of the data packet is usually fixed, but the actual transmitted data may not always fill the entire data packet. In order to meet the data packet size requirements, padding data is added to the data packet to make it reach the required size.

[0115] For example, Fig.11 The diagram shows the encapsulation position of the second IPv6 basic message header encapsulating the SAN-ID in the source address field. The second IPv6 basic message header includes Version, Traffic Class, Flow Label, Payload Length, Next Header, Hop Limit, and encapsulated SA and DA.

[0116] It is understandable that network edge devices encapsulate SAN-ID in SA to improve the forwarding efficiency and bandwidth utilization of the devices.

[0117] In some embodiments, the second IPv6 basic message header includes a flow label field, and the service-aware network identifier is encapsulated in the flow label field.

[0118] It can be understood that the process of encapsulating the SAN-ID in the flow label field of the second IPv6 basic message header in the network edge device can refer to the process of encapsulating the SAN-ID identifier in the flow label field of the first IPv6 basic message header in the terminal in the above embodiment, and will not be repeated here.

[0119] Step S950: Send the encapsulated tunnel message to the next-hop network device.

[0120] It is understandable that the next-hop network device of the network edge device sends the encapsulated tunnel message, wherein the network edge device can be any edge device in the computing network.

[0121] It should be noted that, for network edge devices, the encapsulation position and encapsulation length information can be transmitted from the network management to the terminal to pre-configure the encapsulation position and encapsulation length. The encapsulation position indication information of the network edge device is used to indicate the parameters for encapsulating the SAN-ID into the destination address field, flow label field or source address of the first IPv6 basic message header. The encapsulation length indication information of the network edge device is used to indicate the data length parameters occupied by encapsulating the SAN-ID into the destination address field, flow label field or source address of the first IPv6 basic message header.

[0122] It should be noted that the user message encapsulated on the terminal side is the original message. When it reaches the network edge device, the tunnel message header will be encapsulated in the outer layer of the original message. The tunnel message header will copy the IPv6 message header information of the inner user message (that is, both the outer layer and the memory have an IP header). During the transmission process on the network side, only the outer layer tunnel will be processed, and the inner user message will not be processed. When it reaches the user side of the other end, the user on the other end will remove the outer layer tunnel, thereby popping up the user message.

[0123] For example, in a specific embodiment 1, Fig.12 As shown, Fig.12The schematic diagram of implementing the end-to-end service process by encapsulating the SAN-ID on the terminal side is shown. Specifically, the terminal 310 obtains the SAN-ID corresponding to the user message to be sent by the network operator. The terminal 310 encapsulates the SAN-ID in the Flow Label of the first IPv6 basic message header (i.e., encapsulation position 1 in the figure) or the destination address DA of the first IPv6 basic message header (i.e., encapsulation position 2 in the figure). Then, the terminal 310 sends the encapsulated user message to the network edge device of the network end 320. The network edge device includes but is not limited to the edge device 1210 of the Ingress PE and the edge device 1220 of the Egress PE. The edge device 1210 of the Ingress PE can encapsulate the tunnel message header in the user message after receiving and determining the SAN-ID corresponding to the user message sent by the terminal according to the actual business, and obtains the tunnel message. After that, the edge device 1210 of the Ingress PE sends the encapsulated tunnel message to the next-hop network device. The Ingress PE and the Egress PE of the network end 320 can perform the scheduling of network services or computing network services according to the semantics of the SAN-ID. When exiting the network 320, the outer tunnel of the tunnel message is decapsulated, the outer tunnel and its corresponding SAN-ID are deleted, and the inner user message is not processed. After the outer tunnel is removed, the pop-up user message carries the SAN-ID and enters the cloud 330, and the cloud 330 executes the service scheduling in the cloud 330 according to the set requirements and SAN-ID.

[0124] It should be noted that, in the user message sent by the terminal 310, the message can be encapsulated by SAN-ID using BPF or a method of setting a socket option, which will not be described in detail here.

[0125] For example, in a specific embodiment 2, Fig.13 As shown, Fig.13The schematic diagram of SAN-ID encapsulating the message at the network end to realize the end-to-end service process is shown. Specifically, when the encapsulated user message enters the network end 320, the network edge device maps the five-tuple of the encapsulated user message (i.e., including the source IP address, the destination IP address, the protocol number, the source port, and the destination port) into a SAN-ID according to the mapping controlled by the network, that is, the SAN-ID corresponding to the user message is determined. Then, the SAN-ID is encapsulated in the source address field of the second IPv6 basic message header of the outer tunnel (i.e., the encapsulation position 3 in the figure), or the SAN-ID is encapsulated in the flow label field of the second IPv6 basic message header of the outer tunnel (i.e., the encapsulation position 4 in the figure); or, the SAN-ID is encapsulated in the function field of the destination address field of the second IPv6 basic message header of the outer tunnel (i.e., the encapsulation position 5 in the figure), that is, the SAN-ID is encapsulated in the second IPv6 basic message header to obtain the encapsulated tunnel message. Then, when the encapsulated tunnel message passes through the network end 320, the Ingress PE of the network end 320 performs the scheduling of network services or computing network services, and the conversion edge device (transmit PE) of the network domain can perform functions such as flow OAM detection as needed. The Egress PE of the network domain performs the decapsulation of the tunnel message in the tunnel, removes the outer tunnel and its corresponding SAN-ID, and does not process the inner user message. After removing the outer tunnel, the pop-up user message carries the SAN-ID into the cloud 330. After that, the relevant FIB table is queried according to the destination address of the tunnel message, and the traffic is imported into the cloud 330.

[0126] The embodiment of the present invention redefines the encapsulation position of SAN-ID in IPv6 message. Specifically, the terminal device can encapsulate SAN-ID in any of the function field and flow label field of the destination address field of the first IPv6 basic message header to obtain the encapsulated user message. The network edge device can encapsulate SAN-ID in any of the function field, flow label field and source address field of the destination address field of the second IPv6 basic message header to obtain the encapsulated tunnel message.

[0127] It should be noted that, since the source address on the terminal side involves the routing function, the terminal side cannot use the source address to encapsulate the SAN-ID, and can only use the destination address and flow label for encapsulation. The source address on the network side is generally only used as a tunnel identifier, so only the prefix needs to be retained on the network side, and the interface address part behind it is programmable, so the network side can use the source address to encapsulate the SAN-ID.

[0128] The embodiment of the present invention can avoid the problem of low bandwidth utilization caused by the SAN header occupying more space by encapsulating the SAN-ID in FL / DA / SA. Compared with the SAN header form used in the past, the Flag and Indicator in the SAN header are only the variable parts marked with the service identifier displayed in the message, which is convenient for message parsing. This part of the content can be not carried in the message encapsulation. Therefore, the embodiment of the present invention only carries the SAN-ID in the IPv6 header, removes the original Indicator, T label, and Flag fields, and only encapsulates the SAN-ID in the message encapsulation. The flexible length of the SAN-ID is specified by the control plane of the network element, thereby reducing the encapsulation length of the entire service identifier and achieving the goal of lightweight. In addition, the relevant technical solution requires the terminal to support SRv6, but some terminals do not support SRv6. Therefore, if the SAN-ID is encapsulated in the flow label of this solution, it only requires the terminal to support IPv6, which can effectively solve the limitations of the relevant technology in practical applications. It can be seen that the embodiment of the present invention can realize the lightweight structure of SAN-ID, reduce the message overhead, and effectively improve the forwarding efficiency of the device and the utilization of the bandwidth occupied by the end-to-end service.

[0129] It should be noted that, although the operations are described in a specific order in the drawings in the embodiments of the present invention, it should not be understood as requiring the operations to be performed in the specific order or serial order shown, or requiring the execution of all the operations shown to obtain the desired results. In certain environments, multitasking and parallel processing may be advantageous.

[0130] In addition, in the embodiments of the present invention, the description of each embodiment has its own emphasis. For parts that are not described or recorded in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0131] The embodiment of the present invention further provides an electronic device, such as Fig.14 As shown, the electronic device 1400 includes but is not limited to:

[0132] Processor 1410 and memory 1420;

[0133] The memory 1420 stores program instructions, and when the program instructions are executed by the processor 1410, the processor 1410 executes the message processing method described in any of the above embodiments.

[0134] The processor 1410 and the memory 1420 may be connected via a bus or other means.

[0135] It should be understood that the processor 1410 may be a central processing unit (CPU). The processor may also be other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field programmable gate arrays (FPGA) or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or the processor may be any conventional processor, etc. Alternatively, the processor 1410 may be one or more integrated circuits for executing related programs to implement the technical solutions provided in the embodiments of the present invention.

[0136] The memory 1420 , as a non-transitory computer-readable storage medium, may be used to store non-transitory software programs and non-transitory computer executable programs, such as the message processing method described in any embodiment of the present invention.

[0137] The processor 1410 implements the above-mentioned message processing method by running the non-transitory software program and instructions stored in the memory 1420.

[0138] The memory 1420 may include a program storage area and a data storage area, wherein the program storage area may store an operating system and an application required for at least one function; the data storage area may store and execute the above-mentioned message processing method. In addition, the memory 1420 may include a high-speed random access memory, and may also include a non-volatile memory, such as at least one disk storage device, a flash memory device, or other non-volatile solid-state storage device. In some embodiments, the memory 1420 may optionally include a memory remotely arranged relative to the processor 1410, and these remote memories may be connected to the processor 1410 via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0139] The non-transient software programs and instructions required to implement the above-mentioned message processing method are stored in the memory 1420, and when executed by one or more processors 1410, the message processing method provided by any embodiment of the present invention is executed.

[0140] An embodiment of the present invention further provides a computer-readable storage medium, wherein the computer-readable storage medium stores program instructions, and when the program instructions are executed by a computer, the message processing method described in any of the above embodiments is implemented.

[0141] The computer storage medium of the embodiment of the present invention may adopt any combination of one or more computer-readable media. The computer-readable medium may be a computer-readable signal medium or a computer-readable storage medium. The computer-readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, or any combination thereof. More specific examples (non-exhaustive list) of computer-readable storage media include: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (ElectricalProgrammable Read Only Memory or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof. In this document, a computer-readable storage medium may be any tangible medium containing or storing a program, which may be used by or in combination with an instruction execution system, device or device.

[0142] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, which carry computer-readable program code. Such propagated data signals may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. Computer-readable signal media may also be any computer-readable medium other than a computer-readable storage medium, which may send, propagate, or transmit a program for use by or in conjunction with an instruction execution system, apparatus, or device.

[0143] The program code contained on the computer readable medium can be transmitted using any appropriate medium, including but not limited to wireless, wire, optical cable, electromagnetic frequency (Radio Frequency, RF), etc., or any suitable combination of the above.

[0144] Computer program codes for performing the operations of the present application may be written in one or more programming languages ​​or combinations thereof, including object-oriented programming languages, such as Java, Smalltalk, C++, and conventional procedural programming languages, such as "C" or similar programming languages. The program code may be executed entirely on the user's computer, partially on the user's computer, as an independent software package, partially on the user's computer, partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., using an Internet service provider to connect via the Internet).

[0145] The above is a specific description of the preferred implementation of the present invention, but the present invention is not limited to the above implementation. Those skilled in the art can make various equivalent modifications or substitutions without violating the spirit of the present invention. These equivalent modifications or substitutions are all included in the scope defined by the claims of the present invention.

Claims

1. A message processing method, the method being applied to a terminal, the method comprising the following steps: Obtaining a service-aware network identifier corresponding to a user message to be sent, wherein the user message is a message encapsulated in an Internet Protocol version 6 (IPv6) format, and the user message includes a first IPv6 basic message header; Encapsulating the service-aware network identifier in the first IPv6 basic message header to obtain the encapsulated user message; The encapsulated user message is sent to a network edge device.

2. The method according to claim 1, characterized in that The first IPv6 basic message header includes a destination address field, and the service-aware network identifier is encapsulated in the destination address field.

3. The method according to claim 2, characterized in that The destination address field includes a function field, and the service-aware network identifier is encapsulated in the Function field.

4. The method according to claim 1, characterized in that: The first IPv6 basic message header includes a flow label field, and the service-aware network identifier is encapsulated in the flow label field.

5. The method according to any one of claims 1 to 4, characterized in that: The length of the service-aware network identifier is 16 bits or 32 bits.

6. The method according to any one of claims 1 to 4, further comprising: Encapsulation indication information transmitted in an out-of-band transmission manner is received, where the encapsulation indication information includes at least one of the following information: encapsulation position indication information of the service-aware network identifier and encapsulation length indication information of the service-aware network identifier.

7. A message processing method, the method being applied to a network edge device, the method comprising the following steps: Receiving a user message sent by a terminal, wherein the user message is a message encapsulated in an Internet Protocol version 6 (IPv6) format; Determining a service-aware network identifier corresponding to the user message; Encapsulating a tunnel message header in the user message to obtain a tunnel message, wherein the tunnel message header includes a second IPv6 basic message header; Encapsulating the service-aware network identifier in the second IPv6 basic message header to obtain the encapsulated tunnel message; The encapsulated tunnel message is sent to the next-hop network device.

8. The method according to claim 7, characterized in that The second IPv6 basic message header includes a source address field, and the service-aware network identifier is encapsulated in the source address field.

9. The method according to claim 8, characterized in that The source address field includes a prefix field and an interface identification field, and the service-aware network identifier is encapsulated in the interface identification field.

10. The method according to claim 7, characterized in that The second IPv6 basic message header includes a destination address field, and the service-aware network identifier is encapsulated in the destination address field.

11. The method according to claim 10, characterized in that The destination address field includes a function field, and the service-aware network identifier is encapsulated in the Function field.

12. The method according to claim 7, characterized in that The second IPv6 basic message header includes a flow label field, and the service-aware network identifier is encapsulated in the flow label field.

13. The method according to any one of claims 7 to 12, characterized in that: The length of the service-aware network identifier is 16 bits or 32 bits.

14. The method according to any one of claims 7 to 12, characterized in that: The method further comprises: Encapsulation indication information sent by a network management device is received, where the encapsulation indication information includes at least one of the following information: encapsulation position indication information of a service-aware network identifier and encapsulation length indication information of a service-aware network identifier.

15. The method according to any one of claims 7 to 12, characterized in that: The tunnel message header also includes a segment routing header SRH.

16. An electronic device, comprising: one or more processors; A memory having one or more programs stored thereon, when the one or more programs are executed by the one or more processors, the one or more processors implement: The method according to any one of claims 1 to 6; or, A method as claimed in any one of claims 7 to 15.

17. A computer-readable storage medium having a computer program stored thereon, wherein when the program is executed by a processor, the program implements: The method according to any one of claims 1 to 6; or, A method as claimed in any one of claims 7 to 15.

Images