Information processing method and apparatus

Abstract

Disclosed in the embodiments of the present application is an information processing method. The method can be applied to, for example, a target apparatus. The target apparatus can acquire a BGP message, wherein the address family of the BGP message is a BGP LS address family, and the BGP message comprises indication information, which indicates the link type of a link between a first point of presence (POP) in an SD-WAN and a second POP in the SD-WAN. By using the present solution, the type of a link between POPs can be carried by a BGP message in an LS address family, so as to facilitate the subsequent orchestration of service paths for services on the basis of the type of the link between the POPs, thereby meeting service requirements.

Description

Information processing method and device

[0001] This application claims priority to the Chinese patent application filed with the State Intellectual Property Office on September 28, 2023, with application number 2023112941556 and invention name “A Method and Device for Information Processing”, the entire contents of which are incorporated by reference into this application. Technical Field

[0002] The present application relates to the field of communications, and in particular to an information processing method and device. Background Art

[0003] To achieve fast end-to-end delivery and flexible scheduling in current wide area networks (WANs), software-defined networking in a wide area network (SD-WAN) technology is often used. SD-WAN tunnels are established over different underlying networks, such as the internet and dedicated lines, to build an SD-WAN-based overlay network. This decouples WAN services from the underlying network and improves end-to-end delivery capabilities. The SD-WAN-based overlay network can be referred to as the SD-WAN network.

[0004] In some scenarios, the end-to-end path across the SD-WAN network can be calculated in advance for the business, but the current method of calculating the end-to-end path cannot fully meet business needs.

[0005] Therefore, a solution is urgently needed to solve the above problems.

[0006] Summary of the Invention

[0007] The embodiments of the present application provide an information processing method and apparatus, which can facilitate the arrangement of service paths, thereby better meeting service needs.

[0008] In a first aspect, an embodiment of the present application provides an information processing method, which can be applied to a target device, for example. The target device can obtain a Border Gateway Protocol (BGP) message, the address family of which is a BGP link state (LS) address family, and the BGP message includes indication information, which indicates the link type of the link between a first point of presence (POP) and a second POP. By adopting this solution, the link type between POPs can be carried by using a BGP message of the LS address family, so that a service path can be subsequently arranged for the service based on the link type between the POPs, thereby meeting service needs.

[0009] In a possible implementation, the indication information indicates that the link type may be an overlay link, an underlay link, a direct link, a dedicated line link, a Multi-Protocol Label Switching (MPLS) link, an Internet Protocol Version 6 Segment Routing (SRv6) link, an Internet link, a fourth generation mobile communication technology (4G) link, a fifth generation mobile communication technology 5G (5G) link, or a fifth generation mobile communication technology plus (5G+) link. When the link type indicated by the indication information is an MPLS link, an SRv6 link, an Internet link, a 4G link, a 5G link, or a 5G+ link, the indication information may naturally indicate that the link type of the link between the first POP and the second POP is an overlay link; when the link type indicated by the indication information is a direct link or a dedicated line link, the indication information may naturally indicate that the link type of the link between the first POP and the second POP is an underlay link.

[0010] In one possible implementation, considering that the link network layer reachability information (NLRI) of the Border Gateway Protocol Link State Shortest Path First (BGP-LS-shortest path first, BGP-LS-SPF) address family can be used to announce link information, therefore, in a specific example, the sub-address family of the BGP message can be an SFP sub-address family, that is: in the embodiment of the present application, the characteristic of BGP-LS-SPF being able to announce link information is followed, and the BGP message based on the use of the BGP-LS-SPF address family carries the aforementioned indication information. Among them, the BGP-LS-SPF address family can also be referred to as the BGP-SPF address family.

[0011] In one possible implementation, when the sub-address family of the BGP message is the SPF sub-address family, the BGP message may include a link type type length value (TLV), and the link type TLV is used to carry the indication information. The communication device that receives the BGP message can parse the link type TLV to obtain the indication information, and accordingly, based on the indication information, the link type of the link between the first POP and the second POP can be determined. In one possible implementation, the BGP message may include a BGP path attribute, and the link type TLV may be carried by the BGP path attribute. In other words, the BGP path attribute may include the link type TLV. In a specific example, the BGP path attribute may be a BGP LS attribute. In this case, the communication device that receives the BGP message can parse the BGP LS attribute to obtain the link type TLV, and further obtain the indication information based on the link type TLV. Accordingly, based on the indication information, the link type of the link between the first POP and the second POP can be determined.

[0012] In one possible implementation, the target device may be a first POP. In this case, when the first POP obtains the BGP message, the first POP may generate the BGP message. As an example, after generating the BGP message, the first POP may send the BGP message, for example, to other POPs and / or a controller.

[0013] In a possible implementation, the target device may be a controller. In this case, the controller may obtain the BGP message by receiving the BGP message. As an example, the controller may receive the BGP message sent by the first POP.

[0014] In one possible implementation, the target device may receive path calculation constraint information indicating the required link type for the link reaching the target network prefix. This allows the device orchestrating service paths to orchestrate the service paths based on the path calculation constraint information, aiming to orchestrate service paths that conform to the path calculation constraint information as much as possible, thereby satisfying the service requirements.

[0015] In a possible implementation, when the target device is the first POP, after receiving the path calculation constraint information, the target device may send the path calculation constraint information to the controller, and the controller calculates a service path to the target network prefix based on the path calculation constraint information.

[0016] In a possible implementation, after receiving the path calculation constraint information, the target device may calculate a service path to the target network prefix based on the path calculation constraint information.

[0017] In one possible implementation, the requirement for the link type of the link reaching the target network prefix may include the link types that the link reaching the target network prefix needs to include. In this case, by specifying the link types that the link reaching the target network prefix needs to include, the first POP or controller, when calculating a service path, can attempt to calculate a service path that includes links of the required link types, thereby satisfying the service requirement.

[0018] In one possible implementation, the aforementioned requirement for the link type of the link reaching the target network prefix may include link types that need to be excluded from the link reaching the target network prefix. In this case, by specifying the link types that need to be excluded from the link reaching the target network prefix, the first POP or controller, when calculating the service path, can attempt to calculate a service path that does not include links of the aforementioned link types that need to be excluded, thereby meeting the service requirement.

[0019] In one possible implementation, if the aforementioned requirement includes the link type that the link to the target network prefix needs to include, then the aforementioned path calculation constraint information may include a first TLV, which may be, for example, an Include Link-Type TLV, indicating the link type that the link to the target network prefix needs to include.

[0020] In one possible implementation, if the aforementioned requirement includes link types that need to be excluded from the link reaching the target network prefix, the aforementioned path calculation constraint information may include a second TLV, which may be, for example, an Exclude Link-Type TLV, indicating the link types that need to be excluded from the link reaching the target network prefix.

[0021] In one possible implementation, the aforementioned path calculation constraint information may be carried in an SD-WAN transport network port (TNP) route advertisement message. In other words, in a specific implementation, receiving the route advertisement message may include receiving an SD-WAN TNP route advertisement message, which includes the aforementioned path calculation constraint information. For example, the SD-WAN TNP route advertisement message includes the aforementioned first TLV and / or second TLV.

[0022] In one possible implementation, the path calculation constraint information may be carried by an Extended Port Attribute Sub-TLV in the SD-WAN TNP route announcement message. Specifically, the first TLV and / or the second TLV may serve as a sub-sub-TLV of the Extended Port Attribute Sub-TLV. In this case, the target device may parse the Extended Port Attribute Sub-TLV in the SD-WAN TNP route announcement message to obtain the path calculation constraint information.

[0023] In one possible implementation, the SD-WAN TNP route announcement message may include a first metadata path attribute, and the first TLV and / or second TLV may be carried by the first metadata path attribute. In this case, the target device may parse the first metadata path attribute in the SD-WAN TNP route announcement message to obtain the path calculation constraint information.

[0024] In one possible implementation, the aforementioned path calculation constraint information may be carried by a Path Computation Element Protocol (PCEP) message. In other words, when receiving a route advertisement message, a PCEP message may be received during a specific implementation, and the PCEP message includes the aforementioned path calculation constraint information. In a specific example, the PCEP message may include a first object and / or a second object, wherein the first object is used to carry the first TLV, and the second object is used to carry the second TLV. The first object and the second object may be newly extended objects. In another specific example, the aforementioned first TLV and the second TLV may be carried by an existing PCEP object. For example, the existing PCEP object may be extended to carry the aforementioned first TLV and the second TLV.

[0025] In one possible implementation, the aforementioned path calculation constraint information can be carried via a BGP outbound route filter (ORF) message. In other words, when receiving a route advertisement message, a BGP ORF message can be received during a specific implementation, and the BGP ORF message includes the aforementioned path calculation constraint information. For example, the BGP ORF message includes the aforementioned first TLV and / or second TLV. In a specific example, the BGP ORF message can include a second metadata path attribute, and the aforementioned first TLV and / or second TLV can be carried via the second metadata path attribute.

[0026] In a possible implementation, the path calculation constraint information may be carried in an Overlay Management Protocol (OMP) message. In one example, the first TLV and the second TLV may be carried in a data field of the OMP message.

