CN117579285A

CN117579285A - Traffic forwarding method, device, equipment and storage medium in service network

Info

Publication number: CN117579285A
Application number: CN202311596948.3A
Authority: CN
Inventors: 李雪婷; 王爱俊; 王巍
Original assignee: China Telecom Technology Innovation Center; China Telecom Corp Ltd
Current assignee: China Telecom Technology Innovation Center; China Telecom Corp Ltd
Priority date: 2023-11-27
Filing date: 2023-11-27
Publication date: 2024-02-20

Abstract

The embodiment of the disclosure provides a method and a device for forwarding traffic in a service network, comprising the following steps: receiving a service request sent by a Pod bearing a plurality of micro services; based on the service request, sending a prefix authentication request to the SPA; the prefix authentication request at least comprises the following steps: the Pod identity information and the service prefix signature information; and responding to the SPA to pass the authentication of the prefix authentication request, and carrying out traffic forwarding processing on the service request according to the service prefix. By providing digital signature for the service prefix of the micro-service, and by SPA, verifying the validity and validity of the service prefix announced by the Pod to which the micro-service belongs through the service gateway. Only authorized micro services can participate in the communication, and the safety and the credibility of the communication are ensured. A security mechanism is provided for traffic forwarding in a servitized network.

Description

Traffic forwarding method, device, equipment and storage medium in service network

Technical Field

The disclosure relates to the technical field of communication, and in particular relates to a traffic forwarding method, a traffic forwarding device, electronic equipment and a storage medium in a service network.

Background

A server network based on a named data network (Named Data Networking, NDN) is a promising research direction in information centric networks (Information Central Network, ICN). NDN is a content-oriented network architecture that is data-centric rather than host-centric. It makes service discovery and communication more flexible and decentralised by uniquely identifying the data using a data name.

With the rise of cloud computing and micro-Service architecture, a Service Mesh (servicemesh) becomes an important component for constructing distributed applications and micro-Service communications. The service network simplifies the complex micro-service architecture management and communication problems by providing functions such as inter-service communication, load balancing, service discovery, security authentication and the like. However, current servitized network traffic forwarding is based primarily on a traditional centralized control plane, which results in some challenges, in a centralized architecture, the central control point becomes a potential performance bottleneck in handling all traffic. Routing traffic through the central controller may increase latency, which may adversely affect overall system performance. As the number of micro-services and traffic grows, centralized control points can face challenges in efficiently managing the ever-increasing traffic loads.

It should be noted that the information disclosed in the above background section is only for enhancing understanding of the background of the present disclosure and thus may include information that does not constitute prior art known to those of ordinary skill in the art.

Disclosure of Invention

The embodiment of the disclosure provides a traffic forwarding method, a traffic forwarding device, electronic equipment and a storage medium in a service network.

Other features and advantages of the present disclosure will be apparent from the following detailed description, or may be learned in part by the practice of the disclosure.

According to one aspect of the present disclosure, there is provided a traffic forwarding method in a Service Gateway (SG), applied to a Service Gateway (SG), the method including: receiving a service request sent by a Pod bearing a plurality of micro services; the service request corresponds to any micro-service; the service request at least comprises the following steps: pod identity information, service prefix signature information, service content information; the service prefix signature information is obtained by carrying out signature processing based on the service prefix corresponding to the micro service; based on the service request, sending a prefix authentication request to a service prefix authentication (Service Prefix Authentication, SPA); the prefix authentication request at least comprises the following steps: the Pod identity information and the service prefix signature information; and responding to the SPA to pass the authentication of the prefix authentication request, and carrying out flow forwarding processing on the service request according to the service prefix corresponding to the micro service.

In an exemplary embodiment, before receiving the service request, the micro service registers a corresponding service prefix with the SG in advance, and the registration method includes: the Pod generates a set of key pairs for the micro-service, the key pairs including private keys and public keys; respectively receiving the public key sent by the Pod and a prefix registration request sent by the Pod; the prefix registration request at least comprises the service prefix signature information; the service prefix signature information is obtained by carrying out signature processing on the service prefix corresponding to the micro service based on the private key; signature verification is carried out on the service prefix signature information through the public key; and establishing a binding relationship based on the micro service, the service prefix and the public key and transmitting the binding relationship to the SPA in response to the service prefix signature information verification passing.

In an exemplary embodiment, the registration method further includes: the prefix registration request also comprises the Pod identity information; the binding relationship also comprises the Pod identity information.

In an exemplary embodiment, the SPA authenticates the prefix authentication request, and the authentication method includes: verifying the legality of the Pod according to the Pod identity information; according to the binding relation, signature verification is carried out on the service prefix signature information based on the public key corresponding to the micro service; and determining whether the prefix authentication request passes authentication or not according to the Pod validity verification result and the signature verification result.

In an exemplary embodiment, the authentication method further includes: decrypting the service prefix signature information based on the public key to obtain the service prefix; matching the service prefix with a preset legal prefix list, and determining whether the service prefix is legal or not; confirming that the service prefix and the Pod identity information accord with the binding relation; and determining whether the prefix authentication request passes authentication or not according to the service prefix validity verification result and the binding relation verification result.

In an exemplary embodiment, the authentication method further includes: the binding relationship also comprises service authority information; the service right information is used for representing the service right corresponding to the micro service; decrypting the service prefix signature information based on the public key to obtain the service prefix; and determining the service authority information corresponding to the service prefix according to the binding relation.

In an exemplary embodiment, the performing, according to the service prefix corresponding to the micro service, a traffic forwarding process on the service request includes: determining the service request as an interest packet according to the service content information; determining whether matching Content data is retained in a local Content Store (CS) according to the service prefix; returning the content data to the micro-service in response to the CS retaining the matched content data; determining whether a first interest packet matching the interest packet is retained in a local pending interest table (Pending Interest Table, PIT) in response to no matching content data being retained in the CS; responding to the PIT and reserving a matched first interest message, and adding the Pod identity information and the micro-service information into the first interest message; generating a second interest message according to the service request in response to the fact that the matched first interest message is not reserved in the PIT; and reserving the second interest message in the PIT, and forwarding the second interest message according to a forwarding information base (Forwarding Information Base, FIB).

