An information processing method and apparatus

Abstract

The embodiment of the application discloses an information processing method, which can be applied to a target device, for example. The target device can obtain a BGP message, the address family of the BGP message being a BGP LS address family, and the BGP message including indication information indicating a link type of a link between a first point of presence (POP) in an SD-WAN network and a second POP in the SD-WAN network. According to the scheme, the link type between the POPs can be carried by the BGP message with the LS address family, so that a service path can be arranged for a service based on the link type between the POPs, thereby meeting the service requirement.

Description

Technical Field

[0001] This application relates to the field of communications, and more particularly to an information processing method and apparatus. Background Technology

[0002] In current wide area networks (WANs), to achieve rapid end-to-end delivery and flexible scheduling, software-defined networking in a wide area network (SD-WAN) technology is typically used. SD-WAN tunnels are established on top of different underlying networks such as the internet and leased lines to construct an overlay network based on SD-WAN. This decouples WAN services from the underlying network, improving end-to-end delivery capabilities. The overlay network based on SD-WAN can be simply referred to as an SD-WAN network.

[0003] In some scenarios, end-to-end paths across SD-WAN networks can be pre-calculated for services, but the current methods of calculating end-to-end paths cannot fully meet service requirements.

[0004] Therefore, there is an urgent need for a solution to address the above problems. Summary of the Invention

[0005] This application provides an information processing method and apparatus that can facilitate the arrangement of business paths, thereby better meeting business needs.

[0006] Firstly, embodiments of this application provide an information processing method, which can be applied, for example, to a target device. The target device can obtain Border Gateway Protocol (BGP) messages, the address family of which is the BGP link state (LS) address family. The BGP message includes indication information indicating the link type between a first point of presence (POP) and a second POP. Using this approach, the link type between POPs can be carried in BGP messages using the LS address family, facilitating subsequent service path orchestration based on the link type between POPs, thereby meeting service requirements.

[0007] In one possible implementation, the indication information indicates that the link type can be an overlay link, underlay link, direct link, leased link, Multi-Protocol Label Switching (MPLS) link, Segment Routing Internet Protocol Version 6 (SRv6) link, internet link, 4th generation mobile communication technology (4G) link, 5G link, or 5th generation mobile communication technology plus (5G+) link. When the indication information indicates an MPLS link, SRv6 link, internet link, 4G link, 5G link, or 5G+ link, the indication information naturally indicates that the link type between the first POP and the second POP is an overlay link. When the indication information indicates a direct link or leased link, the indication information naturally indicates that the link type between the first POP and the second POP is an underlay link.