[0027] In a second aspect, embodiments of the present application provide an information processing method that can be applied, for example, to a target device. The target device can be a controller or a first Point of Presence (POP). The target device can receive path calculation constraint information, where the path calculation constraint information indicates the link type requirements for links reaching the target network prefix. In this way, a device for orchestrating service paths can orchestrate service paths based on the path calculation constraint information, maximizing the number of service paths that conform to the path calculation constraint information, thereby satisfying service requirements.

[0028] In a possible implementation, the method is applied to the first POP, and the method further includes: sending the target network prefix and the link type requirement information to a controller.

[0029] In a possible implementation, the requirement includes: link types that need to be included in the link reaching the target network prefix, and / or link types that need to be excluded in the link reaching the target network prefix.

[0030] In one possible implementation, the path calculation constraint information includes an included link type TLV and / or an excluded link type TLV, wherein the included link type TLV indicates the link type that needs to be included in the link to reach the target network prefix, and the excluded link type TLV indicates the link type that needs to be excluded in the link to reach the target network prefix.

[0031] In a possible implementation, the receiving of the path calculation constraint information includes: receiving a software-defined wide area network transport network port SD-WAN TNP routing announcement message, wherein the SD-WAN TNP routing announcement message includes the path calculation constraint information.

[0032] In one possible implementation, the SD-WAN TNP route announcement message includes an extended port attribute sub-TLV, and the extended port attribute sub-TLV includes the path calculation constraint information.

[0033] In one possible implementation, the SD-WAN TNP route includes a first metadata path attribute, and the first metadata path attribute includes the path calculation constraint information.

[0034] In a possible implementation, the receiving the path calculation constraint information includes: receiving a Path Computation Protocol (PCEP) message, where the PCEP message includes the path calculation constraint information.

[0035] In a possible implementation, the receiving the path calculation constraint information includes: receiving a BGP egress route filtering ORF message, wherein the BGP ORF message includes the path calculation constraint information.

[0036] In a possible implementation manner, the receiving the path calculation constraint information includes: receiving an Overlay Management Protocol (OMP) message, where the OMP message includes the path calculation constraint information.

[0037] In a third aspect, embodiments of the present application provide an information processing method, comprising: obtaining path calculation constraint information and transmitting the path calculation constraint information, wherein the path calculation constraint information indicates a requirement for a link type of a link to a target network prefix. In this way, a device for orchestrating service paths can orchestrate service paths based on the path calculation constraint information, maximizing the likelihood of orchestrating service paths that conform to the path calculation constraint information, thereby satisfying service requirements.

[0038] In a possible implementation, the requirement includes: link types that need to be included in the link reaching the target network prefix, and / or link types that need to be excluded in the link reaching the target network prefix.

[0039] In one possible implementation, the path calculation constraint information includes an included link type TLV and / or an excluded link type TLV, wherein the included link type TLV indicates the link type that needs to be included in the link to reach the target network prefix, and the excluded link type TLV indicates the link type that needs to be excluded in the link to reach the target network prefix.

[0040] In a possible implementation, the sending of the path calculation constraint information includes: sending a software-defined wide area network transport network port SD-WAN TNP routing announcement message, wherein the SD-WAN TNP routing announcement message includes the path calculation constraint information.

[0041] In one possible implementation, the SD-WAN TNP route announcement message includes an extended port attribute sub-TLV, and the extended port attribute sub-TLV includes the path calculation constraint information.

[0042] In one possible implementation, the SD-WAN TNP route includes a first metadata path attribute, and the first metadata path attribute includes the path calculation constraint information.

[0043] In a possible implementation, sending the path calculation constraint information includes sending a Path Computation Protocol (PCEP) message, where the PCEP message includes the path calculation constraint information.

[0044] In a possible implementation, sending the path calculation constraint information includes sending a BGP egress route filtering ORF message, where the BGP ORF message includes the path calculation constraint information.

[0045] In a possible implementation manner, sending the path calculation constraint information includes: sending an Overlay Management Protocol (OMP) message, where the OMP message includes the path calculation constraint information.

[0046] In a fourth aspect, embodiments of the present application provide an information processing device, comprising a transceiver unit and / or a processing unit, wherein the transceiver unit is configured to perform transceiver operations, and the processing unit is configured to perform operations other than transceiver operations. The receiving unit may include a receiving unit and / or a sending unit, wherein the receiving unit is configured to perform a receiving operation, and the sending unit is configured to perform a sending operation.

[0047] In a specific example, the information processing device is configured to execute the method described in any one of the first aspects above. In this case, the information processing device may specifically include: an acquisition unit configured to acquire a Border Gateway Protocol (BGP) message, wherein the BGP message includes indication information, wherein the indication information indicates a link type of a link between a first point of presence (POP) and a second point of presence (POP), and wherein the address family of the BGP message is a BGP link state (LS) address family.

[0048] In a possible implementation manner, the acquiring unit may specifically be a receiving unit, configured to receive the BGP message.

[0049] In another possible implementation, the acquiring unit may specifically be a processing unit configured to generate the BGP message.

[0050] In one possible implementation, the indication information indicates that the link type is: an upper layer overlay link, an underlying underlay link, a direct link, a dedicated line link, a multi-protocol label switching MPLS link, an Internet Protocol version 6 segment routing SRv6 link, an Internet link, a fourth generation mobile communication technology 4G link, a fifth generation mobile communication technology 5G link, or a fifth generation mobile communication technology plus 5G+ link.

[0051] In a possible implementation, the sub-address family of the BGP message is a shortest path first (SPF) sub-address family.

[0052] In a possible implementation, the BGP message includes a link type length value TLV, and the link type TLV includes the indication information.

[0053] In a possible implementation, the BGP message includes a BGP LS attribute, and the BGP LS attribute includes the link type TLV.

[0054] In a possible implementation, the device is applied to the first POP or a controller.

[0055] In a possible implementation, when the acquisition unit 501 is specifically a receiving unit, the receiving unit is further configured to: receive path calculation constraint information, where the path calculation constraint information indicates a requirement for a link type of a link reaching a target network prefix.

[0056] In a possible implementation, when the aforementioned acquiring unit 501 is specifically a processing unit, the apparatus further includes a receiving unit configured to receive path calculation constraint information, where the path calculation constraint information indicates a requirement for a link type of a link reaching a target network prefix.

[0057] In a possible implementation, the device is applied to the first POP, and the device further includes: a sending unit, configured to send the target network prefix and the link type requirement information to a controller.

[0058] In a possible implementation, the requirement includes: link types that need to be included in the link reaching the target network prefix, and / or link types that need to be excluded in the link reaching the target network prefix.

[0059] In one possible implementation, the path calculation constraint information includes an included link type TLV and / or an excluded link type TLV, wherein the included link type TLV indicates the link type that needs to be included in the link to reach the target network prefix, and the excluded link type TLV indicates the link type that needs to be excluded in the link to reach the target network prefix.

[0060] In a possible implementation, the receiving unit is specifically used to: receive a software-defined wide area network transport network port SD-WAN TNP routing announcement message, where the SD-WAN TNP routing announcement message includes the path calculation constraint information.

[0061] In one possible implementation, the SD-WAN TNP route announcement message includes an extended port attribute sub-TLV, and the extended port attribute sub-TLV includes the path calculation constraint information.

[0062] In one possible implementation, the SD-WAN TNP route includes a first metadata path attribute, and the first metadata path attribute includes the path calculation constraint information.

[0063] In a possible implementation manner, the receiving unit is specifically configured to: receive a Path Computation Protocol (PCEP) message, where the PCEP message includes the path calculation constraint information.

[0064] In a possible implementation, the receiving unit is specifically configured to receive a BGP egress route filtering ORF message, where the BGP ORF message includes the path calculation constraint information.

[0065] In a possible implementation manner, the receiving unit is specifically configured to: receive an Overlay Management Protocol (OMP) message, where the OMP message includes the path calculation constraint information.

[0066] In another specific example, the information processing device is configured to execute the method described in any one of the second aspects above. In this case, the information processing device may specifically include: a receiving unit configured to receive path calculation constraint information, wherein the path calculation constraint information indicates a requirement for a link type of a link to a target network prefix.

[0067] In another specific example, the information processing apparatus is configured to execute the method described in any one of the third aspects above. In this case, the information processing apparatus may specifically include: an acquisition unit and a sending unit. The acquisition unit is configured to acquire path calculation constraint information, the path calculation constraint information indicating a link type requirement for a link to a target network prefix; and the sending unit is configured to send the path calculation constraint information.

[0068] In a possible implementation manner, the acquiring unit may specifically be a receiving unit, configured to receive the path calculation constraint information.

[0069] In another possible implementation, the acquisition unit may specifically be a processing unit, configured to generate the path calculation constraint information.

[0070] In a fifth aspect, an embodiment of the present application provides a communication device, characterized in that it includes: a processor and a memory;

[0071] The memory is used to store instructions; the processor is used to execute the instructions, so that the communication device performs the method described in the first aspect and any one of the first aspects, or the communication device performs the method described in the second aspect and any one of the second aspects, or the communication device performs the method described in the third aspect and any one of the third aspects.