In an exemplary embodiment, the performing, according to the service prefix corresponding to the micro service, a traffic forwarding process on the service request includes: determining the service request as a data packet according to the service content information; determining whether a data request message matched with the data packet is reserved in the local PIT according to the service prefix; responding to the PIT with the matched data request message, and acquiring a data request list corresponding to the data request message; and forwarding the data packet according to the FIB and the data request list.

In an exemplary embodiment, the performing, according to the service prefix corresponding to the micro service, a traffic forwarding process on the service request includes: receiving the forwarded data packet; the content data corresponding to the data packet is reserved in the CS; determining whether interest messages matched with the data packets are reserved in the PIT; and responding to the interest message which remains in the PIT and is matched with the interest message, and forwarding the content data corresponding to the data packet to the micro-service carried by the corresponding Pod according to the interest message.

In an exemplary embodiment, the FIB is generated according to the following method: acquiring service prefix information corresponding to each SG in a network; obtaining topological link relation between each SG and a Service Router (SR) in a network; forming a link state database based on service prefix according to the service prefix information and the topological link relation; and processing the data in the link state database based on a routing algorithm to form the FIB based on a service prefix.

According to still another aspect of the present disclosure, there is provided a traffic forwarding device in a service network, including: a service request receiving module configured to receive a service request sent by a Pod carrying a plurality of micro services; the service request corresponds to any micro-service; the service request at least comprises the following steps: pod identity information, service prefix signature information, service content information; the service prefix signature information is obtained by carrying out signature processing based on the service prefix corresponding to the micro service; a prefix authentication request sending module configured to send a prefix authentication request to the SPA based on the service request; the prefix authentication request at least comprises the following steps: the Pod identity information and the service prefix signature information; and the flow forwarding processing module is configured to respond to the SPA to pass the authentication of the prefix authentication request, and perform flow forwarding processing on the service request according to the service prefix corresponding to the micro service.

According to still another aspect of the present disclosure, there is provided an electronic apparatus including: one or more processors; and a storage configured to store one or more programs that, when executed by the one or more processors, cause the one or more processors to implement the method of forwarding traffic in a serviced network as described in the above embodiments.

According to yet another aspect of the present disclosure, there is provided a computer readable storage medium storing a computer program which, when executed by a processor, implements a method of forwarding traffic in a serviced network as described in the above embodiments.

According to the traffic forwarding method in the service network, the digital signature is provided for the service prefix of the micro service, and the validity of the service prefix announced by the Pod of the micro service through the service gateway are verified through the SPA. Only authorized micro services can participate in the communication, and the safety and the credibility of the communication are ensured. A security mechanism is provided for traffic forwarding in a servitized network.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the disclosure.

Drawings

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the disclosure and together with the description, serve to explain the principles of the disclosure and do not constitute an undue limitation on the disclosure.

FIG. 1 illustrates a schematic diagram of an exemplary system architecture for traffic forwarding in a servitization network in accordance with an embodiment of the present disclosure;

FIG. 2 illustrates a flow chart of a method of traffic forwarding in a serviced network according to an embodiment of the present disclosure;

FIG. 3 illustrates a flow chart of a service prefix registration method of an embodiment of the present disclosure;

fig. 4 shows a flowchart of a service prefix authentication method of an embodiment of the present disclosure;

fig. 5 shows a schematic diagram of a service prefix authentication procedure of an embodiment of the present disclosure;

fig. 6 shows a flow chart of a traffic forwarding processing method of an embodiment of the present disclosure;

FIG. 7 shows a schematic diagram of an interest packet forwarding process according to an embodiment of the present disclosure;

FIG. 8 illustrates a flow chart of another traffic forwarding processing method of an embodiment of the present disclosure;

fig. 9 is a schematic structural diagram of a traffic forwarding device in a service network according to an embodiment of the present disclosure;

fig. 10 shows a schematic structural diagram of an electronic device suitable for use in implementing exemplary embodiments of the present disclosure.

Detailed Description

Example embodiments will now be described more fully with reference to the accompanying drawings. However, the exemplary embodiments may be embodied in many forms and should not be construed as limited to the examples set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the concept of the example embodiments to those skilled in the art. The described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.

Furthermore, the drawings are merely schematic illustrations of the present disclosure and are not necessarily drawn to scale. The same reference numerals in the drawings denote the same or similar parts, and thus a repetitive description thereof will be omitted. Some of the block diagrams shown in the figures are functional entities and do not necessarily correspond to physically or logically separate entities. These functional entities may be implemented in software or in one or more hardware modules or integrated circuits or in different networks and/or processor devices and/or microcontroller devices.

It should be noted that, the embodiments of the present disclosure refer to ordinal terms such as "first," "second," etc. for distinguishing a plurality of objects, and are not used to define an order, a timing, a priority, or an importance of the plurality of objects, and the descriptions of "first," "second," and the like do not necessarily define that the objects are different.

For ease of understanding, before describing embodiments of the present disclosure, several terms referred to in the embodiments of the present disclosure are first explained as follows:

service Mesh, a server network, an infrastructure layer for managing communications between the various micro-services in the distributed application.

Service is a component or micro-Service in an application.

Pod, in a Kubernetes cluster, which is the basis for all traffic types, is a collection of one or more containers that share storage, networks and namespaces, and specifications of how to operate, all of which are uniformly arranged and scheduled and run in a shared context.

Service Gateway, SG.

SPA, service prefix authentication Service Prefix Authentication for authenticating service prefixes owned by Pod.

Service Router, SR.

Content Store, CS, for temporarily storing a cache of packets that have been received.

Pending Interest Table, pending interest table, PIT is used to store the data structure of interest packages that have not yet been satisfied.

Forwarding Information Base, forwarding information base, FIB for maintaining routing forwarding rules and tables for packet forwarding.

The Interest Packet is a Packet of request data sent by Pod, and specifies the required content by the service prefix.

Data Packet, is a Packet containing actual Data, is a response to a Packet of interest

In the related art, the service network architecture is generally implemented by a centralized control manner.

Proxy deployed co-located with micro-services Pod performs common functions required for communication between micro-services, such as service registration, service discovery, service scheduling and service measurement, and communication at all forwarding levels between micro-services is implemented through Proxy. The complex links between Proxy form a new infrastructure of communication, the Service Mesh.

In order to solve the problems of the centralized service network architecture, the present disclosure provides a distributed micro service architecture to better cope with the complex communication requirements between micro services.

The following detailed description of embodiments of the present disclosure refers to the accompanying drawings.

