Information processing method and device

Abstract

The embodiment of the invention discloses an information processing method. The method can be applied to a target device for example. A target device can obtain a BGP message, the address family of the BGP message is a BGP LS address family, the BGP message comprises indication information, and the indication information indicates the link type of a link between a first POP in an SD-WAN network and a second POP in the SD-WAN network. By adopting the scheme, the link type between the POP points can be carried by adopting the BGP message of the LS address family, so that a service path is subsequently arranged for the service based on the link type between the POP points, and the service requirement is met.

Description

Technical Field

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

[0002] In the current wide area network (WAN), in order to achieve end-to-end fast delivery and flexible scheduling, software-defined networking in a wide area network (SD-WAN) technology is usually used. On the basis of different underlying networks such as the Internet and dedicated line networks, SD-WAN tunnels are established to build an upper layer (overlay) network based on SD-WAN, so as to decouple the WAN service from the underlying network and improve the end-to-end delivery capability. Among them, the overlay network based on SD-WAN can be referred to as SD-WAN network.

[0003] 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.

[0004] Therefore, a solution is urgently needed to solve the above problems. Summary of the invention

[0005] The embodiments of the present application provide an information processing method and device, which can be helpful for arranging business paths to better meet business needs.

[0006] In the 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 POP points can be carried by using a BGP message of the LS address family, so as to facilitate the subsequent orchestration of service paths for services based on the link type between POP points, thereby meeting service needs.

[0007] 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 4th generation mobile communication technology (4G) link, a 5th generation mobile communication technology 5G (5G) link, or a 5th 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, and 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.

[0008] In a 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.

[0009] In a possible implementation, when the sub-address family of the BGP message is an 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, the link type of the link between the first POP and the second POP can be determined based on the indication information. In a possible implementation, the BGP message may include a BGP path attribute, and the aforementioned link type TLV can 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, and accordingly, the link type of the link between the first POP and the second POP can be determined based on the indication information.

[0010] In a possible implementation, the target device may be a first POP. In this case, the first POP may generate the BGP message when acquiring the BGP message. As an example, after the first POP generates the BGP message, the BGP message may be sent, for example, to other POPs and / or controllers.

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

[0012] In a possible implementation, the target device may receive path calculation constraint information, wherein the path calculation constraint information indicates a requirement for a link type of a link reaching the target network prefix. In this way, the device for arranging a service path may arrange the service path based on the path calculation constraint information, so as to arrange a service path that conforms to the aforementioned path calculation constraint information as much as possible, thereby meeting the service requirement.

[0013] 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.

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

[0015] In a possible implementation, 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. In this case, by specifying the link type that the link reaching the target network prefix needs to include, the first POP or controller can calculate the service path including the link of the aforementioned link type that needs to be included as much as possible when calculating the service path, thereby meeting the service requirement.

[0016] In a possible implementation, the aforementioned requirement for the link type of the link reaching the target network prefix may include: the link type that needs to be excluded from the link reaching the target network prefix. In this case, by specifying the link type that needs to be excluded from the link reaching the target network prefix, the first POP or controller can calculate the service path as much as possible without including the link type that needs to be excluded when calculating the service path, thereby meeting the service requirement.

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

[0018] In one possible implementation, if the aforementioned requirement includes a link type that needs 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 type that needs to be excluded from the link reaching the target network prefix.

[0019] In a possible implementation, the aforementioned path calculation constraint information may be carried by a SD-WAN transport network port (TNP) routing announcement message. In other words, when receiving a routing announcement message, a SD-WAN TNP routing announcement message may be received, and the SD-WAN TNP routing announcement message includes the aforementioned path calculation constraint information. For example, the SD-WAN TNP routing announcement message includes the aforementioned first TLV and / or second TLV.

[0020] In one possible implementation, the path calculation constraint information may be carried by an extended port attribute sub-TLV (Extended Port Attribute Sub-TLV) in the SD-WAN TNP routing announcement message. Specifically, the aforementioned first TLV and / or second TLV may be used as a sub-sub-TLV of the extended port attribute sub-TLV. In this case, the target device may obtain the path calculation constraint information by parsing the Extended Port Attribute Sub-TLV in the SD-WAN TNP routing announcement message.

[0021] In a possible implementation, the SD-WAN TNP route announcement message may include a first metadata path attribute, and the aforementioned 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.