[0072] In a sixth aspect, an embodiment of the present application provides a computer-readable storage medium, comprising instructions or a computer program. When the instructions or computer program are executed on a processor, the method described in the first aspect and any one of the first aspects is implemented, or the method described in the second aspect and any one of the second aspects is implemented, or the method described in the third aspect and any one of the third aspects is implemented.

[0073] In the seventh aspect, an embodiment of the present application provides a computer program product, including a computer program product, which, when running on a processor, implements the method described in the first aspect and any one of the first aspects, or implements the method described in the second aspect and any one of the second aspects, or implements the method described in the third aspect and any one of the third aspects.

[0074] In an eighth aspect, an embodiment of the present application provides a communication system, which includes a communication device for executing the method described in the second aspect and any one of the second aspect, and a communication device for executing the method described in the third aspect and any one of the third aspect. BRIEF DESCRIPTION OF THE DRAWINGS

[0075] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are only some embodiments recorded in this application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0076] FIG1a is a schematic diagram of an exemplary application scenario provided by an embodiment of the present application;

[0077] FIG1b is a schematic diagram of another exemplary application scenario provided by an embodiment of the present application;

[0078] FIG1c is a schematic diagram of another exemplary application scenario provided by an embodiment of the present application;

[0079] FIG2a is a schematic diagram of the structure of a BGP message header provided in an embodiment of the present application;

[0080] FIG2 b is a schematic diagram of the structure of an MP_REACH_NLRI provided in an embodiment of the present application;

[0081] FIG2c is a schematic diagram of the structure of a link state NLRI provided in an embodiment of the present application;

[0082] FIG2d is a schematic diagram of the structure of a BGP route update message provided in an embodiment of the present application;

[0083] FIG2e is a schematic diagram of the structure of a PCEP message provided in an embodiment of the present application;

[0084] FIG2f is a schematic diagram of the structure of an OMP message provided in an embodiment of the present application;

[0085] FIG3 is a flow chart of an information processing method provided in an embodiment of the present application;

[0086] FIG4a is a schematic diagram of the structure of a link type TLV provided in an embodiment of the present application;

[0087] FIG4 b is a schematic structural diagram of a first TLV provided in an embodiment of the present application;

[0088] FIG4c is a schematic diagram of the structure of a second TLV provided in an embodiment of the present application;

[0089] FIG4 d is a schematic diagram of the structure of an LSPA object provided in an embodiment of the present application;

[0090] FIG4e is a schematic diagram of the structure of an RP object provided in an embodiment of the present application;

[0091] FIG5 is a schematic diagram of the structure of an information processing device provided in an embodiment of the present application;

[0092] FIG6 is a schematic structural diagram of another information processing device provided in an embodiment of the present application;

[0093] FIG7 is a schematic structural diagram of another information processing device provided in an embodiment of the present application;

[0094] FIG8 is a schematic structural diagram of a communication device provided in an embodiment of the present application;

[0095] FIG9 is a schematic structural diagram of a communication device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0096] The embodiments of the present application provide a method and apparatus for forwarding traffic, which can facilitate orchestration of service paths, thereby making the orchestrated paths more consistent with service requirements.

[0097] For ease of understanding, the possible application scenarios of the embodiments of the present application are first introduced.

[0098] After SD-WAN is deployed, the SD-WAN overlay network under the wide area network establishes SD-WAN tunnels between POP points and between customer-premises equipment (CPE) and edge point of presence (EPOP) based on the original underlay network. Business traffic passes through intermediate devices in the form of tunnels, making the intermediate devices unaware of the business.

[0099] Refer to Figure 1a, which is a schematic diagram of an exemplary application scenario provided by an embodiment of the present application. As shown in Figure 1a, service traffic needs to be transmitted across the edge access area 100, the backbone network 200, and the edge access area 300. Among them:

[0100] The backbone network 200 is an SD-WAN overlay network.

[0101] The edge access network 100 includes a site edge1, a site edge3, and a site edge4.

[0102] Backbone network 200 includes at least one network device. For example, when backbone network 200 is a Point of Presence (POP) backbone network, backbone network 200 includes at least one Point of Presence (POP). A POP connected to a site edge in the POP backbone network is called an EPOP, and a POP not connected to a site edge is called a backbone point of presence (BPOP). In one example, a site edge can be a Customer Presence Equipment (CPE).

[0103] The edge access network 300 includes a site edge2 and a site edge5.

[0104] Site edges in edge access networks 100 and 300 can access the backbone network through the EPOP in the backbone network. The EPOP in the backbone network used by a site edge to access the backbone network can be considered the gateway corresponding to the site edge. For example, as shown in Figure 1a, site edge1 is dual-homed to gateway (GW) 1 and gateway 3. Site edge1 can access backbone network 200 through gateways 1 and 3. For another example, site edge2 is dual-homed to gateways 2 and 4. Site edge2 can access backbone network 200 through gateways 2 and 4.

[0105] The site edge can access its corresponding gateway through the SD-WAN tunnel or the internet. The gateway is a POP in the backbone network 200.

[0106] In an embodiment of the present application, the backbone network may be a hybrid network including at least one network domain, including but not limited to: a self-built backbone network and / or a managed service provider (MSP) backbone network, wherein the MSP backbone network may include a single operator network, a hybrid operator network, or a self-built dedicated line network, which is not specifically limited in the embodiment of the present application. MPLS technology or SRv6 technology may be applied to the backbone network, which is not specifically limited in the embodiment of the present application.

[0107] This can be understood by referring to FIG. 1 b and FIG. 1 c , which are schematic diagrams of two other exemplary application scenarios provided in an embodiment of the present application.

[0108] As shown in Figure 1b, backbone network 400 includes: Internet Service Provider (ISP) network 1 (ISP1), ISP2, ISP3, and a self-built dedicated line network. The difference between the scenario shown in Figure 1c and Figure 1b is that backbone network 500 shown in Figure 1c does not include a self-built dedicated line network.

[0109] The connection method between the network devices in the network architecture shown in Figure 1b and Figure 1c is not described in detail here.

[0110] Currently, service paths across the backbone network 200 can be orchestrated for services. In one example, the ingress POP in the backbone network can orchestrate an end-to-end path from the ingress POP to the egress POP. After the service traffic reaches the ingress POP, it is forwarded to the egress POP via the end-to-end path, and further forwarded to the destination device via the egress POP. In another example, the end-to-end path that carries the service can be calculated by the CPE. For example, in the scenario shown in Figure 1b, the end-to-end path from edge1 to edge2 is calculated by edge1. In another example, the controller can uniformly orchestrate paths across the entire network. For example, the controller can uniformly orchestrate the end-to-end path from the ingress POP to the egress POP. For another example, the controller can uniformly orchestrate the end-to-end path between two CPEs across the backbone network.

[0111] Currently, when orchestrating service paths, path orchestration can be performed by combining information such as link cost, latency and other parameter values. However, using this approach, the orchestrated paths often fail to meet service requirements.

[0112] In order to solve the above problems, an embodiment of the present application provides an information processing method.

[0113] To facilitate understanding of this solution, we first introduce the relevant technologies that may be involved in this application.

[0114] 1.BGP

[0115] BGP is a dynamic routing protocol used between autonomous systems (ASs). As a standard for external internet routing, BGP is widely used between internet service providers (ISPs). Currently, the most widely used version is Multi-Protocol Extensions for BGP (MP-BGP), which is an extension of BGP version 4 (BGP-4).

[0116] BGP messages consist of two parts: a BGP message header and message content. As shown in Table 1 below, BGP has five message types as shown in Table 2 below, and these five message types have the same BGP message header. These messages are transmitted through the Transmission Control Protocol (TCP). The maximum length of a message is 65,535 bytes, and the shortest is 19 bytes (containing only the BGP message header). Among them: the BGP message header can be shown in Figure 2a, which is a structural diagram of a BGP message header provided in an embodiment of the present application. As shown in Figure 2a, the BGP message header includes three parts, namely, a marker field, a length field, and a type field. The three parts of the BGP message header can be understood in conjunction with Table 1 below.

[0117] Table 1

[0118] Table 2

[0119] in:

[0120] BGP open messages, BGP notification messages, and BGP keepalive messages are not described in detail here.

[0121] BGP update messages are used to advertise routes;

[0122] In one example, routes can be announced between communication devices via MP-BGP. Specifically, the BGP messages for announcing routes exchanged between communication devices include multi-protocol reach network layer reachability information (MP_REACH_NLRI), and MP_REACH_NLRI is used to carry routes. In one example, the structure of MP_REACH_NLRI is shown in Figure 2b, which is a structural diagram of an MP_REACH_NLRI provided in an embodiment of the present application. As shown in Figure 2b, the MP_REACH_NLRI includes an address family identifier (AFI), a subsequent address family identifier (SAFI), a next hop information length field, a next hop information field, and an NLRI domain.

[0123] As an example, the AFI field can identify the network layer protocol. For example, the value of the AFI field is 1 to identify IPv4, and the value of the AFI field is 2 to identify IPv6. The value of the AFI field can refer to the relevant description of the address family number in RFC1700, which is not described in detail here. The SAFI field identifies the type of the sub-address family. For example, the value of the SAFI field is 1 to identify unicast, the value of the SAFI field is 2 to identify multicast, the value of the SAFI field is 74 to identify SD-WAN, and the value of the SAFI field is 128 to identify a virtual private network (VPN).