Fig. 1 shows a schematic diagram of an exemplary system architecture for traffic forwarding in a servitization network according to an embodiment of the present disclosure.

As shown in fig. 1, the system architecture includes a micro service 101, a plurality of service gateways 102, a plurality of service routers 103, and a service prefix authentication 104, for example, the system in fig. 1 is provided with 4 service gateways 102, which are service gateways 1 to 4 respectively; the system is provided with three service routers 103, respectively service routers 1-3.

The micro service 101 is a logical set of multiple Pod of one service and a policy for accessing Pod, and can be regarded as a set of Pod external access interfaces providing the same service. By means of micro-services, applications can conveniently implement service discovery and load balancing.

In one embodiment, the Pod in which the micro service 101 resides may announce a service prefix to the service gateway linked to the Pod.

One Pod links one service gateway 102, one service gateway 102 may link at least one Pod, for example, in fig. 1, service gateway 1 links two pods, and a micro service under one Pod is defined as micro service a/1 as service identification information of the one Pod; the micro service under another Pod is defined as micro service B/1 as service identification information of the other Pod.

The service gateway 102 may also be called an intersystem connector or a protocol converter, and the service gateway 102 implements network interconnection above a network layer, and may be used for interconnection of wide area networks or local area networks.

In one embodiment, the service gateway 102 may interact the service identification information of each Pod with the corresponding service router 103 through different interfaces of the service gateway 102, and may select a corresponding gateway interface according to service requirements.

Service router 104 may include, but is not limited to, a provider edge router, a hub router, a spoke router, an autonomous system border router, an area border router, and the like.

Other suitable network devices may be included in the system architecture, such as switches, hubs, modems, bridges, repeaters, multiplexers, network adapters, network interfaces, network racks, enclosures, servers, computing devices, combinations or variations of one or more of the virtual machines shown in the drawings.

The SPA104 is used for authenticating the service prefix corresponding to the micro service sent by the service gateway 102, and the service gateway 102 adopts the SPA mode to realize proxy registration. After the authentication to the SPA is passed by the service gateway 102, the synchronization of the micro service information is realized by distributing the authentication between the service gateway 102 and the service router 103 through a distributed protocol.

One service gateway 102 may link one SPA104.

The micro service 101 in the embodiments of the present disclosure may be initiated by a client of an application installed in a terminal device. The specific form of the application client may also be different based on the different terminal platforms, for example, the application client may be a mobile phone client, a PC client, etc.

Those skilled in the art will appreciate that the number of micro services 101, service gateways 102, service routers 103, SPA104 in fig. 1 is merely illustrative, and that any number of micro services 101, service gateways 102, service routers 103, SPA104 may be provided as desired. The embodiments of the present disclosure are not limited in this regard.

Embodiments of the present disclosure provide a method for forwarding traffic in a Service network, which may be performed by a Service Gateway (SG).

Fig. 2 is a flowchart illustrating a method for forwarding traffic in a service network according to an embodiment of the present disclosure, and as shown in fig. 2, the method for forwarding traffic in a service network provided in an embodiment of the present disclosure, applied to a service gateway, may include the following steps.

In step S210, a service request sent by Pod carrying a plurality of micro services is received; the service request corresponds to any micro-service; the service request at least comprises the following steps: pod identity information, service prefix signature information, service content information; the service prefix signature information is obtained by carrying out signature processing based on the service prefix corresponding to the micro service.

In a distributed micro-service architecture, one application system includes a plurality of micro-services, which may include routing request micro-services, security authentication micro-services, traffic monitoring micro-services, logging and monitoring micro-services, and the like. Multiple micro-services may be deployed on the same server or on different servers.

The service gateway is a network gateway through which client accesses system requests and system responses pass, encapsulates the internal functional architecture of the system and provides different interfaces for each client access.

In the embodiment of the disclosure, the Pod carrying the plurality of micro services sends a service request to the service gateway to request the service gateway to execute a related traffic forwarding operation. The service request at least comprises: pod identity information, service prefix signature information, service content information.

The Pod identity information may be ID, certificate, network identification information or other identifier of the Pod, for indicating unique identification information of the Pod in the network. Through Pod identity information, data request and forwarding in the NDN network can determine a target Pod through a name, so that directional transmission and address independence of data are realized. By using Pod identity information, each Pod node in the network can directly identify data that has been received from the named data and can push the data directly into a particular Pod node.

A service prefix is a named prefix that is used to identify a particular dataset. It is an important part of the interest package for indicating the name of the required data. The service prefix may be represented by text, letters, numbers, symbols, etc., for example, micro service a/1, micro service B/1, etc. in fig. 1, which are used to distinguish different Pod, and ensure the uniqueness of the micro service under Pod.

Since the service prefix is very important information for the NDN network, data request and forwarding between the respective Pod are realized based on the service prefix. Thus, directly using plaintext to deliver the service prefix clearly presents a significant security risk. Based on the service prefix signature information in the service request, the service prefix signature information is obtained by performing signature processing based on the service prefix corresponding to the micro service.

In an exemplary embodiment, the signing process may be accomplished by encrypting the service prefix with a pre-generated set of key pairs (including a private key and a public key). It should be noted that there are many secure encryption methods for service prefixes, and a one-to-one description is not given here.

Service content information for recording essential content information of a service request, i.e., a payload of data. There are typically two roles of producer and consumer in NDN networks.

The consumer obtains the content required for the specification through the interest package. For interest packages, the service content information typically includes: interest tags, meta-information, service prefixes. Interest tags, which are used to distinguish between different interest packages. Meta information contains the desire for the data, such as the time to live of the requested data, the priority of the interest package, etc. A service prefix identifying a naming prefix of the desired service data set.

The producer responds to the demand of the interest package through the data package to provide corresponding data content. For data packets, the service content information typically includes: service prefix, meta information, payload. A service prefix identifying a naming prefix of the provided service data set. Meta information contains additional information of the data, such as the lifetime of the data, the publisher of the data, etc. The payload, i.e. the actual data content, contains the specific content of the data, may be any type of data.

In step S220, a prefix authentication request is sent to a service prefix authentication (Service Prefix Authentication, SPA) based on the service request; the prefix authentication request at least comprises the following steps: the Pod identity information and the service prefix signature information.