[0008] In one possible implementation, considering that the network layer reachability information (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 can be the SFP sub-address family. That is, in this embodiment, the characteristic of BGP-LS-SPF in advertising link information is utilized, and the aforementioned indication information is carried based on the BGP message using the BGP-LS-SPF address family. The BGP-LS-SPF address family can also be abbreviated as BGP-SPF address family.

[0009] 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 length value (TLV), which carries the indication information. The communication device receiving the BGP message can parse the link type TLV to obtain the indication information, and accordingly, determine the link type of the link between the first POP and the second POP based on the indication information. In another possible implementation, the BGP message may include BGP path attributes, through which the aforementioned link type TLV can be carried. In other words, the BGP path attributes 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 receiving 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, determine the link type of the link between the first POP and the second POP based on the indication information.

[0010] In one possible implementation, the target device can be a first POP. In this case, the first POP acquiring the BGP message can specifically involve generating the BGP message. As an example, after generating the BGP message, the first POP can send the BGP message, for example, to other POPs and / or the controller.

[0011] In one possible implementation, the target device can be a controller. In this case, the controller acquiring the BGP message can specifically involve receiving the BGP message. As an example, the controller can receive the BGP message sent by the first POP.

[0012] In one possible implementation, the target device can receive routing constraint information indicating the required link type for links reaching the target network prefix. In this way, the device for orchestrating service paths can orchestrate the service paths based on the routing constraint information to obtain service paths that conform to the aforementioned routing constraint information as much as possible, thereby meeting service requirements.

[0013] In one possible implementation, when the target device is the first POP, after receiving the routing constraint information, the target device can send the routing constraint information to the controller, and the controller can calculate the service path to the target network prefix based on the routing constraint information.

[0014] In one possible implementation, after receiving the routing constraint information, the target device can calculate the service path to the target network prefix based on the routing constraint information.

[0015] In one possible implementation, the aforementioned 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 can calculate a service path that includes the aforementioned required link types as much as possible when calculating the service path, thereby meeting the service requirements.

[0016] 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 can calculate a service path that does not include the aforementioned link types that need to be excluded when calculating the service path, thereby meeting the service requirements.

[0017] In one possible implementation, if the aforementioned requirement includes the link types that the links leading to the target network prefix need to include, then the aforementioned routing constraint information may include a first TLV, which may be, for example, an Include Link-Type TLV, indicating the link types that the links leading to the target network prefix need to include.

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

[0019] In one possible implementation, the aforementioned routing constraint information can be carried through an SD-WAN transport network port (TNP) routing advertisement message. In other words, the receiving routing advertisement message can specifically be an SD-WAN TNP routing advertisement message that includes the aforementioned routing constraint information. For example, the SD-WAN TNP routing advertisement message may include the aforementioned first TLV and / or second TLV.

[0020] In one possible implementation, the routing constraint information can be carried through the Extended Port Attribute Sub-TLV in the SD-WAN TNP routing advertisement message. Specifically, the aforementioned first TLV and / or second TLV can be a sub-sub-TLV of the Extended Port Attribute Sub-TLV. In this case, the target device can obtain the routing constraint information by parsing the Extended Port Attribute Sub-TLV in the SD-WAN TNP routing advertisement message.

[0021] In one possible implementation, the SD-WAN TNP routing advertisement message may include a first metadata path attribute, through which the aforementioned first TLV and / or second TLV can be carried. In this case, the target device can obtain the routing constraint information by parsing the first metadata path attribute in the SD-WAN TNP routing advertisement message.

[0022] In one possible implementation, the aforementioned routing constraint information can be carried via a Path Computation Element Protocol (PCEP) message. In other words, the receiving route advertisement message, in a specific implementation, can receive a PCEP message that includes the routing constraint information. In a specific example, the PCEP message may include a first object and / or a second object, where the first object carries the first TLV and the second object carries the second TLV. The first and second objects can be newly extended objects. In yet another specific example, the aforementioned first and second TLVs can be carried using existing PCEP objects; for example, an existing PCEP object can be extended to carry the aforementioned first and second TLVs.

[0023] In one possible implementation, the aforementioned routing constraint information can be carried through a BGP outbound route filters (ORF) message. In other words, the receiving route advertisement message can, in a specific implementation, receive a BGP ORF message that includes the routing constraint information. For example, the BGP ORF message may include the aforementioned first TLV and / or second TLV. In a specific example, the BGP ORF message may include a second metadata path attribute, through which the aforementioned first TLV and / or second TLV can be carried.

[0024] In one possible implementation, the aforementioned path constraint information can be carried via an Overlay Management Protocol (OMP) message. In one example, the first TLV and the second TLV can be carried in the data field of the OMP message.

[0025] Secondly, embodiments of this application provide an information processing method, which can be applied, for example, to a target device. The target device can be a controller or a first point of interest (POP). The target device can receive routing constraint information, which indicates the required link type for links reaching a target network prefix. In this way, a device for orchestrating service paths can orchestrate service paths based on the routing constraint information to obtain service paths that conform to the aforementioned routing constraint information as much as possible, thereby meeting service requirements.

[0026] In one possible implementation, the method is applied to the first POP, and the method further includes sending the target network prefix and the path constraint information to the controller.

[0027] In one possible implementation, the requirements include: the link types that links reaching the target network prefix need to include, and / or, the link types that links reaching the target network prefix need to exclude.

[0028] In one possible implementation, the routing constraint information includes a Link Type TLV (Than Link Type Value) and / or an Excluded Link Type TLV (Than Link Type Value), wherein the included Link Type TLV indicates the link types that need to be included for links reaching the target network prefix, and the excluded Link Type TLV indicates the link types that need to be excluded for links reaching the target network prefix.

[0029] In one possible implementation, receiving the routing constraint information includes: receiving a Software-Defined Wide Area Network (SD-WAN) TNP routing advertisement message, wherein the SD-WAN TNP routing advertisement message includes the routing constraint information.

[0030] In one possible implementation, the SD-WAN TNP routing advertisement message includes an extended port attribute sub-TLV, which includes the routing constraint information.

[0031] In one possible implementation, the SD-WAN TNP routing advertisement message includes a first metadata path attribute, which includes the routing constraint information.

[0032] In one possible implementation, receiving the path constraint information includes: receiving a Path Calculation Unit Protocol (PCEP) message, wherein the PCEP message includes the path constraint information.

[0033] In one possible implementation, receiving the routing constraint information includes receiving a BGP egress route filtering ORF message, wherein the BGP ORF message includes the routing constraint information.

[0034] In one possible implementation, receiving the path constraint information includes receiving an OMP message, wherein the OMP message includes the path constraint information.

[0035] Thirdly, embodiments of this application provide an information processing method, which includes: acquiring routing constraint information and sending the routing constraint information, wherein the routing constraint information indicates the link type requirement for links reaching a target network prefix. In this way, an apparatus for orchestrating service paths can orchestrate service paths based on the routing constraint information to orchestrate service paths that conform to the aforementioned routing constraint information as much as possible, thereby meeting service requirements.

[0036] In one possible implementation, the requirements include: the link types that links reaching the target network prefix need to include, and / or, the link types that links reaching the target network prefix need to exclude.

[0037] In one possible implementation, the routing constraint information includes a Link Type TLV (Than Link Type Value) and / or an Excluded Link Type TLV (Than Link Type Value), wherein the included Link Type TLV indicates the link types that need to be included for links reaching the target network prefix, and the excluded Link Type TLV indicates the link types that need to be excluded for links reaching the target network prefix.

[0038] In one possible implementation, sending the routing constraint information includes: sending a Software-Defined Wide Area Network (SD-WAN) TNP routing advertisement message, wherein the SD-WAN TNP routing advertisement message includes the routing constraint information.

[0039] In one possible implementation, the SD-WAN TNP routing advertisement message includes an extended port attribute sub-TLV, which includes the routing constraint information.

[0040] In one possible implementation, the SD-WAN TNP routing advertisement message includes a first metadata path attribute, which includes the routing constraint information.

[0041] In one possible implementation, sending the path calculation constraint information includes: sending a Path Calculation Unit Protocol (PCEP) message, wherein the PCEP message includes the path calculation constraint information.

[0042] In one possible implementation, sending the routing constraint information includes sending a BGP egress route filtering ORF message, wherein the BGP ORF message includes the routing constraint information.

[0043] In one possible implementation, sending the path constraint information includes sending an Overlay Management Protocol (OMP) message, wherein the OMP message includes the path constraint information.

[0044] Fourthly, embodiments of this application provide an information processing apparatus, which includes a transceiver unit and / or a processing unit. The transceiver unit is used to perform transceiver operations, and the processing unit is used to perform other operations besides the transceiver operations. A receiving unit may include a receiving unit and / or a sending unit, wherein the receiving unit is used to perform a receiving operation, and the sending unit is used to perform a sending operation.

[0045] In a specific example, the information processing device is used to perform the method described in any one of the first aspects above. In this case, the information processing device may specifically include: an acquisition unit, used to acquire a Border Gateway Protocol (BGP) message, the BGP message including indication information indicating the link type of the link between a first ingress point (POP) and a second POP, the address family of the BGP message being the BGP Link State (LS) address family.

[0046] In one possible implementation, the acquisition unit may specifically be a receiving unit, used to receive the BGP message.

[0047] In another possible implementation, the acquisition unit may specifically be a processing unit used to generate the BGP message.

[0048] In one possible implementation, the indication information indicates that the link type is: an overlay link, an underlay link, a direct link, a leased link, a Multiprotocol Label Switching (MPLS) link, an Internet Protocol version 6 (SRv6) segment routing link, an Internet link, a 4G link, a 5G link, or a 5G+ link.

[0049] In one possible implementation, the sub-address family of the BGP message is the Shortest Path First (SPF) sub-address family.

[0050] In one possible implementation, the BGP message includes a Link Type Length Value (TLV), and the Link Type TLV includes the indication information.

[0051] In one possible implementation, the BGP message includes BGP LS attributes, which include the link type TLV.

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

[0053] In one possible implementation, when the aforementioned acquisition unit 501 is specifically a receiving unit, the receiving unit is further configured to: receive routing constraint information, the routing constraint information indicating the requirement for the link type of the link to reach the target network prefix.

[0054] In one possible implementation, when the aforementioned acquisition unit 501 is specifically a processing unit, the device further includes a receiving unit for: receiving routing constraint information, the routing constraint information indicating the link type requirement for the link to the target network prefix.

[0055] In one possible implementation, the apparatus is applied to the first POP, and the apparatus further includes: a sending unit for sending the target network prefix and the routing constraint information to the controller.

[0056] In one possible implementation, the requirements include: the link types that links reaching the target network prefix need to include, and / or, the link types that links reaching the target network prefix need to exclude.

[0057] In one possible implementation, the routing constraint information includes a Link Type TLV (Than Link Type Value) and / or an Excluded Link Type TLV (Than Link Type Value), wherein the included Link Type TLV indicates the link types that need to be included for links reaching the target network prefix, and the excluded Link Type TLV indicates the link types that need to be excluded for links reaching the target network prefix.

[0058] In one possible implementation, the receiving unit is specifically configured to: receive a Software-Defined Wide Area Network (SD-WAN) TNP routing advertisement message, wherein the SD-WAN TNP routing advertisement message includes the routing constraint information.

[0059] In one possible implementation, the SD-WAN TNP routing advertisement message includes an extended port attribute sub-TLV, which includes the routing constraint information.

[0060] In one possible implementation, the SD-WAN TNP routing advertisement message includes a first metadata path attribute, which includes the routing constraint information.

[0061] In one possible implementation, the receiving unit is specifically configured to: receive a Path Calculation Unit Protocol (PCEP) message, wherein the PCEP message includes the path constraint information.

[0062] In one possible implementation, the receiving unit is specifically configured to: receive a BGP egress route filtering ORF message, wherein the BGP ORF message includes the route constraint information.

[0063] In one possible implementation, the receiving unit is specifically configured to: receive an OMP message, the OMP message including the path constraint information.

[0064] In yet another specific example, the information processing apparatus is used to perform the method described in any of the second aspects above. In this case, the information processing apparatus may specifically include: a receiving unit for receiving routing constraint information, the routing constraint information indicating the link type requirement for a link to the target network prefix.

[0065] In another specific example, the information processing device is used to perform the method described in any of the third aspects above. In this case, the information processing device may specifically include: an acquisition unit and a transmission unit. The acquisition unit is used to acquire routing constraint information, which indicates the link type requirement for a link to the target network prefix; the transmission unit is used to transmit the routing constraint information.

[0066] In one possible implementation, the acquisition unit may specifically be a receiving unit, used to receive the path constraint information.

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

[0068] Fifthly, embodiments of this application provide a communication device, characterized in that it includes: a processor and a memory;

[0069] The memory is used to store instructions; the processor is used to execute the instructions, causing the communication device to perform the method described in the first aspect and any one of the first aspects above, or causing the communication device to perform the method described in the second aspect and any one of the second aspects above, or causing the communication device to perform the method described in the third aspect and any one of the third aspects above.

[0070] Sixthly, embodiments of this application provide a computer-readable storage medium, including instructions or a computer program, which, when executed on a processor, implement the method described in the first aspect and any one of the first aspects above, or implement the method described in the second aspect and any one of the second aspects above, or implement the method described in the third aspect and any one of the third aspects above.

[0071] In a seventh aspect, embodiments of this application provide a computer program product, including a computer program product that, when run on a processor, implements the method described in the first aspect and any one of the first aspects above, or implements the method described in the second aspect and any one of the second aspects above, or implements the method described in the third aspect and any one of the third aspects above.

[0072] Eighthly, embodiments of this application provide a communication system, which includes a communication device for performing the methods described in the second aspect and any one of the second aspects, and a communication device for performing the methods described in the third aspect and any one of the third aspects. Attached Figure Description

[0073] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0074] Figure 1a This is a schematic diagram illustrating an exemplary application scenario provided in an embodiment of this application;