[0022] In a 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 routing advertisement message, a PCEP message may be received in a specific implementation, and the PCEP message includes the path calculation constraint information. In a specific example, the PCEP message may include a first object and / or a second object, the first object being used to carry the first TLV, and the second object being 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 using an existing PCEP object. For example, the existing PCEP object may be extended to carry the aforementioned first TLV and the second TLV.

[0023] In a possible implementation, the aforementioned path calculation constraint information may be carried by a BGP outbound route filters (ORF) message. In other words, when receiving a route advertisement message, a BGP ORF message may be received, and the BGP ORF message includes the 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 by the second metadata path attribute.

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

[0025] In a second 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 be a controller or a first POP. The target device can receive path calculation constraint information, and the path calculation constraint information indicates the requirement for the link type of the link reaching the target network prefix. In this way, the device for arranging the service path can arrange the service path based on the path calculation constraint information, so as to arrange the service path that meets the aforementioned path calculation constraint information as much as possible, thereby meeting the service demand.

[0026] 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.

[0027] In a possible implementation manner, 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.

[0028] In a 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.

[0029] 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.

[0030] In a possible implementation, 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.

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

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

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

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

[0035] In a third aspect, an embodiment of the present application provides an information processing method, the method comprising: obtaining path calculation constraint information, and sending the path calculation constraint information, wherein the path calculation constraint information indicates the requirement for the link type of the link reaching the target network prefix. In this way, the device for arranging the service path can arrange the service path based on the path calculation constraint information, so as to arrange the service path that meets the aforementioned path calculation constraint information as much as possible, thereby meeting the service demand.

[0036] In a possible implementation manner, 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.

[0037] In a 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.

[0038] 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.

[0039] In a possible implementation, 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.

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

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

[0042] In a possible implementation manner, the sending of the path calculation constraint information includes: sending a BGP export route filtering ORF message, wherein the BGP ORF message includes the path calculation constraint information.

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

[0044] In a fourth aspect, an embodiment of the present application provides an information processing device, which includes a transceiver unit and / or a processing unit, wherein the transceiver unit is used to perform a transceiver operation, and the processing unit is used to perform other operations except the transceiver operation. The 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 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, used to acquire a Border Gateway Protocol BGP message, the BGP message includes indication information, the indication information indicates the link type of the link between the first point of presence POP and the second POP, and the address family of the BGP message is a BGP link state LS address family.

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

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

[0048] 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.

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

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

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

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

[0053] 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.

[0054] In a possible implementation, when the aforementioned acquisition 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.

[0055] 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.

[0056] In a possible implementation manner, 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.

[0057] In a 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.

[0058] 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, and the SD-WAN TNP routing announcement message includes the path calculation constraint information.

[0059] In a possible implementation, 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.

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

[0061] 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.

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

[0063] 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.

[0064] In another specific example, the information processing device is used 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, used to receive path calculation constraint information, wherein the path calculation constraint information indicates a requirement for a link type of a link to reach a target network prefix.

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

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

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

[0068] In a fifth aspect, an embodiment of the present application provides 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, 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.

[0070] 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 the computer program are executed on a processor, the method described in the first aspect and any one of the first aspect is implemented, or the method described in the second aspect and any one of the second aspect is implemented, or the method described in the third aspect and any one of the third aspect is implemented.

[0071] 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.

[0072] 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

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

[0074] Figure 1a A schematic diagram of an exemplary application scenario provided for an embodiment of the present application;

[0075] Figure 1b A schematic diagram of another exemplary application scenario provided for an embodiment of the present application;

[0076] Figure 1c A schematic diagram of another exemplary application scenario provided for an embodiment of the present application;

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

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

[0079] Figure 2c A schematic diagram of the structure of a link state NLRI provided in an embodiment of the present application;

[0080] Figure 2dA schematic diagram of the structure of a BGP routing update message provided in an embodiment of the present application;

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

[0082] Figure 2f A schematic diagram of the structure of an OMP message provided in an embodiment of the present application;

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

[0084] Figure 4a A schematic diagram of the structure of a link type TLV provided in an embodiment of the present application;

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

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

[0087] Figure 4d A schematic diagram of the structure of an LSPA object provided in an embodiment of the present application;

[0088] Figure 4e A schematic diagram of the structure of an RP object provided in an embodiment of the present application;

[0089] Figure 5 A schematic diagram of the structure of an information processing device provided in an embodiment of the present application;