[0124] In one example, the aforementioned next-hop network address may refer to the network address of the next device on the path to the destination device.

[0125] In an example, the NLRI field may include one or more NLRIs, each NLRI includes a length field and an NLRI value field, and the specific content of the NLRI value may be determined according to a combination of the AFI field and the SAFI field.

[0126] The NLRI information field includes a route type field, a length field, and a type specific value field. The route type field is used to indicate the route type, the length field is the length of the type specific value field, and the type specific value field is used to carry a value related to the type corresponding to the route type field.

[0127] The BGP route refresh message may include multiple messages, one of which is the BGP ORF message.

[0128] Regarding BGP ORF messages, it is important to note that:

[0129] RFC5291 and RFC5292 specify BGP's prefix-based ORF capability, which can send the prefix-based ingress policy configured on the local device to BGP neighbors via a route refresh message. BGP neighbors construct egress policies based on these policies and filter routes as they are sent. This not only prevents the local device from receiving a large number of useless routes and reduces the utilization of the local device's central processing unit (CPU), but also effectively reduces the configuration work required for BGP neighbors and reduces link bandwidth usage. For example, communication device A and communication device B establish a direct BGP neighbor relationship. After communication devices A and B negotiate the prefix-based ORF capability, communication device A sends the locally configured prefix-based ingress policy to communication device B via a route refresh message. Communication device B constructs an egress policy based on the received route refresh message. Communication device A only receives the routes it needs, and communication device B does not need to maintain routing policies, reducing configuration work.

[0130] 2. BGP LS

[0131] BGP-LS is a method for collecting network topology, which can make topology collection simpler and more efficient.

[0132] Based on the original BGP, BGP-LS introduces a series of new NLRIs to carry information related to links, nodes, and IPv4 prefixes or IPv6 prefixes. This new NLRI is called link-state NLRI. In one example, BGP-LS uses the MP_REACH_NLRI attribute as a container for link-state NLRI, that is, the link-state NLRI is carried in the BGP Update message as an MP_REACH_NLRI attribute. See Figure 2c, which is a structural diagram of a link-state NLRI provided in an embodiment of the present application. As shown in Figure 2c, the link-state NLRI includes an NLRI type field, a total NLRI length field, and a link-state NLRI field. Among them:

[0133] The NLRI type field is used to indicate the NLRI type, which can be understood by referring to Table 3 below;

[0134] The total NLRI length field indicates the length of the entire NLRI;

[0135] The link-state NLRI field is used to carry specific content. The content of the link-state NLRI field is determined by the value of the NLRI type field.

[0136] Table 4

[0137] 3. BGP-LS-SPF address family

[0138] The BGP-LS-SPF address family is also called the BGP-SPF address family. The BGP-SPF address family is a new address family added under Link-state AFI. This new sub-address family is a combination of the LS address family and the SPF sub-address family.

[0139] The SAFI value of the BGP-SPF address family is 80.

[0140] The NLRI types defined by the BGP-SPF address family remain as shown in Table 4 above: node NLRI, link NLRI, IPv4 topology prefix NLRI, and IPv6 topology prefix NLRI.

[0141] Each communication device that enables the BGP-LS-SPF address family needs to unconditionally generate a node NLRI. The specific format of the node NLRI is not described in detail here.

[0142] For communication devices that have the BGP-LS-SPF address family enabled, they generate a link NLRI for their own link information and advertise it to other communication devices. The format of the link NLRI complies with the definition in RFC7752 and is not detailed here.

[0143] BGP route update messages for the BGP-LS-SPF address family carry multiple path attributes, one of which is called the BGP-LS Attribute, which is defined in RFC7752. The BGP-LS Attribute can carry one or more TLVs used to describe nodes, links, or prefixes. As mentioned earlier, BGP messages also contain an MP_REACH_NLRI, which is defined in RFC4760. When the AFI of the MP_REACH_NLRI is 16388 and the SAFI is 80, it indicates that this is a BGP route update message for the BGP-LS-SPF address family. In addition, as shown in Table 4 above, when the NLRI Type value in the MP_REACH_NLRI is 2, it indicates that the NLRI included in the BGP route update message for the BGP-LS-SPF address family is the Link NLRI.

[0144] For a BGP route update message for a BGP-LS-SPF address family that includes a Link NLRI, its Link NLRI may include a Link Description TLV. The Link Description TLV may include one or more TLVs that describe the link. For example, the Link Description TLV may include a Local Address TLV and a Neighbor Address TLV. The Local Address TLV is used to carry its own IP address, and the Neighbor Address TLV is used to carry the IP address of the other end, and is used to identify the link between the local end and the other end. In one example, the Local Address TLV may be an IPv6 Interface Address TLV (IPv6 interface address TLV), and the Neighbor Address TLV may be an IPv6 Neighbor Address TLV (IPv6 neighbor address TLV).

[0145] Next, the structure of a BGP route update message including the BGP-LS-SPF address family of Link NLRI will be introduced in conjunction with Figure 2d. Figure 2d is a schematic diagram of the structure of a BGP route update message provided in an embodiment of the present application.

[0146] As shown in Figure 2d, the BGP route update message includes: a marker field, a length field, a type field, an unavailable route length field, a total path attribute length field, and a path attribute field. The path attribute field can carry multiple BGP path attributes, wherein the multiple BGP path attributes can include at least: a BGP LS attribute and an MP_REACH_NLRI, and the MP_REACH_NLRI can include at least the aforementioned link description TLV. In an embodiment of the present application, the value carried by the unavailable route length field can be 0.

[0147] 4. SD-WAN TNP

[0148] When the address family of the BGP route refresh message is the SD-WAN address family or the sub-address family is the SD-WAN sub-address family, and the value of the route type field shown in Figure 2b is 1, the BGP route refresh message can be called an SD-WAN TNP route announcement message, which is used to announce the SD-WAN TNP route. In this case, the NLRI field shown in Figure 2b can be used to carry the information of the SD-WAN TNP route. The information about the TNP route is not described in detail here.

[0149] 5.PCEP

[0150] PCEP messages include a PCEP request message and a PCEP response message. The structures of both the PCEP request message and the PCEP response message are as described in Figure 2e , which is a schematic diagram of the structure of a PCEP message provided in an embodiment of the present application. The PCEP message shown in Figure 2e includes a PCEP general message header and an object list. For details about the PCEP general message header, refer to RFC5440 and are not described in detail here. The object list is used to carry one or more objects.

[0151] in:

[0152] A PCEP request message may be used to request a device (eg, a controller or POP) to calculate a path. After the device calculates the path, it may return a PCEP response message corresponding to the PCEP request message.

[0153] The PCEP request message must carry a request parameter (RP) object and an end point (END-POINTS) object. It also carries other optional objects, such as a label switched path attributes (LSPA) object, a record route object (RRO), and an include route object (IRO).

[0154] The PCEP response message must carry an RP object. If path calculation succeeds, it can carry an explicit route object (ERO). If path calculation fails, it can carry a no-path object. The PCEP response message also carries other optional objects, such as the LSPA object and the IRO object.

[0155] For the various objects included in the PCEP request message and the PCEP response message, please refer to the relevant description in RFC5440, which will not be described in detail here.

[0156] 6.OMP Message

[0157] The OMP message is used to announce the OMP route. The message structure of the OMP message can be shown in Figure 2f, which is a schematic diagram of the structure of an OMP message provided in an embodiment of the present application. As shown in Figure 2f, the OMP message includes an attribute length field and a data field.

[0158] The Attributes Length field is used to indicate the length of the data field: attribute length, 2 bytes.

[0159] The data field is used to carry various attributes of one or more OMP routes, which are carried in the form of TLVs.

[0160] Next, the information processing method is introduced with reference to the accompanying drawings.

[0161] See FIG3 , which is a flow chart of an information processing method provided in an embodiment of the present application.

[0162] In one example, the method 100 shown in Figure 3 can be applied to a first POP. In another example, the method 100 shown in Figure 3 can be applied to a controller.

[0163] The method 100 shown in FIG3 may include S101 .

[0164] S101: Obtain a BGP message, where the BGP message includes indication information, where the indication information indicates a link type of a link between a first POP and a second POP, and an address family of the BGP message is a BGP LS address family.

[0165] When the method 100 is applied to a first POP, in a specific implementation, S101 may first determine the link type of the link between the first POP and the second POP, and then generate the BGP message based on the link type of the link.

[0166] Regarding the first POP and the second POP, using the network scenario shown in Figure 1b as an example, the first POP may be POP1 shown in Figure 1b, and the second POP may be POP2 shown in Figure 1b. Alternatively, the first POP may be POP2 shown in Figure 1b, and the second POP may be POP1, POP5, POP6, POP7, POP3, or POP8 shown in Figure 1b. These are not listed here.

[0167] As an example, after the first POP generates the BGP message, S102 may be executed.

[0168] S102: Send the BGP message.