[0075] Figure 1b This is a schematic diagram illustrating another exemplary application scenario provided in the embodiments of this application;

[0076] Figure 1c This is a schematic diagram illustrating another exemplary application scenario provided by an embodiment of this application;

[0077] Figure 2a This is a schematic diagram of the structure of a BGP message header provided in an embodiment of this application;

[0078] Figure 2b A schematic diagram of the structure of MP_REACH_NLRI provided in an embodiment of this application;

[0079] Figure 2c A schematic diagram of a Link State NLRI provided in an embodiment of this application;

[0080] Figure 2dThis is a schematic diagram of the structure of a BGP route update message provided in an embodiment of this application;

[0081] Figure 2e This is a schematic diagram of the structure of a PCEP message provided in an embodiment of this application;

[0082] Figure 2f This is a schematic diagram of the structure of an OMP message provided in an embodiment of this application;

[0083] Figure 3 A flowchart illustrating an information processing method provided in an embodiment of this application;

[0084] Figure 4a This is a schematic diagram of the structure of a Link Type TLV provided in an embodiment of this application;

[0085] Figure 4b This is a schematic diagram of the structure of a first TLV provided in an embodiment of this application;

[0086] Figure 4c This is a schematic diagram of the structure of a second TLV provided in an embodiment of this application;

[0087] Figure 4d This is a schematic diagram of the structure of an LSPA object provided in an embodiment of this application;

[0088] Figure 4e This is a schematic diagram of the structure of an RP object provided in an embodiment of this application;

[0089] Figure 5 This is a schematic diagram of the structure of an information processing device provided in an embodiment of this application;

[0090] Figure 6 This is a schematic diagram of the structure of another information processing device provided in the embodiments of this application;

[0091] Figure 7 This is a schematic diagram of the structure of another information processing device provided in the embodiments of this application;

[0092] Figure 8 This is a schematic diagram of the structure of a communication device provided in an embodiment of this application;

[0093] Figure 9 This is a schematic diagram of the structure of a communication device provided in an embodiment of this application. Detailed Implementation

[0094] This application provides a method and apparatus for forwarding traffic, which can facilitate the orchestration of service paths, thereby making the orchestrated paths more in line with service requirements.

[0095] To facilitate understanding, the possible application scenarios of the embodiments of this application will be introduced first.

[0096] After deploying SD-WAN, the SD-WAN overlay network under the wide area network establishes SD-WAN tunnels between POPs, customer-premises equipment (CPE), and edgepoint of presence (EPOP) on the basis of the original underlay network. Service traffic passes through intermediate devices in the form of tunnels, so that the intermediate devices are unaware of the service.

[0097] See Figure 1a This figure is a schematic diagram of an exemplary application scenario provided by an embodiment of this application. Figure 1a As shown, service traffic needs to be transmitted across edge access zone 100, backbone network 200, and edge access zone 300. Specifically:

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

[0099] The edge access network 100 includes: edge1, edge3 and edge4.

[0100] The backbone network 200 includes at least one network device. For example, when the backbone network 200 is a POP backbone network, the backbone network 200 includes at least one POP. In the POP backbone network, the POP connected to the site edge is called EPOP, and the POP not connected to the site edge is called backbone point of presence (BPOP). In one example, the site edge can be a CPE.

[0101] The edge access network 300 includes: site edge2 and site edge5.

[0102] Edge sites in edge access networks 100 and 300 can access the backbone network through EPOPs in the backbone network. The EPOP in the backbone network used by the edge site to access the backbone network can be considered as the gateway corresponding to that edge site. For example, Figure 1a As shown, site edge1 is dual-homed to gateway (GW)1 and gateway 3, and site edge1 can access backbone network 200 through gateway 1 and gateway 3. Similarly, site edge2 is dual-homed to gateway 2 and gateway 4, and site edge2 can access backbone network 200 through gateway 2 and gateway 4.

[0103] A site edge can access its corresponding gateway via an SD-WAN tunnel or the internet. The gateway is a Point of Presence (POP) within the backbone network 200.

[0104] In this embodiment, the backbone network can be a hybrid network comprising at least one network domain. This at least one network domain includes, but is not limited to, a self-built backbone network and / or a managed service provider (MSP) backbone network. The MSP backbone network can include a single-carrier network, a hybrid carrier network, or a self-built leased line network; this embodiment does not impose specific limitations. MPLS technology or SRv6 technology can be applied to the backbone network; this embodiment does not impose specific limitations.

[0105] For reference Figure 1b and Figure 1c To understand, Figure 1b and Figure 1c The diagrams illustrate two other exemplary application scenarios provided in the embodiments of this application.