In the embodiment of the disclosure, after receiving the service request, the service gateway needs to generate a prefix authentication request according to the service request. And sending the prefix authentication request to the SPA for service prefix authentication to determine the validity and effectiveness of the service prefix in the service request. The prefix authentication request at least comprises the following steps: the Pod identity information and the service prefix signature information. The relevant content has been described above and will not be repeated here. SPA authenticates the service prefix of the prefix authentication request according to the pre-registered service prefix and Pod identity information. After the service prefix authentication is completed, the SPA returns the related authentication result to the service gateway.

In step S230, in response to the SPA authenticating the prefix authentication request, traffic forwarding processing is performed on the service request according to the service prefix corresponding to the micro service.

In the embodiment of the disclosure, the service gateway directly drops the service request in response to that the SPA fails to authenticate the prefix authentication request.

In the embodiment of the disclosure, if the service gateway responds to the SPA to authenticate the prefix authentication request, the service gateway performs traffic forwarding processing on the service request according to the service prefix corresponding to the micro service. The traffic forwarding process may include: for the interest packet, forwarding relevant data request information to a service gateway corresponding to a relevant data producer; for the data packet, forwarding the related data content to a service gateway corresponding to a consumer requiring the related data; and for the received data content returned by the network layer, forwarding the related content to the Pod of the data related to the requirement under the service gateway.

The method for forwarding the traffic in the service network provided by the embodiment of the disclosure comprises the following steps: receiving a service request sent by a Pod bearing a plurality of micro services; based on the service request, sending a prefix authentication request to the SPA; the prefix authentication request at least comprises the following steps: the Pod identity information and the service prefix signature information; and responding to the SPA to pass the authentication of the prefix authentication request, and carrying out traffic forwarding processing on the service request according to the service prefix. By providing digital signature for the service prefix of the micro-service, and by SPA, verifying the validity and validity of the service prefix announced by the Pod to which the micro-service belongs through the service gateway. Only authorized micro services can participate in the communication, and the safety and the credibility of the communication are ensured. A security mechanism is provided for traffic forwarding in a servitized network.

Fig. 3 shows a flowchart of a service prefix registration method of an embodiment of the present disclosure. As shown in fig. 3, the service prefix registration method may include the following steps.

In step S310, the Pod generates a set of key pairs for the micro service, the key pairs including a private key and a public key.

In the disclosed embodiment, when a new micro-service is generated in the Pod, a service prefix needs to be registered for the micro-service first. The service prefix is used as a unique identifier of the micro service to realize that related data of the micro service is transmitted in the NDN network.

During this registration process, pod generates a set of key pairs for the microservice. The key pair includes a private key and a public key. And the Pod performs signature processing on the generated service prefix through a private key to obtain the service prefix signature information.

In step S320, the public key sent by the Pod and a prefix registration request sent by the Pod are received respectively; the prefix registration request at least comprises the service prefix signature information; the service prefix signature information is obtained by carrying out signature processing on the service prefix corresponding to the micro service based on the private key.

In the embodiment of the disclosure, the Pod sends the public key and the prefix registration request to the service gateway respectively. Wherein the prefix registration request at least includes the service prefix signature information. Since the public key can be used to decrypt the service prefix signature information, both cannot be sent together for security reasons, but need to be sent separately. The public key may be distributed to the SG by other security mechanisms (e.g., certificate authorities) to ensure the authenticity and integrity of the public key.

In an exemplary embodiment, the prefix registration request further includes the Pod identity information, which is used to determine a correspondence between a service prefix and a Pod.

In step S330, the service prefix signature information is signature-verified by the public key.

In the embodiment of the disclosure, the service gateway receives the public key and the prefix registration request sent by the Pod respectively. And verifying the service prefix signature information in the prefix registration request through the public key. The validity of the service prefix signature information can be verified by using the public key through a digital signature algorithm. Meanwhile, the service prefix signature information can be decrypted into a service prefix by using the public key. In addition to verifying the validity of the service prefix signature information, it is also necessary to verify the validity and uniqueness of the service prefix. Legitimacy means that the service prefix should conform to the naming convention of the service prefix. Uniqueness means that the service prefix should be unique in the NDN network and not be repeated with the previously registered service prefix.

In step S340, in response to the service prefix signature information verification passing, a binding relationship is established based on the micro service, the service prefix and the public key, and the binding relationship is transmitted to the SPA.

In the embodiment of the present disclosure, after the verification in step S330, the service gateway establishes a binding relationship among the micro service, the service prefix and the public key, and sends the binding relationship to the SPA. The SPA stores binding relations of each complete registration verification for subsequent verification of service prefixes.

In an exemplary embodiment, the binding relationship further includes the Pod identity information, so that the SPA verifies the corresponding relationship between the service prefix and the Pod at the same time during verification, thereby further enhancing security.

The embodiment of the disclosure provides a service prefix registration method for a traffic forwarding method in a service network. By the registration method, the service prefix is registered by the micro service, a digital signature mechanism is provided for the service prefix, and a binding relation between a public key in the signature and information such as the service prefix, pod identity information and the like is established and stored in the SPA for verification in the service prefix authentication process.

Fig. 4 shows a flowchart of a service prefix authentication method of an embodiment of the present disclosure. Fig. 5 shows a schematic diagram of a service prefix authentication procedure of an embodiment of the present disclosure. As shown in fig. 4 and 5, the service prefix authentication method may include the following steps.

In step S410, the validity of the Pod is verified according to the Pod identity information.

In the embodiment of the disclosure, after receiving the prefix authentication request, the SPA checks validity of the Pod according to the Pod identity information therein. As previously described, pod identity information may be an ID, certificate, network identification information, or other identifier of a Pod, for indicating unique identification information of the Pod in the network. This information is pre-stored on the SPA and the validity of Pod can be determined by verification.

In step S420, according to the binding relationship, signature verification is performed on the service prefix signature information based on the public key corresponding to the micro service.

In the embodiment of the disclosure, after receiving the prefix authentication request, the SPA performs signature verification on the service prefix signature information based on the corresponding public key according to the binding relationship determined during service prefix registration.

In an exemplary embodiment, first, the received service prefix signature information is decrypted using a public key, and a decrypted hash value is obtained. Then, hash calculation is carried out on the received service prefix by using a hash function, so that a hash value of the service prefix is obtained. And then comparing the decrypted hash value with the hash value of the service prefix obtained by calculation. If the two hash values are equal, then this indicates that the signature is valid and the data has not been tampered with. Otherwise, the signature is invalid and the service prefix may be tampered with.