[0090] Figure 6 A schematic diagram of the structure of another information processing device provided in an embodiment of the present application;

[0091] Figure 7 A schematic diagram of the structure of another information processing device provided in an embodiment of the present application;

[0092] Figure 8 A schematic diagram of the structure of a communication device provided in an embodiment of the present application;

[0093] Fig. 9 A schematic diagram of the structure of a communication device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0094] The embodiments of the present application provide a method and device for forwarding traffic, which can be helpful for orchestrating service paths, so that the orchestrated paths better meet service requirements.

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

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

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

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

[0099] The edge access network 100 includes: site edge1, site edge3 and site 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, wherein the POP connected to the site edge in the POP backbone network is called an EPOP, and the POP not connected to the site edge is called a 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] The site edge in the edge access network 100 and 300 can access the backbone network through the EPOP in the backbone network. The EPOP in the backbone network used by the site edge to access the backbone network can be considered as the gateway corresponding to the site edge. 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. For another example, 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] The site edge can access its corresponding gateway through the SD-WAN tunnel or the internet, where the gateway is a POP in the backbone network 200.

[0104] In the embodiment of the present application, the backbone network can be a hybrid network including at least one network domain, and the 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, wherein the MSP backbone network can include a single operator network, a hybrid operator network, and a self-built dedicated line network, which is not specifically limited in the embodiment of the present application. MPLS technology can be applied to the backbone network, and SRv6 technology can also be applied, which is not specifically limited in the embodiment of the present application.

[0105] For reference Figure 1b and Figure 1c To understand, Figure 1b and Figure 1c Two other exemplary application scenario schematic diagrams are provided for the embodiments of the present application.

[0106] like Figure 1b As shown, the backbone network 400 includes: Internet service provider (ISP) network 1 (referred to as ISP1), ISP2, ISP3 and a self-built dedicated line network. Figure 1c The scene shown is similar to Figure 1b The difference is that Figure 1c The backbone network 500 shown does not include a self-built dedicated line network.

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

[0108] At present, a service path across the backbone network 200 can be arranged for the service. In one example, the ingress POP in the backbone network can arrange 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 through the egress POP. In another example, the CPE can calculate the end-to-end path of the bearer service, for example, Figure 1b In the scenario shown, edge1 calculates the end-to-end path from edge1 to edge2. In another example, the controller can uniformly arrange paths across the entire network, for example, the controller uniformly arranges the end-to-end path from the ingress POP to the egress POP, or the controller uniformly arranges the end-to-end path between two CPEs across the backbone network.

[0109] Currently, when arranging service paths, path arrangement can be performed in combination with information such as link cost, delay and other parameter values. However, using this method, the arranged paths often cannot meet service requirements.

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

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

[0112] 1.BGP

[0113] BGP is a dynamic routing protocol used between autonomous systems (AS). As the standard for internet external routing protocols, BGP is widely used between internet service providers (ISPs). Currently, the most widely used protocol is Multi-Protocol Extensions for BGP (MP-BGP), which is based on BGP version 4 (BGP-4).

[0114] BGP messages consist of two parts: the BGP message header and the message content. As shown in Table 1, BGP has five message types as shown in Table 2. 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 65535 bytes and the minimum length is 19 bytes (including only the BGP message header). Figure 2a As shown, Figure 2a A schematic diagram of the structure of a BGP message header provided in an embodiment of the present application. Figure 2a As shown in FIG. 1 , 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 the following Table 1.