[0106] like Figure 1b As shown, the backbone network 400 includes: Internet Service Provider (ISP) network 1 (ISP1), ISP2, ISP3 and a self-built leased line network. Figure 1c The scene shown is Figure 1b The difference is that, Figure 1c The backbone network 500 shown does not include self-built leased lines.

[0107] about Figure 1b and Figure 1c The connection methods between network devices in the network architecture shown are not described in detail here.

[0108] Currently, service paths across a cross-domain backbone network 200 can be orchestrated for services. In one example, an end-to-end path from the ingress POP to the egress POP can be orchestrated by the ingress POP in the backbone network. After service traffic arrives at the ingress POP, it is forwarded to the egress POP via this end-to-end path, and further forwarded to the destination device through the egress POP. In another example, the end-to-end path carrying the service can be calculated by the CPE, for example, in... Figure 1b In the scenario shown, edge1 calculates the end-to-end path from edge1 to edge2. In another example, the controller can orchestrate paths uniformly across the entire network, such as orchestrating end-to-end paths from ingress POP to egress POP, or orchestrating end-to-end paths between two CPEs spanning the backbone network.

[0109] Currently, when orchestrating business paths, information such as link cost and latency can be combined for path orchestration. However, the paths orchestrated in this way often fail to meet business requirements.

[0110] To address the aforementioned problems, this application provides an information processing method.

[0111] To facilitate understanding of this solution, the relevant technologies that may be involved in this application will be introduced first.

[0112] 1. BGP

[0113] BGP is a dynamic routing protocol used between autonomous systems (AS). As an internet external routing protocol standard, BGP is widely used among 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).

[0114] A BGP message consists of two parts: a BGP message header and a message content. As shown in Table 1, BGP has five message types, as shown in Table 2, all of which share the same BGP message header. These messages are transmitted via the Transmission Control Protocol (TCP). The longest message is 65535 bytes, and the shortest is 19 bytes (containing only the BGP message header). The BGP message header can be as follows: Figure 2a As shown, Figure 2a This is a schematic diagram of the structure of a BGP message header provided in an embodiment of this application. Figure 2a As shown, the BGP message header consists of three parts: a marker field, a length field, and a type field. These three parts of the BGP message header can be understood in conjunction with Table 1 below.

[0115] Table 1

[0116]

[0117] Table 2

[0118] type value Message Type 1 open 2 update 3 notification 4 keepalive 5 route refresh