In step S430, decrypting the service prefix signature information based on the public key to obtain the service prefix; and matching the service prefix with a preset legal prefix list, and determining whether the service prefix is legal or not.

In the embodiment of the disclosure, after receiving the prefix authentication request, the SPA decrypts the service prefix signature information based on the public key to obtain the service prefix. And matching the service prefix with a preset legal prefix list. The legal prefix list is a list of legal service prefixes which are registered and entered through service prefixes and are maintained and managed. And determining whether the service prefix is legal or not through matching with the prefix list.

In step S440, it is determined that the service prefix and the Pod identity information conform to the foregoing binding relationship.

In the embodiment of the disclosure, after receiving the prefix authentication request, the SPA decrypts the service prefix signature information based on the public key to obtain the service prefix. Based on the binding relation stored during service prefix registration, whether the service prefix and Pod identity information conform to the pre-stored binding relation or not is confirmed, so that the corresponding relation between the service prefix and the Pod is determined, and the prefix is prevented from being tampered or abused maliciously.

In step S450, it is determined whether the prefix authentication request passes authentication according to the Pod validity verification result, the signature verification result, the service prefix validity verification result, and the binding relationship verification result.

In the embodiment of the present disclosure, through the verification process in steps S410 to S440, a Pod validity verification result, a signature verification result, a service prefix validity verification result, and a binding relationship verification result are obtained respectively. And determining whether the prefix authentication request passes authentication or not according to the verification results.

It should be noted that the above-described partial security verification may be selected for verification of the service prefix according to actual security requirements, and the related verification sequence is not limited to the above-described sequence. The person skilled in the art can make corresponding combinations according to the actual needs.

In addition, the security authentication of the service prefix is performed through the SPA, and the service authority of the micro service corresponding to the service prefix can be further managed. Specifically, the foregoing binding relationship may further include service authority information. The service right information is used for representing the service right corresponding to the micro service. In the service prefix authentication process, the service prefix signature information is decrypted based on the public key to obtain the service prefix. And determining the service authority information corresponding to the service prefix according to the binding relation. And when the SPA returns a service prefix authentication result to the service gateway, the service authority information corresponding to the authenticated service prefix can be returned to the service gateway so as to match the service content of the corresponding service authority to the micro service.

The embodiment of the disclosure provides a service prefix verification method for a traffic forwarding method in a service network. By the verification method, in the service prefix verification process of the micro service, the service request information can be verified through multiple aspects such as Pod validity verification, service prefix signature verification, service prefix validity verification, binding relation verification and the like. The person skilled in the art can freely combine and arrange the verification content according to the actual service requirements. An extensible security mechanism is provided for traffic forwarding in a servitized network.

Fig. 6 shows a flow chart of a traffic forwarding processing method according to an embodiment of the present disclosure. Fig. 7 shows a schematic diagram of an interest packet forwarding process according to an embodiment of the present disclosure. As shown in fig. 6 and 7, the traffic forwarding processing method may include the following steps.

In step S610, the service request is determined to be an interest package according to the service content information.

As described above, the service content information is used to record the essential content information of the service request, i.e., the payload of the data. There are typically two roles of producer and consumer in NDN networks. The consumer obtains the content required for the specification through the interest package. The producer responds to the demand of the interest package through the data package to provide corresponding data content.

In the embodiment of the disclosure, the service request is determined to be an interest packet according to the service content information. That is, an interest package provided by a consumer to obtain a specified desired content.

For interest packages, the service content information typically includes: interest tags, meta-information, service prefixes. Interest tags, which are used to distinguish between different interest packages. Meta information contains the desire for the data, such as the time to live of the requested data, the priority of the interest package, etc. A service prefix identifying a naming prefix of the desired service data set.

In step S620, it is determined whether matching Content data is retained in a local Content Store (CS) according to the service prefix.

In an embodiment of the present disclosure, the service gateway is locally provided with a Content Store (CS) for temporarily storing a buffer of already received data packets. The service gateway first searches whether the matched content data is reserved in the CS according to the service prefix in the service request.

In step S630, the content data is returned to the micro service in response to the matching content data remaining in the CS.

In an embodiment of the disclosure, in response to content data matching the service prefix remaining in the CS, the content data is returned to the micro-service. Therefore, the micro service can obtain the required content data without forwarding the relevant message in the network, thereby saving network resources.

In step S640, in response to the CS not retaining the matched content data, it is determined whether a first interest packet matching the interest packet is retained in a local pending interest table (Pending Interest Table, PIT).

In the embodiment of the disclosure, a Pending Interest Table (PIT) is locally provided in the service gateway, and is a data structure for storing interest packets that have not yet been satisfied. And in response to no matched content data is reserved in the CS, determining whether a first interest packet matched with the interest packet is reserved in the local PIT. The first interest message is used for indicating that the demand message related to the content data is forwarded under the service gateway.

In step S650, in response to the PIT retaining the matched first interest packet, the Pod identity information and microservice information are added to the first interest packet.

In the embodiment of the disclosure, in response to the first interest packet remaining in the PIT, it is indicated that the demand packet related to the content data has been forwarded under the service gateway. Therefore, the forwarding of the related demand message is not needed again, and only the Pod identity information and the micro-service information are added into the first interest message. By adding Pod identity information and micro-service information into the first interest message, when relevant content data is returned, the relevant content data is forwarded to the micro-service carried by the corresponding Pod under the service gateway according to the PIT. Therefore, the micro service can obtain the required content data without forwarding the relevant message in the network, thereby saving network resources.

In step S660, in response to the PIT not having the matched first interest packet retained therein, generating a second interest packet according to the service request; and reserving the second interest message in the PIT, and forwarding the second interest message according to a forwarding information base (Forwarding Information Base, FIB).

In the embodiment of the disclosure, in response to the fact that the matched first interest packet is not reserved in the PIT, it is indicated that the demand packet related to the content data is not forwarded under the service gateway. Therefore, the related demand message needs to be forwarded to the service gateway where the producer of the content data is located, so as to obtain the content data. Meanwhile, a second interest message needs to be newly built in the PIT according to the service request. The second interest packet is associated with content data required by the service request. In this way, there is an interest packet for the content data, then the relevant Pod identity information and micro service information may be added to the second interest packet in step S650.