[0169] In one example, when S102 is implemented, the BGP message may be sent to other POPs in the backbone network. In another example, when S102 is implemented, the BGP message may be sent to a controller.

[0170] When the method 100 is applied to a controller, S101 may be implemented as receiving the BGP message sent by the first POP.

[0171] In one example, the link type indicated by the indication information may be: an overlay link, an underlay link, a direct link, a dedicated line link, an MPLS link, an SRv6 link, an internet link, a 4G link, a 5G link, or a 5G+ link. A 5G+ link refers to a link that uses a technology developed further on the basis of 5G technology. 5G+ may include 6G.

[0172] Among them, direct links and dedicated links are underlay links, and MPLS links, SRv6 links, internet links, 4G links, 5G links, or 5G+ links are all overlay links. When the link type indicated by the indication information is an MPLS link, an SRv6 link, an internet link, a 4G link, a 5G link, or a 5G+ link, the indication information can naturally indicate that the link type of the link between the first POP and the second POP is an overlay link. When the link type indicated by the indication information is a direct link or a dedicated link, the indication information can naturally indicate that the link type of the link between the first POP and the second POP is an underlay link.

[0173] The embodiments of the present application do not specifically limit the sub-address family of the BGP message; the sub-address family of the BGP message may be any sub-address family under the BGP LS address family. In one example, considering that the link NLRI of the BGP-LS-SPF address family can be used to advertise link information, in a specific example, the sub-address family of the BGP message may be the SFP sub-address family. That is, in the embodiments of the present application, the feature of BGP-LS-SPF capable of advertising link information is maintained, and the BGP message based on the use of the BGP-LS-SPF address family carries the aforementioned indication information.

[0174] In the case where the sub-address family of the BGP message is the SPF sub-address family, the BGP message may include a link type TLV, which is used to carry the indication information. The format of the link type TLV can be understood with reference to Figure 4a, which is a structural diagram of a link type TLV provided in an embodiment of the present application. As shown in Figure 4a, the link type TLV may include a type field 401, a length field 402, and a value field 403, wherein the type field 401 indicates that the type of the TLV is a link type TLV, the length field 402 indicates the length of the value field 403, and the value field 403 is used to carry the aforementioned indication information.

[0175] In one example, the BGP message may include a BGP path attribute, and the aforementioned link type TLV may be carried by the BGP path attribute. In other words, the BGP path attribute may include the link type TLV. The embodiments of the present application do not specifically limit the BGP path attribute. In one specific example, the BGP path attribute may be a BGP LS attribute. In this case, the link type TLV may be carried in the BGP LS attribute shown in Figure 2d.

[0176] In one example, the BGP message may include an MP_REACH_NLRI, which may include a link description TLV. The link type TLV may be carried by the link description TLV. In this case, the link type TLV may be carried by the link description TLV shown in FIG2 d . That is, in addition to including a local address TLV and a neighbor address TLV, the link type TLV may also include the link description TLV to indicate the link type of the link.

[0177] In an embodiment of the present application, in order to better meet business needs, the first POP or controller may combine path calculation constraint information when calculating a business path for the business, wherein the path calculation constraint information indicates the link type requirement for the link reaching the target network prefix. The business path reaching the target network prefix may include multiple links, and the aforementioned path calculation constraint information may indicate the link type requirement for the multiple links reaching the target network prefix. In a specific example, the controller or the first POP may receive the path calculation constraint information and further determine the path to the target network prefix based on the path calculation constraint information.

[0178] In one example, when method 100 is applied to a controller, the controller may receive the aforementioned path calculation constraint information sent by a first POP or CPE, so as to calculate a service path to a target network prefix based on the path calculation constraint information. In other words, the first POP or CPE may obtain the path calculation constraint information and send it to the controller.

[0179] In another example, when method 100 is applied to a first POP, the first POP may receive the aforementioned path calculation constraint information sent by a CPE. As an example, the first POP may calculate a service path to a target network prefix based on the path calculation constraint information. As another example, after receiving the path calculation constraint information, the first POP may send the path calculation constraint information to a controller, which then calculates a service path to the target network prefix based on the path calculation constraint information.

[0180] In a specific example, the aforementioned requirement for the link type of the link reaching the target network prefix may include: the link type that the link reaching the target network prefix needs to include. For example, when the service quality requirement of the business is high, the aforementioned requirement may be, for example: the link reaching the target network prefix needs to include a dedicated line link. In this way, by specifying the link type that the link reaching the target network prefix needs to include, the first POP or controller can calculate the business path including the link of the aforementioned link type as much as possible when calculating the business path, thereby meeting the business demand.

[0181] In another specific example, the aforementioned requirement for link types for links reaching the target network prefix may include link types that need to be excluded from links reaching the target network prefix. For example, when a service has high quality of service requirements, the aforementioned requirement may include excluding internet links from links reaching the target network prefix. By specifying the link types that need to be excluded from links reaching the target network prefix, the first POP or controller, when calculating a service path, can attempt to calculate a service path that excludes links of the aforementioned link types, thereby meeting the service requirements.

[0182] In one example, if the aforementioned requirements include the link type that the link to the target network prefix needs to include, the aforementioned path calculation constraint information may include a first TLV, which may, for example, be a link type TLV indicating the link type that the link to the target network prefix needs to include.

[0183] The first TLV can be understood in conjunction with Figure 4b. Figure 4b is a schematic diagram of the structure of a first TLV provided in an embodiment of the present application. As shown in Figure 4b, the first TLV includes a type field 404, a length field 405, and a value field 406, wherein the type field 404 indicates that the type of the TLV is a link type TLV, the length field 405 indicates the length of the value field 406, and the value field 406 is used to carry the link type to be included.

[0184] In another example, if the aforementioned requirements include link types that need to be excluded from the link reaching the target network prefix, the aforementioned path calculation constraint information may include a second TLV, which may be, for example, an excluded link type TLV, indicating the link types that need to be excluded from the link reaching the target network prefix.

[0185] The second TLV can be understood in conjunction with Figure 4c. Figure 4c is a schematic diagram of the structure of a second TLV provided in an embodiment of the present application. As shown in Figure 4c, the second TLV includes a type field 407, a length field 408, and a value field 409, wherein the type field 407 indicates that the type of the TLV is an exclusion link type TLV, the length field 408 indicates the length of the value field 409, and the value field 409 is used to carry the link type to be excluded.

[0186] In one implementation, the aforementioned path calculation constraint information may be carried by an SD-WAN TNP route advertisement message. In other words, in a specific implementation, receiving the route advertisement message may include receiving an SD-WAN TNP route advertisement message, which includes the aforementioned path calculation constraint information. For example, the SD-WAN TNP route advertisement message includes the aforementioned first TLV and / or second TLV.

[0187] The embodiment of the present application does not specifically limit the carrying position of the path calculation constraint information in the SD-WAN TNP route announcement message. In a specific example, the path calculation constraint information can be carried by the extended port attribute sub-TLV in the SD-WAN TNP route announcement message. Specifically, the aforementioned first TLV and / or second TLV can be used as a sub-sub-TLV of the extended port attribute sub-TLV. In another specific example, the SD-WAN TNP route announcement message may include a first metadata path attribute, and the aforementioned first TLV and / or second TLV can be carried by the first metadata path attribute.

[0188] In another implementation, the aforementioned path calculation constraint information may be carried via a PCEP message. For example, it may be carried via a PCEP request message. In other words, when receiving a route advertisement message, a PCEP message may be received, which includes the aforementioned path calculation constraint information. For example, the PCEP message includes the aforementioned first TLV and / or second TLV. In a specific example, the PCEP message may include a first object and / or a second object, where the first object is used to carry the first TLV, and the second object is used to carry the second TLV. The first object and the second object may be newly extended objects. In other words, in an embodiment of the present application, two new PCEP objects (i.e., the first object and the second object) may be extended in the PCEP message to carry the first TLV and the second TLV. In another specific example, the aforementioned first TLV and the second TLV may be carried using an existing PCEP object. In a specific example, an existing PCEP object may be extended to carry the aforementioned first TLV and the second TLV.

[0189] As a specific example, an LSPA object can be extended, and the extended LSPA object can be used to carry the aforementioned first and second TLVs. For further information, refer to Figure 4d, which is a schematic diagram of the structure of an LSPA object provided in an embodiment of the present application. As shown in Figure 4d, the LSPA object includes: an Exclude-any field, an Include-any field, an Include-all field, a Setup Priority field, a Holding Priority field, a Flags field, an L flag, a Reserved field, and an Optional TLVs field. For details about the Exclude-any field, Include-any field, Include-all field, Setup Priority field, Holding Priority field, Flags field, L flag, and Reserved field in the LSPA object, refer to RFC 5440 and are not described in detail here.

[0190] In one example, the Optional TLVs field can be extended to carry the aforementioned first TLV and second TLV. Specifically, the path information TLV can be carried in the Optional TLVs field. The structure of the path information TLV can be as shown in Figure 4d, including: a type field, a length field, a source endpoint address field, a destination endpoint address field, and the aforementioned first TLV field and second TLV field. Wherein:

[0191] The source endpoint address field is used to carry the address of the source endpoint of the path for which calculation is requested, and the destination endpoint address field is used to carry the destination address of the path for which calculation is requested (e.g., the aforementioned target network prefix). Optionally, the path information TLV may also include a path identification (path ID) field to indicate the identification of the path for which calculation is requested.

[0192] As another example, the RP object can be extended, and the extended RP object can be used to carry the aforementioned first TLV and second TLV. Please refer to Figure 4e for understanding, which is a structural diagram of an RP object provided in an embodiment of the present application. As shown in Figure 4e, the RP object includes: an identification (Flags) field, an O indicator bit, a B indicator bit, an R indicator bit, a priority (Prio) indicator bit, a request ID number (Request-ID-number) field and an optional TLVs (Optional TLVs) field. Regarding the Flags field, O indicator bit, B indicator bit, R indicator bit, Prio indicator bit and Request-ID-number field in the RP object, please refer to the relevant description in RFC5440, which will not be described in detail here.

[0193] In one example, the Optional TLVs field in the RP object can be expanded to carry the first TLV and the second TLV. Specifically, the Optional TLVs field can carry a path information TLV. The structure of the path information TLV is the same as the path information TLV shown in Figure 4d, and is not repeated here.

[0194] In another implementation, the aforementioned path calculation constraint information may be carried in a BGP ORF message. In other words, when receiving a route advertisement message, a BGP ORF message may be received, which includes the aforementioned path calculation constraint information. For example, the BGP ORF message includes the aforementioned first TLV and / or second TLV. In a specific example, the BGP ORF message may include a second metadata path attribute, and the aforementioned first TLV and / or second TLV may be carried in the second metadata path attribute.

[0195] In another implementation, the aforementioned path calculation constraint information may be carried in an OMP message. In one example, the aforementioned first TLV and second TLV may be carried in the data field of the OMP message shown in FIG2f.

[0196] The above introduces the information processing method provided in the embodiment of the present application. Next, in combination with the application scenario shown in Figure 1b, a possible implementation method of the embodiment of the present application is introduced.

[0197] As shown in Figure 1b, each POP in the backbone network uses BGP messages to notify other POPs of the link type of its connected links. The address family of this BGP message is the BGP LS address family, with the SPF subaddress family as the subaddress family. A POP can notify its own link type directly to its BGP neighbors or to other POPs via a route reflector (RR). In this way, each POP in the backbone network obtains the link type of each link in the backbone network.

[0198] Site edge1 can send path calculation constraint information to POP1 to request POP1 to calculate a service path from POP1 to site edge2. POP1 can calculate the corresponding service path based on the link type of each link in the backbone network, for example, to obtain a service path that meets the path calculation constraint information.

[0199] Based on the information processing method provided in the above embodiments, the embodiments of the present application also provide a corresponding device, which is described below in conjunction with the accompanying drawings.

[0200] 5 , which is a schematic diagram of the structure of an information processing device provided in an embodiment of the present application. The information processing device 500 shown in FIG5 can be used to execute the above method 100. Specifically, the device 500 can include: an acquisition unit 501.

[0201] The acquisition unit 501 is used to obtain a Border Gateway Protocol BGP message, wherein the BGP message includes indication information, wherein the indication information indicates the link type of the link between the first presence point POP and the second POP, and the address family of the BGP message is the BGP link state LS address family.

[0202] In a possible implementation, the acquiring unit 501 may specifically be a receiving unit configured to receive the BGP message.

[0203] In another possible implementation, the obtaining unit 501 may specifically be a processing unit configured to generate the BGP message.

[0204] In one possible implementation, the indication information indicates that the link type is: an upper layer overlay link, an underlying underlay link, a direct link, a dedicated line link, a multi-protocol label switching MPLS link, an Internet Protocol version 6 segment routing SRv6 link, an Internet link, a fourth generation mobile communication technology 4G link, a fifth generation mobile communication technology 5G link, or a fifth generation mobile communication technology plus 5G+ link.

[0205] In a possible implementation, the sub-address family of the BGP message is a shortest path first (SPF) sub-address family.

[0206] In a possible implementation, the BGP message includes a link type length value TLV, and the link type TLV includes the indication information.

[0207] In a possible implementation, the BGP message includes a BGP LS attribute, and the BGP LS attribute includes the link type TLV.

[0208] In a possible implementation, the device is applied to the first POP or a controller.

[0209] In a possible implementation, when the acquisition unit 501 is specifically a receiving unit, the receiving unit is further configured to: receive path calculation constraint information, where the path calculation constraint information indicates a requirement for a link type of a link reaching a target network prefix.

[0210] In a possible implementation, when the aforementioned acquiring unit 501 is specifically a processing unit, the apparatus further includes a receiving unit configured to receive path calculation constraint information, where the path calculation constraint information indicates a requirement for a link type of a link reaching a target network prefix.

[0211] In a possible implementation, the device is applied to the first POP, and the device further includes: a sending unit, configured to send the target network prefix and the link type requirement information to a controller.

[0212] In a possible implementation, the requirement includes: link types that need to be included in the link reaching the target network prefix, and / or link types that need to be excluded in the link reaching the target network prefix.

[0213] In one possible implementation, the path calculation constraint information includes an included link type TLV and / or an excluded link type TLV, wherein the included link type TLV indicates the link type that needs to be included in the link to reach the target network prefix, and the excluded link type TLV indicates the link type that needs to be excluded in the link to reach the target network prefix.

[0214] In a possible implementation, the receiving unit is specifically used to: receive a software-defined wide area network transport network port SD-WAN TNP routing announcement message, where the SD-WAN TNP routing announcement message includes the path calculation constraint information.

[0215] In one possible implementation, the SD-WAN TNP route announcement message includes an extended port attribute sub-TLV, and the extended port attribute sub-TLV includes the path calculation constraint information.

[0216] In one possible implementation, the SD-WAN TNP route includes a first metadata path attribute, and the first metadata path attribute includes the path calculation constraint information.

[0217] In a possible implementation manner, the receiving unit is specifically configured to: receive a Path Computation Protocol (PCEP) message, where the PCEP message includes the path calculation constraint information.

[0218] In a possible implementation, the receiving unit is specifically configured to receive a BGP egress route filtering ORF message, where the BGP ORF message includes the path calculation constraint information.

[0219] In a possible implementation manner, the receiving unit is specifically configured to: receive an Overlay Management Protocol (OMP) message, where the OMP message includes the path calculation constraint information.

[0220] 6 , which is a schematic diagram of the structure of another information processing device provided in an embodiment of the present application. The information processing device 600 shown in FIG6 can be used to execute the above method 100. Specifically, the device 600 may include: a receiving unit 601.

[0221] The receiving unit 601 is configured to receive path calculation constraint information, where the path calculation constraint information indicates a requirement on a link type of a link reaching a target network prefix.

[0222] Regarding the specific implementation of the receiving unit 601, reference may be made to the above description of the receiving unit in the apparatus 500, which will not be repeated here.

[0223] 7 , which is a schematic diagram of the structure of another information processing device provided in an embodiment of the present application. The information processing device 700 shown in FIG7 can be used to perform some of the steps in the above method 100. Specifically, the device 700 may include: an acquisition unit 701 and a sending unit 702.

[0224] The acquiring unit 701 is configured to acquire path calculation constraint information, where the path calculation constraint information indicates a requirement for a link type of a link to a target network prefix;

[0225] The sending unit 702 is configured to send the path calculation constraint information.

[0226] In a possible implementation, the acquiring unit 701 may specifically be a receiving unit configured to receive the path calculation constraint information.

[0227] In another possible implementation, the acquiring unit 701 may specifically be a processing unit configured to generate the path calculation constraint information.

[0228] In addition, an embodiment of the present application further provides a communication device 800, as shown in Figure 8, which is a schematic diagram of the structure of a communication device provided in an embodiment of the present application. The communication device 800 includes a communication interface 801 and a processor 802 connected to the communication interface 801. The communication device 800 can be used to perform the method 100 in the above embodiment.

[0229] When the communication device 800 is configured to execute the above method 100, the communication interface 801 is configured to execute the sending and receiving operations in method 100. The processor 802 is configured to execute operations other than the sending and receiving operations in method 100. For example, the processor 802 is configured to generate a BGP message, wherein the BGP message includes indication information indicating the link type of the link between the first POP and the second POP, and the address family of the BGP message is the BGP LS address family. The communication interface 801 is configured to send the BGP message.

[0230] In addition, the present invention also provides a communication device 900, as shown in Figure 9, which is a schematic diagram of the structure of a communication device provided in the present invention. The communication device 900 can be used to execute the method 100 in the above embodiment.

[0231] As shown in Figure 9, the communication device 900 may include a processor 910, a memory 920 coupled to the processor 910, and a transceiver 930. The transceiver 930 may be, for example, a communication interface, an optical module, etc. The processor 910 may be a central processing unit (CPU), a network processor (NP), or a combination of a CPU and an NP. The processor may also be an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. The PLD may be a complex programmable logic device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof. The processor 910 may be a single processor or may include multiple processors. The memory 920 may include volatile memory, such as random-access memory (RAM); the memory may also include non-volatile memory, such as read-only memory (ROM), flash memory, a hard disk drive (HDD), or a solid-state drive (SSD); and the memory 920 may also include a combination of the aforementioned types of memory. The memory 920 may refer to a single memory or may include multiple memories. In one embodiment, the memory 920 stores computer-readable instructions, which include multiple software modules, such as a sending module 921, a processing module 922, and a receiving module 923. After executing each software module, the processor 910 may perform corresponding operations according to the instructions of each software module. In this embodiment, the operations performed by a software module actually refer to the operations performed by the processor 910 according to the instructions of the software module.