[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, communication devices can advertise routes via MP-BGP. Specifically, the BGP messages exchanged between communication devices for route advertising include Multi-Protocol reach network layer reachability information (MP_REACH_NLRI), which carries the route. In one example, the structure of MP_REACH_NLRI is as follows: Figure 2b As shown, Figure 2b This is a schematic diagram of the structure of MP_REACH_NLRI provided for an embodiment of this application. For example... Figure 2b As shown, the MP_REACH_NLRI includes address family identifiers (AFI), subsequent address family identifiers (SAFI), next-hop information length field, next-hop information field, and NLRI field.

[0123] As an example, the AFI field can identify the network layer protocol. For instance, an AFI value of 1 indicates IPv4, and an AFI value of 2 indicates IPv6. The values ​​for the AFI field can be found in the relevant description of Address Family Numbers in RFC 1700, which will not be detailed here. The SAFI field identifies the type of sub-address family. For instance, an SAFI value of 1 indicates unicast, an SAFI value of 2 indicates multicast, an SAFI value of 74 indicates SD-WAN, and an SAFI value of 128 indicates a Virtual Private Network (VPN).

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

[0125] In one example, the NLRI field may include one or more NLRIs, each of which includes a length field and an NLRI value field. The specific content of the NLRI value can be determined based on 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 indicates the route type, the length field is the same as the length of the type specific value field, and the type specific value field carries a value related to the type corresponding to the route type field.

[0127] BGP route refresh messages can include various messages, one of which is the BGP ORF message.

[0128] Regarding BGP ORF messages, it should be noted that:

[0129] RFC5291 and RFC5292 specify BGP prefix-based ORF capabilities, which allow local devices to send their configured prefix-based inbound policies to BGP neighbors via route refresh messages. BGP neighbors then construct their outbound policies based on these policies and filter routes during transmission. This not only prevents local devices from receiving a large number of useless routes, reducing the utilization of their central processing unit (CPU), but also effectively reduces the configuration work for BGP neighbors and lowers link bandwidth usage. For example, communication device A and communication device B establish a direct BGP neighbor relationship. After negotiating prefix-based ORF capabilities, communication device A sends its locally configured prefix-based inbound policy to communication device B via a route refresh message. Communication device B constructs its outbound 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 network topology collection that makes topology collection simpler and more efficient.

[0132] BGP-LS introduces a series of new Link-State NLRIs (NLRIs) to carry information related to links, nodes, and IPv4 or IPv6 prefixes, building upon the foundation of BGP. In one example, BGP-LS uses the MP_REACH_NLRI attribute as a container for link-state NLRIs; that is, the link-state NLRI is carried as an MP_REACH_NLRI attribute in the BGP Update message. See also... Figure 2c , Figure 2c This is a schematic diagram of a Link State NLRI provided in an embodiment of this application. Figure 2cAs shown, the link-state NLRI includes an NLRI type field, a total NLRI length field, and a link-state NLRI field. Wherein:

[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, and the content of the link-state NLRI field is determined by the value of the NLRI type field.

[0136] Table 4

[0137] NLRI Type Values Link-State NLRI type 1 Node (NLRI) 2 Link NLRI 3 IPv4 Topology Prefix (NLRI) 4 IPv6 Topology Prefix (NLRI)

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

[0139] The BGP-LS-SPF address family can also be referred to as 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.

[0140] The SAFI value for the BGP-SPF address family is 80.

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

[0142] Each communication device that enables the BGP-LS-SPF address family needs to unconditionally generate a nodeNLRI. The specific format of the nodeNLRI will not be described in detail here.

[0143] For communication devices that have enabled the BGP-LS-SPF address family, they generate a linkNLRI for their own link information and advertise it to other communication devices. The format of the link NLRI follows the definition in RFC 7752, which will not be described in detail here.

[0144] BGP route update messages for the BGP-LS-SPF address family carry multiple path attributes, one of which is called the BGP-LS Attribute, defined in RFC 7752. The BGP-LS Attribute can carry one or more TLVs describing nodes, links, or prefixes. As mentioned earlier, the BGP message also contains an MP_REACH_NLRI, defined in RFC 4760. When the AFI of 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. Furthermore, as shown in Table 4 above, when the NLRI Type value in 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 a Link NLRI.

[0145] For BGP route update messages in the BGP-LS-SPF address family that include a Link NLRI, the Link NLRI may include a Link Description TLV. This Link Description TLV may include one or more TLVs describing the link; for example, it may include a local address TLV and a neighbor address TLV. The local address TLV carries the sender's own IP address, and the neighbor address TLV carries the peer's IP address, identifying the link between the sender and peer. In one example, the local address TLV may be an IPv6 interface address TLV, and the peer address TLV may be an IPv6 neighbor address TLV.

[0146] Next, combined Figure 2d This section describes the structure of BGP route update messages, including the BGP-LS-SPF address family of Link NLRI. Figure 2d This is a schematic diagram of the structure of a BGP route update message provided in an embodiment of this application.

[0147] like Figure 2dAs shown, the BGP route update message includes: a marker field, a length field, a type field, an unfeasible routes length field, a total pathattribute length field, and a path attribute field. The path attribute field can carry multiple BGP path attributes, which may include at least: BGP LS attributes and MP_REACH_NLRI. MP_REACH_NLRI may include at least the aforementioned link description TLV. In this embodiment, the value carried by the unfeasible routes length field can be 0.

[0148] 4. SD-WAN TNP

[0149] 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 Figure 2b When the value of the route type field shown is 1, this BGP route refresh message can be called an SD-WAN TNP route advertisement message, used to advertise SD-WAN TNP routes. In this case, Figure 2b The NLRI field shown can be used to carry information about SD-WAN TNP routes. Information about TNP routes will not be described in detail here.

[0150] 5. PCEP

[0151] PCEP messages include PCEP request messages and PCEP response messages. The structures of PCEP request messages and PCEP response messages are as follows: Figure 2e The above, Figure 2e This is a schematic diagram of the structure of a PCEP message provided in an embodiment of this application. Figure 2e The PCEP message shown includes a PCEP general message header and an object list. For details on the PCEP general message header, please refer to the relevant description in RFC 5440; it will not be elaborated upon here. The object list is used to carry one or more objects.

[0152] in:

[0153] A PCEP request message can be used to request a device (such as a controller or POP) to calculate a path. After the device performs the path calculation, it can return a PCEP response message corresponding to the PCEP request message.

[0154] The PCEP request message must carry a request parameter (RP) object and an end-points object, as well as some other optional objects, such as label switched pathattributes (LSPA) objects, record route objects (RRO) objects, and include route objects (IRO) objects.

[0155] The PCEP response message must include an RP object. If path calculation is successful, an explicit route object (ERO) can be included; if path calculation fails, a no-path object can be included. The PCEP response message also includes other optional objects, such as LSPA objects and IRO objects.

[0156] For details regarding the various objects included in the PCEP request message and PCEP response message, please refer to the relevant descriptions in RFC5440; they will not be described in detail here.

[0157] 6. OMP Message

[0158] OMP messages are used to advertise OMP routes. The message structure of an OMP message can be as follows: Figure 2f As shown, Figure 2f This is a schematic diagram illustrating the structure of an OMP message provided in an embodiment of this application. Figure 2f As shown, the OMP message includes an Attributes Length field and a data field. Wherein:

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

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

[0161] Next, this information processing method will be described with reference to the accompanying drawings.

[0162] See Figure 3 The figure is a flowchart illustrating an information processing method provided in an embodiment of this application.

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

[0164] Figure 3 The method 100 shown may include S101.

[0165] S101: Obtain a BGP message, the BGP message including indication information, the 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 being the BGP LS address family.

[0166] When the method 100 is applied to the first POP, in the specific implementation of S101, the link type of the link between the first POP and the second POP can be determined first, and then the BGP message can be generated based on the link type of the link.

[0167] Regarding the first POP and the second POP, Figure 1b Taking the network scenario shown as an example, the first POP can be Figure 1b The second POP can be POP1 shown. Figure 1b The first POP can be POP2 as shown. Alternatively, the first POP could be... Figure 1b The second POP shown is POP2. Figure 1b The POPs shown are POP1, POP5, POP6, POP7, POP3, or POP8. They are not listed individually here.

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

[0169] S102: Send the BGP message.

[0170] In one example, S102, in its specific implementation, can send the BGP message to other POPs in the backbone network. In another example, S102, in its specific implementation, can send the BGP message to the controller.

[0171] When the method 100 is applied to the controller, in a specific implementation, S101 may be receiving the BGP message sent by the first POP.

[0172] In one example, the link type indicated by the indication information can be: overlay link, underlay link, direct link, leased line link, MPLS link, SRv6 link, internet link, 4G link, 5G link, or 5G+ link. Among these, a 5G+ link refers to a link that utilizes technologies further developed based on 5G technology. 5G+ can include 6G.

[0173] Direct links and leased links are considered underlay links, while MPLS links, SRv6 links, internet links, 4G links, 5G links, or 5G+ links are considered overlay links. When the indication information indicates an MPLS link, SRv6 link, internet link, 4G link, 5G link, or 5G+ link, the indication information naturally indicates that the link type between the first POP and the second POP is an overlay link. When the indication information indicates a direct link or leased link, the indication information naturally indicates that the link type between the first POP and the second POP is an underlay link.

[0174] This application does not specifically limit the sub-address family of the BGP message; the sub-address family of the BGP message can 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 can be the SFP sub-address family. That is, in this application embodiment, the characteristic of BGP-LS-SPF being able to advertise link information is retained, and the aforementioned indication information is carried based on the BGP message using the BGP-LS-SPF address family.

[0175] When the sub-address family of the BGP message is the SPF sub-address family, the BGP message may include a Link Type Volume (TLV), which carries the indication information. The format of the Link Type Volume (TLV) can be found in [reference needed]. Figure 4a To understand, Figure 4a This is a schematic diagram of a link type TLV provided in an embodiment of this application. 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.

[0176] In one example, the BGP message may include BGP path attributes, through which the aforementioned Link Type TLV can be carried. In other words, the BGP path attributes may include the Link Type TLV. This application does not specifically limit the BGP path attributes; in a specific example, the BGP path attributes may be BGP LS attributes. In this case, the Link Type TLV can be carried in... Figure 2d The BGP LS attributes shown.

[0177] In one example, the BGP message may include MP_REACH_NLRI, which may include a Link Description TLV, and the Link Type TLV may be carried through the Link Description TLV. In this case, the Link Type TLV can be carried through... Figure 2d The link description TLV shown can include, in addition to the local address TLV and the neighbor address TLV, the link description TLV, which is used to indicate the link type.

[0178] In this embodiment, to better meet service requirements, the first POP or controller may incorporate path calculation constraint information when calculating service paths. This constraint information indicates the required link type for links reaching the target network prefix. The service path to the target network prefix may include multiple links, and the aforementioned path calculation constraint information may indicate the required link type for these multiple links. In a specific example, the controller or first POP may receive the path calculation constraint information and further determine the path to the target network prefix based on this information.

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

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

[0181] In a specific example, the aforementioned requirement for the link type of the link reaching the target network prefix can include: the link types that the link reaching the target network prefix needs to include. For example, when the service has high quality of service requirements, the aforementioned requirement could be: the link reaching the target network prefix needs to include leased links. Using this approach, by specifying the link types that the link reaching the target network prefix needs to include, the first POP or controller, when calculating the service path, can calculate a service path that includes the aforementioned required link types as much as possible, thereby meeting the service requirements.

[0182] In another specific example, the aforementioned requirement regarding the link type of links reaching the target network prefix may include: link types that need to be excluded from reaching the target network prefix. For example, when the service has high quality of service requirements, the aforementioned requirement may be: internet links need to be excluded from reaching the target network prefix. Using this approach, by specifying the link types that need to be excluded from reaching the target network prefix, the first POP or controller, when calculating the service path, will calculate a service path that excludes the aforementioned excluded link types as much as possible, thereby meeting the service requirements.

[0183] In one example, if the aforementioned requirement includes the link types that the links leading to the target network prefix need to include, then the aforementioned routing constraint information may include a first TLV, which may be, for example, a link type TLV that indicates the link types that the links leading to the target network prefix need to include.

[0184] Regarding the first TLV, it can be combined with Figure 4b To understand. Figure 4b This is a schematic diagram of a first TLV provided in an embodiment of this application. Figure 4b As shown, the first TLV includes a type field 404, a length field 405, and a value field 406. 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 types that need to be included.

[0185] In another example, if the aforementioned requirement includes a link type that needs to be excluded from the path to the target network prefix, then the aforementioned path constraint information may include a second TLV, which may be, for example, an exclusion link type TLV, indicating the link type that needs to be excluded from the path to the target network prefix.

[0186] Regarding the second TLV, it can be combined with Figure 4c To understand. Figure 4c This is a schematic diagram of a second TLV provided in an embodiment of this application. Figure 4c As shown, the second TLV includes a type field 407, a length field 408, and a value field 409. The type field 407 indicates that the type of the TLV is an excluded 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 that needs to be excluded.

[0187] In one implementation, the aforementioned routing constraint information can be carried through an SD-WAN TNP routing advertisement message. In other words, the receiving routing advertisement message can specifically receive an SD-WAN TNP routing advertisement message that includes the routing constraint information. For example, the SD-WAN TNP routing advertisement message may include the aforementioned first TLV and / or second TLV.

[0188] This application does not specifically limit the location of the routing constraint information in the SD-WAN TNP routing advertisement message. In one specific example, the routing constraint information can be carried through the extended port attribute sub-TLV in the SD-WAN TNP routing advertisement message. Specifically, the aforementioned first TLV and / or second TLV can be a sub-sub-TLV of the extended port attribute sub-TLV. In yet another specific example, the SD-WAN TNP routing advertisement message may include a first metadata path attribute, and the aforementioned first TLV and / or second TLV can be carried through the first metadata path attribute.

[0189] In another implementation, the aforementioned routing constraint information can be carried through a PCEP message. For example, it can be carried through a PCEP request message. In other words, in a specific implementation, the receiving route advertisement message can receive a PCEP message that includes the routing 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 carries the first TLV and the second object carries the second TLV. The first and second objects can be newly extended objects; in other words, in this embodiment, one or two new PCEP objects (i.e., the first object and the second object) can be extended in the PCEP message to carry the first TLV and the second TLV. In yet another specific example, the aforementioned first TLV and second TLV can be carried using an existing PCEP object. In a specific example, an existing PCEP object can be extended to carry the aforementioned first TLV and second TLV.

[0190] As a concrete example, an LSPA object can be extended, and the extended LSPA object can carry the aforementioned first TLV and second TLV. See also... Figure 4d To understand, Figure 4d This is a schematic diagram of the structure of an LSPA object provided in an embodiment of this application. Figure 4dAs shown, the LSPA object includes: Exclude-any fields, Include-any fields, Include-all fields, Setup Prio fields, Holding Prio fields, Flags fields, L-flag bits, Reserved fields, and Optional TLVs fields. For details regarding the Exclude-any, Include-any, Include-all, Setup Prio, Holding Prio, Flags, L-flag bits, and Reserved fields in the LSPA object, please refer to the relevant descriptions in RFC 5440; they will not be described in detail here.

[0191] In one example, the Optional TLVs field can be expanded to carry the aforementioned first TLV and second TLV. Specifically, a path information TLV can be carried in the Optional TLVs field, and the structure of the path information TLV can be as follows: Figure 4d As shown, it includes: a type field, a length field, a source end-point address field, a destination end-point address field, and the aforementioned first TLV field and second TLV field. Among them:

[0192] The source endpoint address field carries the address of the source endpoint of the path to be computed, and the destination endpoint address field carries the destination address of the path to be computed (e.g., the aforementioned target network prefix). Optionally, the path information TLV may also include a path ID field to indicate the identifier of the path to be computed.

[0193] As another example, the RP object can be extended, and the extended RP object can carry the aforementioned first TLV and second TLV. See also... Figure 4e To understand, Figure 4e This is a schematic diagram of the structure of an RP object provided in an embodiment of this application. Figure 4eAs shown, the RP object includes: a Flags field, an O indicator bit, a B indicator bit, an R indicator bit, a Priority indicator bit, a Request-ID-number field, and an Optional TLVs field. For details regarding the Flags, O, B, R, Priority, and Request-ID-number fields in the RP object, please refer to the relevant descriptions in RFC 5440; they will not be described in detail here.

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

[0195] In another implementation, the aforementioned routing constraint information can be carried through a BGP ORF message. In other words, the receiving route advertisement message can specifically receive a BGP ORF message that includes the routing constraint information. For example, the BGP ORF message may include the aforementioned first TLV and / or second TLV. In a specific example, the BGP ORF message may include a second metadata path attribute, through which the aforementioned first TLV and / or second TLV can be carried.

[0196] In another implementation, the aforementioned path constraint information can be carried through an OMP message. In one example, the aforementioned first TLV and second TLV can be carried in... Figure 2f The data field of the OMP message shown.

[0197] The information processing method provided in the embodiments of this application has been described above. Next, in conjunction with... Figure 1b The application scenario shown illustrates one possible implementation of the embodiments of this application.

[0198] like Figure 1bAs shown, each Point of Presence (POP) in the backbone network advertises the link types of its connected links to other POPs in the backbone network via BGP messages. The BGP message can use the BGP LS address family and the SPF sub-address family. A POP can directly advertise the link types of its connected links to its BGP neighbors, or it can advertise them to other POPs through a route reflector (RR). Using this method, each POP in the backbone network obtains the link types of all links in the backbone network.

[0199] Station edge1 can send routing constraint information to POP1 to request POP1 to calculate the service path from POP1 to station edge2. POP1 can calculate the corresponding service path by combining the link types of each link in the backbone network, for example, by calculating the service path that conforms to the routing constraint information.

[0200] Based on the information processing method provided in the above embodiments, this application also provides a corresponding device, which will be described below with reference to the accompanying drawings.

[0201] See Figure 5 The figure is a schematic diagram of the structure of an information processing device provided in an embodiment of this application. Figure 5 The information processing device 500 can be used to execute the above method 100. Specifically, the device 500 may include: an acquisition unit 501.

[0202] The acquisition unit 501 is used to acquire Border Gateway Protocol (BGP) messages. The BGP messages include indication information, which indicates the link type of the link between the first ingress point (POP) and the second POP. The address family of the BGP messages is the BGP Link State (LS) address family.

[0203] In one possible implementation, the acquisition unit 501 may specifically be a receiving unit, used to receive the BGP message.

[0204] In another possible implementation, the acquisition unit 501 may specifically be a processing unit used to generate the BGP message.

[0205] In one possible implementation, the indication information indicates that the link type is: an overlay link, an underlay link, a direct link, a leased link, a Multiprotocol Label Switching (MPLS) link, an Internet Protocol version 6 (SRv6) segment routing link, an Internet link, a 4G link, a 5G link, or a 5G+ link.

[0206] In one possible implementation, the sub-address family of the BGP message is the Shortest Path First (SPF) sub-address family.

[0207] In one possible implementation, the BGP message includes a Link Type Length Value (TLV), and the Link Type TLV includes the indication information.

[0208] In one possible implementation, the BGP message includes BGP LS attributes, which include the link type TLV.

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

[0210] In one possible implementation, when the aforementioned acquisition unit 501 is specifically a receiving unit, the receiving unit is further configured to: receive routing constraint information, the routing constraint information indicating the requirement for the link type of the link to reach the target network prefix.

[0211] In one possible implementation, when the aforementioned acquisition unit 501 is specifically a processing unit, the device further includes a receiving unit for: receiving routing constraint information, the routing constraint information indicating the link type requirement for the link to the target network prefix.

[0212] In one possible implementation, the apparatus is applied to the first POP, and the apparatus further includes: a sending unit for sending the target network prefix and the routing constraint information to the controller.

[0213] In one possible implementation, the requirements include: the link types that links reaching the target network prefix need to include, and / or, the link types that links reaching the target network prefix need to exclude.

[0214] In one possible implementation, the routing constraint information includes a Link Type TLV (Than Link Type Value) and / or an Excluded Link Type TLV (Than Link Type Value), wherein the included Link Type TLV indicates the link types that need to be included for links reaching the target network prefix, and the excluded Link Type TLV indicates the link types that need to be excluded for links reaching the target network prefix.

[0215] In one possible implementation, the receiving unit is specifically configured to: receive a Software-Defined Wide Area Network (SD-WAN) TNP routing advertisement message, wherein the SD-WAN TNP routing advertisement message includes the routing constraint information.

[0216] In one possible implementation, the SD-WAN TNP routing advertisement message includes an extended port attribute sub-TLV, which includes the routing constraint information.

[0217] In one possible implementation, the SD-WAN TNP routing advertisement message includes a first metadata path attribute, which includes the routing constraint information.

[0218] In one possible implementation, the receiving unit is specifically configured to: receive a Path Calculation Unit Protocol (PCEP) message, wherein the PCEP message includes the path constraint information.

[0219] In one possible implementation, the receiving unit is specifically configured to: receive a BGP egress route filtering ORF message, wherein the BGP ORF message includes the route constraint information.

[0220] In one possible implementation, the receiving unit is specifically configured to: receive an OMP message, the OMP message including the path constraint information.

[0221] See Figure 6 The figure is a schematic diagram of the structure of another information processing device provided in the embodiment of this application. Figure 6 The information processing device 600 can be used to execute the above method 100. Specifically, the device 600 may include a receiving unit 601.

[0222] The receiving unit 601 is used to receive routing constraint information, which indicates the link type requirement for the link to reach the target network prefix.

[0223] For details on the specific implementation of the receiving unit 601, please refer to the description of the receiving unit in the above description of the device 500; the description will not be repeated here.

[0224] See Figure 7 The figure is a schematic diagram of the structure of another information processing device provided in the embodiment of this application. Figure 7 The information processing device 700 can be used to perform some of the steps in the method 100 described above. Specifically, the device 700 may include an acquisition unit 701 and a transmission unit 702.

[0225] The acquisition unit 701 is used to acquire path constraint information, which indicates the link type requirement for the link to reach the target network prefix;

[0226] The sending unit 702 is used to send the path constraint information.

[0227] In one possible implementation, the acquisition unit 701 may specifically be a receiving unit, used to receive the path constraint information.

[0228] In another possible implementation, the acquisition unit 701 may specifically be a processing unit used to generate the path constraint information.

[0229] In addition, this application also provides a communication device 800, see [link to relevant documentation]. Figure 8 As shown, Figure 8 This is a schematic diagram of a communication device provided in an embodiment of this 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 execute the method 100 in the above embodiments.

[0230] When the communication device 800 executes method 100, the communication interface 801 performs the send / receive operations in method 100. The processor 802 performs operations in method 100 other than the send / receive operations. For example, the processor 802 generates a BGP message, which includes indication information indicating the link type 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 then sends the BGP message.

[0231] In addition, this application also provides a communication device 900, see [link to relevant documentation]. Figure 9 As shown, Figure 9 This is a schematic diagram of a communication device provided in an embodiment of this application. The communication device 900 can be used to execute the method 100 in the above embodiments.

[0232] like Figure 9As shown, 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 aforementioned 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 refer to a single processor or may include multiple processors. The memory 920 may include volatile memory, such as random-access memory (RAM); it may also include non-volatile memory, such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid-state drive (SSD); or it may include a combination of the above 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 can perform corresponding operations according to the instructions of each software module. In this embodiment, the operation performed by a software module actually refers to the operation performed by the processor 910 according to the instructions of the software module.

[0233] When the communication device 900 executes method 100, the transceiver 930 performs the transmit / receive operations in method 100. The processor 910 performs operations in method 100 other than the transmit / receive operations. For example, the processor 910 generates a BGP message, which includes indication information indicating the link type 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 then transmits the BGP message.

[0234] This application also provides a computer-readable storage medium storing instructions or computer programs that, when executed on a processor, can implement any one or more operations described in the foregoing embodiments (e.g., method 100).

[0235] This application also provides a computer program product, including a computer program that, when run on a processor, can implement any one or more of the operations described in the foregoing embodiments (e.g., method 100).

[0236] This application also provides a communication system for performing the methods described in the foregoing embodiments. For example, the communication system includes a communication device for acquiring and sending the aforementioned BGP messages and a communication device for receiving the BGP messages. As another example, the communication system includes a communication device for acquiring and sending the aforementioned path constraint information and a communication device for receiving the path constraint information.

[0237] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a particular order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments described herein can be implemented in a sequence other than that illustrated or described herein. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises 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.

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

[0239] In the embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical business division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, indirect coupling or communication connection between apparatuses or units, and may be electrical, mechanical, or other forms.

[0240] The units described as separate components may or may not be physically separate. The 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 the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0241] Furthermore, the various business units in the embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software business unit.

[0242] If the integrated unit is implemented as 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 this application, in essence, 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. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0243] Those skilled in the art will recognize that, in one or more of the examples above, the services described in this invention can be implemented using hardware, software, firmware, or any combination thereof. When implemented in software, these services can be stored in a computer-readable medium or transmitted as one or more instructions or code on a computer-readable medium. Computer-readable media include computer storage media and communication media, wherein communication media include any medium that facilitates the transmission of computer programs from one place to another. Storage media can be any available medium accessible to general-purpose or special-purpose computers.