And simultaneously, the service gateway forwards the second interest message according to a Forwarding Information Base (FIB). A Forwarding Information Base (FIB) for maintaining routing forwarding rules and tables for packet forwarding. It IS associated with a Routing Information Base (RIB) that IS constructed from information provided by various routing processes through routing protocols (e.g., OSPF, IS-IS, BGP, and even static route entries). When forwarding the data packet, the network device determines the next hop of the data packet according to the information in the FIB, and then forwards the data packet from the ingress and egress interfaces. This way, the network device is enabled to quickly forward the data packets according to the routing information. The FIB is generated according to the following method:

Acquiring service prefix information corresponding to each SG in a network;

obtaining topological link relation between each SG and a Service Router (SR) in a network;

forming a link state database based on service prefix according to the service prefix information and the topological link relation;

and processing the data in the link state database based on a routing algorithm to form the FIB based on a service prefix.

Through the traffic forwarding processing method, the service gateway forwards the interest packet to the service gateway where the corresponding producer is located based on the FIB. After receiving the interest packet, the producer generates corresponding content data and generates a related data packet. The Data Packet is a Packet containing actual Data, and is a response to the interest Packet.

Fig. 8 shows a flow chart of another traffic forwarding processing method of an embodiment of the present disclosure. As shown in fig. 8, the traffic forwarding processing method may include the following steps.

In step S810, the service request is determined to be a data packet according to the service content information.

In the embodiment of the disclosure, the service request is determined to be a data packet according to the service content information. That is, the producer responds to the demand of the interest package by the data package to provide the corresponding data content.

For data packets, the service content information typically includes: service prefix, meta information, payload. A service prefix identifying a naming prefix of the provided service data set. Meta information contains additional information of the data, such as the lifetime of the data, the publisher of the data, etc. The payload, i.e. the actual data content, contains the specific content of the data, may be any type of data.

In step S820, it is determined whether a data request packet matching the data packet is reserved in the local PIT according to the service prefix.

In the embodiment of the disclosure, the service gateway first determines whether a data request message matched with the data packet is reserved in the local PIT according to the service prefix.

In step S830, in response to the data request packet that remains in the PIT and matches, a data request list corresponding to the data request packet is obtained.

In step S840, forwarding the data packet according to the FIB and the data request list.

In the embodiment of the disclosure, according to the acquired data request list, the service gateway forwards the data packet to the service gateway corresponding to the corresponding data consumer according to a Forwarding Information Base (FIB).

When the service gateway corresponding to the consumer receives the forwarded data packet, the following flow forwarding processing is performed, including:

and receiving the forwarded data packet.

And reserving the content data corresponding to the data packet in the CS.

And determining whether interest messages matched with the data packets are reserved in the PIT.

And responding to the interest message which remains in the PIT and is matched with the interest message, and forwarding the content data corresponding to the data packet to the micro-service carried by the corresponding Pod according to the interest message.

By the method, the service gateway can keep the related data packet in the local CS so as to directly provide the related data packet when the related content data is required. And simultaneously, responding to the interest message which remains in the PIT and is matched with the interest message, and forwarding the content data corresponding to the data packet to the micro-service carried by the corresponding Pod according to the interest message so as to meet the micro-service requirement of the sent content data interest packet.

Based on the same inventive concept, embodiments of the present disclosure provide a traffic forwarding device in a service network, as described in the following embodiments. Since the principle of solving the problem of the embodiment of the apparatus is similar to that of the embodiment of the method, the real-time implementation of the embodiment of the apparatus can be referred to the implementation of the embodiment of the method, and the repetition is not repeated.

Fig. 9 is a schematic structural diagram of a traffic forwarding device in a service network according to an embodiment of the present disclosure. As shown in fig. 9, the traffic forwarding device 900 in the service network may include: a service request receiving module 910, a prefix authentication request sending module 920, and a traffic forwarding processing module 930.

A service request receiving module 910 configured to receive a service request sent by a Pod carrying a plurality of micro services; the service request corresponds to any micro-service; the service request at least comprises the following steps: pod identity information, service prefix signature information, service content information; the service prefix signature information is obtained by carrying out signature processing based on the service prefix corresponding to the micro service.

A prefix authentication request sending module 920 configured to send a prefix authentication request to the SPA based on the service request; the prefix authentication request at least comprises the following steps: the Pod identity information and the service prefix signature information.

And the traffic forwarding processing module 930 is configured to perform traffic forwarding processing on the service request according to the service prefix corresponding to the micro service in response to the SPA authenticating the prefix authentication request.

In an exemplary embodiment, the traffic forwarding device 900 in the service network further includes a service prefix registration module. The service prefix registration module is configured for the Pod to generate a set of key pairs for the micro-service, the key pairs including a private key and a public key; respectively receiving the public key sent by the Pod and a prefix registration request sent by the Pod; the prefix registration request at least comprises the service prefix signature information; the service prefix signature information is obtained by carrying out signature processing on the service prefix corresponding to the micro service based on the private key; signature verification is carried out on the service prefix signature information through the public key; and establishing a binding relationship based on the micro service, the service prefix and the public key and transmitting the binding relationship to the SPA in response to the service prefix signature information verification passing.

In an exemplary embodiment, the service prefix registration module is further operable to: the prefix registration request also comprises the Pod identity information; the binding relationship also comprises the Pod identity information.

In an exemplary embodiment, the traffic forwarding device 900 in the service network further includes a service prefix authentication module. The service prefix authentication module is configured to verify the validity of the Pod according to the Pod identity information; according to the binding relation, signature verification is carried out on the service prefix signature information based on the public key corresponding to the micro service; and determining whether the prefix authentication request passes authentication or not according to the Pod validity verification result and the signature verification result.

In an exemplary embodiment, the service prefix authentication module is further operable to: decrypting the service prefix signature information based on the public key to obtain the service prefix; matching the service prefix with a preset legal prefix list, and determining whether the service prefix is legal or not; confirming that the service prefix and the Pod identity information accord with the binding relation; and determining whether the prefix authentication request passes authentication or not according to the service prefix validity verification result and the binding relation verification result.

In an exemplary embodiment, the service prefix authentication module is further operable to: the binding relationship also comprises service authority information; the service right information is used for representing the service right corresponding to the micro service; decrypting the service prefix signature information based on the public key to obtain the service prefix; and determining the service authority information corresponding to the service prefix according to the binding relation.