[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, the communication devices may announce routes through MP-BGP. Specifically, the BGP messages exchanged between the communication devices for announcing routes include Multi-Protocol reachnetwork 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 as follows: Figure 2b As shown, Figure 2b A schematic diagram of the structure of MP_REACH_NLRI provided in an embodiment of the present application. Figure 2b As shown, 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 field.

[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, the value of the AFI field is 2 to identify IPv6, and 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 an 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, wherein 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 a BGP ORF message.

[0128] Regarding BGP ORF messages, it is necessary to explain:

[0129] RFC5291 and RFC5292 specify the prefix-based ORF capability of BGP, which can send the prefix-based ingress policy configured by the local device to the BGP neighbor through the route refresh message. The BGP neighbor constructs the egress policy based on these policies and filters the routes when sending them. This not only prevents the local device from receiving a large number of useless routes and reduces the utilization rate of the central processing unit (CPU) of the local device, but also effectively reduces the configuration work of BGP neighbors and reduces the occupancy rate of the link bandwidth. For example: communication device A and communication device B establish a direct BGP neighbor relationship. After communication device A and communication device B negotiate the prefix-based ORF capability, communication device A sends the locally configured prefix-based ingress policy to communication device B through the route refresh message. Communication device B constructs the egress policy based on the received route refresh message. Communication device A only receives the routes it needs, and communication device B does not have to maintain the routing policy, which reduces the configuration work.

[0130] 2. BGP LS

[0131] BGP-LS is a way to collect 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 about links, nodes, and IPv4 prefixes or IPv6 prefixes. This new NLRI is called link-state NLRI. In an 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. Figure 2c , Figure 2c A schematic diagram of the structure of a link state NLRI provided in an embodiment of the present application. Figure 2cAs shown, the link state NLRI includes an NLRI type field, a total NLRI length field and a link-state NLRI field.

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

[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 according to the value of the NLRI type field.

[0136] Table 4

[0137] NLRI Type Value 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 called the BGP-SPF address family. The BGP-SPF address family is a newly added address family under Link-stateAFI, and the newly added sub-address family is the LS address family combined with the SPF sub-address family.

[0140] The SAFI value of 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] Among them, each communication device enabled with the BGP-LS-SPF address family needs to generate a nodeNLRI unconditionally. The specific format of the node NLRI is not described in detail here.

[0143] For a communication device that enables the BGP-LS-SPF address family, it will generate a link NLRI for its own link information and notify other communication devices. The format of the Link NLRI complies with the definition of RFC7752 and is not described in detail here.

[0144] The BGP route update message of the BGP-LS-SPF address family carries multiple path attributes, one of which is called 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 above, there is also an MP_REACH_NLRI in the BGP message, which is defined in RFC4760. When the AFI of MP_REACH_NLRI is 16388 and the SAFI is 80, it indicates that this is a BGP route update message of the BGP-LS-SPF address family. In addition, 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 of the BGP-LS-SPF address family is Link NLRI.

[0145] For a BGP route update message of a BGP-LS-SPF address family including a Link NLRI, its Link NLRI may include a link description TLV, and the link description TLV may include one or more TLVs describing the link, for example, 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 an example, the local address TLV may be an IPv6 interface address TLV (IPv6 interface address TLV), and the other end address TLV may be an IPv6 neighbor address TLV (IPv6 neighbor address TLV).

[0146] Next, combine Figure 2d , introduces the structure of the BGP routing update message including the BGP-LS-SPF address family of Link NLRI. Figure 2d A schematic diagram of the structure of a BGP routing update message provided in an embodiment of the present application.

[0147] like Figure 2dAs shown, 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, and the path attribute field can carry multiple BGP path attributes, wherein the multiple BGP path attributes can at least include: BGP LS attributes and MP_REACH_NLRI, and MP_REACH_NLRI can at least include the aforementioned link description TLV. In an embodiment of the present application, the value carried by the unavailable route 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 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. Figure 2b The NLRI domain shown can be used to carry SD-WAN TNP routing information. The information about TNP routing is not described in detail here.

[0150] 5. PCEP

[0151] The PCEP message includes: PCEP request message and PCEP response message. The structures of PCEP request message and PCEP response message are as follows: Figure 2e As stated, Figure 2e A schematic diagram of the structure of a PCEP message provided in an embodiment of the present application. Figure 2e The PCEP message shown includes a PCEP general message header and an object list. For the PCEP general message header, reference may be made to the relevant description of RFC5440, which will not be described in detail here. The object list is used to carry one or more objects.

[0152] in:

[0153] A PCEP request message may be used to request a device (eg, a controller or a POP) to calculate a path. After the device calculates the path, it may 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 point (END-POINTS) object, as well as some other optional objects, such as a label switched path attributes (LSPA) object, a record route object (RRO) object, and an include route object (IRO) object.

[0155] The PCEP response message must carry an RP object. If the path calculation is successful, it can carry an explicit route object (ERO) object; if the path calculation fails, it can carry a NO-PATH object. The PCEP response message also has some other optional objects, such as the LSPA object and the IRO object.

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

[0157] 6.OMP Message

[0158] OMP messages are used to announce OMP routes. The message structure of OMP messages can be as follows Figure 2f As shown, Figure 2f A schematic diagram of the structure of an OMP message provided in an embodiment of the present application. Figure 2f As shown, the OMP message includes an attribute length field and a data field.

[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 TLVs.

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

[0162] See also Figure 3 , which is a flow chart of an information processing method provided in an embodiment of the present application.

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

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

[0165] S101: Obtain a BGP message, wherein the BGP message includes indication information, wherein 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.

[0166] When the method 100 is applied to the 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.

[0167] Regarding the first POP and the second POP, Figure 1b For example, the first POP can be Figure 1b POP1 shown, the second POP can be Figure 1b Alternatively, the first POP can be Figure 1b As shown in POP2, the second POP can be Figure 1b The POP1, POP5, POP6, POP7, POP3 or POP8 shown in the figure are not listed here one by one.

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

[0169] S102: Send the BGP message.

[0170] 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.

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

[0172] In an 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. Among them, a 5G+ link refers to a link that uses a technology further developed on the basis of 5G technology. 5G+ may include 6G.

[0173] 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, and 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.

[0174] The embodiment of the present application does not specifically limit the sub-address family of the BGP message, and 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 announce link information, therefore, in a specific example, the sub-address family of the BGP message may be the SFP sub-address family, that is, in the embodiment of the present application, the feature 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.

[0175] 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, and the link type TLV is used to carry the indication information. The format of the link type TLV can refer to Figure 4a To understand, Figure 4a A schematic diagram of the structure of a link type TLV provided in an embodiment of the present 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 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 embodiment of the present application does not specifically limit the BGP path attribute. In a specific example, the BGP path attribute may be a BGP LS attribute. In this case, the link type TLV may be carried in Figure 2d In the BGP LS attributes shown.

[0177] In one example, the BGP message may include MP_REACH_NLRI, the MP_REACH_NLRI may include a link description TLV, and the link type TLV may be carried by the link description TLV. In this case, the link type TLV may be carried by Figure 2d The link description TLV shown carries, that is, the link type TLV may include, in addition to the local address TLV and the neighbor address TLV, the link description TLV to indicate the link type of the link.

[0178] In an embodiment of the present application, in order to better meet business needs, the first POP or controller may combine the path calculation constraint information when calculating the business path for the business, wherein the path calculation constraint information indicates the requirement for the link type of the link reaching the target network prefix. Among them, the business path reaching the target network prefix may include multiple links, and the aforementioned path calculation constraint information may indicate the requirement for the link type of 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.

[0179] In one example, when the method 100 is applied to a controller, the controller may, for example, receive the aforementioned path calculation constraint information sent by the first POP or CPE, so as to calculate the service path to the 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 the path calculation constraint information to the controller.

[0180] In another example, when the method 100 is applied to the first POP, the first POP may, for example, receive the aforementioned path calculation constraint information sent by the CPE. As an example, the first POP may calculate the service path to the 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 the controller, and the controller calculates the service path to the target network prefix based on the path calculation constraint information.

[0181] 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.

[0182] In another specific example, the aforementioned requirement for the link type of the link reaching the target network prefix may include: the link type that needs to be excluded from the link reaching the target network prefix. 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 exclude the internet link. In this way, by specifying the link type that needs to be excluded from the link reaching the target network prefix, the first POP or controller can calculate the business path that does not include the link type that needs to be excluded when calculating the business path, thereby meeting the business demand.

[0183] In one example, if the aforementioned requirement includes the link type that the link to reach 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 reach the target network prefix needs to include.

[0184] Regarding the first TLV, you can combine Figure 4b To understand. Figure 4b This is a schematic diagram of the structure of a first TLV provided in an embodiment of the present application. Figure 4b As shown, 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 that needs to be included.

[0185] In another example, 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 excluded link type TLV indicating the link types that need to be excluded from the link reaching the target network prefix.

[0186] Regarding the second TLV, you can combine Figure 4c To understand. Figure 4c This is a schematic diagram of the structure of a second TLV provided in an embodiment of the present application. Figure 4c As shown, 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 that needs to be excluded.

[0187] In one implementation, the aforementioned path calculation constraint information may be carried by an SD-WAN TNP routing announcement message. In other words, when receiving a routing announcement message, an SD-WAN TNP routing announcement message may be received, and the SD-WAN TNP routing announcement message includes the aforementioned path calculation constraint information. For example, the SD-WAN TNP routing announcement message includes the aforementioned first TLV and / or second TLV.

[0188] The embodiment of the present application does not specifically limit the carrying position of the path calculation constraint information in the SD-WAN TNP routing announcement message. In a specific example, the path calculation constraint information can be carried through the extended port attribute sub-TLV in the SD-WAN TNP routing 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 routing announcement 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 path calculation constraint information may be carried by a PCEP message. For example, it may be carried by a PCEP request message. In other words, when receiving a route advertisement message, a PCEP message may be received, and the PCEP message includes the 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, the first object being used to carry the first TLV, and the second object being used to carry the second TLV. Among them, the first object and the second object may be newly extended objects. In other words, in an embodiment of the present application, one or two new PCEP objects (i.e., the first object and the second object) may be extended in a 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 by 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.

[0190] As a specific example, the LSPA object may be extended, and the extended LSPA object may be used to carry the first TLV and the second TLV. Figure 4d To understand, Figure 4d A schematic diagram of the structure of an LSPA object provided in an embodiment of the present application. Figure 4dAs shown, the LSPA object includes: an Exclude-any field, an Include-any field, an Include-all field, a Setup Prio field, a Holding Prio field, a Flags field, an L flag, a Reserved field, and an Optional TLVs field. For the Exclude-any field, the Include-any field, the Include-all field, the Setup Prio field, the Holding Prio field, the Flags field, the L flag, and the Reserved field in the LSPA object, reference may be made to the relevant description of RFC5440, which will not be described in detail here.

[0191] In one example, the Optional TLVs field may be extended to carry the first TLV and the second TLV. Specifically, the path information TLV may be carried in the Optional TLVs field. The structure of the path information TLV may be as follows: Figure 4d As shown, it includes: 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.

[0192] The source endpoint address field is used to carry the address of the source endpoint of the path requested to be calculated, and the destination endpoint address field is used to carry the destination address of the path requested to be calculated (such as the aforementioned target network prefix). Optionally, the path information TLV may also include a path ID field to indicate the identifier of the path requested to be calculated.

[0193] As another example, the RP object may be extended, and the extended RP object may be used to carry the first TLV and the second TLV. Figure 4e To understand, Figure 4e A schematic diagram of the structure of an RP object provided in an embodiment of the present application. Figure 4eAs shown, the RP object includes: a Flags field, an O indicator, a B indicator, an R indicator, a Priority (Prio) indicator, a Request-ID-number field, and an Optional TLVs field. For the Flags field, the O indicator, the B indicator, the R indicator, the Prio indicator, and the Request-ID-number field in the RP object, reference may be made to the relevant description in RFC5440, which will not be described in detail here.

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

[0195] In another implementation, the aforementioned path calculation constraint information may be carried by a BGP ORF message. In other words, when receiving a routing advertisement message, a BGP ORF message may be received, and the BGP ORF message includes the 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 by the second metadata path attribute.

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

[0197] The above is an introduction to the information processing method provided in the embodiment of the present application. Figure 1b The application scenario shown introduces a possible implementation method of the embodiment of the present application.

[0198] like Figure 1bAs shown, each POP in the backbone network notifies the link type of the link connected to itself to other POPs in the backbone network through BGP messages. The address family of the BGP message may be the BGP LS address family, and the sub-address family may be the SPF sub-address family. The POP may directly notify the link type of the link connected to itself to its BGP neighbor, or may notify it to other POPs through a route reflector (RR). In this way, each POP in the backbone network obtains the link type of each link in the backbone network.

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

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

[0201] See also Figure 5 , which is a structural schematic diagram of an information processing device provided in an embodiment of the present application. Figure 5 The information processing device 500 may 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 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 an address family of the BGP message is a BGP link state LS address family.

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

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

[0205] 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.

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

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

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

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

[0210] 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.

[0211] In a possible implementation, when the aforementioned acquisition 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.

[0212] 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.

[0213] In a possible implementation manner, 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.

[0214] In a 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.

[0215] 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, and the SD-WAN TNP routing announcement message includes the path calculation constraint information.

[0216] In a possible implementation, 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.

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

[0218] 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.

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

[0220] 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.

[0221] See also Figure 6 , which is a structural schematic diagram of another information processing device provided in an embodiment of the present application. Figure 6 The information processing device 600 may be used to execute the above method 100. Specifically, the device 600 may include: a receiving unit 601.

[0222] The receiving unit 601 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.

[0223] Regarding the specific implementation of the receiving unit 601, reference may be made to the above description of the receiving unit in the device 500, and a repeated description will not be made here.

[0224] See also Figure 7 , which is a structural schematic diagram of another information processing device provided in an embodiment of the present application. Figure 7 The information processing device 700 may be used to execute some steps in the above method 100. Specifically, the device 700 may include: an acquisition unit 701 and a sending unit 702.

[0225] The acquisition unit 701 is used to acquire 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;

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

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

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

[0229] In addition, the present application embodiment also provides a communication device 800, see Figure 8 As shown, Figure 8 The present invention provides a schematic diagram of the structure of a communication device according to 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 execute the method 100 in the above embodiment.

[0230] When the communication device 800 is used to execute the above method 100, the communication interface 801 is used to execute the sending and receiving operations in the method 100. The processor 802 is used to execute operations other than the sending and receiving operations in the method 100. For example, the processor 802 is used to generate a BGP message, the BGP message includes indication information, the indication information indicates 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 used to send the BGP message.

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

[0232] like Fig. 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 a NP. The processor may also be an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. The above-mentioned 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 one processor or may include multiple processors. The memory 920 may include a volatile memory (English: volatile memory), such as a random access memory (English: random-access memory, abbreviated: RAM); the memory may also include a non-volatile memory (English: non-volatile memory), such as a read-only memory (English: read-only memory, abbreviated: ROM), a flash memory (English: flash memory), a hard disk drive (English: hard disk drive, abbreviated: HDD) or a solid-state drive (English: solid-state drive, abbreviated: SSD); the memory 920 may also include a combination of the above-mentioned types of memories. The memory 920 may refer to one memory or may include multiple memories. In one embodiment, the memory 920 stores computer-readable instructions, and the computer-readable instructions 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 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 is used to execute the above method 100, the transceiver 930 is used to execute the transceiver operation in the method 100. The processor 910 is used to execute operations other than the transceiver operation in the method 100. For example, the processor 910 is used to generate a BGP message, the BGP message includes indication information, the indication information indicates 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 used to send the BGP message.

[0234] The present application also provides a computer-readable storage medium, in which instructions or computer programs are stored. When the instruction computer program runs on a processor, any one or more operations of the methods described in the foregoing embodiments (such as method 100) can be implemented.

[0235] The present application also provides a computer program product, including a computer program. When the computer program is executed on a processor, any one or more operations of the method (eg, method 100) described in the foregoing embodiments can be implemented.

[0236] The embodiment of the present application also provides a communication system for executing the method described in the above embodiment. For example, the communication system includes a communication device for acquiring and sending the above BGP message and a communication device for receiving the BGP message. For another example, the communication system includes a communication device for acquiring and sending the above path calculation constraint information and a communication device for receiving the path calculation constraint information.

[0237] The terms "first", "second", "third", "fourth", etc. (if any) in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be 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, for example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units that are clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0238] Those skilled in the art can 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.

[0239] In the several embodiments provided in the present 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 only schematic. For example, the division of units is only a logical business division. There may be other division methods in actual implementation. For example, 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 interfaces, devices or units, which can be electrical, mechanical or other forms.

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

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

[0242] 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, and the computer software product is stored in a storage medium, including a number of instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the various embodiments of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), disk or optical disk and other media that can store program codes.

[0243] Those skilled in the art will appreciate that in one or more of the above examples, the services described in the present invention may be implemented using hardware, software, firmware, or any combination thereof. When implemented using software, the services may be stored in 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, wherein communication media include any media that facilitates the transmission of computer programs from one place to another. Storage media may be any available media that can be accessed by a general-purpose or special-purpose computer.

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

[0245] 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, a person of ordinary skill in the art should understand that the technical solutions described in the aforementioned embodiments may still be modified, or some of the technical features thereof may be replaced by equivalents. 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. 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.

19. An information processing device, characterized in that: The device comprises: a transceiver unit and / or a processing unit; The transceiver unit is used to perform the receiving and / or sending operation according to any one of claims 1 to 18; The processing unit is used to perform operations other than the receiving and / or sending operations described in any one of claims 1-18.

20. 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 instruction so that the communication device executes the method according to any one of claims 1-18.

21. A communication system, characterized in that: The system comprises: A communication device for executing the method according to any one of claims 7 to 16, and a communication device for executing the method according to claim 18.

22. A computer-readable storage medium, characterized in that: The method comprises instructions or computer programs, and when the instructions or computer programs are executed on a processor, the method according to any one of claims 1 to 18 is implemented.

Images