[0244] The above specific embodiments further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above are merely specific embodiments of the present invention.

[0245] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit it. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. An information processing method, characterized in that, The method includes: Obtain a Border Gateway Protocol (BGP) message, which includes indication information indicating the link type between a first Point of Access (POP) in the Software Defined Wide Area Network (SD-WAN) and a second POP in the SD-WAN network. The address family of the BGP message is the 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 or lower-layer underlay link.

3. The method according to claim 2, characterized in that, The overlay links include: Multiprotocol Label Switching (MPLS) links, Internet Protocol version 6 (SRv6) segment routing links, Internet links, 4G links, 5G links, or 5G+ links.

4. The method according to claim 2 or 3, characterized in that, The underlay link includes: a direct link or a leased link.

5. The method according to claim 1, characterized in that, The indication information indicates that the link type is: direct link, leased link, multi-protocol label switching (MPLS) link, Internet Protocol version 6 (SRv6) link, Internet link, 4G link, 5G link, or 5G+ link.

6. The method according to any one of claims 1-5, characterized in that, The sub-address family of the BGP message is the Shortest Path First (SPF) sub-address family.

7. The method according to claim 6, characterized in that, The BGP message includes a Link Type Length Value (TLV), and the Link Type TLV includes the indication information.

8. The method according to claim 7, characterized in that, The BGP message includes BGP LS attributes, and the BGP LS attributes include the link type TLV.