In an exemplary embodiment, the traffic forwarding processing module 930 may be further configured to: determining the service request as an interest packet according to the service content information; determining whether matching Content data is retained in a local Content Store (CS) according to the service prefix; returning the content data to the micro-service in response to the CS retaining the matched content data; determining whether a first interest packet matching the interest packet is retained in a local pending interest table (Pending Interest Table, PIT) in response to no matching content data being retained in the CS; responding to the PIT and reserving a matched first interest message, and adding the Pod identity information and the micro-service information into the first interest message; generating a second interest message according to the service request in response to the fact that the matched first interest message is not reserved in the PIT; and reserving the second interest message in the PIT, and forwarding the second interest message according to a forwarding information base (Forwarding Information Base, FIB).

In an exemplary embodiment, the traffic forwarding processing module 930 may be further configured to: determining the service request as a data packet according to the service content information; determining whether a data request message matched with the data packet is reserved in the local PIT according to the service prefix; responding to the PIT with the matched data request message, and acquiring a data request list corresponding to the data request message; and forwarding the data packet according to the FIB and the data request list.

In an exemplary embodiment, the traffic forwarding processing module 930 may be further configured to: receiving the forwarded data packet; the content data corresponding to the data packet is reserved in the CS; determining whether interest messages matched with the data packets are reserved in the PIT; and responding to the interest message which remains in the PIT and is matched with the interest message, and forwarding the content data corresponding to the data packet to the micro-service carried by the corresponding Pod according to the interest message.

In an exemplary embodiment, the traffic forwarding processing module 930 may be further configured to: the FIB is generated according to the following method: acquiring service prefix information corresponding to each SG in a network; obtaining topological link relation between each SG and a Service Router (SR) in a network; forming a link state database based on service prefix according to the service prefix information and the topological link relation; and processing the data in the link state database based on a routing algorithm to form the FIB based on a service prefix.

Fig. 10 shows a schematic structural diagram of an electronic device suitable for use in implementing exemplary embodiments of the present disclosure. An electronic device 1000 according to this embodiment of the present invention is described below with reference to fig. 10. The electronic device 1000 shown in fig. 10 is merely an example and should not be construed as limiting the functionality and scope of use of embodiments of the present invention.

As shown in fig. 10, the electronic device 1000 is embodied in the form of a general purpose computing device. Components of electronic device 1000 may include, but are not limited to: the at least one processing unit 1010, the at least one memory unit 1020, a bus 1030 connecting the various system components (including the memory unit 1020 and the processing unit 1010), and a display unit 1040.

Wherein the storage unit stores program code that is executable by the processing unit 1010 such that the processing unit 1010 performs steps according to various exemplary embodiments of the present invention described in the above section of the "exemplary method" of the present specification.

The memory unit 1020 may include readable media in the form of volatile memory units such as Random Access Memory (RAM) 10201 and/or cache memory unit 10202, and may further include Read Only Memory (ROM) 10203.

The storage unit 1020 may also include a program/utility 10204 having a set (at least one) of program modules 10205, such program modules 10205 including, but not limited to: an operating system, one or more application programs, other program modules, and program data, each or some combination of which may include an implementation of a network environment.

Bus 1030 may be representing one or more of several types of bus structures including a memory unit bus or memory unit controller, a peripheral bus, an accelerated graphics port, a processing unit, or a local bus using any of a variety of bus architectures.

The electronic device 1000 can also communicate with one or more external devices 1070 (e.g., keyboard, pointing device, bluetooth device, etc.), with one or more devices that enable a user to interact with the electronic device 1000, and/or with any device (e.g., router, modem, etc.) that enables the electronic device 1000 to communicate with one or more other computing devices. Such communication may occur through an input/output (I/O) interface 1050. Also, electronic device 1000 can communicate with one or more networks such as a Local Area Network (LAN), a Wide Area Network (WAN), and/or a public network, such as the Internet, through network adapter 1060. As shown, the network adapter 1060 communicates with other modules of the electronic device 1000 over the bus 1030. It should be appreciated that although not shown, other hardware and/or software modules may be used in connection with the electronic device 1000, including, but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, data backup storage systems, and the like.

In an exemplary embodiment of the present disclosure, a computer-readable storage medium having stored thereon a program product capable of implementing the method described above in the present specification is also provided. In some possible embodiments, the various aspects of the invention may also be implemented in the form of a program product comprising program code for causing a terminal device to carry out the steps according to the various exemplary embodiments of the invention as described in the "exemplary methods" section of this specification, when said program product is run on the terminal device.

A program product for implementing the above-described method according to an embodiment of the present invention may employ a portable compact disc read-only memory (CD-ROM) and include program code, and may be run on a terminal device such as a personal computer. However, the program product of the present invention is not limited thereto, and in this document, a readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.

The program product may employ any combination of one or more readable media. The readable medium may be a readable signal medium or a readable storage medium. The readable storage medium can be, for example, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or a combination of any of the foregoing. More specific examples (a non-exhaustive list) of the readable storage medium would include the following: an electrical connection having one or more wires, a portable disk, a hard disk, random Access Memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

The computer readable signal medium may include a data signal propagated in baseband or as part of a carrier wave with readable program code embodied therein. Such a propagated data signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination of the foregoing. A readable signal medium may also be any readable medium that is not a readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device.

Program code embodied on a readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

Program code for carrying out operations of the present invention may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, C++ or the like and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code may execute entirely on the user's computing device, partly on the user's device, as a stand-alone software package, partly on the user's computing device, partly on a remote computing device, or entirely on the remote computing device or server. In the case of remote computing devices, the remote computing device may be connected to the user computing device through any kind of network, including a Local Area Network (LAN) or a Wide Area Network (WAN), or may be connected to an external computing device (e.g., connected via the Internet using an Internet service provider).

It should be noted that although in the above detailed description several modules or units of a device for action execution are mentioned, such a division is not mandatory. Indeed, the features and functionality of two or more modules or units described above may be embodied in one module or unit in accordance with embodiments of the present disclosure. Conversely, the features and functions of one module or unit described above may be further divided into a plurality of modules or units to be embodied.

Furthermore, although the steps of the methods in the present disclosure are depicted in a particular order in the drawings, this does not require or imply that the steps must be performed in that particular order or that all illustrated steps be performed in order to achieve desirable results. Additionally or alternatively, certain steps may be omitted, multiple steps combined into one step to perform, and/or one step decomposed into multiple steps to perform, etc.