[0232] When the communication device 900 is configured to execute the above method 100, the transceiver 930 is configured to perform the transceiver operations in method 100. The processor 910 is configured to perform operations in method 100 other than the transceiver operations. For example, the processor 910 is configured to generate a BGP message, wherein the BGP message includes indication information indicating the link type of the link between the first POP and the second POP, and the address family of the BGP message is the BGP LS address family. The transceiver 930 is configured to send the BGP message.

[0233] The present application also provides a computer-readable storage medium, which stores instructions or computer programs. When the instruction computer program runs on a processor, it can implement any one or more operations of the methods described in the above embodiments (such as method 100).

[0234] The present application also provides a computer program product, including a computer program. When the computer program is run on a processor, it can implement any one or more operations of the methods described in the above embodiments (such as method 100).

[0235] Embodiments of the present application also provide a communication system for executing the methods described in the aforementioned embodiments. For example, the communication system includes a communication device for acquiring and sending the aforementioned BGP message and a communication device for receiving the BGP message. In another example, the communication system includes a communication device for acquiring and sending the aforementioned path calculation constraint information and a communication device for receiving the path calculation constraint information.

[0236] The terms "first," "second," "third," "fourth," and the like (if any) in the specification and claims of this application and in the accompanying drawings are used to distinguish similar objects and are not necessarily used to describe a particular order or sequential sequence. It should be understood that the terms used in this manner are interchangeable where appropriate so that the embodiments described herein can be implemented in an order other than that illustrated or described herein. In addition, the terms "including" and "having," and any variations thereof, are intended to cover non-exclusive inclusions, e.g., a process, method, system, product, or apparatus comprising a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0237] Those skilled in the art will clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0238] In the several embodiments provided in this application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For example, the division of units is only a logical business division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interface, device or unit, which can be electrical, mechanical or other forms.

[0239] Units described as separate components may or may not be physically separate, and components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of these units may be selected to achieve the purpose of this embodiment according to actual needs.

[0240] In addition, each business unit in each embodiment of the present application can be integrated into a processing unit, each unit can exist physically separately, or two or more units can be integrated into a single unit. The above-mentioned integrated units can be implemented in the form of hardware or software business units.

[0241] If the integrated unit is implemented in the form of a software business unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, or all or part of the technical solution can be embodied in the form of a software product, which is stored in a storage medium and includes several instructions for enabling a computer device (which can be a personal computer, server, or network device, etc.) to execute all or part of the steps of the various embodiments of the present application. The aforementioned storage medium includes: various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

[0242] Those skilled in the art will appreciate that, in one or more of the above examples, the services described herein can be implemented using hardware, software, firmware, or any combination thereof. When implemented using software, these services can be stored on a computer-readable medium or transmitted as one or more instructions or codes on a computer-readable medium. Computer-readable media include computer storage media and communication media, including any medium that facilitates the transmission of computer programs from one location to another. Storage media can be any available medium that can be accessed by a general-purpose or special-purpose computer.

[0243] The above specific implementation methods further illustrate the objectives, technical solutions and beneficial effects of the present invention in detail. It should be understood that the above are only specific implementation methods of the present invention.

[0244] The above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the scope of the technical solutions of the embodiments of the present application.

Claims

1. An information processing method, characterized in that: The method comprises: A Border Gateway Protocol (BGP) message is obtained, wherein the BGP message includes indication information, wherein the indication information indicates a link type of a link between a first point of presence (POP) and a second point of presence (POP), and an address family of the BGP message is a BGP link state (LS) address family.

2. The method according to claim 1, characterized in that The indication information indicates that the link type is: Upper layer overlay link, lower layer underlay link, direct link, dedicated line link, Multi-Protocol Label Switching (MPLS) link, Internet Protocol version 6 segment routing (SRv6) link, Internet link, fourth generation mobile communication technology (4G) link, fifth generation mobile communication technology (5G) link, or fifth generation mobile communication technology plus 5G+ link.

3. The method according to claim 1 or 2, characterized in that: The sub-address family of the BGP message is the shortest path first SPF sub-address family.

4. The method according to claim 3, characterized in that The BGP message includes a link type type length value TLV, and the link type TLV includes the indication information.

5. The method according to claim 4, characterized in that The BGP message includes a BGP LS attribute, and the BGP LS attribute includes the link type TLV.

6. The method according to any one of claims 1 to 5, characterized in that: The method is applied to the first POP or the controller.

7. The method according to any one of claims 1 to 6, characterized in that: The method further comprises: Path computation constraint information is received, the path computation constraint information indicating a requirement for a link type of a link to reach a target network prefix.

8. The method according to claim 7, characterized in that The method is applied to the first POP, and the method further comprises: The target network prefix and the link type requirement information are sent to a controller.

9. The method according to claim 7 or 8, characterized in that: The requirements include: The link types that need to be included in the link reaching the target network prefix, and / or the link types that need to be excluded in the link reaching the target network prefix.

10. The method according to claim 9, characterized in that The path calculation constraint information includes an included link type TLV and / or an excluded link type TLV, wherein the included link type TLV indicates the link type that needs to be included in the link reaching the target network prefix, and the excluded link type TLV indicates the link type that needs to be excluded in the link reaching the target network prefix.

11. The method according to any one of claims 7 to 10, characterized in that: The receiving of path calculation constraint information includes: A software-defined wide area network transport network port SD-WAN TNP routing announcement message is received, wherein the SD-WAN TNP routing announcement message includes the path calculation constraint information.

12. The method according to claim 11, characterized in that The SD-WAN TNP routing announcement message includes an extended port attribute sub-TLV, and the extended port attribute sub-TLV includes the path calculation constraint information.

13. The method according to claim 11, characterized in that The SD-WAN TNP routing includes a first metadata path attribute, and the first metadata path attribute includes the path calculation constraint information.

14. The method according to any one of claims 7 to 10, characterized in that: The receiving of path calculation constraint information includes: A Path Computation Element Protocol (PCEP) message is received, where the PCEP message includes the path calculation constraint information.

15. The method according to any one of claims 7 to 10, characterized in that: The receiving of path calculation constraint information includes: A BGP export route filtering ORF message is received, wherein the BGP ORF message includes the path calculation constraint information.

16. The method according to any one of claims 7 to 10, characterized in that: The receiving of path calculation constraint information includes: An overlay management protocol (OMP) message is received, where the OMP message includes the path calculation constraint information.

17. An information processing method, characterized in that: The method comprises: Path computation constraint information is received, the path computation constraint information indicating a requirement for a link type of a link to reach a target network prefix.

18. The method according to claim 17, characterized in that The method is applied to a first POP, and the method further comprises: The target network prefix and the link type requirement information are sent to a controller.

19. The method according to claim 17 or 18, characterized in that The requirements include: The link types that need to be included in the link reaching the target network prefix, and / or the link types that need to be excluded in the link reaching the target network prefix.

20. The method according to any one of claims 17 to 19, characterized in that: The path calculation constraint information includes an included link type TLV and / or an excluded link type TLV, wherein the included link type TLV indicates the link type that needs to be included in the link reaching the target network prefix, and the excluded link type TLV indicates the link type that needs to be excluded in the link reaching the target network prefix.

21. The method according to any one of claims 17 to 20, characterized in that: The receiving of path calculation constraint information includes: A software-defined wide area network transport network port SD-WAN TNP routing announcement message is received, wherein the SD-WAN TNP routing announcement message includes the path calculation constraint information.

22. The method according to claim 21, characterized in that The SD-WAN TNP routing announcement message includes an extended port attribute sub-TLV, and the extended port attribute sub-TLV includes the path calculation constraint information.

23. The method according to claim 21, characterized in that The SD-WAN TNP routing includes a first metadata path attribute, and the first metadata path attribute includes the path calculation constraint information.

24. The method according to any one of claims 17 to 20, characterized in that: The receiving of path calculation constraint information includes: A Path Computation Element Protocol (PCEP) message is received, where the PCEP message includes the path calculation constraint information.

25. The method according to any one of claims 17 to 20, characterized in that: The receiving of path calculation constraint information includes: A BGP export route filtering ORF message is received, wherein the BGP ORF message includes the path calculation constraint information.

26. The method according to any one of claims 17 to 20, characterized in that: The receiving of path calculation constraint information includes: An overlay management protocol (OMP) message is received, where the OMP message includes the path calculation constraint information.

27. An information processing method, characterized in that: The method comprises: Acquire path calculation constraint information, where the path calculation constraint information indicates a requirement for a link type of a link to reach a target network prefix; The path calculation constraint information is sent.

28. The method according to claim 27, characterized in that The requirements include: The link types that need to be included in the link reaching the target network prefix, and / or the link types that need to be excluded in the link reaching the target network prefix.