9. The method according to any one of claims 1-8, characterized in that, The method is applied to the first POP or the controller.

10. The method according to any one of claims 1-8, characterized in that, The method further includes: Receive routing constraint information, which indicates the link type requirement for the link to the target network prefix.

11. The method according to claim 10, characterized in that, The method is applied to the first POP, and the method further includes: The target network prefix and the path constraint information are sent to the controller.

12. The method according to claim 10 or 11, characterized in that, The requirements include: The types of links that need to be included in the links leading to the target network prefix, and / or the types of links that need to be excluded from the links leading to the target network prefix.

13. The method according to claim 12, characterized in that, The path constraint information includes a Link Type TLV and / or an Excluded Link Type TLV. The included Link Type TLV indicates the link types that need to be included in the path to the target network prefix, and the excluded Link Type TLV indicates the link types that need to be excluded in the path to the target network prefix.

14. The method according to any one of claims 10-13, characterized in that, The received path constraint information includes: Receive a Software-Defined Wide Area Network (SD-WAN) TNP routing advertisement message, wherein the SD-WAN TNP routing advertisement message includes the routing constraint information.

15. The method according to claim 14, characterized in that, The SD-WAN TNP routing advertisement message includes an extended port attribute sub-TLV, and the extended port attribute sub-TLV includes the routing constraint information.