From the above description of embodiments, those skilled in the art will readily appreciate that the example embodiments described herein may be implemented in software, or may be implemented in software in combination with the necessary hardware. Thus, the technical solution according to the embodiments of the present disclosure may be embodied in the form of a software product, which may be stored in a non-volatile storage medium (may be a CD-ROM, a U-disk, a mobile hard disk, etc.) or on a network, including several instructions to cause a computing device (may be a personal computer, a server, a mobile terminal, or a network device, etc.) to perform the method according to the embodiments of the present disclosure.

Other embodiments of the disclosure will be apparent to those skilled in the art from consideration of the specification and practice of the disclosure disclosed herein. This application is intended to cover any adaptations, uses, or adaptations of the disclosure following, in general, the principles of the disclosure and including such departures from the present disclosure as come within known or customary practice within the art to which the disclosure pertains. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the disclosure being indicated by the following claims.

It is to be understood that the present disclosure is not limited to the precise arrangements and instrumentalities shown in the drawings, and that various modifications and changes may be effected without departing from the scope thereof. The scope of the present disclosure is limited only by the appended claims.

Claims

1. A method for forwarding traffic in a Service network, applied to a Service Gateway (SG), the method comprising:

receiving a service request sent by a Pod bearing a plurality of micro services; the service request corresponds to any micro-service; the service request at least comprises the following steps: pod identity information, service prefix signature information, service content information; the service prefix signature information is obtained by carrying out signature processing based on the service prefix corresponding to the micro service;

Based on the service request, sending a prefix authentication request to a service prefix authentication (Service Prefix Authentication, SPA); the prefix authentication request at least comprises the following steps: the Pod identity information and the service prefix signature information;

and responding to the SPA to pass the authentication of the prefix authentication request, and carrying out flow forwarding processing on the service request according to the service prefix corresponding to the micro service.

2. The method of claim 1, wherein the micro service pre-registers a corresponding service prefix with the SG prior to receiving the service request, the registration method comprising:

the Pod generates a set of key pairs for the micro-service, the key pairs including private keys and public keys;

respectively receiving the public key sent by the Pod and a prefix registration request sent by the Pod; the prefix registration request at least comprises the service prefix signature information; the service prefix signature information is obtained by carrying out signature processing on the service prefix corresponding to the micro service based on the private key;

signature verification is carried out on the service prefix signature information through the public key;

and establishing a binding relationship based on the micro service, the service prefix and the public key and transmitting the binding relationship to the SPA in response to the service prefix signature information verification passing.

3. The method of claim 2, wherein the registration method further comprises:

the prefix registration request also comprises the Pod identity information;

the binding relationship also comprises the Pod identity information.

4. The method of claim 3, wherein the SPA authenticates the prefix authentication request, the authentication method comprising:

verifying the legality of the Pod according to the Pod identity information;

according to the binding relation, signature verification is carried out on the service prefix signature information based on the public key corresponding to the micro service;

and determining whether the prefix authentication request passes authentication or not according to the Pod validity verification result and the signature verification result.

5. The method of claim 4, wherein the authentication method further comprises:

decrypting the service prefix signature information based on the public key to obtain the service prefix;

matching the service prefix with a preset legal prefix list, and determining whether the service prefix is legal or not;

confirming that the service prefix and the Pod identity information accord with the binding relation;

and determining whether the prefix authentication request passes authentication or not according to the service prefix validity verification result and the binding relation verification result.

6. The method of claim 4, wherein the authentication method further comprises:

the binding relationship also comprises service authority information; the service right information is used for representing the service right corresponding to the micro service;

and determining the service authority information corresponding to the service prefix according to the binding relation.

7. The method of claim 1, wherein the performing traffic forwarding processing on the service request according to the service prefix corresponding to the micro service includes:

determining the service request as an interest packet according to the service content information;

determining whether matching Content data is retained in a local Content Store (CS) according to the service prefix;

returning the content data to the micro-service in response to the CS retaining the matched content data;

determining whether a first interest packet matching the interest packet is retained in a local pending interest table (Pending Interest Table, PIT) in response to no matching content data being retained in the CS;

Responding to the PIT and reserving a matched first interest message, and adding the Pod identity information and the micro-service information into the first interest message;

generating a second interest message according to the service request in response to the fact that the matched first interest message is not reserved in the PIT; and reserving the second interest message in the PIT, and forwarding the second interest message according to a forwarding information base (Forwarding Information Base, FIB).

8. The method of claim 1, wherein the performing traffic forwarding processing on the service request according to the service prefix corresponding to the micro service includes:

determining the service request as a data packet according to the service content information;

determining whether a data request message matched with the data packet is reserved in the local PIT according to the service prefix;

responding to the PIT with the matched data request message, and acquiring a data request list corresponding to the data request message;

and forwarding the data packet according to the FIB and the data request list.

9. The method of claim 7, wherein the performing traffic forwarding processing on the service request according to the service prefix corresponding to the micro service includes:

Receiving the forwarded data packet;

the content data corresponding to the data packet is reserved in the CS;

determining whether interest messages matched with the data packets are reserved in the PIT;

10. The method of claim 7, wherein the FIB is generated according to the method of:

acquiring service prefix information corresponding to each SG in a network;

11. A traffic forwarding device in a service network, comprising:

a service request receiving module configured to receive a service request sent by a Pod carrying a plurality of micro services; the service request corresponds to any micro-service; the service request at least comprises the following steps: pod identity information, service prefix signature information, service content information; the service prefix signature information is obtained by carrying out signature processing based on the service prefix corresponding to the micro service;

A prefix authentication request sending module configured to send a prefix authentication request to the SPA based on the service request; the prefix authentication request at least comprises the following steps: the Pod identity information and the service prefix signature information;

and the flow forwarding processing module is configured to respond to the SPA to pass the authentication of the prefix authentication request, and perform flow forwarding processing on the service request according to the service prefix corresponding to the micro service.

12. An electronic device, comprising:

one or more processors; storage means configured to store one or more programs which, when executed by the one or more processors, cause the one or more processors to implement the method of any of claims 1 to 10.

13. A computer readable storage medium storing a computer program, characterized in that the computer program when executed by a processor implements the method according to any one of claims 1 to 10.