29. The method according to claim 27 or 28, characterized in that The path calculation constraint information includes an included link type TLV and / or an excluded link type TLV, wherein the included link type TLV indicates the link type that needs to be included in the link reaching the target network prefix, and the excluded link type TLV indicates the link type that needs to be excluded in the link reaching the target network prefix.

30. The method according to any one of claims 27 to 29, characterized in that: The sending of the path calculation constraint information includes: A software defined wide area network transport network port SD-WAN TNP routing announcement message is sent, wherein the SD-WAN TNP routing announcement message includes the path calculation constraint information.

31. The method according to claim 30, characterized in that The SD-WAN TNP routing announcement message includes an extended port attribute sub-TLV, and the extended port attribute sub-TLV includes the path calculation constraint information.

32. The method according to claim 30, characterized in that The SD-WAN TNP routing includes a first metadata path attribute, and the first metadata path attribute includes the path calculation constraint information.

33. The method according to any one of claims 27 to 29, characterized in that: The sending of the path calculation constraint information includes: A Path Computation Element Protocol (PCEP) message is sent, where the PCEP message includes the path calculation constraint information.

34. The method according to any one of claims 27 to 29, characterized in that: The sending of the path calculation constraint information includes: A BGP export route filtering ORF message is sent, wherein the BGP ORF message includes the path calculation constraint information.

35. The method according to any one of claims 27 to 29, characterized in that: The sending of the path calculation constraint information includes: An overlay management protocol (OMP) message is sent, wherein the OMP message includes the path calculation constraint information.

36. An information processing device, characterized in that: The device comprises: A processing unit is used to obtain a Border Gateway Protocol BGP message, wherein the BGP message includes indication information, wherein the indication information indicates a link type of a link between a first access point POP and a second POP, and an address family of the BGP message is a BGP link state LS address family.

37. The device according to claim 36, characterized in that The indication information indicates that the link type is: Upper layer overlay link, lower layer underlay link, direct link, dedicated line link, Multi-Protocol Label Switching (MPLS) link, Internet Protocol version 6 segment routing (SRv6) link, Internet link, fourth generation mobile communication technology (4G) link, fifth generation mobile communication technology (5G) link, or fifth generation mobile communication technology plus 5G+ link.

38. The device according to claim 36 or 37, characterized in that The sub-address family of the BGP message is the shortest path first SPF sub-address family.

39. The device according to claim 38, characterized in that The BGP message includes a link type type length value TLV, and the link type TLV includes the indication information.

40. The device according to claim 39, characterized in that The BGP message includes a BGP LS attribute, and the BGP LS attribute includes the link type TLV.

41. The device according to any one of claims 36 to 40, characterized in that The device is applied to the first POP or the controller.

42. The device according to any one of claims 36 to 41, characterized in that: The device also includes: The receiving unit is configured to receive path calculation constraint information, where the path calculation constraint information indicates a requirement for a link type of a link reaching a target network prefix.

43. The device according to claim 42, characterized in that The device is applied to the first POP, and the device further includes: A sending unit is used to send the target network prefix and the link type requirement information to a controller.

44. The device according to claim 42 or 43, characterized in that The requirements include: The link types that need to be included in the link reaching the target network prefix, and / or the link types that need to be excluded in the link reaching the target network prefix.

45. The device according to claim 44, characterized in that The path calculation constraint information includes an included link type TLV and / or an excluded link type TLV, wherein the included link type TLV indicates the link type that needs to be included in the link reaching the target network prefix, and the excluded link type TLV indicates the link type that needs to be excluded in the link reaching the target network prefix.

46. ​​The device according to any one of claims 42 to 45, characterized in that The receiving unit is used for: A software-defined wide area network transport network port SD-WAN TNP routing announcement message is received, wherein the SD-WAN TNP routing announcement message includes the path calculation constraint information.

47. The device according to claim 46, characterized in that The SD-WAN TNP routing announcement message includes an extended port attribute sub-TLV, and the extended port attribute sub-TLV includes the path calculation constraint information.

48. The device according to claim 46, characterized in that The SD-WAN TNP routing includes a first metadata path attribute, and the first metadata path attribute includes the path calculation constraint information.

49. The device according to any one of claims 42 to 45, characterized in that The receiving unit is used for: A Path Computation Element Protocol (PCEP) message is received, where the PCEP message includes the path calculation constraint information.

50. The device according to any one of claims 42 to 45, characterized in that The receiving unit is used for: A BGP export route filtering ORF message is received, wherein the BGP ORF message includes the path calculation constraint information.

51. The device according to any one of claims 42 to 45, characterized in that The receiving unit is used for: An overlay management protocol (OMP) message is received, where the OMP message includes the path calculation constraint information.

52. An information processing device, characterized in that: The device comprises: The receiving unit is configured to receive path calculation constraint information, where the path calculation constraint information indicates a requirement for a link type of a link reaching a target network prefix.

53. The device according to claim 52, characterized in that The device is applied to a first POP, and the device further comprises: A sending unit is used to send the target network prefix and the link type requirement information to a controller.

54. The device according to claim 52 or 53, characterized in that The requirements include: The link types that need to be included in the link reaching the target network prefix, and / or the link types that need to be excluded in the link reaching the target network prefix.

55. The device according to any one of claims 52 to 54, characterized in that The path calculation constraint information includes an included link type TLV and / or an excluded link type TLV, wherein the included link type TLV indicates the link type that needs to be included in the link reaching the target network prefix, and the excluded link type TLV indicates the link type that needs to be excluded in the link reaching the target network prefix.

56. The device according to any one of claims 52 to 55, characterized in that The receiving unit is used for: A software-defined wide area network transport network port SD-WAN TNP routing announcement message is received, wherein the SD-WAN TNP routing announcement message includes the path calculation constraint information.

57. The device according to claim 56, characterized in that The SD-WAN TNP routing announcement message includes an extended port attribute sub-TLV, and the extended port attribute sub-TLV includes the path calculation constraint information.

58. The device according to claim 56, characterized in that The SD-WAN TNP routing includes a first metadata path attribute, and the first metadata path attribute includes the path calculation constraint information.

59. The device according to any one of claims 52 to 55, characterized in that The receiving unit is used for: A Path Computation Element Protocol (PCEP) message is received, where the PCEP message includes the path calculation constraint information.

60. The device according to any one of claims 52 to 55, characterized in that The receiving unit is used for: A BGP export route filtering ORF message is received, wherein the BGP ORF message includes the path calculation constraint information.

61. The device according to any one of claims 52 to 55, characterized in that The receiving unit is used for: An overlay management protocol (OMP) message is received, where the OMP message includes the path calculation constraint information.

62. An information processing device, characterized in that: The device comprises: A processing unit, configured to obtain path calculation constraint information, wherein the path calculation constraint information indicates a requirement for a link type of a link reaching a target network prefix; A sending unit is used to send the path calculation constraint information.

63. The device according to claim 62, characterized in that The requirements include: The link types that need to be included in the link reaching the target network prefix, and / or the link types that need to be excluded in the link reaching the target network prefix.

64. The device according to claim 62 or 63, characterized in that The path calculation constraint information includes an included link type TLV and / or an excluded link type TLV, wherein the included link type TLV indicates the link type that needs to be included in the link reaching the target network prefix, and the excluded link type TLV indicates the link type that needs to be excluded in the link reaching the target network prefix.

65. The device according to any one of claims 62 to 64, characterized in that The sending unit is used for: A software defined wide area network transport network port SD-WAN TNP routing announcement message is sent, wherein the SD-WAN TNP routing announcement message includes the path calculation constraint information.

66. The device according to claim 65, characterized in that The SD-WAN TNP routing announcement message includes an extended port attribute sub-TLV, and the extended port attribute sub-TLV includes the path calculation constraint information.

67. The device according to claim 65, characterized in that The SD-WAN TNP routing includes a first metadata path attribute, and the first metadata path attribute includes the path calculation constraint information.

68. The device according to any one of claims 62 to 64, characterized in that The sending unit is used for: A Path Computation Element Protocol (PCEP) message is sent, where the PCEP message includes the path calculation constraint information.

69. The device according to any one of claims 62 to 64, characterized in that The sending unit is used for: A BGP export route filtering ORF message is sent, wherein the BGP ORF message includes the path calculation constraint information.

70. The device according to any one of claims 62 to 64, characterized in that The sending unit is used for: An overlay management protocol (OMP) message is sent, wherein the OMP message includes the path calculation constraint information.

71. An information processing device, characterized in that include: Processor and memory; The memory is used to store instructions; The processor is used to execute the instructions so that the communication device executes the method according to any one of claims 1-35.

72. A communication system, characterized in that: The system comprises: A communication device that executes the method described in any one of claims 7 to 16, and a communication device that executes the method described in any one of claims 27 to 35.

73. A computer-readable storage medium, characterized in that The method comprises instructions or computer programs, which, when executed on a processor, implement the method according to any one of claims 1 to 35.

74. A computer program product, characterized in that The invention comprises a computer program which, when executed on a processor, executes the method according to any one of claims 1 to 35 above.

Images