16. The method according to claim 14, characterized in that, The SD-WAN TNP routing announcement message includes a first metadata path attribute, which includes the routing constraint information.

17. The method according to any one of claims 10-13, characterized in that, The received path constraint information includes: Receive a Path Calculation Unit Protocol (PCEP) message, the PCEP message including the path calculation constraint information.

18. The method according to any one of claims 10-13, characterized in that, The received path constraint information includes: Receive a BGP egress route filtering ORF message, which includes the route constraint information.

19. The method according to any one of claims 10-13, characterized in that, The received path constraint information includes: Receive an OMP message from the Coverage Management Protocol, the OMP message including the path constraint information.

20. An information processing device, characterized in that, The device includes: The acquisition unit is used to acquire Border Gateway Protocol (BGP) messages, which include indication information indicating the link type between a first Point of Access (POP) in the Software Defined Wide Area Network (SD-WAN) and a second POP in the SD-WAN network. The address family of the BGP message is the BGP Link State (LS) address family.

21. The apparatus according to claim 20, characterized in that, The indication information indicates that the link type is: Upper-layer overlay link or lower-layer underlay link.

22. The apparatus according to claim 21, characterized in that, The overlay links include: Multiprotocol Label Switching (MPLS) links, Internet Protocol version 6 (SRv6) segment routing links, Internet links, 4G links, 5G links, or 5G+ links.

23. The apparatus according to claim 21 or 22, characterized in that, The underlay link includes: a direct link or a leased link.

24. The apparatus according to claim 20, characterized in that, The indication information indicates that the link type is: direct link, leased link, multi-protocol label switching (MPLS) link, Internet Protocol version 6 (SRv6) link, Internet link, 4G link, 5G link, or 5G+ link.

25. The apparatus according to any one of claims 20-24, characterized in that, The sub-address family of the BGP message is the Shortest Path First (SPF) sub-address family.

26. The apparatus according to claim 25, characterized in that, The BGP message includes a Link Type Length Value (TLV), and the Link Type TLV includes the indication information.

27. The apparatus according to claim 26, characterized in that, The BGP message includes BGP LS attributes, and the BGP LS attributes include the link type TLV.

28. The apparatus according to any one of claims 20-27, characterized in that, The device is applied to the first POP or controller.

29. The apparatus according to any one of claims 20-27, characterized in that, The device further includes: A receiving unit is used to receive routing constraint information, which indicates the link type requirement for the link to the target network prefix.

30. The apparatus according to claim 29, characterized in that, The device is applied to the first POP, and the device further includes: The sending unit is used to send the target network prefix and the path constraint information to the controller.

31. The apparatus according to claim 29 or 30, characterized in that, The requirements include: The types of links that need to be included in the links leading to the target network prefix, and / or the types of links that need to be excluded from the links leading to the target network prefix.

32. The apparatus according to claim 31, characterized in that, The path constraint information includes a Link Type TLV and / or an Excluded Link Type TLV. The included Link Type TLV indicates the link types that need to be included in the path to the target network prefix, and the excluded Link Type TLV indicates the link types that need to be excluded in the path to the target network prefix.

33. The apparatus according to any one of claims 29-32, characterized in that, The receiving unit is specifically used for: Receive a Software-Defined Wide Area Network (SD-WAN) TNP routing advertisement message, wherein the SD-WAN TNP routing advertisement message includes the routing constraint information.

34. The apparatus according to claim 33, characterized in that, The SD-WAN TNP routing advertisement message includes an extended port attribute sub-TLV, and the extended port attribute sub-TLV includes the routing constraint information.

35. The apparatus according to claim 33, characterized in that, The SD-WAN TNP routing announcement message includes a first metadata path attribute, which includes the routing constraint information.

36. The apparatus according to any one of claims 29-32, characterized in that, The receiving unit is specifically used for: Receive a Path Calculation Unit Protocol (PCEP) message, the PCEP message including the path calculation constraint information.

37. The apparatus according to any one of claims 29-32, characterized in that, The receiving unit is specifically used for: Receive a BGP egress route filtering ORF message, which includes the route constraint information.

38. The apparatus according to any one of claims 29-32, characterized in that, The receiving unit is specifically used for: Receive an OMP message from the Coverage Management Protocol, the OMP message including the path constraint information.

39. An information processing device, characterized in that, include: Processor and memory; The memory is used to store instructions; The processor is configured to execute the instructions, causing the device to perform the method according to any one of claims 1-19.

40. A computer-readable storage medium, characterized in that, Includes instructions or computer programs that, when executed on a processor, implement the method described in any one of claims 1-19.

41. A computer program product, characterized in that, Includes program code that, when a computer runs the computer program product, causes the computer to perform the method described in any one of claims 1-19.

Images