WO2022206667A1 - 一种路由方法及设备 - Google Patents

一种路由方法及设备 Download PDF

Info

Publication number
WO2022206667A1
WO2022206667A1 PCT/CN2022/083327 CN2022083327W WO2022206667A1 WO 2022206667 A1 WO2022206667 A1 WO 2022206667A1 CN 2022083327 W CN2022083327 W CN 2022083327W WO 2022206667 A1 WO2022206667 A1 WO 2022206667A1
Authority
WO
WIPO (PCT)
Prior art keywords
path
request
forwarding node
sent
data packet
Prior art date
Application number
PCT/CN2022/083327
Other languages
English (en)
French (fr)
Inventor
李赓
陈永刚
曹振
武昊
王智用
Original Assignee
华为技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 华为技术有限公司 filed Critical 华为技术有限公司
Publication of WO2022206667A1 publication Critical patent/WO2022206667A1/zh

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/34—Source routing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/12—Discovery or management of network topologies
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/45—Network directories; Name-to-address mapping
    • H04L61/4505—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols
    • H04L61/4511—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols using domain name system [DNS]

Definitions

  • the present application relates to the field of data transmission, and in particular, to a routing method and device.
  • the end-to-end transmission path is determined by routing protocols in the Internet (such as border gateway protocol (BGP), interior gateway protocol (interior gateway protocol). gateway protocol, IGP), etc.).
  • Border gateway protocol Border gateway protocol
  • IGP interior gateway protocol
  • BGP border gateway protocol
  • IGP interior gateway protocol
  • the routing methods from the source device to the destination device are generally divided into the following types: global server load balance (GSLB) based on intelligent domain name system (DNS), overlay intelligent routing and segment/ Source routing (segment/source routing, SR), in which the DNS-based GSLB solves the application's control of the destination address of the destination device requested by the user, but cannot control the access path to the destination device, that is, the source device
  • DNS domain name system
  • SR segment/source routing
  • Embodiments of the present application provide a routing method and device, which are used to provide an application on a source device with a control capability of accessing a path of a destination device, extend the SR domain to the terminal device, and initiate SR from the real data source,
  • the terminal defines an end-to-end transmission path for Internet transmission, which improves routing efficiency and improves the end-to-end performance of Internet services.
  • an embodiment of the present application first provides a routing method, which can be used in the field of data transmission.
  • the method includes: first, the source device sends a first extended DNS request to the controller, where the first extended DNS request includes The first path request, the first path request is used to indicate the path through which the subsequent source-end device sends data packets to the destination-end device (that is, instructing the source-end device to send data packets to the destination-end device).
  • different path requests are defined in advance in the fields of the resource record of the extended DNS request, and there can be multiple implementations, for example, it can be an extension to the extended DNS protocol standard (that is, adding a new extension field). ), or it can be compatible with existing standard protocols.
  • this application does not limit the specific implementation of defining different path requests in the fields of the resource record of the extended DNS request.
  • the source device After the source device sends the first extended DNS request to the controller, it will then obtain the first extended DNS response sent by the controller, the first extended DNS response is generated by the controller, and the first extended DNS response includes and Path information corresponding to the first path request, where the path information is obtained by the controller performing a matching query according to the information in the first extended DNS request.
  • the path information includes the forwarding nodes between the source device and the destination device and the forwarding sequence of the forwarding nodes.
  • the source-end device sends the target data packet to be sent to the destination-end device via the forwarding node (that is, the forwarding node included in the path information) according to the forwarding sequence.
  • the forwarding node that is, the forwarding node included in the path information
  • the default sequential forwarding order is forwarded by this one forwarding node.
  • n forwarding nodes it is the normal sequential forwarding order.
  • the request for the path and the response to the path request (that is, the path information planned by the controller) are carried in the extended DNS message, so as to provide the application on the source device with access to the destination device. control of the path.
  • the source device carries the path request in the extended DNS request and sends it to the controller.
  • the controller plans a path based on the received extended DNS request, and carries the planned path information in the extended DNS response to the source device.
  • the source end device sends the target data packet to the target end device according to the specific content of the path information (for example, including several forwarding nodes, the forwarding sequence between the forwarding nodes, etc.).
  • the embodiment of the present application uses the extended DNS message as the medium, configures the path information in the response message in the extended DNS message to initiate the SR from the real data source, and configures the end-to-end transmission path for Internet transmission at the terminal, which improves the routing performance. efficiency, and improve the end-to-end performance of Internet business.
  • the source device responds to the received first extension
  • the process of parsing the DNS response, and sending the target data packet to be sent to the destination device in the forwarding order through the forwarding node included in the path information can be as follows: first, the source device sends the target data packet according to the obtained path information
  • the packet is encapsulated to obtain a data packet (which may be referred to as a first data packet) encapsulated with a header field (which may be referred to as a first header field).
  • the first header field includes the forwarding sequence of the forwarding node and the source address of the source device.
  • the source device sends the first data packet to the first hop forwarding node, and the first hop forwarding node is based on the sequence of the forwarding nodes included in the first header field.
  • the forwarding sequence judges whether it is the last hop forwarding node. If the first hop forwarding node is not the last hop forwarding node, in this case, the first forwarding node has the first header field of the first data packet.
  • the second data packet includes the forwarding sequence of the forwarding nodes, the address of the first-hop forwarding node, and the address of the second-hop forwarding node.
  • the first-hop forwarding node transfers the first-hop forwarding node according to the forwarding sequence of the forwarding nodes.
  • the second data packet is sent to the second hop forwarding node.
  • the second-hop forwarding node determines whether it is the last-hop forwarding node according to the forwarding sequence of the forwarding nodes included in the second header field in the second data packet, if the second-hop forwarding node is the last forwarding node.
  • One-hop forwarding node in this case, the second-hop forwarding node decapsulates the second header field of the second data packet (that is, deletes the second header field of the second data packet) to obtain the initial target
  • the second-hop forwarding node sends the target data packet with the second header field deleted to the destination device.
  • each other forwarding node needs to communicate with the previous forwarding node (for the first hop forwarding node, the last forwarding node).
  • the data packets sent by the forwarding node are decapsulated and then encapsulated, and the outermost network packet header in the re-encapsulated header field is written in the forwarding order of the forwarding node, its own address, and the next hop.
  • the address of the forwarding node is not limited to the forwarding node.
  • a forwarding node When a forwarding node receives the data packet sent by the previous forwarding node, it knows that it is the last hop according to the forwarding sequence in the header field in the data packet, then the forwarding node removes all the header fields and obtains the initial target data packet , and then the last-hop forwarding node sends the obtained target data packet to the destination device.
  • the source device and each forwarding node realize the sending of the target data packet based on the forwarding sequence between the forwarding nodes encapsulated in the header field.
  • the forwarding node does not need to maintain any table entry, avoids interaction and update with the controller, and all forwarding states are inside the data packet, reducing maintenance costs.
  • the first forwarding node receives the header field-encapsulated data sent by the source device After the packet, it is known from the forwarding order of the forwarding nodes included in the header field that it is not only the first hop forwarding node, but also the last hop forwarding node, then the forwarding node will delete the header field and delete it.
  • the target packet in the header field is sent to the destination device.
  • how the target data packet is sent to the destination device via the forwarding node when only one forwarding node is included in the path information, that is, no matter how many forwarding nodes are included in the path information it can be realized based on
  • the sequential forwarding sequence between the forwarding nodes encapsulated in the header field achieves the purpose of sending the target data packet to the destination device, and has wide applicability.
  • the source device directly sends the target data The packet is sent to the destination device.
  • the generation of the first extended DNS request may have multiple triggering forms.
  • the first extended DNS request may be generated through an SDK (terminal) installed on the source device.
  • software suite which can be called by an application), specifically, an application installed on the source device initiates a session request, for example, a session request for a browser application to access www.huawei.com, and the session request triggers the source device to call the SDK Generate a first extended DNS request;
  • the first extended DNS request may also be a software module written in advance in the application, when the application installed on the source device initiates a session request, the session request will trigger the source
  • the terminal device invokes the software module in the application to generate the first extended DNS request; as another example, by rewriting the existing communication protocol, the rewritten new communication protocol can support the generation of the first extended DNS request.
  • the present application does not limit the specific implementation manner of how to trigger the generation of the first extended DNS request, which will not be illustrated here.
  • the implementation manner of the source-end device sending the first extended DNS request to the controller may specifically be: the source-end device first sends the generated first extended DNS request to the source-end device The DNS server corresponding to the device sends the received first extended DNS request to the controller.
  • a specific implementation manner for the source device to obtain the first extended DNS response sent by the controller may be: the controller first sends the generated first extended DNS response to the DNS server corresponding to the source device, and then the controller sends the generated first extended DNS response to the DNS server corresponding to the source device, The source device receives the first extended DNS response sent by the DNS server.
  • the data interaction between the source end device and the controller is performed via the DNS server corresponding to the source end device, which is achievable.
  • the first path request includes at least any one of the following information:
  • the address of the destination device to which the data to be sent is destined (that is, the destination address described above), the application type of the data to be sent (for example, real-time audio and video applications, game applications, browser applications, etc.), the type of application to be sent
  • the application ID of the data (for example, it can be the application identifier maintained by the overlay network operator)
  • the service type of the data to be sent for example, the data stream is real-time audio and video data, game instruction data, web page request data, etc.)
  • QoS requirements of the data to be sent eg, QoS performance required by the data to be sent
  • a first path type required to be used by the data to be sent e. QoS performance required by the data to be sent.
  • the controller can plan the path information to select the optimal path suitable for the current data to be sent. applicability.
  • the first path type includes at least any one of the following types: an overlay network path, an SRv6 path, or a service function chain (SFC) path.
  • the routed path is forwarded through the overlay network;
  • the first path type is an SRv6 path, then the routed path is forwarded through SRv6;
  • the first path type is SFC
  • a typical network application scenario of SFC path is: a data flow usually needs to pass through multiple network service devices (such as intrusion detection system, intrusion prevention system, firewall, LB, etc. ), and finally the destination device can be reached. This is the most commonly used scenario of SFC. Specifically, this application does not illustrate the possible existence of the first path type.
  • the types of the forwarding nodes involved are different depending on the path type.
  • the forwarding node when the first path type is an overlay network path, the forwarding node is a PoP; If the type is an SRv6 path, the forwarding node is an SRv6 router; when the first path type is an SFC path, the forwarding node is a hardware device that supports SFC.
  • the type of the forwarding node is related to the path type, which is not repeated here.
  • a definition method may be an extension of the extended DNS protocol standard (that is, adding a new extension field).
  • different path requests are pre-defined in the extension field of the pseudo resource record of the extended DNS request, and the extension field is pre-defined. It can be obtained by applying to the Internet Assigned Numbers Agency; another definition method can also be compatible with existing standard protocols.
  • different path requests are pre-defined in the type field of the standard resource record of the extended DNS request.
  • a second aspect of the embodiments of the present application further provides a routing method, which includes: first, the source-end device sends a first Http request to an Http DNS server, where the first Http request includes a first path request, and the first path request It is used to indicate the path through which the subsequent source-end device sends data packets to the destination-end device (that is, instructing the source-end device to send data packets to the destination-end device).
  • different path requests are pre-defined in the Http request, and the definition process does not involve standards, so there is no need to apply to the institution.
  • the source device After the source device sends the first Http request to the Http DNS server, it will then obtain the first Http response sent by the Http DNS server.
  • the first Http response is generated by the Http DNS server, and the first Http response includes the Path information corresponding to a path request, the path information is obtained by the Http DNS server by performing a matching query according to the information in the first Http request.
  • the path information when the value of the path information is not empty, the path information includes the forwarding nodes between the source device and the destination device and the forwarding sequence of the forwarding nodes.
  • the source-end device sends the target data packet to be sent to the destination-end device via the forwarding node (that is, the forwarding node included in the path information) according to the forwarding sequence.
  • the forwarding node that is, the forwarding node included in the path information
  • the default sequential forwarding order is forwarded by the one forwarding node, and when the number of forwarding nodes is n (n ⁇ 2), it is the normal sequential forwarding order.
  • the request for the path and the response to the path request (that is, the path information planned by the Http DNS server) are carried in the Http request and the Http response respectively, so as to provide access for applications on the source device
  • the control capability of the path of the destination device Specifically, first, the source device carries the path request in the Http request and sends it to the Http DNS server.
  • the Http DNS server plans the path based on the received Http request, and carries the planned path information in the Http response to the source device.
  • the source end device sends the target data packet to the target end device according to the specific content of the path information (for example, including several forwarding nodes, the forwarding sequence between the forwarding nodes, etc.).
  • the embodiment of the present application uses Http request and Http response as the medium, configures the path information in the Http response to initiate SR from the real data source, and configures the end-to-end transmission path for Internet transmission at the terminal, which improves the routing efficiency and improves the Internet Business end-to-end performance.
  • the source device responds to the received first Http
  • the process of parsing the response, and sending the target data packet to be sent to the destination device in the forwarding order through the forwarding node included in the path information may be as follows: first, the source device sends the target data packet to the target data packet according to the obtained path information.
  • a data packet (which may be referred to as a first data packet) encapsulated with a header field (which may be referred to as a first header field), where the first header field includes the forwarding sequence of the forwarding node, the source address of the source device, and The address of the first-hop forwarding node, after which the source device sends the first data packet to the first-hop forwarding node, and the first-hop forwarding node judges itself according to the forwarding sequence of the forwarding nodes included in the first header field Whether it is the last hop forwarding node, if the first hop forwarding node is not the last hop forwarding node, in this case, after the first forwarding node decapsulates the first header field of the first data packet, Then re-encapsulate the target data packet to obtain a data packet (which may be called a second data packet) with a header field (which may be called a second header field) encapsulated by the first forwarding node.
  • a data packet which may be called a second
  • the second data packet is It includes the forwarding sequence of the forwarding nodes, the address of the first-hop forwarding node, and the address of the second-hop forwarding node.
  • the first-hop forwarding node sends the second data packet to the forwarding node according to the forwarding sequence of the forwarding nodes.
  • the second hop forwarding node sends.
  • the second-hop forwarding node determines whether it is the last-hop forwarding node according to the forwarding sequence of the forwarding nodes included in the second header field in the second data packet, if the second-hop forwarding node is the last forwarding node.
  • the second-hop forwarding node decapsulates the second header field of the second data packet (that is, deletes the second header field of the second data packet) to obtain the initial target
  • the second-hop forwarding node sends the target data packet with the second header field deleted to the destination device.
  • each other forwarding node needs to communicate with the previous forwarding node (for the first hop forwarding node, the last forwarding node).
  • the data packets sent by the forwarding node are decapsulated and then encapsulated, and the outermost network packet header in the re-encapsulated header field is written in the forwarding order of the forwarding node, its own address, and the next hop.
  • the address of the forwarding node is not limited to the forwarding node.
  • a forwarding node When a forwarding node receives the data packet sent by the previous forwarding node, it knows that it is the last hop according to the forwarding sequence in the header field in the data packet, then the forwarding node removes all the header fields and obtains the initial target data packet , and then the last-hop forwarding node sends the obtained target data packet to the destination device.
  • the source device and each forwarding node realize the sending of the target data packet based on the forwarding sequence between the forwarding nodes encapsulated in the header field.
  • the forwarding node does not need to maintain any table items, avoiding interaction and updating with the Http DNS server, and all forwarding states are inside the data packet, reducing maintenance costs. .
  • the first forwarding node receives the header field-encapsulated data sent by the source device After the packet, it is known from the forwarding order of the forwarding nodes included in the header field that it is not only the first hop forwarding node, but also the last hop forwarding node, then the forwarding node will delete the header field and delete it.
  • the target packet in the header field is sent to the destination device.
  • how the target data packet is sent to the destination device via the forwarding node when only one forwarding node is included in the path information, that is, no matter how many forwarding nodes are included in the path information it can be realized based on
  • the sequential forwarding sequence between the forwarding nodes encapsulated in the header field achieves the purpose of sending the target data packet to the destination device, and has wide applicability.
  • the source-end device directly sends the target data The packet is sent to the destination device.
  • the generation of the first Http request may have multiple triggering forms.
  • the first Http request may be generated through an SDK installed on the source device, specifically , the application installed on the source device may initiate a session request, and the session request triggers the source device to call the SDK to generate the first extended DNS request; as another example, the first Http request may also be pre-written in the application Software module, when the application installed on the source device initiates a session request, the session request will trigger the source device to call the software module in the application to generate the first Http request; Rewriting, so that the new communication protocol obtained by rewriting can support generating the first Http request.
  • the present application does not limit the specific implementation manner of how to trigger the generation of the first Http request, which will not be illustrated here.
  • the first path request includes at least any one of the following information: the address of the destination device to which the data to be sent is destined (that is, the destination address described above), the address of the destination device to be sent
  • the type of application that sends the data for example, real-time audio and video applications, game applications, browser applications, etc.
  • the application ID of the data to be sent for example, it can be the application identifier maintained by the overlay network operator
  • the application ID to be sent The service type of the data (for example, the data stream is real-time audio and video data, game instruction data, web page request data, etc.), the QoS requirements of the data to be sent (for example, the QoS performance required for the data to be sent), the data to be sent
  • the controller can plan the path information to select the optimal path suitable for the current data to be sent. applicability.
  • the first path type includes at least any one of the following types: an overlay network path, an SRv6 path, or an SFC path.
  • the types of the forwarding nodes involved are different in different path types.
  • the forwarding node when the first path type is an overlay network path, the forwarding node is PoP; when the first path type is an overlay network path, the forwarding node is PoP; If the type is an SRv6 path, the forwarding node is an SRv6 router; when the first path type is an SFC path, the forwarding node is a hardware device that supports SFC.
  • the type of the forwarding node is related to the path type, which is not repeated here.
  • a third aspect of the embodiments of the present application further provides a routing method.
  • the method includes: first, the controller obtains a first extended DNS request sent by a source device, where the first extended DNS request includes a first path request, and the first extended DNS request includes a first path request.
  • a path request is used to indicate the path through which the source-end device sends data packets to the destination-end device (that is, instructing the source-end device to send data packets to the destination-end device).
  • the path request is defined in advance in the field of the resource record of the extended DNS request, and can be implemented in a variety of ways. For some standard protocols, this application does not limit the specific implementation manner of defining different path requests in the fields of the resource record of the extended DNS request.
  • the controller may perform a matching query according to the information in the first extended DNS request to obtain path information corresponding to the first path request. After obtaining the path information based on the first extended DNS request, the controller sends the first extended DNS response to the source device, and the path information is included in the first extended DNS response.
  • the path information includes the forwarding nodes between the source device and the destination device and the forwarding sequence of the forwarding nodes. So that the source end device sends the target data packet to be sent to the destination end device via the forwarding node (that is, the forwarding node included in the path information) according to the forwarding sequence. It should be noted that when there is one forwarding node, the default sequential forwarding order is forwarded by this one forwarding node. When there are n forwarding nodes (n ⁇ 2), it is the normal sequential forwarding order.
  • the request for the path and the response to the path request are carried in the extended DNS message, so as to provide the application on the source device with access to the destination device. control of the path.
  • the controller plans a path based on the received extended DNS request, where the extended DNS request contains a request for the path (ie, the first path request), and carries the planned path information in the extended DNS response to the source end device, and then the source end device sends the target data packet to the target end device according to the specific content of the path information (eg, including several forwarding nodes, the forwarding sequence between the forwarding nodes, etc.).
  • This embodiment of the present application uses the extended DNS message as the medium, configures the path information in the response message in the extended DNS message to initiate SR from the real data source, and configures the end-to-end transmission path for Internet transmission at the terminal, which improves the Routing efficiency, and improve the end-to-end performance of Internet services.
  • the source device directly sends the target data The packet is sent to the destination device.
  • the implementation manner for the controller to obtain the first extended DNS request sent by the source device may specifically be: the source device first sends the generated first extended DNS request to the The DNS server corresponding to the source device sends the request, and the controller then receives the first extended DNS request sent by the DNS server.
  • the specific implementation manner for the controller to send the first extended DNS response to the source device may be as follows: the controller first sends the generated first extended DNS response to the DNS server corresponding to the source device, and then the controller sends the generated first extended DNS response to the DNS server corresponding to the source device, and then the The DNS server sends the first extended DNS response to the source device.
  • the data interaction between the source end device and the controller is performed via the DNS server corresponding to the source end device, which is achievable.
  • a fourth aspect of the embodiments of the present application further provides a routing method, the method includes: first, the Http DNS server obtains a first Http request sent by a source device, where the first Http request includes a first path request, and the first Http request
  • the path request is used to indicate the path through which the subsequent source-end device sends data packets to the destination-end device (that is, instructing the source-end device to send data packets to the destination-end device).
  • different paths The request is defined in the Http request in advance, and the definition process does not involve standards, so there is no need to apply to the agency.
  • the Http DNS server can perform a matching query according to the information in the first Http request to obtain path information corresponding to the first path request.
  • the Http DNS server After the Http DNS server obtains the path information based on the first Http request, it will send the first Http response to the source device, and the path information is included in the first Http response.
  • the path information when the value of the path information is not empty, the path information includes the forwarding nodes between the source device and the destination device and the forwarding sequence of the forwarding nodes.
  • the source end device sends the target data packet to be sent to the destination end device via the forwarding node (that is, the forwarding node included in the path information) according to the forwarding sequence.
  • the forwarding node that is, the forwarding node included in the path information
  • the default sequential forwarding order is forwarded by this one forwarding node.
  • n forwarding nodes it is the normal sequential forwarding order.
  • the request for the path and the response to the path request (that is, the path information planned by the Http DNS server) are carried in the Http request and the Http response respectively, so as to provide access for applications on the source device
  • the control capability of the path of the destination device Specifically, first, the source device carries the path request in the Http request and sends it to the Http DNS server.
  • the Http DNS server plans the path based on the received Http request, and carries the planned path information in the Http response to the source device.
  • the source end device sends the target data packet to the target end device according to the specific content of the path information (for example, including several forwarding nodes, the forwarding sequence between the forwarding nodes, etc.).
  • the embodiment of the present application uses Http request and Http response as the medium, configures the path information in the Http response to initiate SR from the real data source, and configures the end-to-end transmission path for Internet transmission at the terminal, which improves the routing efficiency and improves the Internet Business end-to-end performance.
  • the source device directly sends the target data The packet is sent to the destination device.
  • a fifth aspect of the embodiments of the present application provides a terminal device.
  • the terminal device has a function of implementing the method of the first aspect or any of the possible implementation manners of the first aspect. This function can be implemented by hardware or by executing corresponding software by hardware.
  • the hardware or software includes one or more modules corresponding to the above functions.
  • a sixth aspect of the embodiments of the present application further provides a terminal device.
  • the terminal device has a function of implementing the method of the second aspect or any of the possible implementation manners of the second aspect. This function can be implemented by hardware or by executing corresponding software by hardware.
  • the hardware or software includes one or more modules corresponding to the above functions.
  • a seventh aspect of the embodiments of the present application further provides a controller, where the controller has a function of implementing the third aspect or the method of any possible implementation manner of the third aspect.
  • This function can be implemented by hardware or by executing corresponding software by hardware.
  • the hardware or software includes one or more modules corresponding to the above functions.
  • An eighth aspect of the embodiments of the present application further provides an Http DNS server, where the Http DNS server has the function of implementing the method of the fourth aspect or any one of the possible implementation manners of the fourth aspect.
  • This function can be implemented by hardware or by executing corresponding software by hardware.
  • the hardware or software includes one or more modules corresponding to the above functions.
  • a ninth aspect of an embodiment of the present application provides a terminal device, which may include a memory, a processor, and a bus system, wherein the memory is used to store a program, and the processor is used to call the program stored in the memory to execute the first aspect of the embodiment of the present application Or the method of any possible implementation manner of the first aspect, or the processor is configured to call the program stored in the memory to execute the method of the second aspect or any possible implementation manner of the second aspect of the embodiments of the present application.
  • a tenth aspect of an embodiment of the present application provides a controller, which may include a memory, a processor, and a bus system, wherein the memory is used to store a program, and the processor is used to call the program stored in the memory to execute the third aspect of the embodiment of the present application or any one of the possible implementations of the third aspect.
  • An eleventh aspect of an embodiment of the present application provides an Http DNS server, which may include a memory, a processor, and a bus system, wherein the memory is used to store a program, and the processor is used to call the program stored in the memory to execute the first embodiment of the present application.
  • a twelfth aspect of the present application provides a computer-readable storage medium, where instructions are stored in the computer-readable storage medium, and when the instructions are executed on a computer, the computer can execute the first aspect or any one of the first aspects.
  • a thirteenth aspect of the embodiments of the present application provides a computer program or computer program product, which, when the computer program or computer program product runs on a computer, enables the computer to execute the first aspect or any possible implementation manner of the first aspect method, or, so that the computer can execute the method of the second aspect or any possible implementation of the second aspect, or, so that the computer can execute the method of the third aspect or any possible implementation of the third aspect, or , so that the computer can execute the method of the fourth aspect or any possible implementation manner of the fourth aspect.
  • a fourteenth aspect of an embodiment of the present application provides a chip, the chip includes at least one processor and at least one interface circuit, the interface circuit is coupled to the processor, and the at least one interface circuit is configured to perform a transceiving function and send an instruction
  • at least one processor is used to run a computer program or instruction, which has the function of implementing the method as described above in the first aspect or any possible implementation manner of the first aspect, or, has the function of implementing the method as described above in the second aspect or The function of the method in any possible implementation manner of the second aspect, or, having the function of implementing the method as described in the third aspect or any possible implementation manner of the third aspect, or, having the function of realizing the above-mentioned fourth aspect or the fourth aspect
  • the function of the method of any possible implementation manner of the aspect the function can be realized by hardware, can also be realized by software, and can also be realized by a combination of hardware and software, and the hardware or software includes one or more modules corresponding to the above functions .
  • the interface circuit is used to communicate with other modules other than the chip.
  • the interface circuit can encapsulate the path information obtained by the on-chip processor to the destination device, for example, send it to other terminal devices (such as , mobile phones, personal computers, smart watches, etc.) or cloud-side devices (such as cloud servers, clusters, etc.).
  • terminal devices such as , mobile phones, personal computers, smart watches, etc.
  • cloud-side devices such as cloud servers, clusters, etc.
  • Fig. 1 is a schematic diagram of a traditional DNS resolution process
  • Fig. 2 is a schematic diagram of standard DNS message format
  • Fig. 3 is a schematic diagram of the pseudo resource record in the extended DNS message
  • Fig. 4 is a schematic diagram of the relationship between each part in the pseudo-resource record in the extended DNS message
  • Fig. 5 is a schematic diagram of the GSLB request process based on intelligent DNS
  • Fig. 6 is an application scene diagram of Internet Overlay technology
  • Fig. 7 is a frame structure diagram of three subsystems of existing Overlay intelligent routing
  • FIG. 8 is a schematic flowchart of a routing method provided by an embodiment of the present application.
  • Fig. 9 is a schematic diagram of the standard resource record format in the DNS protocol.
  • Figure 10 is an example of a standard resource record
  • FIG. 11 is a schematic diagram of an encapsulation format of a data packet provided by an embodiment of the application.
  • FIG. 12 is a schematic diagram of another encapsulation format of a data packet provided by an embodiment of the present application.
  • FIG. 13 is a schematic diagram of a process of transferring a data packet between forwarding nodes according to an embodiment of the present application
  • FIG. 14 is a schematic diagram of a scenario of an overall flow of a routing method provided by an embodiment of the present application.
  • Figure 15 is a schematic diagram of each PoP provided for this embodiment of the application decapsulating, re-encapsulating and forwarding the target data packet;
  • FIG. 16 is a schematic diagram of compatibility analysis provided by an embodiment of the present application.
  • FIG. 17 is another schematic flowchart of a routing method provided by an embodiment of the present application.
  • 18 is a schematic diagram of a comparison between the routing method provided by the embodiment of the present application and the DNS resolution solution of traditional Internet transmission;
  • FIG. 19 is an experimental topology diagram provided by this embodiment of the application.
  • FIG. 20 is a schematic diagram of time delay distribution between any two points provided by an embodiment of the present application.
  • FIG. 21 is a comparison diagram of the variation curves of the time delay with the distance of the four methods under the scenarios where the number of PoP points are 100, 200, and 500 respectively provided by the embodiment of the present application;
  • Fig. 22 is a schematic flow chart of the back-to-source request between the user and the server to establish a connection by means of an edge proxy server;
  • FIG. 23 is a schematic structural diagram of a terminal device provided by an embodiment of the present application.
  • FIG. 24 is another schematic structural diagram of a terminal device provided by an embodiment of the present application.
  • FIG. 25 is a schematic structural diagram of a controller provided by an embodiment of the present application.
  • FIG. 26 is a schematic structural diagram of the Http DNS server provided by the embodiment of the present application.
  • FIG. 27 is a schematic structural diagram of a computer device provided by an embodiment of the present application.
  • Embodiments of the present application provide a routing method and device, which are used to provide an application on a source device with a control capability of accessing a path of a destination device, extend the SR domain to the terminal device, and initiate SR from the real data source, Configure an end-to-end transmission path for Internet transmission at the terminal, which improves routing efficiency and improves the end-to-end performance of Internet services.
  • DNS Domain Name System
  • DNS is a service of the Internet. It is a distributed database that maps domain names and IP addresses to each other, making it easier for people to access the Internet.
  • DNS is a system for resolving the naming of online machines on the Internet.
  • the traditional DNS domain name resolution process is: when a user accesses a website through a terminal device (also called a source device), he needs to first pass the DNS server ( A server used to provide domain name resolution services) to obtain the IP address of the website. Domain name resolution is usually not done at one time, and it is often necessary to query several different DNS servers to find the IP address corresponding to the website.
  • Figure 1 is a schematic diagram of a traditional DNS resolution process.
  • the user first configures the address of a local DNS server on the local source device, and the local DNS server receives the DNS request sent by the user through the source device. If the local DNS server cannot resolve the DNS request, the DNS request will be forwarded to a higher-level DNS server (eg, a DNS root server) until an IP address corresponding to the domain name is found or it is determined that the domain name does not exist.
  • a higher-level DNS server eg, a DNS root server
  • Domain Name-Implementation and Standards defines two kinds of messages, one is a query message (also called a DNS request), and the other is a response to a query message, called a response message (also called a DNS request). called a DNS response).
  • Both the DNS request and the DNS response use the same message format and are divided into 5 segments (some segments may be empty under different circumstances), as shown in Figure 2, which is a standard DNS message format
  • the schematic diagram in which the Header segment must exist, it defines whether the type of DNS message is DNS request or DNS response, and also defines whether other segments need to exist, and whether it is a standard query or others;
  • the Question segment describes the query problem, Including query type (QTYPE), query class (QCLASS), and query domain name (QNAME); the remaining three segments have the same format, specifically, a series of possibly empty resource records (resource records, RR) If there are multiple resource records, they are recorded as RRs.
  • the Answer segment contains the RRs that answer the question
  • the Authority segment contains the RRs that authorize the domain name server
  • the Additional segment contains the RRs that are related to the request but not required to be answered.
  • extended DNS message can be called extended DNS message, similar to DNS message, extended DNS message also includes two kinds of messages, one is called extended DNS request, and the other is the response to extended DNS message, called Extended DNS response, extended DNS message is to add some fields to the existing DNS message format to support more DNS request services.
  • extended DNS message is to add some fields to the existing DNS message format to support more DNS request services.
  • FIG. 3 is a schematic diagram of the pseudo resource record in the extended DNS message, wherein, sub-schematic diagram (a) in FIG.
  • the NAME field is currently empty
  • the TYPE field is the type number of the pseudo resource record, the Internet Assigned Numbers Authority (IANA) It is assigned 41 (0x29)
  • the TTL field is the header of the extended DNS message, which will be introduced below
  • the RDLEN field is the length of the variable part RDATA
  • RDATA is the variable part of the KV type.
  • the original TTL field is used to store the RCODE and flags in the header of the extended message. Its format is shown in the sub-schematic diagram (b) in Figure 3.
  • the high-order 8 bits It is the extended RCODE (return status code). These 8 bits plus the 4 bits of the DNS header have a total of 12 bits (8 bits are in the high order), so that more return types can be represented; the VERSOION field represents the version of the extended DNS message (extended There will be many versions of DNS packets according to different extensions supported).
  • the extended DNS message the structure of the variable part of the RDATA field is shown in sub-schematic (c) in Figure 3.
  • the relationship among the sub-schematic diagrams in FIG. 3 may be as shown in FIG. 4 . It should be noted that there can only be one pseudo resource record in each DNS message. When there are multiple extended DNS protocols, each ⁇ attribute, value ⁇ pair is stored in the RDATA field one by one.
  • the GSLB request process based on smart DNS is shown in Figure 5.
  • the root DNS server (referred to as root DNS in Figure 5) will forward the DNS request to the GSLB device (ie, the DNS-based GSLB in Figure 5).
  • the load situation and the user's IP information resolve the optimal IP address for the user, put it in the DNS response and reply to the local DNS server, and the local DNS server will finally return the DNS response to the user.
  • the first method solves the control of the application on the source device to the destination of the user request (ie, the destination device), but cannot control the path accessed by the destination. For example, if the application on the source device considers its own requirements (such as security considerations, performance considerations, etc.), and wants to further optimize the path requested by the user, this method cannot meet the requirements.
  • the Internet Since the Internet is composed of multiple operators/internet service providers (ISPs)/autonomous domains, there is a complex commercial relationship in the interconnection between domains, and the transmission path of the Internet is affected by commercial relationships, which are often not the shortest path. For example, transmissions between two Asian nodes may be detoured to Europe, increasing end-to-end latency. At the same time, because Internet routing is not aware of path performance, failure or congestion in the path is often difficult to avoid, or it takes a long time to converge.
  • ISPs operators/internet service providers
  • FIG. 6 is an application scenario diagram of the Internet Overlay technology.
  • the default link between the source device and the destination device is the path shown by the dotted line.
  • the cross-domain link between domain B and domain B is currently facing severe congestion, so routing according to the default link will lead to end-to-end performance degradation.
  • PoPs are deployed in Domain A, Domain B, and Domain C, respectively.
  • the PoP deployed on Domain A is called PoP1
  • the PoP deployed on Domain B is called PoP2
  • the PoP deployed on Domain C is called PoP2.
  • SDK software development kit
  • the overlay backbone network controls the route from PoP1 to PoP3 as PoP1 ⁇ PoP2 ⁇ PoP3, thereby effectively bypassing the congested link between domain A and domain B and improving the overall end-to-end performance.
  • Overlay intelligent routing is the key to the overlay technology, which directly determines the transmission performance of users accessing the overlay network.
  • Overlay intelligent routing selects a suitable Overlay network forwarding node PoP for user transmission to form an end-to-end optimal forwarding path.
  • the existing Overlay intelligent routing solution is jointly implemented by three subsystems, which are respectively: an ingress PoP selection system, an egress PoP selection system, and an overlay network internal routing system. The three subsystems are described below.
  • the system selects the optimal entry PoP as the first hop to access the Overlay network according to the source address of the source device used by the user.
  • the source device sends data packets through the SDK deployed on the source device.
  • To access the overlay network first, the source device sends a session request to the ingress PoP selection system, reporting the source address of the source device, and the ingress PoP selection system selects the optimal ingress PoP IP for the user session by matching the source address.
  • the selection principle follows the nearest access principle, that is, the user selects the entry PoP closest to the source device, and the mapping relationship between the source address of the source device and the IP address of the entry PoP can be called "source IP-entry".
  • PoP PoP
  • the source device After the source device obtains the IP address of the ingress PoP, the source device encapsulates a new outer network header outside the original network layer data packet.
  • the IP is written as the IP address of the ingress PoP, and the encapsulated data packets are sent to the Underlay network for transmission. It should be noted here that the data transmission process is still based on the Underlay network, and the PoP in the overlay network is only used to indicate which domain to send the data packet to.
  • FIG. 7 is a frame structure diagram of three subsystems of existing Overlay intelligent routing.
  • the source device obtains the address of the nearest entry PoP from the entry PoP selection system (denoted as PoP1 IP), after the acquisition, the source device writes the PoP1 IP into the outermost network header of the data packet, the destination IP is the PoP1 IP, and the source IP remains unchanged.
  • PoP1 IP the entry PoP selection system
  • the system selects the egress PoP as the last hop of the overlay network according to the IP address of the destination device.
  • the system selection principle is usually the principle of proximity, that is, the user selects the IP address of the PoP closest to the destination device, and the mapping relationship between the IP address of the destination device and the IP address of the egress PoP can be called "destination IP-egress PoP" "Mapping table, the mapping table is issued by the egress PoP selection system to the egress PoP (in some implementations, the above-mentioned "source IP-ingress PoP" mapping table and "destination IP-egress PoP” mapping table can be merged into one The table is distributed to the ingress PoP and the egress PoP respectively by the ingress PoP selection system and the egress PoP selection system).
  • the ingress PoP decapsulates the outermost network packet header, and compares the IP address of the destination end of the original data packet with the "destination IP-egress PoP" mapping table to obtain the IP address of the egress PoP, and then The ingress PoP encapsulates the header field outside the original network layer data packet, and writes the IP address of the egress PoP.
  • PoP1 unpacks the outer layer to obtain the IP address of the destination device of the original data packet.
  • This address and the "destination IP-egress PoP" mapping table maintained by PoP1 (the "source IP-ingress PoP" mapping table and the "destination IP-egress PoP” mapping table can be combined into one table and combined into one table ) to compare, and obtain that the nearest exit PoP of the IP address of the destination device is PoP3, and then write the IP address of PoP3 into the exit PoP field.
  • the system selects the next-hop PoP forwarding point according to the IP address of the egress PoP.
  • the system performs PoP-level routing in the Overlay network by delivering routing tables to each intermediate PoP node.
  • the routing table matches the egress PoP and returns to the next hop PoP.
  • the PoP removes the outermost network packet header, and selects the next hop PoP according to the egress PoP address in the header field. After selection, the IP address of the next hop PoP is written in the outermost network packet header. .
  • PoP1-PoP2-PoP3 the optimal route is calculated by the routing subsystem inside the Overlay network.
  • the routing table finds that the next hop is PoP2, and then encapsulates the IP address of PoP2 into the destination IP of the outermost network header, and sends it to the Underlay network.
  • PoP2 PoP2 receives the data packet, unpacks the outer layer, matches the exit PoP, and obtains the next hop PoP3, which is further encapsulated by the PoP2 and sent to PoP3.
  • PoP3 After PoP3 receives the data packet, it finds that it is the last hop.
  • PoP3 removes all the outer encapsulation, sends the original data packet to the Underlay network, and sends the data packet to the destination device according to the final destination IP.
  • the disadvantage of the routing method of the second mode is that each subsystem independently optimizes the path independently, but the local optimal decision is not equal to the end-to-end global optimal decision. Specifically, selecting the optimal ingress/egress PoP (that is, closest to the source device/destination device) is not necessarily optimal end-to-end. As shown in Figure 7, it is assumed that the optimal end-to-end path is source-end device ⁇ PoP2 ⁇ destination-end device, but since the second method is independent optimization of each subsystem, no matter what the path selected by the system is, at least There are at least 2 PoPs including the ingress PoP and the egress PoP, so that the optimal path of source device ⁇ PoP2 ⁇ destination device cannot actually be obtained.
  • each subsystem in the second method maintains its own state, and each PoP node needs to deploy a mapping table or routing table issued by the corresponding subsystem.
  • each PoP node needs to deploy a mapping table or routing table issued by the corresponding subsystem.
  • SR is a source-based routing technology that simplifies traffic engineering and management across network domains.
  • the source host/router, etc. according to multiple different subnets or intranet addresses, add relevant routing information to the packet header to plan the forwarding path for the packet, so that the data plane in the network can selectively send the packet to different destination.
  • the main advantage of SR lies in its ability to simplify the network and reduce resource consumption.
  • the technology can eliminate the network state information of the transition routers and nodes in the network, and put the path state information into the packet header of the ingress node, so that the network management and easier to operate.
  • SR can globally optimize network paths through a centralized controller, while simplifying the maintenance of intermediate node forwarding states.
  • this technology currently only works inside the network, such as routers, switches or PoPs, and cannot apply SR technology to user terminals, such as mobile phones or PCs.
  • the main difficulty in applying SR on the terminal is the control of the SR domain, which is reflected in poor controllability and high dynamics.
  • controllability terminal manufacturers are different, the kernel protocol stack is uncontrollable, and the network transmission process involves a large number of operators/ISPs or cloud backbones, so overall control cannot be achieved.
  • the central controller is configured to the corresponding forwarding device through the PCEP protocol or the Openflow protocol, which is relatively static and easy to update.
  • the embodiments of the present application first provide a routing method, which is used to provide the application on the source device with the control capability of accessing the path of the destination device, and extend the SR domain to the terminal device , SR is initiated from the real data source, and the end-to-end transmission path is configured at the terminal for Internet transmission, which improves the routing efficiency and improves the end-to-end performance of Internet services.
  • FIG. 8 is a schematic flowchart of a routing method provided by an embodiment of the present application, which may specifically include the following steps:
  • the source device sends a first extended DNS request to a controller, where the first extended DNS request includes a first path request.
  • the source device will send a first extended DNS request to the controller, the first extended DNS request includes a first path request, and the first path request is used to instruct the subsequent source device to send data packets to the destination device. What path is passed at the time (that is, the method used to indicate the source device to send the data packet to the destination device).
  • the first path request includes relevant information for determining a routing path. If the information included in the first path request is different, the path information planned by the controller based on the first path request is also different. .
  • the first path request includes at least any one of the following information: the address of the destination device to which the data to be sent is destined (that is, the destination address described above), the application type of the data to be sent, the data to be sent The application ID of the data to be sent, the service type of the data to be sent, the QoS requirements of the data to be sent, and the type of the first path required to be used by the data to be sent. The following are respectively introduced:
  • the address of the destination device to which the data to be sent is destined that is, the destination address, which can be a specific IP address or URL (the address can also be stored in the QUESTION field in the extended DNS request).
  • the application type of the data to be sent for example, real-time audio and video applications, game applications, browser applications, etc.
  • the division method for application types may be based on terminal devices from The "App Market", “App Store”, etc. of the terminal device (the manufacturer of the terminal device may have a different name, which is not limited here)
  • the application market has already classified each application (that is, the application The classification information determined by the market label, each application downloaded from the application market has its own classification).
  • the application ID of the data to be sent can be the application identifier maintained by the overlay network operator. By matching the mapping, the QoS requirements and priority of the data to be sent can be known. For example, some applications have purchased the overlay network. For high-quality acceleration services, higher-quality paths will be allocated when calculating paths, and paths with lower transmission costs can be allocated when paths are allocated for low-priority applications.
  • the service type of the data to be sent is a description of the data stream to be sent.
  • the data stream to be sent is real-time audio and video data, game instruction data, web page request data, etc. Performance requirements are also different and can be taken into account when calculating paths.
  • the QoS requirement of the data to be sent is a direct description of the path performance. According to this information, the controller allocates a path that meets the QoS requirement and effectively plans resources.
  • the path type required to be used for the data to be sent (that is, the first path type), which may include an Overlay network path, an SRv6 path, or an SFC path, corresponding to different transmission scenarios.
  • the source to The destination can be transmitted using either the Overlay path or the Underlay SRv6 path. By passing this information in the path request, the corresponding path information can be obtained.
  • the routed path is forwarded through the overlay network; assuming that the first path type is an SRv6 path, then the routed path is forwarded through SRv6; assuming that the first path type is a service Chain (service function chain, SFC) path, then the routing path is forwarded through the service chain.
  • SFC service function chain
  • a typical network application scenario of the service chain path is: a data flow usually needs to pass through multiple network service devices (such as intrusion detection systems (intrusion detection systems, IDS), intrusion prevention systems (intrusion prevention systems, IPS), firewalls, LB, etc.), can finally reach the destination device, this is the most commonly used scenario of service chain, specifically this application will no longer focus on the first Indicate the form in which the path type may exist.
  • IDS intrusion detection systems
  • IPS intrusion prevention systems
  • firewalls LB, etc.
  • the information of the above categories may include one or more types in the path request, for example, only the application ID is included, and the controller maintains the corresponding matching relationship to know the category of the path request, related QoS requirements, and the like. At the same time, this information is not necessary information, and the controller can default the type of the route request, etc., which will not be described in detail here.
  • the generation of the first extended DNS request may have various triggering forms.
  • the first extended DNS request may be generated through the SDK (terminal software) installed on the source device. kit, which can be called by the application) to generate, specifically, the application installed on the source device can initiate a session request, for example, a session request for a browser application to access www.huawei.com, the session request triggers the source device to call the SDK to generate
  • the first extended DNS request may also be a software module written in advance in the application.
  • the session request will trigger the source
  • the device invokes the software module in the application to generate the first extended DNS request; as another example, by rewriting the existing communication protocol, the rewritten new communication protocol can support the generation of the first extended DNS request.
  • the present application does not limit the specific implementation manner of how to trigger the generation of the first extended DNS request, which will not be illustrated here.
  • controller described in this application can be deployed on a top-level DNS server, or can be deployed independently, and can exist in the form of a hardware device or a software module, or multiple
  • the controller implements the disaster recovery function (that is, under normal circumstances, only the main controller works, and other controllers serve as backups).
  • the specific manifestation, deployment method, and deployment quantity of the controller are not limited here.
  • path requests are defined in advance in the field of the resource record of the extended DNS request, and there can be multiple implementations, for example, it can be an extension to the extended DNS protocol standard (that is, adding a new extension). field), it can also be compatible with existing standard protocols. Specifically, this application does not limit the specific implementation of defining different path requests in the fields of the resource record of the extended DNS request.
  • the information contained in the first path request is taken as an example of the first path type, and the description is made based on two definitions of adding a new extension field and being compatible with an existing standard protocol.
  • different path types may be predefined in the extension field of the pseudo resource record of the extension DNS request, and the extension field needs to be obtained by applying to the Internet Assigned Numbers Authority (IANA) in advance.
  • IANA Internet Assigned Numbers Authority
  • the Header, Question, Answer, and Authority fields included in the extended DNS request provided by the embodiment of the present application are consistent with conventional DNS packets.
  • the destination address (which may be the destination The device's IP address, URL address, etc.) are put into the QNAME field, and the Answer field is empty.
  • the Answer field is empty.
  • a new extended field required by the application can be added normally.
  • a new RDATA related to the path request can be added after the last one.
  • the standard format of RDATA is as follows: (c) sub-schematic diagram in Figure 3.
  • Overlay is placed in OPTION-DATA, it indicates that the requested path type is a forwarding path based on the Overlay network; if SRv6 is placed in OPTION-DATA, it indicates that the requested path type is an SRv6-based forwarding path (ie It can support the source device to initiate SRv6 transmission); if SFC is placed in the OPTION-DATA, it means that the requested path type is an SFC-based forwarding path (that can support the source device to initiate SFC transmission). The path type placed in OPTION-DATA is indicated.
  • QPATH is used to indicate that the request for the path type is customized by this application, and other words or sentences can also be used to indicate the request for the path type, as long as it can be used as the unique identifier of the request for the path type.
  • the present application does not limit the specific expression form of the mark.
  • the above examples of this application directly use Overlay, SRv6, SFC, etc. to represent path types.
  • different path types can also be assigned unique corresponding identifiers, and the corresponding identifiers can also be used
  • the identifier of the path type is Overlay network
  • SFC path can be 1 (or, A, one, etc. identifiers), 2 (or, B, two, etc. identifiers), 3 (or , C, three, etc. identifiers), in this case, when the data in the OPTION-DATA is the corresponding identifier (eg, 1), it means that the corresponding path type is an Overlay network.
  • the embodiment of the present application provides a method compatible with the existing standard protocol, that is, different path types can also be predefined in the standard resource record of the extended DNS request, for example, can be defined as In the type field of standard resource records of extended DNS requests.
  • the advantage of this method is that there is no need to apply to IANA in advance.
  • FIG. 9 is a schematic diagram of a standard resource record format in the DNS protocol
  • FIG. 10 is an example of a standard resource record.
  • the TYPE field in FIG. 9 represents the resource record type, and several commonly used resource record types are shown in Table 1.
  • TYPE field Resource record type A address (address), IPv4 AAAA address, IPv6 NS domain name server SOA start of authority MX mail exchange CNAME canonical name PTR pointer txt text SRV service
  • the TXT field can be used to achieve the purpose of defining the path type. For example, in a traditional resource request, the QTYPE in the QUESTION field is assigned a type A resource request, and the server returns the IP address of the destination device in the QNAME. In this application, since the path type needs to be obtained, the TXT type can be filled in QTYPE. For the route request type, the destination device address can be expanded.
  • the format of the resource record is shown in Figure 9, where the TYPE field is TXT, NAME is the expanded destination address, and RDATA records the path information and destination
  • the IP address of the device such as ⁇ PoP1 IP, PoP2 IP, PoP3 IP, dst IP ⁇ , where PoP1 IP, PoP2 IP, and PoP3 IP are the IP addresses of PoP1, PoP2, and PoP3 respectively, and dst IP refers to the destination device's IP address. IP address.
  • the implementation manner of the source-end device sending the first extended DNS request to the controller may specifically be: the source-end device first sends the generated first extended DNS request to the source The DNS server corresponding to the end device sends, and then the DNS server sends the received first extended DNS request to the controller.
  • the DNS server may perform a recursive query on the first extended DNS request sent by the source device, and the process of the recursive query may reuse the processing flow of the conventional DNS server, which will not be repeated here.
  • the DNS server corresponding to the source device is a summary of the local DNS server, DNS root server, authoritative DNS server, top-level DNS server, etc. and send the first extended DNS request to the controller.
  • the implementation manner of making the DNS server send the first extended DNS request to the controller may be that the controller registers the authoritative DNS server, and adds the address of the controller to the DNS root server or the top-level DNS server , so that when the DNS server corresponding to the source device receives the first extended DNS request, based on the address of the registered controller and based on the recursive query process, the first extended DNS request will be sent to the controller.
  • the authoritative server address of huawei.com is registered in the .com server
  • the extended DNS request with the URL www.huawei.com is queried, the extended DNS request will be sent to the authoritative server of huawei.com (that is, the location where the controller is deployed). ).
  • the controller obtains path information corresponding to the first path request according to the first extended DNS request.
  • the controller may perform a matching query according to the information in the first extended DNS request to obtain path information corresponding to the first path request.
  • the prerequisite for the controller to obtain the path information corresponding to the first path request according to the first extended DNS request is that the controller has obtained the necessary information for planning the path (for example, the user requires less delay and packet loss.
  • the necessary information can be carried in the first extended DNS request, or can be sent by the DNS server corresponding to the source device to the controller. .
  • the necessary information can be carried in the first extended DNS request, or can be sent by the DNS server corresponding to the source device to the controller. .
  • they are described as follows:
  • the first extended DNS request already contains all the necessary information for the planned path
  • the first extended DNS request already contains all necessary information for the controller to perform path planning.
  • the controller obtains the first extended DNS request
  • the first extended DNS request After analysis, based on all necessary information contained therein, path information corresponding to the first path request can be obtained, and the path information is generally an optimal forwarding path corresponding to the first path request.
  • the first extended DNS request does not contain or only contains some necessary information for planning the path
  • the first extended DNS request does not contain necessary information for planning a path, or the first extended DNS request only contains part of the necessary information for planning a path.
  • the necessary information not included in the first extended DNS request is generally difficult or impossible for the source device to obtain. Therefore, after the source device sends the first extended DNS request to the corresponding DNS server, the The DNS server needs to collect other information necessary for planning the path for the controller (that is, the part of necessary information not included in the first extended DNS request).
  • the source address of the source device can be obtained by calling the EDNS0 extended protocol CSUBNET by the local DNS server, and then the source address is added to the first extended DNS request and sent to the controller (or sent separately).
  • the reason for obtaining the source address of the source device is not in the source device but in the local DNS server because of NAT traversal problems, and the address reported by the source device may be a private network address (source In theory, the address can also be obtained by the source device itself, but the acquisition process is difficult).
  • the private network address is useless information
  • the address obtained by the local DNS server is the public network address (that is, the source address described in this application) , it can be used for the controller to do path planning.
  • the default controller may implement the function of path planning based on the obtained necessary information.
  • the controller may be based on the existing Algorithms or self-developed algorithms are obtained, which are not limited here.
  • the controller sends a first extended DNS response to the source device, where the path information is included in the first extended DNS response, where, in the case where the value of the path information is not empty, the path information includes the source device.
  • the forwarding nodes from the device to the destination device and the forwarding sequence of the forwarding nodes.
  • the controller After obtaining the path information based on the first extended DNS request, the controller sends the first extended DNS response to the source device, and the path information is included in the first extended DNS response.
  • the implementation manner of the controller sending the first extended DNS response to the source device may specifically be as follows: the controller firstly sends the generated first extended DNS response to the source device. The DNS server corresponding to the end device sends, and then the DNS server sends the received first extended DNS response to the source end device.
  • the first extended DNS response is used as the response message of the first extended DNS request, and the return for different path requests may also be defined in advance in the field of the resource record of the extended DNS response, and there may be various implementations, such as , which can be an extension to the extended DNS protocol standard (that is, adding a new extension field), or it can be compatible with an existing standard protocol, which is not limited in this application, but it should be noted that the first extended DNS response needs to be matched with The implementation of the first extended DNS request corresponds to.
  • the information contained in the first path request is taken as an example of the first path type, and the description is based on two definitions of adding a new extension field and being compatible with an existing standard protocol.
  • different path types can be pre-defined in the extension field of the pseudo resource record of the extended DNS request, and the extension field needs to be obtained by applying to IANA in advance.
  • the return of the path type can also be pre-defined. It is defined in the extension field of the pseudo resource record of the extended DNS response, and the extension field also needs to be obtained from IANA in advance.
  • OPTION-CODE PATH (this PATH is customized, and will be disclosed after the application is approved, corresponding to the extended field OPTION-CODE: PATH in the extended DNS request), OPTION-CODE: PATH
  • the field represents the return to the path type request; and in the corresponding OPTION-DATA field, the path information of the corresponding path type is placed (for example, it can be stored in the form of a path list).
  • the corresponding OPTION-DATA is put into the path information based on the Overlay network (eg, PoP address list ⁇ PoP1 IP, PoP2 IP, PoP3 IP ⁇ ); If the requested path type is an SRv6-based forwarding path (that can support the source device to initiate SRv6 transmission), then the corresponding OPTION-DATA is put into SRv6-based path information; if the requested path type is SFC-based forwarding path (that can support the source device to initiate SFC transmission), then the corresponding OPTION-DATA is put into SFC-based path information. Specifically, this application does not illustrate the path information put into the OPTION-DATA.
  • PATH to indicate the return of the path type request
  • other words or sentences can also be used to indicate the path type request, as long as it can be used as the return of the path type request.
  • a unique identifier is sufficient, and the specific expression form of the identifier is not specifically limited in this application.
  • the path type is defined in the extended DNS request by applying to IANA in advance for a pair of new extended fields (ie OPTION-CODE: QPATH and OPTION-CODE: PATH).
  • the request message the purpose of defining the path information (ie the response message) in the extended DNS response.
  • the purpose of defining the path type in the extended DNS request and defining the path information in the extended DNS response can be achieved by applying for a new extension field from IANA in advance.
  • the OPTION-DATA in the extension field is Overlay, indicating that the requested path type is a forwarding path based on the Overlay network; if the controller sends a response message to the source device , then the OPTION-DATA in the extension field is the path information based on the Overlay network (eg, PoP address list ⁇ PoP1 IP, PoP2 IP, PoP3 IP ⁇ ).
  • the embodiment of the present application provides a method compatible with existing standard protocols, that is, the return of requests for different path types can also be pre-defined in the standard resource records of the extended DNS response, such as , which may be defined in the type field of the standard resource record of the extended DNS response.
  • the source device after obtaining the first extended DNS response, the source device directly obtains the destination address from the RATA in the ANSWER of the total response packet.
  • the advantage of this approach is that there is no need to apply to IANA in advance.
  • the specific definition method is similar to the above-mentioned method to achieve the purpose of defining the path type in the extended DNS request by being compatible with the existing standard protocol, and will not be repeated here.
  • the controller receives the extended DNS request sent by the source device, and if the OPTION-CODE is found in the RDATA of the Additional field of the extended DNS request, it is an extension of QPATH. field, indicating that the extended DNS request is the first extended DNS request containing the path type, and it is found in its OPTION-DATA that the requested path type is the path type of the Overlay network, indicating that it is a request for the Overlay network path.
  • the controller reads the source address of the source device from the OPTION-DATA in the CSUBNET extension protocol, and matches the source address and destination address (eg, URL address, IP address of the destination device, etc.) Calculate to obtain the optimal overlay path from the source device to the destination device.
  • the path information is returned through the RDATA of the Additional field.
  • the controller adds a response to the path type request in the RDATA of the Additional field of the extended DNS response ( That is, path information)
  • OPTION-CODE: PATH, OPTION-DATA is the path information representing the Overlay network, for example, it can be a PoP address list ⁇ PoP1 IP, PoP2 IP, PoP3 IP ⁇ . It should be noted that the controller has no special treatment for other fields, for example, the normal return destination address in the Answer field.
  • the planning of path information is related to the application type and application requirements of the source device (for example, whether the bandwidth is large, whether the delay is small, etc.), and the path planned by the controller generally refers to the path from the source device.
  • the optimal path to the destination device that meets the current requirements is also different. Specifically, it can be divided into the following types:
  • the path information includes the forwarding nodes between the source device and the destination device and the forwarding sequence of the forwarding nodes. It should be noted that when there is one forwarding node , then the default sequential forwarding order is forwarded by this one forwarding node. When the number of forwarding nodes is n (n ⁇ 2), it is the normal sequential forwarding order.
  • the types of forwarding nodes involved are different in different path types.
  • the forwarding node when the first path type is an overlay network path, the forwarding node is PoP; when the first path type is an overlay network path, the forwarding node is PoP; If the path type is an SRv6 path, the forwarding node is an SRv6 router; when the first path type is an SFC path, the forwarding node is a hardware device supporting the service chain.
  • the type of the forwarding node is related to the path type, which is not repeated here.
  • the source-end device sends the target data packet to be sent to the destination-end device via the forwarding node according to the forwarding sequence.
  • the source-end device parses the received first extended DNS response, and uses the path information included in the The forwarding node sends the target data packet to be sent to the destination device in the forwarding sequence.
  • the following specifically describes how to send the target data packet to be sent to the destination device via the forwarding node.
  • the number of forwarding nodes included in the path information is n (n ⁇ 2)
  • the source device encapsulates the target data packet according to the obtained path information, and obtains a data packet (which may be referred to as a first data packet) encapsulated with a header field (which may be referred to as a first header field),
  • the first header field includes the forwarding sequence of forwarding nodes, the source address of the source device, and the address of the first hop forwarding node.
  • the address of the first forwarding node may refer to the IP address of the first forwarding node, or may refer to an identifier (eg, ID) used to point to the IP address of the first forwarding node, or may be other
  • the addresses of other forwarding nodes involved in the embodiments of the present application eg, the second-hop forwarding node, the third-hop forwarding node, ..., the last-hop forwarding node, etc.
  • the addresses of other forwarding nodes involved in the embodiments of the present application eg, the second-hop forwarding node, the third-hop forwarding node, ..., the last-hop forwarding node, etc.
  • the addresses of other forwarding nodes involved in the embodiments of the present application eg, the second-hop forwarding no
  • the encapsulation methods for the source device to encapsulate the target data packet according to the obtained path information include but are not limited to:
  • the added header field contains two fields, PoP_list and OLD L3.
  • the path information eg, path list
  • the UDP header is added.
  • the encapsulation format of the data packet can be shown in Figure 12. After encapsulation, the source device will encapsulate the encapsulated data. The packet is sent to the Underlay network for forwarding.
  • the source-end device encapsulates the target data packet according to the obtained path information, and after obtaining the data packet (which may be called the first data packet) encapsulated with the header field (which may be called the first header field), it will encapsulate the first data packet.
  • the first forwarding node R1 has a pair of After the first header field of the first data packet is decapsulated, the target data packet is re-encapsulated to obtain a data packet (which may be referred to as a second header field) encapsulated by the first forwarding node R1
  • the second data packet includes the forwarding sequence of the forwarding nodes, the IP address of the first jumping forwarding node, and the IP address of the second jumping forwarding node. Please refer to FIG. 13 for details.
  • the IP address of the second-hop forwarding node is the first-hop forwarding node in FIG. 13
  • Dst R2 in the packet header of the outermost network on the R1 side
  • the second-hop forwarding node R2 decapsulates the second header field of the second data packet (that is, deletes the second header field of the second data packet), and obtains the initial target data packet (that is, only contains the original network layer header) , and the second-hop forwarding node R2 sends the target data packet with the second header field deleted to the destination device.
  • the first jump forwarding node R1 will send the encapsulated data packet (referred to as the first data packet) to the second jump Then, the second hop forwarding node R2 decapsulates the received first data packet and then encapsulates it.
  • the header field when the second hop forwarding node R2 encapsulates the target data packet includes the sequence of the forwarding nodes.
  • R-list ⁇ R1, R2,...,Rn ⁇ , the IP address of the first-hop forwarding node and the IP address of the second-hop forwarding node, the second-hop forwarding node R2 will encapsulate the The data packet (referred to as the second data packet) is sent to the next-hop forwarding node, . . . , until the data packet is sent to the last-hop forwarding node Rn.
  • R-list ⁇ R1, R2,...,Rn ⁇ , except for the last hop forwarding node Rn, every other forwarding node needs to communicate with the previous forwarding node (the first hop forwarding node).
  • the forwarding node Rn When the forwarding node Rn receives the data packet sent by the forwarding node Rn-1, it knows that it is the last hop according to the R-list in the header field of the data packet, then the forwarding node Rn removes all the header fields to obtain the initial target data packet , and then the last-hop forwarding node Rn sends the obtained target data packet to the Underlay network and sends it to the destination device.
  • the re-encapsulation of the decapsulated target data packet by each forwarding node is similar to the encapsulation process of the original target data packet by the above-mentioned source device, which may be performed at the network layer (L3).
  • message outside encapsulation, or encapsulation outside the transport layer (L4) message for details, please refer to the corresponding encapsulation methods described in FIG. 11 and FIG. 12 , which will not be repeated here.
  • the forwarding node included in the path information is 1
  • the difference from the multiple forwarding nodes included in the above path information is that: after the first forwarding node R1 receives the data packet encapsulated with the header field sent by the source device, the forwarding sequence of the forwarding nodes included in the header field is determined by the forwarding sequence.
  • R-list ⁇ R1 ⁇ knows that it is not only the first hop forwarding node, but also the last hop forwarding node, then the forwarding node R1 will delete the header field, and send the target data packet whose header field has been deleted to the Sent by the destination device.
  • This full method only needs to change the pointer item in the header field, which is easy to change, and because the number of forwarding nodes contained in the path information is generally not large, each forwarding node carries the full forwarding sequence and does not carry the forwarding order. higher computational cost.
  • the forwarding sequence between hop forwarding nodes, and in the last hop forwarding node, the carried information is empty, indicating that it is the last hop, then the last hop forwarding node will delete the header field and put the The target packet with the header field removed is sent to the destination device. This incremental method requires modification of the length of the header field.
  • the controller may directly act as an authoritative DNS server, or may be configured in a DNS proxy mode.
  • the controller described in this application can be regarded as a DNS server in essence, with the function of NS RR query and return.
  • Other DNS servers such as the local DNS server, do not need to be modified.
  • the extended DNS request with the path request will be directed to the DNS server where the controller is located. Inquire.
  • the source device generates the first extended DNS request
  • the first extended DNS request is not limited to only the source device Device generation, the generation of the first extended DNS request may also be completed by other devices, such as a DNS server, DNS proxy or other third-party devices.
  • the device After the device intercepts the traditional DNS request sent by the source device, it modifies it into an extended DNS request with a path request, and completes subsequent operations in conjunction with the controller to obtain the path information, which can be carried in the traditional DNS request directly by the
  • the controller returns to the source device, and the path information can also be carried in other responses (eg, extended DNS responses), and then sent to the source device after being relayed by other devices, which is not specifically limited in this application.
  • the request for the path and the response to the path request (that is, the path information planned by the controller) are carried in the extended DNS message, so as to provide the application on the source device with access to the destination device. control of the path.
  • the source device carries the path request in the extended DNS request and sends it to the controller.
  • the controller plans a path based on the received extended DNS request, and carries the planned path information in the extended DNS response to the source device.
  • the source end device sends the target data packet to the target end device according to the specific content of the path information (for example, including several forwarding nodes, the forwarding sequence between the forwarding nodes, etc.).
  • the extended DNS message is used as the medium
  • the path information is defined in the response message in the extended DNS message and the SR is initiated from the real data source
  • the end-to-end transmission path is defined at the terminal for Internet transmission, which improves the Routing efficiency, and improve the end-to-end performance of Internet services.
  • FIG. 14 A schematic diagram of the overall process of the routing method, the entire routing process is as follows:
  • Step 1 First, an application on the source device (eg, mobile phone) initiates a session request, for example, a browser application initiates a request to visit www.huawei.com, and the session request triggers the source device to call and deploy on the source
  • the SDK on the device generates an extended DNS request, and sends the extended DNS request to the DNS server corresponding to the source device.
  • the extended DNS request includes the first path type (assuming that the first path type is an overlay network path).
  • step 2 the DNS server performs a recursive query on the extended DNS request sent by the source device, and this step can reuse the normal processing flow of the DNS server, and send the extended DNS request to the controller.
  • the DNS server also needs to synchronously collect the data in this step. Necessary information for path planning, the collected necessary information can be added to the extended DNS request and sent to the controller again, or can be sent to the controller independently.
  • Step 3 the controller performs a matching query according to the information in the received extended DNS request. Specifically, if the controller does not find that OPTION-CODE is an extension field of QPATH in the RDATA of the Additional field (assuming that the extension field has been applied to IANA in advance), or if there is no RDATA at all, it means that this is a regular DNS report. If the controller finds the OPTION-CODE in the RDATA of the Additional field, it is QPATH
  • the extension field indicates that it is a DNS request containing the path type, and the path type is found to be an Overlay network path in its OPTION-DATA, indicating that it is a DNS request for the Overlay network path, and the controller reads the OPTION-DATA in the CSUBNET extension protocol.
  • the controller After reading the source address of the source device, the controller performs a matching calculation based on the source address and the destination address of the destination device, and obtains the optimal overlay network path for accessing the destination address from the user.
  • the path information is written to the Additional field.
  • the controller adds a new extension field OPTION-CODE: PATH after the last item in RDATA of the Additional field (assuming that the extension field has been applied to IANA in advance), and OPTION-DATA is the PoP address list representing the Overlay network path , such as ⁇ PoP1 IP, PoP2 IP, PoP3 IP ⁇ .
  • the OPTION-DATA here is the path list of other path information, that is, the path list here must correspond to the path type.
  • Step 4 the DNS server sends the received extended DNS response to the source device.
  • Step 5 the source device receives the extended DNS response sent by the DNS server, and parses the message. Specifically, if the source-end device does not find that OPTION-CODE is an extension field of PATH in the RDATA of the Additional field, or there is no RDATA at all, it means that this is a regular DNS response, and the source-end device responds according to the IP address in the ANSWER field. The address is forwarded normally; if the source device finds that OPTION-CODE is an extension field of PATH in the RDATA of the Additional field, it reads that OPTION-CODE is an extension field of QPATH. If its OPTION-DATA value is Overlay, it means that it is Overlay The path type of the network.
  • OPTION-DATA in PATH indicates the path list corresponding to the overlay network path.
  • the source device encapsulates the target data packet to be sent, and the encapsulation header field includes the forwarding node.
  • forwarding sequence eg, PoP path list PoP-list
  • source address of the source device IP address of the first hop PoP
  • each PoP involved in the path list receives the data packets in the forwarding order, and unpacks the header field of the outer layer, reads the PoP-list, and puts the IP address of the next PoP into the new
  • the outer network packet header is sent to the Underlay network. If the PoP is the last hop in the PoP-list, the PoP deletes the header field of the data packet and sends the original target data packet to the Underlay network to send to the destination device.
  • the process of step 6 can be referred to as shown in FIG. 15 , and the detailed encapsulation and decapsulation process can be referred to the description of the corresponding embodiment in FIG. 13 , which will not be repeated here.
  • FIG. 15 is for showing each PoP How to decapsulate, re-encapsulate and forward the target data packet, so in Figure 15, the DNS server is omitted.
  • the description is made by taking the path type included in the extended DNS request as the Overlay network path as an example, that is, filling in the OPTION-DATA of the QPATH extension field of the extended DNS request is the Overlay network path.
  • the source device can also be supported to initiate SRv6 transmission.
  • SRv6 is filled in the OPTION-DATA of the QPATH extension field of the extended DNS request, and in steps 3 and In step 4, the controller matches and calculates the path list SRv6-list of the optimal SRv6 path according to the extended DNS request, and puts the path list SRv6-list into the OPTION-DATA of the PATH extension field and is returned by the DNS controller. .
  • the source device and the forwarding node perform encapsulation and forwarding according to the obtained path list SRv6-list of SRv6 paths. The encapsulation and forwarding process is similar to the SRv6 forwarding standard, and will not be repeated here.
  • the path type is an SRv6 path
  • the source device can be a terminal device such as a mobile phone and a PC in the enterprise network.
  • SRv6 path can also be replaced with SR MPLS, that is, the path type can be changed to MPLS label stack, and the routing method is similar to that of SRv6 path, which is not repeated here.
  • the path type included in the extended DNS request in the embodiment of this application may be an SFC path in addition to an Overlay network path and an SRv6 path, that is, the routing method described in this application can support an SFC path.
  • the path information in the extended DNS response returned by the controller is the path list of the SFC, the source device and each forwarding node.
  • the data packets are encapsulated and forwarded based on the path list of the SFC.
  • the process is similar to the above, and will not be repeated here. The difference is that the relevant forwarding node needs to support the forwarding function in step 6.
  • FIG. 16 is a schematic diagram of compatibility provided by the embodiment of the present application.
  • the new source device refers to the source device where the SDK is deployed
  • the traditional DNS server refers to the DNS server without the corresponding deployment controller
  • the new DNS server refers to the DNS server corresponding to the deployed controller. The following is an analysis of different situations:
  • the traditional source device sends DNS packets to the traditional DNS server, it is a conventional DNS packet resolution process.
  • the new DNS server If the traditional source device sends a DNS packet to the new DNS server, the new DNS server normally returns the destination address of the destination device according to the QUESTION field.
  • the traditional DNS server If the new source device sends DNS packets to the traditional DNS server, the traditional DNS server normally returns the destination address of the destination device according to the QUESTION field. This is because the traditional DNS server cannot resolve the OPTION-CODE: QPATH in the ADDITIONAL field, so No special treatment is required.
  • the new DNS server can resolve OPTION-CODE: QPATH, and the specific process is the routing process described in the embodiment of the present application.
  • the embodiment of the present application follows the principle of backward compatibility, that is, the new source device can cooperate with a traditional DNS server (without a controller) or a new DNS server (correspondingly with a controller), and the new DNS server can respond to the traditional DNS server. DNS request or extended DNS request.
  • the request for the path and the response to the path request are carried in the extended DNS message, so as to realize the source
  • the application on the end device provides the ability to control the path to the destination end device.
  • other information may also be used as a medium to realize the function of configuring an end-to-end transmission path for Internet transmission at the terminal.
  • the HTTP protocol can be used for domain name resolution instead of the existing UDP-based DNS protocol, and the domain name resolution request is directly sent to the flexibly configurable HTTP DNS server, thereby bypassing the operator's local DNS server and avoiding the domain name caused by the local DNS server. Hijacking problems and scheduling inaccuracy problems.
  • FIG. 17 is another schematic flowchart of a routing method provided by an embodiment of the present application. The method may include the following steps:
  • the source device sends a first Http request to the Http DNS server, where the first Http request includes a first path request.
  • the source-end device sends a first Http request to the Http DNS server, the first Http request includes a first path request, and the first path request is used to instruct the subsequent source-end device to send data packets to the destination-end device. what path (that is, instructing the source device to send the data packet to the destination device).
  • the first path request includes relevant information for determining a routing path. If the information included in the first path request is different, the path information planned by the controller based on the first path request is also different.
  • the first path request includes at least any one of the following information: the address of the destination device to which the data to be sent is destined (that is, the destination address described above), the application type of the data to be sent, the data to be sent The application ID of the data to be sent, the service type of the data to be sent, the QoS requirements of the data to be sent, and the type of the first path required to be used by the data to be sent.
  • the address of the destination device to which the data to be sent is destined that is, the destination address described above
  • the application type of the data to be sent the data to be sent
  • the application ID of the data to be sent the service type of the data to be sent, the QoS requirements of the data to be sent, and the type of the first path required to be used by the data to be sent.
  • different path requests are defined in advance in the fields of the resource record of the extended DNS request, for example, it may be an extension to the extended DNS protocol standard (that is, adding a new extension field), or it can be compatible with existing standard protocols.
  • different path requests are predefined in the Http request, and the definition process does not involve standards, so there is no need to apply to an organization (eg, IANA).
  • the generation of the first Http request may have various triggering forms.
  • the first Http request may be generated through the SDK installed on the source device.
  • the session request may be initiated by an application installed on the source device.
  • a browser application accesses a session request to www.huawei.com, and the session request triggers the source device to call the SDK to generate the first Http request;
  • An Http request can also be a pre-written software module in the application.
  • the session request will trigger the source device to call the software module in the application to generate the first Http request;
  • the generation of the first Http request may also be triggered by writing a protocol stack.
  • the present application does not limit the specific implementation manner of how to trigger the generation of the first Http request, which will not be illustrated here.
  • the Http DNS server obtains path information corresponding to the first path request according to the first Http request.
  • the Http DNS server After receiving the first Http request sent by the source device, the Http DNS server can perform a matching query according to the information in the first Http request to obtain path information corresponding to the first path request.
  • the default Http DNS server can implement the function of path planning based on the information in the first Http request.
  • the Http DNS server obtains the planned path information based on the obtained information, it can be based on It is obtained from the self-developed algorithm, which is not limited here.
  • the Http DNS server sends a first Http response to the source device, and the path information is included in the first Http response, wherein, in the case where the value of the path information is not empty, the path information includes the source device To the forwarding nodes between the destination devices and the forwarding sequence of the forwarding nodes.
  • the Http DNS server After the Http DNS server obtains the path information based on the first Http request, it will send the first Http response to the source device, and the path information is included in the first Http response.
  • the planning of the path information is related to the application type and application requirements of the source device (eg, whether the bandwidth is large, whether the delay is small, etc.), etc.
  • the path planned by the Http DNS server generally refers to The optimal path from the source device to the destination device that meets the current requirements.
  • the information contained in the path information is also different. Specifically, it can be divided into the following types:
  • the path information includes the forwarding nodes between the source device and the destination device and the forwarding sequence of the forwarding nodes. It should be noted that when there is one forwarding node , then the default sequential forwarding order is forwarded by this one forwarding node. When the number of forwarding nodes is n (n ⁇ 2), it is the normal sequential forwarding order.
  • the path request when the path request is a path type, then the path types are different, and the types of forwarding nodes involved are also different.
  • the first path type when the first path type is an overlay network path, forwarding The node is a PoP; when the first path type is an SRv6 path, the forwarding node is an SRv6 router; when the first path type is an SFC path, the forwarding node is a hardware device supporting the service chain.
  • the type of the forwarding node is related to the path type, which is not repeated here.
  • the source-end device sends the target data packet to be sent to the destination-end device via the forwarding node according to the forwarding sequence.
  • step 1704 is similar to the above-mentioned step 804.
  • step 804 please refer to the above-mentioned step 804, which will not be repeated here.
  • the difference between this embodiment and the embodiment corresponding to FIG. 8 is: 1) In the embodiment corresponding to FIG. 17 , the request and response to the path are carried by the Http request and the Http response, while the The corresponding embodiment of 8 is carried by the extended DNS message; 2) in the corresponding embodiment of FIG. 17 , the function of the controller planning the path in the corresponding embodiment of FIG. 8 is integrated on the Http DNS server. Except for these two differences, other processes are similar to those of the corresponding embodiment in FIG. 8 .
  • the function of the controller to plan the path in the embodiment corresponding to FIG. 8 is integrated on the Http DNS server, and in other embodiments of the present application, the function corresponding to FIG. 8 may also be integrated
  • the function of the controller planning the path is independently deployed as one module or multiple modules, and the module may not be deployed on the Http DNS server, but be deployed on other devices.
  • the operations performed by the Http DNS server are performed by other devices where the module is deployed.
  • each forwarding node may be full or incremental, which is not limited in this application.
  • the sequential forwarding sequence encapsulated in the header field by each forwarding node may be full or incremental, which is not limited in this application.
  • FIG. 18 is a schematic diagram of the comparison between the routing method provided by the embodiment of the present application and the DNS resolution scheme of traditional Internet transmission. It can be seen from the sub-schematic diagram (a) in FIG. 18 that Baidu can (a) The Baidu GSLB in the sub-schematic diagram allocates the optimal server for users to access, but the path from the user to the server is completely determined by the Internet.
  • the routing method provided by the embodiment of the present application is a direct, simple and efficient method.
  • Baidu plans paths for users through the deployed controller i.e. Baidu E2E in sub-schematic diagram (b) in Figure 18
  • the planning strategy can be differentiated user experience, for example, Member users are assigned a better acceleration path, while regular users are assigned a default internet path.
  • the routing method provided by the embodiments of the present application provides a means for implementing the end-to-end joint optimization, and the end-to-end joint optimization can bring better performance improvement for users.
  • the present application briefly summarizes the advantages of the joint optimization. simulation.
  • the specific experimental configuration is as follows:
  • Topology generation As shown in Figure 19, simulate the earth scale on a two-dimensional plane, fix the source point, move the destination point horizontally on the x-axis, and adjust the source-destination distance; randomly sprinkle points and deploy PoP (the point in Figure 19). ), the number of PoP points is 100, 200, 500.
  • Figure 21 shows the variation curves of the four methods' delays with distance under different PoP points scenarios. It can be seen from Figure 21 that the existing nearest access routing method will bring negative gain in the short-range communication scenario, and the delay is higher than the default direct connection path due to the detour on the overlay network. However, the method provided by the embodiment of the present application determines the overlay network path (or direct connection communication) according to the actual network situation, and the performance is better than other existing methods and the default direct connection path.
  • PoP is managed by the central controller, and the routing table and destination IP-exit PoP mapping table are updated according to the link quality.
  • the PoP does not need to maintain any entry, avoids interaction and update with the controller, and all forwarding states are inside the data packet.
  • the SR technology can eliminate the network status information of the transition nodes in the network, and include the path status information in the packet header, which makes network management and operation and maintenance easier.
  • most of the existing SR domains are inside the network, for example, routers and switches in the same autonomous domain.
  • the routing method provided by the embodiment of the present application further extends the SR domain to the user terminal, starts the SR from the real data source, and cooperates with the device, the edge and the cloud to realize a simplified network.
  • routing method provided by the embodiment of the present application can also be extended and applied to the back-to-source request with the server.
  • the extended application is described in detail below.
  • the path from users to servers includes : user-edge proxy server-cloud backbone network-DC.
  • the functions of each device are: the edge proxy server/PoP point is used to terminate the user's TCP or Http request and cache the content; the DC is used to carry the logic and status of the application; the cloud backbone network is used to connect the DC and the edge proxy server.
  • the edge proxy server acts as the entrance and exit of the DC server network. On the one hand, it caches the content closer to the user, and on the other hand, it acts as the manager between the user and the DC to ensure security and load balancing.
  • the existing method for back-to-source requests between users and servers includes three subsystems: 1) Edge proxy server selection system: the user obtains the nearest edge proxy server/PoP point according to the DNS protocol; 2) DC selection system: According to the load of each DC 3) Cloud backbone network routing system: generate the optimal path from each edge proxy server to each DC.
  • the inconsistency of the independent configurations of different subsystems in the user back-to-source process can be solved.
  • the user initiates a back-to-source request and performs DNS packet resolution.
  • the DNS server and the controller jointly calculate the back-to-source path based on the user address, DC load and network conditions, edge proxy server load and network conditions, and cloud backbone network conditions.
  • the back-to-source path is carried in the extended DNS message for delivery, and the back-to-source path includes the selected proxy server, the selected backbone network route, the selected DC node, and the like.
  • the back-to-source path is encapsulated in the data packet header transmitted by the user.
  • the client device first establishes a connection with the selected edge proxy server according to the path information, and then the edge proxy server establishes a connection with the corresponding DC according to the path information (multiplex long connection), and The path is planned according to the backbone line in the back-to-source path.
  • FIG. 23 is a schematic diagram of a terminal device provided by an embodiment of the application.
  • the terminal device may specifically include: a first sending module 2301, an obtaining module 2302, and a second sending module 2303, wherein , a first sending module 2301, configured to send a first extended DNS request to the controller, where the first extended DNS request includes a first path request, and the first path request is used to instruct the source device to send data to the destination device
  • the acquisition module 2302 is configured to receive the first extended DNS response sent by the controller, the first extended DNS response includes path information corresponding to the first path request, and the path information is used by the controller according to the The first extended DNS request is obtained, and in the case that the value of the path information is not empty, the path information includes the forwarding nodes between the source device and the destination device and the forwarding sequence of the forwarding nodes; the second sending Module 2303, configured to send the target data packet to be sent to the destination device via the forwarding node according to the forwarding sequence.
  • the request for the path and the response to the path request (that is, the path information planned by the controller) are carried in the extended DNS message, so as to provide the application on the source device with access to the destination device. control of the path.
  • the first sending module 2301 carries the path request in the extended DNS request and sends it to the controller, the controller plans a path based on the received extended DNS request, and the planned path information is carried in the extended DNS response, the obtaining module 2302 sends The extended DNS response sent by the controller will be received, and then the second sending module 2303 will send the target data according to the specific content of the path information (for example, including several forwarding nodes, the forwarding sequence between the forwarding nodes, etc.).
  • the packet is sent to the target end device.
  • the embodiment of the present application uses the extended DNS message as the medium, configures the path information in the response message in the extended DNS message to initiate the SR from the real data source, and configures the end-to-end transmission path for Internet transmission at the terminal, which improves the routing performance. efficiency, and improve the end-to-end performance of Internet business.
  • the second sending module 2303 is specifically configured to: first, encapsulate the target data packet according to the path information to obtain a first data packet encapsulated with a first header field, the first header
  • the domain includes the forwarding sequence, the source address of the source device, and the address of the first-hop forwarding node (for example, IP address, or, the identifier of the IP address, or, other addresses that can address the first-hop forwarding node.
  • the first data packet is sent to the first hop forwarding node, and in the case that the first hop forwarding node is not the last hop forwarding node, the first hop forwarding node is sent by the first hop forwarding node
  • the target data packet is re-encapsulated to obtain a second data packet encapsulated with the second header field, and the second data packet is encapsulated by the first hop forwarding node.
  • the packet is sent to the second hop forwarding node, and the second header field includes the sequential forwarding sequence, the address of the first hop forwarding node, and the address of the second hop forwarding node, and the second hop forwarding node is In the case of the last hop forwarding node, the second hop forwarding node deletes the second header field, and the second hop forwarding node sends the target data packet with the second header field deleted to the destination sent by the end device.
  • the second sending module 2303 and each forwarding node realize the forwarding sequence between the forwarding nodes encapsulated in the header field to realize the target data
  • the forwarding node does not need to maintain any entry, avoiding interaction and updating with the controller, and all forwarding states are inside the data packet, reducing maintenance cost.
  • the second sending module 2303 is further configured to: directly send the target data packet to be sent to the destination device when the value of the path information is empty.
  • how the target data packet is sent to the destination device via the forwarding node when only one forwarding node is included in the path information, that is, no matter how many forwarding nodes are included in the path information it can be realized based on
  • the sequential forwarding sequence between the forwarding nodes encapsulated in the header field achieves the purpose of sending the target data packet to the destination device, and has wide applicability.
  • the terminal device 2300 further includes a generating module 2304, and the generating module 2304 is used for, before the first sending module 2301 sends the first extended DNS request to the controller, by installing on the source device
  • the SDK on the server generates the first extended DNS request, and the generation of the first extended DNS request is triggered by a session request initiated by an application installed on the source device.
  • the first sending module 2301 is specifically configured to: send the first extended DNS request to the DNS server corresponding to the source device, and send the first extended DNS request to the controller by the DNS server Extended DNS requests;
  • the obtaining module 2302 is specifically configured to receive the first extended DNS response forwarded by the controller through the DNS server.
  • the data interaction between the first sending module 2301 and the obtaining module 2302 and the controller is performed via the DNS server corresponding to the source device, which is achievable.
  • FIG. 24 is a schematic structural diagram of a terminal device provided by an embodiment of the present application.
  • the terminal device may specifically include: A sending module 2401, an obtaining module 2402 and a second sending module 2403, wherein the first sending module 2401 is used to send a first Http request to the Http DNS server, the first Http request includes a first path request, the first path The request is used to instruct the source device to send the data packet to the destination device; the obtaining module 2402 is used to obtain the first Http response sent by the Http DNS server, and the first Http response includes the corresponding first path request.
  • Path information the path information is obtained by the Http DNS server according to the first Http request, if the value of the path information is not empty, the path information includes the forwarding node between the source device and the destination device and the forwarding sequence of the forwarding node; the second sending module 2403 is configured to send the target data packet to be sent to the destination device via the forwarding node according to the forwarding sequence.
  • the request for the path and the response to the path request (that is, the path information planned by the Http DNS server) are carried in the Http request and the Http response respectively, so as to provide access for applications on the source device The control capability of the path of the destination device.
  • the first sending module 2401 carries the route request in the Http request and sends it to the Http DNS server, the Http DNS server plans the route based on the received Http request, and carries the planned route information in the Http response, the obtaining module 2402 will The Http response sent by the Http DNS server will be received, and then the second sending module 2403 will send the target data according to the specific content of the path information (for example, including several forwarding nodes, the order of forwarding between forwarding nodes, etc.). The packet is sent to the target end device.
  • the specific content of the path information for example, including several forwarding nodes, the order of forwarding between forwarding nodes, etc.
  • the embodiment of the present application uses Http request and Http response as the medium, defines the path information in the Http response to initiate the SR from the real data source, and defines the end-to-end transmission path for Internet transmission at the terminal, which improves the routing efficiency and improves the Internet Business end-to-end performance.
  • the second sending module 2403 is specifically configured to: first, encapsulate the target data packet according to the path information to obtain a first data packet encapsulated with a first header field, the first header
  • the domain includes the sequential forwarding sequence, the source address of the source device, and the address of the first-hop forwarding node; after that, the first data packet is sent to the first-hop forwarding node, and the first-hop forwarding node is sent to the first-hop forwarding node.
  • the first hop forwarding node decapsulates the first header field of the first data packet and then re-encapsulates the target data packet, and obtains an encapsulated second header field.
  • the second data packet is sent by the first hop forwarding node to the second hop forwarding node, and the second header field includes the sequential forwarding sequence, the address of the first hop forwarding node, and The address of the second-hop forwarding node, and if the second-hop forwarding node is the last-hop forwarding node, the second-hop forwarding node deletes the second header field, and the second-hop forwarding node
  • the forwarding node sends the target data packet with the second header field deleted to the destination device.
  • the second sending module 2403 and each forwarding node realize the forwarding sequence between the forwarding nodes encapsulated in the header field to realize the forwarding of the target data.
  • the forwarding node does not need to maintain any entry, avoiding interaction and updating with the controller, and all forwarding states are inside the data packet, reducing maintenance cost.
  • the second sending module 2403 is further configured to: directly send the target data packet to be sent to the destination device when the value of the path information is empty.
  • how the target data packet is sent to the destination device via the forwarding node when only one forwarding node is included in the path information, that is, no matter how many forwarding nodes are included in the path information it can be realized based on
  • the sequential forwarding sequence between the forwarding nodes encapsulated in the header field achieves the purpose of sending the target data packet to the destination device, and has wide applicability.
  • the terminal device 2400 further includes a generating module 2404, and the generating module 2404 is configured to, before the first sending module 2401 sends the first Http request to the Http DNS server, by installing on the source device
  • the SDK on the server generates the first Http request, and the generation of the first Http request is triggered by a session request initiated by an application installed on the source device.
  • the controller 2500 may specifically include: an acquisition module 2501 , a path planning module 2502 and Sending module 2503, wherein the obtaining module 2501 is used to obtain the first extended DNS request sent by the source device, the first extended DNS request includes a first path request, and the first path request is used to indicate the source device to the destination The way the end device sends data packets; the path planning module 2502 is used to obtain the path information corresponding to the first path request according to the first extended DNS request; the sending module 2503 is used to send the first extended DNS to the source device response, the path information is included in the first extended DNS response, wherein, in the case that the value of the path information is not empty, the path information includes the forwarding node and the forwarding between the source device and the destination device The forwarding sequence of the nodes, so that the source end device sends the target data packet to be sent to the destination end device via
  • the request for the path and the response to the path request are carried in the extended DNS message, so as to provide the application on the source device with access to the destination device. control of the path.
  • the obtaining module 2501 obtains the extended DNS request sent by the source device, the extended DNS request contains a request for the path (ie the first path request), and the path planning module 2502 plans the path based on the received extended DNS request,
  • the sending module 2503 then carries the planned path information in the extended DNS response and sends it to the source-end device, and the source-end device according to the specific content of the path information (for example, including several forwarding nodes, the sequential forwarding between the forwarding nodes) sequence, etc.) send the target packet to the target's end device.
  • This embodiment of the present application uses the extended DNS message as the medium, configures the path information in the response message in the extended DNS message to initiate SR from the real data source, and configures the end-to-end transmission path for Internet transmission at the terminal, which improves the Routing efficiency, and improve the end-to-end performance of Internet services.
  • the obtaining module 2501 is specifically configured to: obtain the first extended DNS request forwarded by the source device through a DNS server, and the DNS sending server corresponds to the source device;
  • the sending module 2503 is specifically configured to send a first extended DNS response to the DNS server, and the DNS server to send the first extended DNS response to the source device.
  • the data interaction between the acquisition module 2501, the sending module 2503 and the source device is performed via the DNS server corresponding to the source device, which is achievable.
  • FIG. 26 is a schematic structural diagram of the Http DNS server provided by the embodiment of the present application
  • the Http DNS server 2600 may specifically include: an acquisition module 2601, a path planning Module 2602 and sending module 2603, wherein the obtaining module is used to obtain the first Http request sent by the source-end device, the first Http request includes a first path request, and the first path request is used to instruct the source-end device to send the destination The way the end device sends data packets; the path planning module 2602 is used to obtain the path information corresponding to the first path request according to the first Http request; the sending module 2603 is used to send the first Http response to the source end device, The path information is included in the first Http response, where, in the case where the value of the path information is not empty, the path information includes the forwarding node between the source device and the destination device and the sequence of the forwarding no
  • the request for the path and the response to the path request (that is, the path information planned by the Http DNS server) are carried in the Http request and the Http response respectively, so as to provide access for applications on the source device The control capability of the path of the destination device.
  • the acquisition module 2601 acquires the Http request sent by the source device, and the Http request contains a request for a path (ie, the first path request), and the path planning module 2602 plans the path based on the received Http request, and then sends the Module 2603 carries the planned path information in the Http response and sends it to the source-end device, and the source-end device sends the information according to the specific content of the path information (for example, including several forwarding nodes, the sequence of forwarding between the forwarding nodes, etc.).
  • the destination packet is sent to the destination's end device.
  • the embodiment of the present application uses Http request and Http response as the medium, configures the path information in the Http response to initiate SR from the real data source, and configures the end-to-end transmission path for Internet transmission at the terminal, which improves the routing efficiency and improves the Internet Business end-to-end performance.
  • FIG. 27 is a schematic structural diagram of the computer device provided by the embodiment of the present application.
  • the computer device 2700 may be the terminal device described in the present application. It can also be the controller described in this application, and it can also be the Http DNS server described in this application.
  • the modules described in the corresponding embodiment of FIG. 23 or FIG. 24 can be deployed on the computer device 2700 to realize the functions of the terminal device in the corresponding embodiment of FIG. 23 or FIG. 24 ;
  • the computer device 2700 is a controller, the modules described in the corresponding embodiment of FIG.
  • the computer device 2700 is implemented by one or more servers, and the computer device 2700 may vary greatly due to differences in configuration or performance, and may include one or more central processing units (CPU) 2722 (for example, one or more above central processing unit) and memory 2732, one or more storage media 2730 (eg, one or more mass storage devices) storing application programs 2742 or data 2744.
  • CPU central processing units
  • storage media 2730 eg, one or more mass storage devices
  • the memory 2732 and the storage medium 2730 may be short-term storage or persistent storage.
  • the program stored in the storage medium 2730 may include one or more modules (not shown in the figure), and each module may include a series of instructions to operate on the computer device 2700 .
  • the central processing unit 2722 may be configured to communicate with the storage medium 2730 to execute a series of instruction operations in the storage medium 2730 on the computer device 2700.
  • Computer device 2700 may also include one or more power supplies 2726, one or more wired or wireless network interfaces 2750, one or more input and output interfaces 2758, and/or, one or more operating systems 2741, such as Windows ServerTM, Mac OS XTM, UnixTM, LinuxTM, FreeBSDTM and many more.
  • operating systems 2741 such as Windows ServerTM, Mac OS XTM, UnixTM, LinuxTM, FreeBSDTM and many more.
  • the computer device 2700 when the computer device 2700 is a terminal device, then the computer device 2700, as a source device, can be used to execute the steps performed by the source device in the embodiment corresponding to FIG. 8 or FIG. 17 , for example, the central processing unit 2722 It can be used to: send a first extended DNS request to the controller, where the first extended DNS request includes a first path request, and the first path request is used to instruct the subsequent source-end device to send data packets to the destination-end device.
  • the path that is, instructing the source end device to send the data packet to the destination end device
  • different path requests are defined in advance in the fields of the resource record of the extended DNS request.
  • An implementation manner may be an extension to the extended DNS protocol standard (that is, adding a new extension field), or may be compatible with an existing standard protocol.
  • the first extended DNS response sent by the controller will be obtained.
  • the first extended DNS response is generated by the controller, and the first extended DNS response includes a path related to the first path.
  • the corresponding path information is requested, and the path information is obtained by the controller performing a matching query according to the information in the first extended DNS request.
  • the path information includes the forwarding nodes between the source device and the destination device and the forwarding sequence of the forwarding nodes.
  • the target data packet to be sent is sent to the destination device according to the forwarding sequence through the forwarding node (that is, the forwarding node included in the path information).
  • the forwarding node that is, the forwarding node included in the path information.
  • the central processing unit 2722 is configured to perform any one of the steps performed by the source device in the embodiment corresponding to FIG. 8 or FIG. 17 .
  • the central processing unit 2722 is configured to perform any one of the steps performed by the source device in the embodiment corresponding to FIG. 8 or FIG. 17 .
  • the computer device 2700 when it is a controller, it can be used to perform the steps performed by the controller in the corresponding embodiment of FIG. 8 .
  • the central processing unit 2722 can be used to: obtain the first data sent by the source device.
  • An extended DNS request the first extended DNS request includes a first path request, and the first path request is used to indicate the path through which the subsequent source-end device sends data packets to the destination-end device (that is, to indicate the source-end device).
  • different path requests are defined in advance in the fields of the resource record of the extended DNS request, and there may be multiple implementations, for example, it may be The extension of the extension DNS protocol standard (that is, adding a new extension field) can also be compatible with the existing standard protocol.
  • a matching query may be performed according to the information in the first extended DNS request to obtain path information corresponding to the first path request.
  • the path information is obtained based on the first extended DNS request, the first extended DNS response is sent to the source device, and the path information is included in the first extended DNS response.
  • the path information when the value of the path information is not empty, the path information includes the forwarding nodes between the source device and the destination device and the forwarding sequence of the forwarding nodes. So that the source end device sends the target data packet to be sent to the destination end device via the forwarding node (that is, the forwarding node included in the path information) according to the forwarding sequence. It should be noted that when there is one forwarding node, the default sequential forwarding order is forwarded by this one forwarding node. When there are n forwarding nodes (n ⁇ 2), it is the normal sequential forwarding order.
  • the central processing unit 2722 is configured to execute any one of the steps executed by the controller in the embodiment corresponding to FIG. 8 .
  • the central processing unit 2722 is configured to execute any one of the steps executed by the controller in the embodiment corresponding to FIG. 8 .
  • the computer device 2700 when the computer device 2700 is an Http DNS server, it can be used to perform the steps performed by the Http DNS server in the corresponding embodiment of FIG. 17.
  • the central processing unit 2722 can be used to: obtain the data sent by the source device.
  • the first Http request, the first Http request includes the first path request, and the first path request is used to indicate the path through which the source-end device sends data packets to the destination-end device (that is, indicating the source-end device).
  • the method of sending data packets to the destination device in the embodiment of the present application, different path requests are defined in the Http request in advance, and the definition process does not involve standards, so there is no need to apply to the institution.
  • a matching query can be performed according to the information in the first Http request to obtain path information corresponding to the first path request.
  • the first Http response is sent to the source device, and the path information is included in the first Http response.
  • the path information includes the forwarding nodes between the source device and the destination device and the forwarding sequence of the forwarding nodes. So that the source end device sends the target data packet to be sent to the destination end device via the forwarding node (that is, the forwarding node included in the path information) according to the forwarding sequence.
  • the default sequential forwarding order is forwarded by this one forwarding node.
  • n forwarding nodes it is the normal sequential forwarding order.
  • the central processing unit 2722 is configured to perform any one of the steps performed by the Http DNS server in the embodiment corresponding to FIG. 17 .
  • the central processing unit 2722 is configured to perform any one of the steps performed by the Http DNS server in the embodiment corresponding to FIG. 17 .
  • Embodiments of the present application further provide a computer-readable storage medium, where a program for performing signal processing is stored in the computer-readable storage medium, and when the computer-readable storage medium runs on a computer, it causes the computer to execute the programs described in the foregoing embodiments. steps performed by computer equipment.
  • the device embodiments described above are only schematic, wherein the units described as separate components may or may not be physically separated, and the components displayed as units may or may not be A physical unit, which can be located in one place or distributed over multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution in this embodiment.
  • the connection relationship between the modules indicates that there is a communication connection between them, which may be specifically implemented as one or more communication buses or signal lines.
  • U disk U disk
  • mobile hard disk ROM
  • RAM random access memory
  • disk or CD etc.
  • a computer device which can be a personal computer, training equipment, or network equipment, etc. to execute the methods described in the various embodiments of the present application.
  • the computer program product includes one or more computer instructions.
  • the computer may be a general purpose computer, special purpose computer, computer network, or other programmable device.
  • the computer instructions may be stored in or transmitted from one computer-readable storage medium to another computer-readable storage medium, for example, the computer instructions may be retrieved from a website, computer, training device, or data
  • the center transmits to another website site, computer, training equipment, or data center by wire (eg, coaxial cable, optical fiber, digital subscriber line) or wireless (eg, infrared, wireless, microwave, etc.).
  • the computer-readable storage medium may be any available medium that can be stored by a computer, or a data storage device such as a training device, a data center, or the like that includes an integration of one or more available media.
  • the available media may be magnetic media (eg, floppy disks, hard disks, magnetic tapes), optical media (eg, high-density digital video discs (DVDs)), or semiconductor media (eg, solid state disks) , SSD)) etc.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本申请实施例公开了一种路由方法及设备，可应用于数据传输领域，包括：源端设备将对路径的请求携带在扩展DNS请求中向控制器发送，控制器基于该扩展DNS请求规划路径，并将规划的路径信息携带在扩展DNS响应中向源端设备发送，再由该源端设备根据该路径信息内容(如包括几个转发节点、转发节点间的先后转发顺序等)将目标数据包向目的端设备发送。本申请将对路径的请求以及对路径请求的响应(即控制器规划的路径信息)携带在扩展DNS报文中(即以扩展DNS报文为媒介)，将路径信息配置在扩展DNS报文的响应报文中从真正的数据源头发起SR，在终端为互联网传输配置端到端传输路径，从而实现为源端设备上的应用提供访问目的端设备的路径的控制能力。

Description

一种路由方法及设备
本申请要求于2021年3月31日提交中国专利局、申请号为202110350574.1、申请名称为“一种路由方法及设备”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请涉及数据传输领域，尤其涉及一种路由方法及设备。
背景技术
随着5G时代的到来，互联网应用呈现新的发展态势，在线游戏、音视频、增强现实(augmented reality，AR)、虚拟现实(virtual reality，VR)等新兴移动应用对网络时延、吞吐、丢包等体验的要求不断提高。
传统互联网传输在确定源端设备的源地址、目的端设备的目的地址后，端到端的传输路径由互联网中的路由协议(如，边界网关协议(border gateway protocol，BGP)、内部网关协议(interior gateway protocol，IGP)等)所决定。
目前，源端设备到目的端设备的路由方式一般分为如下几种：基于智能域名系统(domain name system，DNS)的全局负载均衡(global server load balance，GSLB)、Overlay智能路由以及分段/源路由(segment/source routing，SR)，其中，基于DNS的GSLB解决了应用对用户请求目的端设备的目的地址的控制，但无法控制对目的端设备访问的路径，也就是说，源端设备到目的端设备的访问路径完全由互联网所决定；Overlay智能路由则涉及3个子系统，各子系统各自独立对路径进行优化，每个子系统做出的本地最优决策不等于端到端的全局最优决策；而分段/源路由目前只工作在网络内部(如路由器、交换机或网路中继转发节点(point-of-presence，PoP))。
发明内容
本申请实施例提供了一种路由方法及设备，用于为源端设备上的应用提供访问目的端设备的路径的控制能力，并将SR域延伸至终端设备，从真正的数据源头发起SR，在终端为互联网传输定义端到端传输路径，提高了路由效率，并提升了互联网业务端到端表现。
基于此，本申请实施例提供以下技术方案：
第一方面，本申请实施例首先提供一种路由方法，可用于数据传输领域中，该方法包括：首先，源端设备会向控制器发送第一扩展DNS请求，该第一扩展DNS请求中包括第一路径请求，该第一路径请求用于指示后续源端设备向目的端设备发送数据包的时候通过的是什么路径(即指示源端设备向目的端设备发送数据包的方式)，在本申请实施例中，不同的路径请求是事先定义在扩展DNS请求的资源记录的字段内的，具体可以有多种实现方式，例如，可以是对扩展DNS协议标准的扩展(即增加新的扩展字段)，也可以是兼容现有的标准协议，具体本申请对将不同的路径请求定义在扩展DNS请求的资源记录的字段内的具体实现方式不做限定。源端设备在向控制器发送了第一扩展DNS请求后，之后将获取 由控制器发送的第一扩展DNS响应，该第一扩展DNS响应由控制器生成，该第一扩展DNS响应中包括与第一路径请求对应的路径信息，该路径信息由控制器根据该第一扩展DNS请求中的信息做匹配查询得到。需要注意的是，在本申请实施例中，在该路径信息的取值不为空的情况下，该路径信息包括源端设备到目的端设备之间的转发节点以及转发节点的先后转发顺序。最后，源端设备经由转发节点(即路径信息中包括的转发节点)按照所述先后转发顺序将待发送的目标数据包向该目的端设备发送。需要注意的是，当转发节点为1个时，则默认先后转发顺序就是由这1个转发节点进行转发，当转发节点为n个(n≥2)，则是正常的先后转发顺序。
在本申请上述实施方式中，将对路径的请求以及对路径请求的响应(即控制器规划的路径信息)携带在扩展DNS报文中，从而实现为源端设备上的应用提供访问目的端设备的路径的控制能力。具体来说，首先源端设备将路径请求携带在扩展DNS请求中向控制器发送，控制器基于接收到的扩展DNS请求规划路径，并将规划的路径信息携带在扩展DNS响应中向源端设备发送，再由该源端设备根据该路径信息的具体内容(如，包括几个转发节点、转发节点之间的先后转发顺序等)将目标数据包向目标的端设备发送。本申请实施例以扩展DNS报文为媒介，将路径信息配置在扩展DNS报文中的响应报文中从真正的数据源头发起SR，在终端为互联网传输配置端到端传输路径，提高了路由效率，并提升了互联网业务端到端表现。
在第一方面的一种可能的实现方式中，在路径信息的取值不为空的情况下，也就是说，该路径信息至少包括有一个转发节点，源端设备对收到的第一扩展DNS响应进行解析，并经由该路径信息所包括的转发节点按照先后转发顺序将待发送的目标数据包向目的端设备发送的过程具体可以是：首先，源端设备根据得到的路径信息对目标数据包进行封装，得到封装了头域(可称为第一头域)的数据包(可称为第一数据包)，该第一头域内包括转发节点的先后转发顺序、源端设备的源地址以及第一跳转发节点的地址(如，IP地址，或，用于映射IP地址的标识，或，其他可以对第一跳转发节点进行寻址的标识等，下述各个转发节点的地址的含义与此类似，此处不予赘述)，之后，源端设备将第一数据包发送至第一跳转发节点，第一跳转发节点根据该第一头域内包括的转发节点的先后转发顺序判断自身是否是最后一跳转发节点，若该第一跳转发节点不是最后一跳转发节点，在这种情况下，第一转发节点对该第一数据包的第一头域解封装后，再对目标数据包进行再封装，得到由第一转发节点封装了头域(可称为第二头域)的数据包(可称为第二数据包)，此时，该第二数据包则包括转发节点的先后转发顺序、第一跳转发节点的地址以及第二跳转发节点的地址，之后，由该第一跳转发节点根据转发节点的先后转发顺序将该第二数据包向第二跳转发节点发送。类似地，第二跳转发节点根据该第二数据包中的第二头域内包括的转发节点的先后转发顺序判断自身是否是最后一跳转发节点，若该第二跳转发节点是最后一跳转发节点，在这种情况下，第二跳转发节点对该第二数据包的第二头域解封装(即删除该第二数据包的第二头域)，得到初始的目标数据包(即只包含原始网络层包头)，并由该第二跳转发节点将该删除了第二头域的目标数据包向目的端设备发送。需要注意的是，在本申请实施例中，路径信息中除了最后一跳转发节点之外，其他每个转发节点都需对上一个转 发节点(对第一跳转发节点来说，上一个转发节点则为源端设备)发送的数据包进行解封装后再封装，再封装的头域里的最外层网络包头里写入的就是转发节点的先后转发顺序、自身的地址以及下一跳转发节点的地址。当某个转发节点接收到由上一个转发节点发送的数据包，根据数据包中头域内的先后转发顺序得知自身为最后一跳，那么该转发节点去除所有头域，得到初始的目标数据包，再由该最后一跳转发节点将得到的目标数据包发送给目的端设备。
在本申请上述实施方式中，阐述了当路径信息中包括至少两个转发节点时，源端设备以及各个转发节点基于头域中封装入的转发节点之间的先后转发顺序实现将目标数据包发送至目的端设备的目的，在本申请实施例提供的路由方法中，转发节点无需维护任何表项，避免了与控制器的交互与更新，所有转发状态均在数据包内部，降低了维护成本。
在第一方面的一种可能的实现方式中，若路径信息中只包括一个转发节点(即第一转发节点)，那么该第一转发节点接收到由源端设备发送的封装了头域的数据包后，由该头域内包括的转发节点的先后转发顺序得知，自身不仅是第一跳转发节点，也是最后一跳转发节点，那么该转发节点会将头域删除，并将删除了头域的目标数据包向目的端设备发送。
在本申请上述实施方式中，阐述了当路径信息中只包括一个转发节点时目标数据包如何经由该转发节点发送到目的端设备，也就是不管路径信息中包括几个转发节点，都可实现基于头域中封装入的转发节点之间的先后转发顺序实现将目标数据包发送至目的端设备的目的，具备广泛适用性。
在第一方面的一种可能的实现方式中，在路径信息的取值为空的情况下，说明最优路径是公网直连通信，无需转发节点的参与，那么源端设备直接将目标数据包向目的端设备发送。
在本申请上述实施方式中，阐述了当路径信息中没有转发节点时目标数据包如何由该源端设备发送到目的端设备，具备灵活性。
在第一方面的一种可能的实现方式中，该第一扩展DNS请求的生成可以有多种触发形式，作为一个示例，该第一扩展DNS请求可以通过安装于该源端设备的SDK(终端软件套件，可被应用调用)生成，具体地，可以是源端设备上安装的应用发起会话请求，例如，浏览器应用访问www.huawei.com的会话请求，该会话请求触发源端设备调用SDK生成第一扩展DNS请求；作为另一示例，该第一扩展DNS请求也可以是在应用中事先写好的软件模块，当源端设备上安装的应用发起会话请求，该会话请求就会触发源端设备调用该应用中的软件模块生成第一扩展DNS请求；作为另一示例，通过对现有的通信协议进行改写，使得改写得到的新的通信协议可支持生成该第一扩展DNS请求。具体地，本申请对如何触发生成第一扩展DNS请求的具体实现方式不做限定，此处不再举例示意。
在本申请上述实施方式中，阐述了几种触发第一扩展DNS请求生成的应用场景，具备普遍适用性。
在第一方面的一种可能的实现方式中，源端设备向控制器发送第一扩展DNS请求的实现方式具体可以是：由源端设备先将生成的第一扩展DNS请求向与该源端设备对应的DNS服务器发送，再由该DNS服务器将收到的第一扩展DNS请求向该控制器发送。类似地， 源端设备获取由控制器发送的第一扩展DNS响应的实现方式具体可以是：由控制器先将生成的第一扩展DNS响应向与该源端设备对应的DNS服务器发送，再由该源端设备接收由该DNS服务器发送的第一扩展DNS响应。
在本申请上述实施方式中，具体阐述了源端设备与控制器之间的数据交互是经由与该源端设备对应的DNS服务器进行的，具备可实现性。
在第一方面的一种可能的实现方式中，第一路径请求至少包括如下信息中的任意一种：
待发送数据所要去向的目的端设备的地址(即上述所述的目的端地址)、待发送数据的应用类型(如，实时音视频类应用、游戏类应用、浏览器类应用等)、待发送数据的应用ID(如，可以是Overlay网络运营商所维护的应用标识符)、待发送数据的业务类型(如，该数据流是实时音视频数据、游戏指令类数据、网页请求类数据等)、待发送数据的QoS要求(如，待发送数据所需要的QoS性能)、待发送数据要求使用的第一路径类型。
在本申请上述实施方式中，具体阐述了第一路径请求可以是哪些类型的信息，基于这些信息，控制器可对路径信息进行规划，以选择出适合当前待发送数据的最优路径，具备广泛适用性。
在第一方面的一种可能的实现方式中，第一路径类型至少包括如下类型中的任意一种：Overlay网络路径、SRv6路径或服务链(service function chain，SFC)路径。例如，假设第一路径类型是Overlay网络路径，那么路由的路径是通过Overlay网络进行转发；假设第一路径类型是SRv6路径，那么路由的路径是通过SRv6方式进行转发；假设第一路径类型是SFC路径，那么路由的路径是通过SFC方式进行转发，SFC路径的一种典型网络应用场景是：一个数据流通常需要通过多个网络服务设备(如，入侵检测系统、入侵防御系统、防火墙、LB等)，最终才能到达目的端设备，这就是SFC最常用的场景，具体本申请不再对第一路径类型可能存在的形式进行示意。
在本申请上述实施方式中，具体阐述了第一路径类型的几种具体形式，由用户根据需求自行选择选择哪种路由路径，具备可选择性。
在第一方面的一种可能的实现方式中，路径类型不同，所涉及的转发节点的类型也不同，例如，当第一路径类型是Overlay网络路径时，转发节点就为PoP；当第一路径类型是SRv6路径，转发节点就为SRv6路由器；当第一路径类型为SFC路径，转发节点就为支持SFC的硬件设备。在本申请实施例中，转发节点的类型与路径类型相关，此处不予赘述。
在本申请上述实施方式中，具体阐述了当第一路径类型选择不同，所涉及的转发节点的具体表现形式也不同，在实际应用中，可根据转发节点的具体部署情况选择合适的路由路径，具备灵活性。
在第一方面的一种可能的实现方式中，不同的路径请求是事先定义在扩展DNS请求的资源记录的字段内的，具体可以有多种实现方式。具体地，一种定义方式可以是对扩展DNS协议标准的扩展(即增加新的扩展字段)，例如，不同的路径请求预先定义在扩展DNS请求的伪资源记录的扩展字段内，该扩展字段预先向互联网数字分配机构申请得到；另一种定义方式还可以是兼容现有的标准协议，例如，不同路径请求预先定义在扩展DNS请求的标准资源记录的type字段内。
在本申请上述实施方式中，阐述了几种将路径请求定义在扩展DNS请求的资源记录的几种实现方式，可根据实际情况选择如何定义，具备可选择性。
本申请实施例第二方面还提供一种路由方法，该方法包括：首先，源端设备向Http DNS服务器发送第一Http请求，该第一Http请求中包括第一路径请求，该第一路径请求就用于指示后续源端设备向目的端设备发送数据包的时候通过的是什么路径(即指示源端设备向目的端设备发送数据包的方式)。在本申请实施例中，不同的路径请求预先定义在Http请求内，定义过程不涉及标准，因此无需向机构申请。源端设备在向Http DNS服务器发送了第一Http请求后，之后将获取由Http DNS服务器发送的第一Http响应，该第一Http响应由Http DNS服务器生成，该第一Http响应中包括与第一路径请求对应的路径信息，该路径信息由Http DNS服务器根据该第一Http请求中的信息做匹配查询得到。需要注意的是，在本申请实施例中，在该路径信息的取值不为空的情况下，该路径信息包括源端设备到目的端设备之间的转发节点以及转发节点的先后转发顺序。最后，源端设备经由转发节点(即路径信息中包括的转发节点)按照所述先后转发顺序将待发送的目标数据包向该目的端设备发送。类似地，当转发节点为1个时，则默认先后转发顺序就是由这1个转发节点进行转发，当转发节点为n个(n≥2)，则是正常的先后转发顺序。
在本申请上述实施方式中，将对路径的请求以及对路径请求的响应(即Http DNS服务器规划的路径信息)分别携带在Http请求和Http响应中，从而实现为源端设备上的应用提供访问目的端设备的路径的控制能力。具体来说，首先，源端设备将路径请求携带在Http请求中向Http DNS服务器发送，Http DNS服务器基于接收到的Http请求规划路径，并将规划的路径信息携带在Http响应中向源端设备发送，再由该源端设备根据该路径信息的具体内容(如，包括几个转发节点、转发节点之间的先后转发顺序等)将目标数据包向目标的端设备发送。本申请实施例以Http请求和Http响应为媒介，将路径信息配置在Http响应中从真正的数据源头发起SR，在终端为互联网传输配置端到端传输路径，提高了路由效率，并提升了互联网业务端到端表现。
在第二方面的一种可能的实现方式中，在路径信息的取值不为空的情况下，也就是说，该路径信息至少包括有一个转发节点，源端设备对收到的第一Http响应进行解析，并经由该路径信息所包括的转发节点按照先后转发顺序将待发送的目标数据包向目的端设备发送的过程具体可以是：首先，源端设备根据得到的路径信息对目标数据包进行封装，得到封装了头域(可称为第一头域)的数据包(可称为第一数据包)，该第一头域内包括转发节点的先后转发顺序、源端设备的源地址以及第一跳转发节点的地址，之后，源端设备将第一数据包发送至第一跳转发节点，第一跳转发节点根据该第一头域内包括的转发节点的先后转发顺序判断自身是否是最后一跳转发节点，若该第一跳转发节点不是最后一跳转发节点，在这种情况下，第一转发节点对该第一数据包的第一头域解封装后，再对目标数据包进行再封装，得到由第一转发节点封装了头域(可称为第二头域)的数据包(可称为第二数据包)，此时，该第二数据包则包括转发节点的先后转发顺序、第一跳转发节点的地址以及第二跳转发节点的地址，之后，由该第一跳转发节点根据转发节点的先后转发顺序将该第二数据包向第二跳转发节点发送。类似地，第二跳转发节点根据该第二数据包中的第二头域 内包括的转发节点的先后转发顺序判断自身是否是最后一跳转发节点，若该第二跳转发节点是最后一跳转发节点，在这种情况下，第二跳转发节点对该第二数据包的第二头域解封装(即删除该第二数据包的第二头域)，得到初始的目标数据包，并由该第二跳转发节点将该删除了第二头域的目标数据包向目的端设备发送。需要注意的是，在本申请实施例中，路径信息中除了最后一跳转发节点之外，其他每个转发节点都需对上一个转发节点(对第一跳转发节点来说，上一个转发节点则为源端设备)发送的数据包进行解封装后再封装，再封装的头域里的最外层网络包头里写入的就是转发节点的先后转发顺序、自身的地址以及下一跳转发节点的地址。当某个转发节点接收到由上一个转发节点发送的数据包，根据数据包中头域内的先后转发顺序得知自身为最后一跳，那么该转发节点去除所有头域，得到初始的目标数据包，再由该最后一跳转发节点将得到的目标数据包发送给目的端设备。
在本申请上述实施方式中，阐述了当路径信息中包括至少两个转发节点时，源端设备以及各个转发节点基于头域中封装入的转发节点之间的先后转发顺序实现将目标数据包发送至目的端设备的目的，在本申请实施例提供的路由方法中，转发节点无需维护任何表项，避免了与Http DNS服务器的交互与更新，所有转发状态均在数据包内部，降低了维护成本。
在第二方面的一种可能的实现方式中，若路径信息中只包括一个转发节点(即第一转发节点)，那么该第一转发节点接收到由源端设备发送的封装了头域的数据包后，由该头域内包括的转发节点的先后转发顺序得知，自身不仅是第一跳转发节点，也是最后一跳转发节点，那么该转发节点会将头域删除，并将删除了头域的目标数据包向目的端设备发送。
在本申请上述实施方式中，阐述了当路径信息中只包括一个转发节点时目标数据包如何经由该转发节点发送到目的端设备，也就是不管路径信息中包括几个转发节点，都可实现基于头域中封装入的转发节点之间的先后转发顺序实现将目标数据包发送至目的端设备的目的，具备广泛适用性。
在第二方面的一种可能的实现方式中，在路径信息的取值为空的情况下，说明最优路径是公网直连通信，无需转发节点的参与，那么源端设备直接将目标数据包向目的端设备发送。
在本申请上述实施方式中，阐述了当路径信息中没有转发节点时目标数据包如何由该源端设备发送到目的端设备，具备灵活性。
在第二方面的一种可能的实现方式中，该第一Http请求的生成可以有多种触发形式，作为一个示例，该第一Http请求可以通过安装于该源端设备的SDK生成，具体地，可以是源端设备上安装的应用发起会话请求，该会话请求触发源端设备调用SDK生成第一扩展DNS请求；作为另一示例，该第一Http请求也可以是在应用中事先写好的软件模块，当源端设备上安装的应用发起会话请求，该会话请求就会触发源端设备调用该应用中的软件模块生成第一Http请求；作为另一示例，通过对现有的通信协议进行改写，使得改写得到的新的通信协议可支持生成该第一Http请求。具体地，本申请对如何触发生成第一Http请求的具体实现方式不做限定，此处不再举例示意。
在本申请上述实施方式中，阐述了几种触发第一Http请求生成的应用场景，具备普遍适用性。
在第二方面的一种可能的实现方式中，第一路径请求至少包括如下信息中的任意一种：待发送数据所要去向的目的端设备的地址(即上述所述的目的端地址)、待发送数据的应用类型(如，实时音视频类应用、游戏类应用、浏览器类应用等)、待发送数据的应用ID(如，可以是Overlay网络运营商所维护的应用标识符)、待发送数据的业务类型(如，该数据流是实时音视频数据、游戏指令类数据、网页请求类数据等)、待发送数据的QoS要求(如，待发送数据所需要的QoS性能)、待发送数据要求使用的第一路径类型。
在本申请上述实施方式中，具体阐述了第一路径请求可以是哪些类型的信息，基于这些信息，控制器可对路径信息进行规划，以选择出适合当前待发送数据的最优路径，具备广泛适用性。
在第二方面的一种可能的实现方式中，第一路径类型至少包括如下类型中的任意一种：Overlay网络路径、SRv6路径或SFC路径。
在本申请上述实施方式中，具体阐述了第一路径类型的几种具体形式，由用户根据需求自行选择选择哪种路由路径，具备可选择性。
在第二方面的一种可能的实现方式中，路径类型不同，所涉及的转发节点的类型也不同，例如，当第一路径类型是Overlay网络路径时，转发节点就为PoP；当第一路径类型是SRv6路径，转发节点就为SRv6路由器；当第一路径类型为SFC路径，转发节点就为支持SFC的硬件设备。在本申请实施例中，转发节点的类型与路径类型相关，此处不予赘述。
在本申请上述实施方式中，具体阐述了当第一路径类型选择不同，所涉及的转发节点的具体表现形式也不同，在实际应用中，可根据转发节点的具体部署情况选择合适的路由路径，具备灵活性。
本申请实施例第三方面还提供一种路由方法，该方法包括：首先，控制器获取由源端设备发送的第一扩展DNS请求，该第一扩展DNS请求中包括第一路径请求，该第一路径请求用于指示后续源端设备向目的端设备发送数据包的时候通过的是什么路径(即指示源端设备向目的端设备发送数据包的方式)，在本申请实施例中，不同的路径请求是事先定义在扩展DNS请求的资源记录的字段内的，具体可以有多种实现方式，例如，可以是对扩展DNS协议标准的扩展(即增加新的扩展字段)，也可以是兼容现有的标准协议，具体本申请对将不同的路径请求定义在扩展DNS请求的资源记录的字段内的具体实现方式不做限定。控制器接收到该第一扩展DNS请求后，可以根据该第一扩展DNS请求中的信息做匹配查询，得到与该第一路径请求对应的路径信息。控制器基于该第一扩展DNS请求得到路径信息后，会向源端设备发送该第一扩展DNS响应，该路径信息就包含在该第一扩展DNS响应中。需要注意的是，在本申请实施例中，在该路径信息的取值不为空的情况下，该路径信息包括源端设备到目的端设备之间的转发节点以及转发节点的先后转发顺序，以使得源端设备经由转发节点(即路径信息中包括的转发节点)按照所述先后转发顺序将待发送的目标数据包向该目的端设备发送。需要注意的是，当转发节点为1个时，则默认先后转发顺序就是由这1个转发节点进行转发，当转发节点为n个(n≥2)，则是正常的先后转发顺序。
在本申请上述实施方式中，将对路径的请求以及对路径请求的响应(即控制器规划的 路径信息)携带在扩展DNS报文中，从而实现为源端设备上的应用提供访问目的端设备的路径的控制能力。具体来说，控制器基于接收到的扩展DNS请求规划路径，该扩展DNS请求中包含有对路径的请求(即第一路径请求)，并将规划的路径信息携带在扩展DNS响应中向源端设备发送，再由该源端设备根据该路径信息的具体内容(如，包括几个转发节点、转发节点之间的先后转发顺序等)将目标数据包向目标的端设备发送。该本申请实施例以扩展DNS报文为媒介，将路径信息配置在扩展DNS报文中的响应报文中从真正的数据源头发起SR，在终端为互联网传输配置端到端传输路径，提高了路由效率，并提升了互联网业务端到端表现。
在第三方面的一种可能的实现方式中，在路径信息的取值为空的情况下，说明最优路径是公网直连通信，无需转发节点的参与，那么源端设备直接将目标数据包向目的端设备发送。
在本申请上述实施方式中，阐述了当路径信息中没有转发节点时目标数据包如何由该源端设备发送到目的端设备，具备灵活性。
在第三方面的一种可能的实现方式中，控制器获取由源端设备发送的第一扩展DNS请求的实现方式具体可以是：由源端设备先将生成的第一扩展DNS请求向与该源端设备对应的DNS服务器发送，控制器再接收由该DNS服务器发送的第一扩展DNS请求。类似地，控制器向源端设备发送第一扩展DNS响应的具体实现方式具体可以是：由控制器先将生成的第一扩展DNS响应向与该源端设备对应的DNS服务器发送，再由该DNS服务器将第一扩展DNS响应向源端设备发送。
在本申请上述实施方式中，具体阐述了源端设备与控制器之间的数据交互是经由与该源端设备对应的DNS服务器进行的，具备可实现性。
本申请实施例第四方面还提供一种路由方法，该方法包括：首先，Http DNS服务器获取由源端设备发送的第一Http请求，该第一Http请求中包括第一路径请求，该第一路径请求用于指示后续源端设备向目的端设备发送数据包的时候通过的是什么路径(即指示源端设备向目的端设备发送数据包的方式)，在本申请实施例中，不同的路径请求是事先定义在Http请求内，定义过程不涉及标准，因此无需向机构申请。Http DNS服务器接收到该第一Http请求后，可以根据该第一Http请求中的信息做匹配查询，得到与该第一路径请求对应的路径信息。Http DNS服务器基于该第一Http请求得到路径信息后，会向源端设备发送该第一Http响应，该路径信息就包含在该第一Http响应中。需要注意的是，在本申请实施例中，在该路径信息的取值不为空的情况下，该路径信息包括源端设备到目的端设备之间的转发节点以及转发节点的先后转发顺序，以使得源端设备经由转发节点(即路径信息中包括的转发节点)按照所述先后转发顺序将待发送的目标数据包向该目的端设备发送。需要注意的是，当转发节点为1个时，则默认先后转发顺序就是由这1个转发节点进行转发，当转发节点为n个(n≥2)，则是正常的先后转发顺序。
在本申请上述实施方式中，将对路径的请求以及对路径请求的响应(即Http DNS服务器规划的路径信息)分别携带在Http请求和Http响应中，从而实现为源端设备上的应用提供访问目的端设备的路径的控制能力。具体来说，首先，源端设备将路径请求携带在Http 请求中向Http DNS服务器发送，Http DNS服务器基于接收到的Http请求规划路径，并将规划的路径信息携带在Http响应中向源端设备发送，再由该源端设备根据该路径信息的具体内容(如，包括几个转发节点、转发节点之间的先后转发顺序等)将目标数据包向目标的端设备发送。本申请实施例以Http请求和Http响应为媒介，将路径信息配置在Http响应中从真正的数据源头发起SR，在终端为互联网传输配置端到端传输路径，提高了路由效率，并提升了互联网业务端到端表现。
在第四方面的一种可能的实现方式中，在路径信息的取值为空的情况下，说明最优路径是公网直连通信，无需转发节点的参与，那么源端设备直接将目标数据包向目的端设备发送。
在本申请上述实施方式中，阐述了当路径信息中没有转发节点时目标数据包如何由该源端设备发送到目的端设备，具备灵活性。
本申请实施例第五方面提供一种终端设备，该终端设备作为源端设备，具有实现上述第一方面或第一方面任意一种可能实现方式的方法的功能。该功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。该硬件或软件包括一个或多个与上述功能相对应的模块。
本申请实施例第六方面还提供一种终端设备，该终端设备作为源端设备，具有实现上述第二方面或第二方面任意一种可能实现方式的方法的功能。该功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。该硬件或软件包括一个或多个与上述功能相对应的模块。
本申请实施例第七方面还提供一种控制器，该控制器具有实现上述第三方面或第三方面任意一种可能实现方式的方法的功能。该功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。该硬件或软件包括一个或多个与上述功能相对应的模块。
本申请实施例第八方面还提供一种Http DNS服务器，该Http DNS服务器具有实现上述第四方面或第四方面任意一种可能实现方式的方法的功能。该功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。该硬件或软件包括一个或多个与上述功能相对应的模块。
本申请实施例第九方面提供一种终端设备，可以包括存储器、处理器以及总线系统，其中，存储器用于存储程序，处理器用于调用该存储器中存储的程序以执行本申请实施例第一方面或第一方面任意一种可能实现方式的方法，或，处理器用于调用该存储器中存储的程序以执行本申请实施例第二方面或第二方面任意一种可能实现方式的方法。
本申请实施例第十方面提供一种控制器，可以包括存储器、处理器以及总线系统，其中，存储器用于存储程序，处理器用于调用该存储器中存储的程序以执行本申请实施例第三方面或第三方面任意一种可能实现方式的方法。
本申请实施例第十一方面提供一种Http DNS服务器，可以包括存储器、处理器以及总线系统，其中，存储器用于存储程序，处理器用于调用该存储器中存储的程序以执行本申请实施例第四方面或第四方面任意一种可能实现方式的方法。
本申请第十二方面提供一种计算机可读存储介质，该计算机可读存储介质中存储有指 令，当该指令在计算机上运行时，使得计算机可以执行上述第一方面或第一方面任意一种可能实现方式的方法，或，使得计算机可以执行上述第二方面或第二方面任意一种可能实现方式的方法，或，使得计算机可以执行上述第三方面或第三方面任意一种可能实现方式的方法，或，使得计算机可以执行上述第四方面或第四方面任意一种可能实现方式的方法。
本申请实施例第十三方面提供了一种计算机程序或计算机程序产品，当该计算机程序或计算机程序产品在计算机上运行时，使得计算机执行上述第一方面或第一方面任意一种可能实现方式的方法，或，使得计算机可以执行上述第二方面或第二方面任意一种可能实现方式的方法，或，使得计算机可以执行上述第三方面或第三方面任意一种可能实现方式的方法，或，使得计算机可以执行上述第四方面或第四方面任意一种可能实现方式的方法。
本申请实施例第十四方面提供了一种芯片，该芯片包括至少一个处理器和至少一个接口电路，该接口电路和该处理器耦合，至少一个接口电路用于执行收发功能，并将指令发送给至少一个处理器，至少一个处理器用于运行计算机程序或指令，其具有实现如上述第一方面或第一方面任意一种可能实现方式的方法的功能，或，具有实现如上述第二方面或第二方面任意一种可能实现方式的方法的功能，或，具有实现如上述第三方面或第三方面任意一种可能实现方式的方法的功能，或，具有实现如上述第四方面或第四方面任意一种可能实现方式的方法的功能，该功能可以通过硬件实现，也可以通过软件实现，还可以通过硬件和软件组合实现，该硬件或软件包括一个或多个与上述功能相对应的模块。此外，该接口电路用于与该芯片之外的其它模块进行通信，例如，该接口电路可将芯片上处理器得到的路径信息封装后发生给目的端设备，如，发送给其他终端设备(如，手机、个人电脑、智能手表等)或云侧设备(如，云服务器、集群等)。
附图说明
图1为传统DNS解析流程的一个示意图；
图2为标准DNS报文格式的一个示意图；
图3为扩展DNS报文中的伪资源记录的一个示意图；
图4为扩展DNS报文中伪资源记录中各个部分之间关系的一个示意图；
图5为基于智能DNS的GSLB请求流程的一个示意图；
图6为互联网Overlay技术的一个应用场景图；
图7为现有Overlay智能路由的三个子系统的一个框架结构图；
图8为本申请实施例提供的路由方法的一个流程示意图；
图9为DNS协议中标准资源记录格式的一个示意图；
图10为一个标准资源记录的实例；
图11为本申请实施例提供的数据包的一种封装格式的示意图；
图12为本申请实施例提供的数据包的另一种封装格式的示意图；
图13为本申请实施例提供的数据包在各个转发节点之间传递过程的一个示意图；
图14为本申请实施例提供的路由方法的整体流程的一个场景示意图；
图15为本申请实施例提供的各个PoP各自对目标数据包进行解封、再封装以及转发过 程的一个示意图；
图16为本申请实施例提供的兼容性分析的一个示意图；
图17为本申请实施例提供的路由方法的另一流程示意图；
图18为本申请实施例提供的路由方法与传统互联网传输的DNS解析方案的对比示意图；
图19为本申请实施例提供的实验拓扑图；
图20为本申请实施例提供的任意两点间时延分布的一个示意图；
图21为本申请实施例提供的PoP点数目分别在100、200、500场景下，四种方法时延随距离的变化曲线的对比图；
图22为用户与服务器的回源请求借助边缘代理服务器做中转建立连接的一个流程示意图；
图23为本申请实施例提供的终端设备的一个结构示意图；
图24为本申请实施例提供的终端设备的另一结构示意图；
图25为本申请实施例提供的控制器的一个结构示意图；
图26为本申请实施例提供的Http DNS服务器的一个结构示意图；
图27为本申请实施例提供的计算机设备的一个结构示意图。
具体实施方式
本申请实施例提供了一种路由方法及设备，用于为源端设备上的应用提供访问目的端设备的路径的控制能力，并将SR域延伸至终端设备，从真正的数据源头发起SR，在终端为互联网传输配置端到端传输路径，提高了路由效率，并提升了互联网业务端到端表现。
本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的术语在适当情况下可以互换，这仅仅是描述本申请的实施例中对相同属性的对象在描述时所采用的区分方式。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，以便包含一系列单元的过程、方法、系统、产品或设备不必限于那些单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它单元。
本申请实施例涉及了许多关于DNS的相关知识，为了更好地理解本申请实施例的方案，下面先对本申请实施例可能涉及的相关术语和概念进行介绍。
(1)域名系统(domain name system，DNS)
DNS是互联网的一项服务，它作为将域名和IP地址相互映射的一个分布式数据库，能够使人更方便地访问互联网。
具体来说，DNS是互联网上解决网上机器命名的一种系统，传统DNS域名的解析过程为：用户通过终端设备(也可称为源端设备)访问某个网站时，需要首先通过DNS服务器(一种用于提供域名解析服务的服务器)获得该网站的IP地址。域名解析通常不是一次性完成的，常常需要查询若干不同的DNS服务器才能找到该网站对应的IP地址。如图1所示，图1为传统DNS解析流程的一个示意图，用户首先在本地的源端设备上配置一个本 地DNS服务器的地址，本地DNS服务器收到用户通过该源端设备发送的DNS请求，若该本地DNS服务器对该DNS请求不能解析，会将该DNS请求转发给更高一级的DNS服务器(如，DNS根服务器)直到找到域名对应的IP地址或确定域名不存在。
(2)DNS报文
域名-实现及标准(RFC1035)中定义了两种报文，一种为查询报文(也可称为DNS请求)，另一种是对查询报文的响应，称为响应报文(也可称为DNS响应)。DNS请求和DNS响应都是用相同的报文格式，分成5个段(有的报文段在不同的情况下可能为空)，如图2所示，图2为标准DNS报文格式的一个示意图，其中，Header段是必须存在的，它定义了DNS报文的类型是DNS请求还是DNS响应，也定义了其他段是否需要存在，以及是标准查询还是其他；Question段描述了查询的问题，包括查询类型(QTYPE)、查询类(QCLASS)以及查询的域名(QNAME)；剩下的3个段则拥有相同的格式，具体地，包含一系列可能为空的资源记录(resource record，RR)，若是多条资源记录，则记为RRs，Answer段包含回答问题的RRs，Authority段包含授权域名服务器的RRs，Additional段则包含和请求相关的但不是必须回答的RRs。
(3)扩展DNS报文
随着业务的复杂化和多样化，RFC1035中定义的DNS消息格式和它支持的消息内容已经不足以满足一些DNS服务器的需求，于是，RFC2671中提出了一种扩展DNS机制(extension mechanisms for DNS，EDNS)，可称为扩展DNS报文，与DNS报文类似，扩展DNS报文也包括两种报文，一种称为扩展DNS请求，另一种为对扩展DNS报文的响应，称为扩展DNS响应，扩展DNS报文是在已有的DNS报文格式的基础上增加一些字段，来支持更多的DNS请求业务。需要注意的是，像DNS服务器这样一个大型且广泛应用的系统软件，新增加扩展协议的时候要考虑到向后兼容性(backward compatibility)，即增加了新特性的消息传输给未支持该特性的服务器时，后者依然能正确处理。
因此，为了保持向后兼容性，并不会对已有的DNS报文的协议格式做更改，而是在扩展DNS报文中引入了一种新的伪资源记录(option resource record，OPT RR)，之所以叫做伪资源记录是因为它不包含任何DNS数据，OPT RR不能被缓存(cache)、不能被转发、不能被存储在zone文件(zone文件是DNS服务器上保存域名配置的文件)中。伪资源记录被放在DNS通信双方(即requestor和responsor)的扩展DNS报文的Additional段的区域内。如图3所示，图3为扩展DNS报文中的伪资源记录的一个示意图，其中，图3中的(a)子示意图为扩展DNS报文中伪资源记录的结构示意图，其包括固定部分和可变部分，最下面的RDATA是可变部分，其余的部分都是固定部分：NAME字段目前为空；TYPE字段是伪资源记录的类型编号，互联网数字分配机构(internet assigned numbers authority，IANA)为其分配的是41(0x29)；TTL字段中是扩展DNS报文消息头部，下面会有介绍；RDLEN字段是可变部分RDATA的长度；RDATA是KV类型的可变部分。而原来的TTL字段被用来存储扩展消息头部中的RCODE和flags，它的格式如图3中的(b)子示意图所示，在图3的(b)子示意图中，高位8个bit是扩展RCODE(返回状态码)，这8个bit加上DNS头部的4bit总共有12bit(8bit在高位)，这样就可以表示更多的返回类型； VERSOION字段表示扩展DNS报文的版本(扩展DNS报文根据支持不同的扩展内容会有很多版本)。在扩展DNS报文中，可变部分RDATA字段的结构则如图3中的(c)子示意图所示，图3中(c)子示意图的OPTION-CODE由IANA分配，OPTION-LENGTH是OPTION-DATA的长度，OPTION-DATA是具体长度。图3中各子示意图中间的关系可如图4所示。需要注意的是，每个DNS消息中只能有一个伪资源记录，当有多种扩展DNS协议时，各个{attribute,value}对一个紧接一个存储在RDATA字段中。
此外，在介绍本申请实施例之前，先对目前源端设备到目的端设备的几种常见路由方式进行简单介绍，使得后续便于理解本申请实施例。
方式一、基于智能DNS的GSLB
基于智能DNS的GSLB请求流程如图5所示，根DNS服务器(在图5中简称根DNS)会将DNS请求转发到GSLB设备(即图5中的基于DNS的GSLB)上，GSLB设备根据服务器的负载情况以及用户的IP信息为用户解析最优的IP地址，放入DNS响应中回复给本地DNS服务器，并由该本地DNS服务器将该DNS响应最终返回给用户。
该方式一解决了源端设备上的应用对用户请求目的地(即目的端设备)的控制，但无法控制目的地访问的路径。例如，源端设备上的应用基于自身的需求考虑(如，安全性考虑、性能考虑等)，想进一步对用户请求的路径做进一步优化，那么该方式一就无法满足该需求。
方式二、Overlay智能路由
由于互联网由多个运营商/互联网服务提供商(internet service provider，ISP)/自治域组成，域间的互联存在着复杂的商业关系，互联网的传输路径受商业关系影响，往往不会是网络中的最短路径。例如，两个亚洲节点间的传输可能会被绕到欧洲，进而增加了端到端的时延。同时，由于互联网的路由对路径性能不感知，路径中的失败或拥塞往往很难避免，或需要很长的收敛时间。
为解决互联网路径的非最优问题，业界提出互联网Overlay技术，通过在互联网上不同地区的数据中心放置转发单元，相互连接互相调度，在现有的公共互联网(即Underlay网络)基础上构建一层新的虚拟覆盖网络(即Overlay网络)。中间部署的转发节点可称为转发中继或PoP。为便于理解，请参阅图6，图6为互联网Overlay技术的一个应用场景图，在图6中，源端设备到目的端设备之间的默认链路为虚线所示的路径，假设在域A和域B间的跨域链路当前面临严重的拥塞，那么依然按照该默认链路进行路由会导致端到端性能下降。而通过Overlay技术，在域A、域B和域C中分别部署有PoP，其中，域A上部署的PoP称为PoP1，域B上部署的PoP称为PoP2，域C上部署的PoP称为PoP3，并在该源端设备部署SDK软件开发工具包(software development kit，SDK)，将流量接入PoP1。Overlay骨干网控制PoP1到PoP3的路由为PoP1→PoP2→PoP3，从而有效绕开域A和域B间的拥塞链路，提升整体端到端表现。
Overlay智能路由是Overlay技术的关键，直接决定接入Overlay网络的用户的传输性能。Overlay智能路由为用户传输选择适合的Overlay网络转发节点PoP，组成端到端最优转发路径。现有Overlay智能路由方案由三个子系统共同实现，这三个子系统分别为：入 口PoP选择系统、出口PoP选择系统和Overlay网络内部路由系统。下面对这三个子系统分别进行介绍。
1)入口PoP选择系统
该系统根据用户使用的源端设备的源地址选择最优入口PoP作为首跳接入Overlay网络。源端设备通过部署于该源端设备的SDK发送数据包。为接入Overlay网络，首先，源端设备向入口PoP选择系统发送会话请求，上报源端设备的源地址，入口PoP选择系统通过匹配该源地址，为该用户会话选择最优的入口PoP的IP地址，通常选择原则遵循就近接入原则，即为用户选择距离该源端设备最近的入口PoP，源端设备的源地址与入口PoP的IP地址之间的映射关系可称为“源IP-入口PoP”映射表，该映射表由入口PoP选择系统洗发给入口PoP；源端设备获取到入口PoP的IP地址后，该源端设备在原网络层数据包外侧封装新的外层网络头，目的IP就写为入口PoP的IP地址，并将封装后数据包送入Underlay网络进行传输。这里需要注意的是，数据的传输过程实质都还是基于Underlay网络进行的，overlay网络中的PoP只是用于指示该将数据包发往哪个域。
为便于理解，请参阅图7，图7为现有Overlay智能路由的三个子系统的一个框架结构图，在图7中，源端设备从入口PoP选择系统获取最近的入口PoP的地址(记为PoP1 IP)，获取后由源端设备将PoP1 IP写入数据包的最外层网络包头，目的IP为PoP1 IP，源IP保持不变。
2)出口PoP选择系统
该系统根据目的端设备的IP地址选择出口PoP作为Overlay网络的最后一跳。该系统选择原则通常也是就近原则，即为用户选择距离目的端设备最近的PoP的IP地址，目的端设备的IP地址与出口PoP的IP地址之间的映射关系可称为“目的IP-出口PoP”映射表，该映射表由出口PoP选择系统下发给出口PoP(在一些实现方式中，上述“源IP-入口PoP”映射表与“目的IP-出口PoP”映射表可被合并为一张表，由入口PoP选择系统和出口PoP选择系统分别下发给入口PoP和出口PoP)。具体地，数据包到达入口PoP，入口PoP将最外层网络包头解封装，根据原数据包目的端的IP地址与“目的IP-出口PoP”映射表进行比对，获取出口PoP的IP地址，之后入口PoP在原网络层数据包外侧封装头域，写入出口PoP的IP地址。
如图7所示，数据包到达PoP1后，PoP1解开外层封装，得到原数据包目的端设备的IP地址。将该地址与PoP1维护的“目的IP-出口PoP”映射表(“源IP-入口PoP”映射表与“目的IP-出口PoP”映射表可被合并为一张表合并为一张表的情况)进行比对，得到目的端设备的IP地址最近的出口PoP为PoP3，进而将PoP3的IP地址写入出口PoP字段。
3)Overlay网络内部路由系统
该系统根据出口PoP的IP地址选择下一跳PoP转发点。该系统在Overlay网络内部做PoP等级的路由，通过向各中间PoP节点下发路由表实现，路由表匹配出口PoP，返回下一跳PoP。数据包到达某一PoP时，该PoP将最外层网络包头去掉，并根据头域中的出口PoP地址选择下一跳PoP，选择后将下一跳PoP的IP地址写在最外层网络包头。
如图7所示，假设Overlay网络中从PoP1到PoP3的最优路由是PoP1-PoP2-PoP3(该 最优路径由Overlay网络内部路由子系统计算得到)，数据包在PoP1封装出口PoP后，匹配路由表，发现下一跳是PoP2，然后将PoP2的IP地址封装至最外层网络头的目的IP，并送至Underlay网络，Underlay网络会根据目的端设备的IP地址(即目的IP)送至PoP2，PoP2接收数据包，解开外层封装，匹配出口PoP，得到下一跳PoP3，由该PoP2做进一步封装后发送到PoP3。PoP3收到数据包后，发现自己是最后一跳，PoP3将外层封装全部去除，将原始数据包送至Underlay网络，并根据最终目的IP将该数据包送到目的端设备。
该方式二的路由方式的缺点在于各子系统各自独立对路径进行独立优化，然而本地最优决策不等于端到端的全局最优决策。具体而言，选择最优的入口/出口PoP(即距离源端设备/目的端设备最近)并不一定在端到端也是最优的。如图7所示，假设最优的端到端的路径是源端设备→PoP2→目的端设备，但由于该方式二是各子系统独立优化，无论该系统选择的路径是怎样的，都至少会包括入口PoP和出口PoP在内的至少2个PoP，这样实际上就无法获得源端设备→PoP2→目的端设备这条最优路径。此外，该方式二中的每个子系统各自维护状态，每个PoP节点都需部署有对应相关的子系统下发的映射表或路由表，在网络动态变化时各子系统更新难度大，同时会面临更新不一致的问题，导致短暂的发送异常，如，黑洞、环路等。
方式三、分段/源路由(即SR)
SR是一项基于源的路由技术，可简化跨网络域的流量工程和管理。源主机/路由器等根据多个不同子网或内网地址，在数据包头部添加相关的路由信息来为数据包规划转发路径，从而实现网络中的数据平面有选择性地将数据包发往不同目的地。SR的主要优势在于其简化网络和降低资源占用的能力，该技术可以消除网络中过渡路由器和节点的网络状态信息，并且将路径状态信息置入入口节点的数据包标头中，从而使网络管理和运维更加容易。
SR可通过集中控制器对网络路径进行全局优化，同时简化中间节点转发状态维护。但该技术目前只工作在网络内部，如路由器、交换机或PoP，无法将SR技术应用于用户终端，如手机或PC。在终端上应用SR的主要难点是对SR域的控制，体现在可控性差和动态性高。基于可控性，终端厂商不同，内核协议栈不可控，并且网络传输过程涉及大量运营商/ISP或云骨干，无法做到整体控制。基于动态性，在传统SR中，中心控制器通过PCEP协议或Openflow协议配置到相应转发设备，且相对静态，更新难度小，但终端设备数量庞大，且具备移动性，无法下达静态配置。
综上所述，为解决上述问题，本申请实施例首先提供了一种路由方法，用于为源端设备上的应用提供访问目的端设备的路径的控制能力，并将SR域延伸至终端设备，从真正的数据源头发起SR，在终端为互联网传输配置端到端传输路径，提高了路由效率，并提升了互联网业务端到端表现。
下面结合附图，对本申请的实施例进行描述。本领域普通技术人员可知，随着技术的发展和新场景的出现，本申请实施例提供的技术方案对于类似的技术问题，同样适用。具体请参阅图8，图8为本申请实施例提供的路由方法的一个流程示意图，具体可以包括如下步骤：
801、源端设备向控制器发送第一扩展DNS请求，第一扩展DNS请求中包括第一路径请求。
首先，源端设备会向控制器发送第一扩展DNS请求，该第一扩展DNS请求中包括第一路径请求，该第一路径请求就用于指示后续源端设备向目的端设备发送数据包的时候通过的是什么路径(即用于指示源端设备向目的端设备发送数据包的方式)。
需要注意的是，在本申请实施例中，第一路径请求中包括决定路由路径的相关信息，第一路径请求所包括的信息不同，那么控制器基于该第一路径请求规划的路径信息也不同。例如，该第一路径请求中至少包括如下信息中的任意一种：待发送数据所要去向的目的端设备的地址(即上述所述的目的端地址)、待发送数据的应用类型、待发送数据的应用ID、待发送数据的业务类型、待发送数据的QoS要求、待发送数据要求使用的第一路径类型。下面分别进行介绍：
a、待发送数据所要去向的目的端设备的地址，也就是所述的目的端地址，可以是具体的IP地址或URL(该地址也可存放于扩展DNS请求中的QUESTION字段内)。
b、待发送数据的应用类型，例如，实时音视频类应用、游戏类应用、浏览器类应用等，需注意的是，在本申请实施例中，针对应用类型的划分方式可以基于终端设备从终端设备的“应用市场”、“App Store”等(终端设备的制造厂商不同，名称可能不同，此处不做限定)下载应用程序时，应用市场中已经将各个应用程序进行了分类(即应用市场标签确定的分类信息，从应用市场中下载的每个应用程序都有属于自己的分类)。
c、待发送数据的应用ID，可以是Overlay网络运营商所维护的应用标识符，通过匹配映射，可获知该待发送数据发送的QoS需求及优先级等，例如，某些应用购买了Overlay网络的优质加速服务，则计算路径时将会分配更为优质的路径，而为低优先级应用分配路径时，可以分配传输成本更低的路径。
d、待发送数据的业务类型，是对该待发送数据流的描述，例如，待发送数据流是实时音视频数据、游戏指令类数据、网页请求类数据等，不同的业务类型对端到端性能的要求也不同，在计算路径时可纳入考量。
e、待发送数据的QoS要求，是对路径性能的直接描述，根据该信息，控制器为其分配满足QoS需求的路径，并有效规划资源。
f、待发送数据要求使用的路径类型(即所述的第一路径类型)，可包括Overlay网络路径、SRv6路径或SFC路径，所对应的是不同的传输场景，例如在SRv6网络中，源到目的地既可以使用Overlay路径传输，也可使用Underlay SRv6路径传输，通过在路径请求中传递该信息，可获取相应的路径信息。例如，假设第一路径类型是Overlay网络路径，那么路由的路径是通过Overlay网络进行转发；假设第一路径类型是SRv6路径，那么路由的路径是通过SRv6方式进行转发；假设第一路径类型是服务链(service function chain，SFC)路径，那么路由的路径是通过服务链方式进行转发，服务链路径的一种典型网络应用场景是：一个数据流通常需要通过多个网络服务设备(如，入侵检测系统(intrusion detection systems，IDS)、入侵防御系统(intrusion prevention systems，IPS)、防火墙、LB等)，最终才能到达目的端设备，这就是服务链最常用的场景，具体本申请不再对第一路径类型可 能存在的形式进行示意。
以上类别的信息在路径请求中可包含一种或多种，例如，仅包含应用ID，控制器维护相应的匹配关系，即可获知该路径请求的类别、相关QoS需求等。同时，该信息也不是必须信息，控制器可默认路径请求的类型等，具体此处不予赘述。
需要说明的是，在本申请实施例中，该第一扩展DNS请求的生成可以有多种触发形式，作为一个示例，该第一扩展DNS请求可以通过安装于该源端设备的SDK(终端软件套件，可被应用调用)生成，具体地，可以是源端设备上安装的应用发起会话请求，例如，浏览器应用访问www.huawei.com的会话请求，该会话请求触发源端设备调用SDK生成第一扩展DNS请求；作为另一示例，该第一扩展DNS请求也可以是在应用中事先写好的软件模块，当源端设备上安装的应用发起会话请求，该会话请求就会触发源端设备调用该应用中的软件模块生成第一扩展DNS请求；作为另一示例，通过对现有的通信协议进行改写，使得改写得到的新的通信协议可支持生成该第一扩展DNS请求。具体地，本申请对如何触发生成第一扩展DNS请求的具体实现方式不做限定，此处不再举例示意。
还需要说明的是，本申请所述的控制器可以部署在顶级DNS服务器上，也可以独立部署，可以是以硬件设备的形态存在，也可以是以软件模块的形态存在，还可以部署多个控制器以实现容灾功能(即在正常情况下，只有主控制器工作，其他控制器作为备份)，具体此处对控制器的具体表现形态、部署方式、部署数量等不做限定。
还需要说明的是，不同的路径请求是事先定义在扩展DNS请求的资源记录的字段内的，具体可以有多种实现方式，例如，可以是对扩展DNS协议标准的扩展(即增加新的扩展字段)，也可以是兼容现有的标准协议，具体本申请对将不同的路径请求定义在扩展DNS请求的资源记录的字段内的具体实现方式不做限定，为便于理解，作为一种示例，下面以第一路径请求中包含的信息为第一路径类型为例，并分别基于增加新的扩展字段和兼容现有的标准协议这两种定义方式进行阐述。
一、通过增加新的扩展字段达到在扩展DNS请求中定义路径类型的目的
在本申请实施例中，不同的路径类型可以预先定义在扩展DNS请求的伪资源记录的扩展字段内，该扩展字段需要预先向互联网数字分配机构(IANA)申请得到。
具体地，可参考图2，本申请实施例所提供的扩展DNS请求所包括的Header、Question、Answer、Authority字段与常规的DNS报文一致，例如，Question字段中将目的地址(可以是目的端设备的IP地址、URL地址等)放入QNAME字段，Answer字段为空。不同的地方在于，在该扩展DNS请求的Additional字段内，可正常添加应用所需的新的扩展字段，具体地，可以在最后一条之后添加新的与路径请求相关的RDATA，RDATA的标准格式如图3中的(c)子示意图所示。在本申请实施例中，需要预先向IANA申请新的OPTION-CODE：QPATH(该QPATH为自定义，申请被批准后即被公开)，OPTION-CODE：QPATH字段表示对路径类型的请求；而在OPTION-DATA字段内，则放入对路径类型请求的类别。例如，若OPTION-DATA内放入的是Overlay，表示请求的路径类型是基于Overlay网络的转发路径；若OPTION-DATA内放入的是SRv6，表示请求的路径类型是基于SRv6的转发路径(即可支持源端设备发起SRv6传输)；若OPTION-DATA内放入的是SFC，表 示请求的路径类型是基于SFC的转发路径(即可支持源端设备发起SFC传输)，具体本申请不再对OPTION-DATA内放入的路径类型进行示意。
需要注意的是，用QPATH表示对路径类型的请求是本申请自定义的，也可以用其他单词或句子表示对路径类型的请求，只要能够用于作为对路径类型的请求的唯一标识即可，具体本申请对该标识的具体表现形式不做限定。
还需要注意的是，本申请上述示例是直接用Overlay、SRv6、SFC等表示路径类型，在本申请的一些实施方式中，也可以赋予不同路径类型各自唯一对应的标识，对应的标识也可以用于指示对应的路径类型，例如，路径类型为Overlay网络、SRv6路径、SFC路径的标识可以分别是1(或，A、one等标识)、2(或，B、two等标识)、3(或，C、three等标识)，在这种情况下，当OPTION-DATA内的数据为对应标识时(如，1)，则说明对应的路径类型是Overlay网络。
二、通过兼容现有的标准协议达到在扩展DNS请求中定义路径类型的目的
与第一种方式不同的地方在于，本申请实施例给出了一种兼容现有标准协议的方法，即不同路径类型还可以预先定义在扩展DNS请求的标准资源记录内，例如，可以是定义在扩展DNS请求的标准资源记录的type字段内。这种方式的好处在于：不需要事先向IANA申请。
具体地，可参阅图9，图9为DNS协议中标准资源记录格式的一个示意图，图10为一个标准资源记录的实例。其中，图9中的TYPE字段表示资源记录类型，常用的几种资源记录类型如表1所示。
表1.几种常见的TYPE字段表示的资源记录类型
TYPE字段 资源记录类型
A 地址(address)，IPv4
AAAA 地址(address)，IPv6
NS 域名服务器(name server)
SOA 起始授权机构(start of authority)
MX 邮件交换(mail exchanger)
CNAME 规范名(canonical name)
PTR 指针(pointer)
TXT 文本(text)
SRV 服务(service)
由于TYPE字段用于表示资源记录类型，且TYPE字段内的TXT为自定义文本，不易产生冲突，因此，在本申请的一些实施方式中，可以利用TXT字段来达到定义路径类型的目的。例如，传统的资源请求在QUESTION字段中的QTYPE赋值A类型资源请求，服务器则返回QNAME中目的端设备的IP地址。而在本申请中，由于需获取路径类型，因此，可以在QTYPE中填写TXT类型。对路径请求的类型，可以对目的端设备地址进行扩展，如，对www.huawei.com的路径请求，则在QNAME字段内www.overlay.huawei.com代表Overlay网络的路径类型请求，QNAME字段内www.srv6.huawei.com代表SRv6路径类型 请求。控制器则需要配置代表不同路径类型的多条TXT类型的资源记录，资源记录的格式如图9所示，其中TYPE字段为TXT，NAME为扩展后的目的地址，RDATA则记录路径信息和目的端设备的IP地址，如{PoP1 IP，PoP2 IP，PoP3 IP，dst IP}，其中，PoP1 IP、PoP2 IP、PoP3 IP分别为PoP1、PoP2、PoP3的IP地址，dst IP指的是目的端设备的IP地址。
需要说明的是，在本申请的一些实施方式中，源端设备向控制器发送第一扩展DNS请求的实现方式具体可以是：由源端设备先将生成的第一扩展DNS请求向与该源端设备对应的DNS服务器发送，再由该DNS服务器将收到的第一扩展DNS请求向该控制器发送。具体地，可以由该DNS服务器对源端设备发送的第一扩展DNS请求进行递归查询，该递归查询的过程可复用常规DNS服务器的处理流程，此处不予赘述。
这里需要注意的是，与该源端设备对应的DNS服务器是对与该源端设备对应的本地DNS服务器、DNS根服务器、权威DNS服务器、顶级DNS服务器等的概括，用于接收源端设备发送的第一扩展DNS请求，并将该第一扩展DNS请求发送到所述的控制器。
在本申请实施例中，使得DNS服务器将该第一扩展DNS请求向控制器发送的实现方式可以是该控制器注册权威DNS服务器，并在DNS根服务器或顶级DNS服务器中加入该控制器的地址，这样当与该源端设备对应的DNS服务器接收到该第一扩展DNS请求，基于已注册的控制器的地址，基于递归查询流程，该第一扩展DNS请求会被发送到该控制器。例如，在.com服务器中注册huawei.com的权威服务器地址，当查询URL为www.huawei.com的扩展DNS请求时，该扩展DNS请求将被送至huawei.com权威服务器(即控制器部署位置)。
802、控制器根据该第一扩展DNS请求，得到与该第一路径请求对应的路径信息。
控制器接收到该第一扩展DNS请求后，可以根据该第一扩展DNS请求中的信息做匹配查询，得到与该第一路径请求对应的路径信息。需要注意的是，控制器根据该第一扩展DNS请求得到与该第一路径请求对应的路径信息的实现前提是：控制器已获得规划路径的必要信息(如，用户要求时延少、丢包少或带宽大等要求下的一些必要指令、指令优先等级等)，该必要信息可以是携带在该第一扩展DNS请求中，也可以是由与源端设备对应的DNS服务器向该控制器发送。为便于理解，下面分别进行阐述：
一、第一扩展DNS请求中已包含规划路径的全部必要信息
在本申请实施例中，第一扩展DNS请求中已包含控制器进行路径规划的全部必要信息，在这种情况下，控制器获取到该第一扩展DNS请求后，对该第一扩展DNS请求解析后，基于其中包含的全部必要信息，就可得到与该第一路径请求对应的路径信息，该路径信息一般为与第一路径请求对应的最优转发路径。
二、第一扩展DNS请求中不包含或只包含规划路径的部分必要信息
在本申请实施例中，第一扩展DNS请求中不包含规划路径的必要信息，或，第一扩展DNS请求中只包含规划路径的部分必要信息。在这种情况下，第一扩展DNS请求中不包含的必要信息一般是源端设备获取困难或不能获取到的，因此，在源端设备向对应的DNS服务器发送第一扩展DNS请求后，该DNS服务器需要为控制器收集对规划路径必要的其 他信息(即第一扩展DNS请求中不包含的那部分必要信息)。例如，源端设备的源地址，可以是由本地DNS服务器调用EDNS0扩展协议CSUBNET获得得到，再将该源地址加入该第一扩展DNS请求一起向控制器发送(或各自单独发送)。
这里需要注意的是，在本申请实施例中，获取源端设备的源地址不在源端设备而是在本地DNS服务器的原因是NAT穿越问题，源端设备上报的地址可能是私网地址(源地址理论上也可由源端设备自行获取，只是获取过程困难)，对控制器来说私网地址是无用信息，本地DNS服务器获取的地址则是公网地址(即本申请所述的源地址)，才可用于控制器做路径规划。
还需要说明的是，在本申请实施例中，默认控制器可基于得到的必要信息实现路径规划的功能，至于该控制器如何基于得到的必要信息得到规划好的路径信息，可基于已有的算法或自研算法得到，此处不做限定。
803、控制器向源端设备发送第一扩展DNS响应，该路径信息包含在该第一扩展DNS响应中，其中，在该路径信息的取值不为空的情况下，该路径信息包括源端设备到目的端设备之间的转发节点以及转发节点的先后转发顺序。
控制器基于该第一扩展DNS请求得到路径信息后，会向源端设备发送该第一扩展DNS响应，该路径信息就包含在该第一扩展DNS响应中。还需要说明的是，在本申请的一些实施方式中，控制器向源端设备发送第一扩展DNS响应的实现方式具体可以是：由控制器先将生成的第一扩展DNS响应向与该源端设备对应的DNS服务器发送，再由该DNS服务器将收到的第一扩展DNS响应向该源端设备发送。
类似地，第一扩展DNS响应作为第一扩展DNS请求的响应消息，针对不同路径请求的返回也可以是事先定义在扩展DNS响应的资源记录的字段内，具体也可以有多种实现方式，例如，可以是对扩展DNS协议标准的扩展(即增加新的扩展字段)，也可以是兼容现有的标准协议，本申请对此不做限定，但需要注意的是，第一扩展DNS响应需与第一扩展DNS请求的实现方式对应。为便于理解，作为一种示例，下面以第一路径请求中包含的信息为第一路径类型为例，分别基于增加新的扩展字段和兼容现有的标准协议这两种定义方式进行阐述。
一、通过增加新的扩展字段达到在扩展DNS响应中定义路径信息的目的
由上述可知，不同的路径类型可以预先定义在扩展DNS请求的伪资源记录的扩展字段内，该扩展字段需要预先向IANA申请得到，那么在本申请实施例中，针对路径类型的返回也可以预先定义在扩展DNS响应的伪资源记录的扩展字段内，该扩展字段也需要预先向IANA申请得到。
作为一个示例，可以预先向IANA申请OPTION-CODE：PATH(该PATH为自定义，申请被批准后即被公开，与扩展DNS请求中的扩展字段OPTION-CODE：PATH对应)，OPTION-CODE：PATH字段表示对路径类型请求的返回；而在对应的OPTION-DATA字段内，则放入对应路径类型的路径信息(如，可以路径列表的形式存放)。例如，若请求的路径类型是基于Overlay网络的转发路径，那么对应的OPTION-DATA内放入的是基于Overlay网络的路径信息(如，PoP地址列表{PoP1 IP，PoP2 IP，PoP3 IP})；若请求的路径类型是 基于SRv6的转发路径(即可支持源端设备发起SRv6传输)，那么对应的OPTION-DATA内放入的是基于SRv6的路径信息；若请求的路径类型是基于SFC的转发路径(即可支持源端设备发起SFC传输)，那么对应的OPTION-DATA内放入的是基于SFC的路径信息，具体本申请不再对OPTION-DATA内放入的路径信息进行示意。
需要注意的是，用PATH表示对路径类型请求的返回也是本申请自定义的，同样地，也可以用其他单词或句子表示对路径类型的请求，只要能够用于作为对路径类型请求的返回的唯一标识即可，具体本申请对该标识的具体表现形式不做限定。
这里还需要说明的是，在本申请实施例中，是通过预先向IANA申请一对新的扩展字段(即OPTION-CODE：QPATH和OPTION-CODE：PATH)来达到在扩展DNS请求中定义路径类型(即请求消息)、在扩展DNS响应中定义路径信息(即响应消息)的目的。在本申请的另一些实施方式中，还可以是只通过预先向IANA申请一个新的扩展字段来同时达到在扩展DNS请求中定义路径类型且在扩展DNS响应中定义路径信息的目的。
申请一个新的扩展字段与申请一对新的扩展字段不同之处在于：只需先判断交互的消息是属于请求消息还是响应消息，作为一个示例，以请求的路径类型为Overlay网络为例，若是源端设备向控制器发送的请求消息，那么该扩展字段中OPTION-DATA内放入的就是Overlay，表示请求的路径类型是基于Overlay网络的转发路径；若是控制器向源端设备发送的响应消息，那么该扩展字段中OPTION-DATA内放入的就是基于Overlay网络的路径信息(如，PoP地址列表{PoP1 IP，PoP2 IP，PoP3 IP})。
二、通过兼容现有的标准协议达到在扩展DNS响应中定义路径信息的目的
与第一种方式不同的地方在于，本申请实施例给出了一种兼容现有标准协议的方法，即针对不同路径类型请求的返回也可以预先定义在扩展DNS响应的标准资源记录内，例如，可以是定义在扩展DNS响应的标准资源记录的type字段内，具体地，源端设备获取第一扩展DNS响应后，直接总响应报文的ANSWER中的RATA获取目的地址。这种方式的好处在于，不需要事先向IANA申请。具体的定义方式与上述通过兼容现有的标准协议达到在扩展DNS请求中定义路径类型的目的的方式类似，此处不予赘述。
为便于理解上述步骤802和步骤803的过程，下面举例进行示意：控制器接收到源端设备发送的扩展DNS请求，若在该扩展DNS请求的Additional字段的RDATA中发现OPTION-CODE是QPATH的扩展字段，说明该扩展DNS请求是包含了路径类型的第一扩展DNS请求，并在其OPTION-DATA中发现请求的路径类型为Overlay网络的路径类型，说明是对Overlay网络路径的请求。在这种情况下，控制器从CSUBNET扩展协议中的OPTION-DATA中读取源端设备的源地址，并根据源地址、目的地址(如，URL地址、目的端设备的IP地址等)做匹配计算，得到从源端设备访问该目的端设备的最优Overlay路径，该路径信息通过Additional字段的RDATA进行返回，该控制器在扩展DNS响应的Additional字段的RDATA中添加对路径类型请求的回应(即路径信息)OPTION-CODE：PATH，OPTION-DATA则为代表Overlay网络的路径信息，如，可以是PoP地址列表{PoP1 IP，PoP2 IP，PoP3 IP}。需要注意的是，控制器对其他字段无特殊处理，例如，Answer字段中正常返回目的地址。
在本申请实施例中，路径信息的规划与源端设备的应用类型、应用需求(如，是否大带宽、是否时延小等需求)等相关，控制器规划的路径一般是指从源端设备至目的端设备之间符合当前要求的最优路径，当该路径信息的取值不同，那么路径信息所包含的信息也不同，具体地，可被划分为如下几种类型：
1)在路径信息的取值不为空的情况下，路径信息包括源端设备到目的端设备之间的转发节点以及转发节点的先后转发顺序，需要注意的是，当转发节点为1个时，则默认先后转发顺序就是由这1个转发节点进行转发，当转发节点为n个(n≥2)，则是正常的先后转发顺序。
2)在路径信息的取值为空的情况下，说明该路径信息不包括任何转发节点。
需要说明的是，在本申请的一些实施方式中，路径类型不同，所涉及的转发节点的类型也不同，例如，当第一路径类型是Overlay网络路径时，转发节点就为PoP；当第一路径类型是SRv6路径，转发节点就为SRv6路由器；当第一路径类型为SFC路径，转发节点就为支持服务链的硬件设备。在本申请实施例中，转发节点的类型与路径类型相关，此处不予赘述。
804、源端设备经由该转发节点按照该先后转发顺序将待发送的目标数据包向目的端设备发送。
在路径信息的取值不为空的情况下，也就是说，该路径信息至少包括有一个转发节点，源端设备对收到的第一扩展DNS响应进行解析，并经由该路径信息所包括的转发节点按照先后转发顺序将待发送的目标数据包向目的端设备发送。
下面基于该路径信息中包括的转发节点数量具体阐述如何经由转发节点将待发送的目标数据包向目的端设备发送。
一、路径信息中包括的转发节点为n个(n≥2)
在申请实施例中，首先，源端设备根据得到的路径信息对目标数据包进行封装，得到封装了头域(可称为第一头域)的数据包(可称为第一数据包)，该第一头域内包括转发节点的先后转发顺序、源端设备的源地址以及第一跳转发节点的地址。这里需要注意的是，第一转发节点的地址可以是指第一转发节点的IP地址，也可以是指用于指向第一转发节点IP地址的标识(如，ID)，还可以是其他可以对第一跳转发节点进行寻址的标识(可称为寻址标识)等，标识(或寻址标识)与IP地址之间存在映射关系，且该映射关系存储在第一转发节点上。类似地，本申请实施例所涉及的其他转发节点的地址(如，第二跳转发节点、第三跳转发节点、……、最后一跳转发节点等)的含义均与此类似，下面就不予赘述。为便于阐述，下面以第一路径请求中包含的信息为第一路径类型为例，且均以转发节点的地址为IP地址为例进行说明。
以路径类型为Overlay网络路径为例，源端设备根据得到的路径信息对目标数据包进行封装的封装方式包括但不限于：
1)在网络层(L3)报文外侧添加头域PoP_list，将路径信息(如，路径列表)放入该头域内，添加UDP头，并将路径列表中的第一个PoP的IP地址和源端设备的源地址放入最外层网络包头。数据包的封装格式可如图11所示，封装后源端设备将封装后的数据包送 入Underlay网络进行转发。
2)在传输层(L4)报文外侧进行封装，添加的头域包含两个字段，PoP_list和OLD L3，类似地，将路径信息(如，路径列表)放入该头域内，添加UDP头，并将路径列表中的第一个PoP的IP地址和源端设备的源地址放入最外层网络包头，数据包的封装格式可如图12所示，封装后源端设备将封装后的数据包送入Underlay网络进行转发。
这里需要注意的是，图12的封装方式与图11的封装方式唯一不同的是：源端设备对数据包的截获位置，图11示意的是在网络层截获，图12示意的是在传输层截获，两种方式仅在工程上有区别，其他无本质区别。
源端设备根据得到的路径信息对目标数据包进行封装，得到封装了头域(可称为第一头域)的数据包(可称为第一数据包)之后，会将该第一数据包发送至第一跳转发节点，第一跳转发节点(假设为R1)根据第一头域读取到自身为目的地址(即图13中源端设备侧最外层网络包头中的Dst＝R1)、源端设备为源地址(即图13中源端设备侧最外层网络包头中的Src＝源IP)，就可确定该第一数据包是由源端设备发送给自身的，并且可确定自身为目的地址；此外，该第一跳转发节点R1还将根据该第一头域内包括的转发节点的先后转发顺序(即图13中的R-list)判断自身是否是最后一跳转发节点，假设R-list＝{R1、R2}，由该R-list可知，该第一跳转发节点R1不是最后一跳转发节点，在这种情况下，第一转发节点R1对该第一数据包的第一头域解封装后，再对目标数据包进行再封装，得到由第一转发节点R1封装了头域(可称为第二头域)的数据包(可称为第二数据包)，此时，该第二数据包则包括转发节点的先后转发顺序、第一跳转发节点的IP地址以及第二跳转发节点的IP地址，具体请参阅图13，第一跳转发节点的IP地址为图13中第一跳转发节点R1侧最外层网络包头中的Src＝R1，第二跳转发节点的IP地址为图13中第一跳转发节点R1侧最外层网络包头中的Dst＝R2，转发节点的先后转发顺序依然为R-list＝{R1、R2}，之后，由该第一跳转发节点R1根据转发节点的先后转发顺序(即R-list)将该第二数据包向第二跳转发节点R2发送。
类似地，第二跳转发节点R2根据该第二数据包中的第二头域读取到自身为目的地址、第一转发节点R1为源地址，就可确定该第二数据包是由第一转发节点R1发送给自身的，并且可确定自身为目的地址；此外，该第二跳转发节点R2还将根据该第二头域内包括的转发节点的先后转发顺序(即R-list)判断自身是否是最后一跳转发节点，由于R-list＝{R1、R2}，由该R-list可知，该第二跳转发节点R2是最后一跳转发节点，在这种情况下，第二跳转发节点R2对该第二数据包的第二头域解封装(即删除该第二数据包的第二头域)，得到初始的目标数据包(即只包含原始网络层包头)，并由该第二跳转发节点R2将该删除了第二头域的目标数据包向目的端设备发送。
这里需要说明的是，在本申请上述实施例中，假设的是路径信息中包括了2个转发节点R1和R2，且这两个转发节点之间的先后转发顺序为R-list＝{R1、R2}。在本申请的另一些实施方式中，如果路径信息中包括的转发节点为R1、R2、……、Rn，n＞2，且这些转发节点之间的先后转发顺序为R-list＝{R1、R2、……、Rn}，那么转发节点R1作为第一跳转发节点，对目标数据包封装时的头域包括的则是转发节点的先后转发顺序R-list＝{R1、 R2、……、Rn}、源端设备的源地址以及第一跳转发节点的IP地址，该第一跳转发节点R1会将封装好的数据包(称为第一数据包)发送给第二跳转发节点R2，再由第二跳转发节点R2对接收到的第一数据包解封装后再封装，第二跳转发节点R2对目标数据包封装时的头域包括的就是转发节点的先后转发顺序R-list＝{R1、R2、……、Rn}、第一跳转发节点的IP地址以及第二跳转发节点的IP地址，该第二跳转发节点R2会将封装好的数据包(称为第二数据包)发送给下一跳转发节点，……，直至将数据包发送至最后一跳转发节点Rn。需要注意的是，R-list＝{R1、R2、……、Rn}中除了最后一跳转发节点Rn之外，其他每个转发节点都需对上一个转发节点(对第一跳转发节点来说，上一个转发节点则为源端设备)发送的数据包进行解封装后再封装，再封装的头域里的最外层网络包头里写入的就是转发节点的先后转发顺序R-list＝{R1、R2、……、Rn}、自身的IP地址以及下一跳转发节点的IP地址。当转发节点Rn接收到由转发节点Rn-1发送的数据包，根据数据包中头域内的R-list得知自身为最后一跳，那么转发节点Rn去除所有头域，得到初始的目标数据包，再由该最后一跳转发节点Rn将得到的目标数据包送至Underlay网络发送给目的端设备。
需要注意的是，在本申请实施例中，各个转发节点对解封装后的目标数据包再次封装的操作与上述源端设备对初始的目标数据包的封装过程类似，可以是在网络层(L3)报文外侧封装，也可以是在传输层(L4)报文外侧进行封装，具体可参阅图11和图12对应所述的封装方式，此处不予赘述。
二、路径信息中包括的转发节点为1个
在申请实施例中，路径信息中只包括一个转发节点(即R-list＝{R1})，源端设备对目标数据包的封装方式与上述包括多个转发节点的路径信息的方式类似，此处不予赘述。
与上述路径信息中包括的多个转发节点不同的地方在于：第一转发节点R1接收到由源端设备发送的封装了头域的数据包后，由该头域内包括的转发节点的先后转发顺序R-list＝{R1}得知，自身不仅是第一跳转发节点，也是最后一跳转发节点，那么该转发节点R1会将头域删除，并将删除了头域的目标数据包向目的端设备发送。
需要说明的是，在本申请的一些实施方式中，在路径信息的取值为空的情况下，即R-list＝{}，说明最优路径是公网直连通信，无需转发节点的参与，那么源端设备直接将目标数据包放入Underlay网络向目的端设备发送。
需要说明的是，在本申请上述实施例中，每个转发节点在头域中封装的先后转发顺序都是全量的，即假设路径信息中包括n个转发节点，分别为R1、R2、……、Rn，转发节点的先后转发顺序为R-list＝{R1、R2、……、Rn}，那么每个转发节点在封装头域时，都会将该全量的先后转发顺序R-list＝{R1、R2、……、Rn}封装在头域中。这种全量的方式由于仅需改变头域中的指针项，更改较为容易，并且由于路径信息中包含的转发节点数目一般不多，因此每个转发节点都携带全量的先后转发顺序也不会带来更高的计算开销。
在本申请的另一些实施方式中，每个转发节点在头域中封装的先后转发顺序也可以是增量的，即假设路径信息中包括n个转发节点，分别为R1、R2、……、Rn，转发节点的先后转发顺序为R-list＝{R1、R2、……、Rn}，那么在第一跳转发节点的头域中，携带的先后转发顺序为R-list-1＝{R2、……、Rn}，在第二跳转发节点的头域中，携带的先后转发顺 序为R-list-2＝{R3、……、Rn}，在第三跳转发节点的头域中，携带的先后转发顺序为R-list-3＝{R3、……、Rn}，以此类推，每个当前转发节点中携带的先后转发顺序都为下一跳转发节点至最后一跳转发节点之间的先后转发顺序，而在最后一跳转发节点中，携带的信息为空，说明为最后一跳，那么该最后一跳转发节点就将头域删除，并将该删除了头域的目标数据包向目的端设备发送。这种增量的方式则需要对头域的长度进行修改。
还需要说明的是，在本申请的一些实施方式中，控制器可直接作为授权DNS服务器，也可配置为DNS代理方式。换句话说，本申请所述的控制器，本质可看做是一个DNS服务器，具备NS RR查询并返回的功能。其他的DNS服务器，如本地DNS服务器等，无需做任何修改，根据传统DNS协议，当本地DNS服务器不存在响应RR时，就会将带有路径请求的扩展DNS请求导向控制器所在的DNS服务器做查询。
还需要说明的是，在本申请上述实施例中，均是由源端设备生成第一扩展DNS请求，而在本申请的另一些实施方式中，该第一扩展DNS请求不限定仅由源端设备生成，该第一扩展DNS请求的生成也可以是由其他设备完成，例如DNS服务器、DNS proxy或其他第三方设备。该设备在截获源端设备发送的传统DNS请求后，修改为带有路径请求的扩展DNS请求，并结合控制器完成后续操作，以得到路径信息，该路径信息可以携带在传统DNS请求中直接由控制器返回至源端设备，该路径信息也可以携带在其他响应(如，扩展DNS响应)中由其他设备进行中转处理后，并最终发送给源端设备，具体本申请对此不做限定。
在本申请上述实施方式中，将对路径的请求以及对路径请求的响应(即控制器规划的路径信息)携带在扩展DNS报文中，从而实现为源端设备上的应用提供访问目的端设备的路径的控制能力。具体来说，首先源端设备将路径请求携带在扩展DNS请求中向控制器发送，控制器基于接收到的扩展DNS请求规划路径，并将规划的路径信息携带在扩展DNS响应中向源端设备发送，再由该源端设备根据该路径信息的具体内容(如，包括几个转发节点、转发节点之间的先后转发顺序等)将目标数据包向目标的端设备发送。该本申请实施例以扩展DNS报文为媒介，将路径信息定义在扩展DNS报文中的响应报文中从真正的数据源头发起SR，在终端为互联网传输定义端到端传输路径，提高了路由效率，并提升了互联网业务端到端表现。
为便于理解，下面以源端设备的路径请求为路径类型、且路径类型为Overlay网络路径为例，对整个路由方法的整体流程进行说明，具体请参阅图14，图14为本申请实施例提供的路由方法的整体流程的一个场景示意图，整个路由过程如下：
步骤①，首先，源端设备(如，手机)上的某个应用发起会话请求，例如，浏览器应用发起访问www.huawei.com的请求，该会话请求触发源端设备调用部署于该源端设备上的SDK生成扩展DNS请求，并将该扩展DNS请求向与源端设备对应的DNS服务器发送，该扩展DNS请求中就包括第一路径类型(假设该第一路径类型为Overlay网络路径)。
步骤②，DNS服务器对源端设备发送的扩展DNS请求进行递归查询，该步骤可复用DNS服务器的常规处理流程，并将该扩展DNS请求向控制器发送。需要注意的是，在该步骤中，若扩展DNS请求中没有包括控制器用于规划路径的全部信息(如，不包括源端设 备的源地址)，那么DNS服务器还需在这个步骤中同步收集对路径规划必要的信息，收集到的必要信息可加入到该扩展DNS请求中再一并发送给控制器，也可以独立发送给控制器。
步骤③，控制器根据接收到的扩展DNS请求中的信息做匹配查询。具体地，若控制器在Additional字段的RDATA中未发现OPTION-CODE是QPATH的扩展字段(假设该扩展字段已事先向IANA申请到)，或根本不存在任何RDATA，说明这是一条常规的DNS报文，控制器则对其做常规DNS报文处理，即返回对应目的端设备的目的地址(如，返回对应URL的IP地址)；若控制器在Additional字段的RDATA中发现OPTION-CODE是QPATH的扩展字段，说明是包含路径类型的DNS请求，并在其OPTION-DATA中发现路径类型为Overlay网络路径，说明是对Overlay网络路径的DNS请求，同时控制器从CSUBNET扩展协议中的OPTION-DATA中读取到源端设备的源地址，控制器基于该源地址、目的设备的目的地址做匹配计算，得到从用户访问该目的地址的最优Overlay网络路径，该路径信息通过写入到Additional字段的RDATA中进行返回给DNS服务器。例如，控制器在Additional字段的RDATA内的最后一条之后添加新的扩展字段OPTION-CODE：PATH(假设该扩展字段已事先向IANA申请到)，OPTION-DATA则为代表Overlay网络路径的PoP地址列表，如{PoP1 IP，PoP2 IP，PoP3 IP}。需要注意的是，如果对路径类型的请求不是Overlay网络，这里OPTION-DATA就是其他的路径信息的路径列表，也就是说，这里的路径列表需与路径类型对应。
步骤④，DNS服务器将接收到的扩展DNS响应发送给源端设备。
步骤⑤，源端设备接收到DNS服务器发送的扩展DNS响应，对该报文进行解析。具体地，若源端设备在Additional字段的RDATA中未发现OPTION-CODE是PATH的扩展字段，或根本不存在任何RDATA，说明这是一条常规的DNS响应，源端设备则根据ANSWER字段中的IP地址做正常转发；若源端设备在Additional字段的RDATA中发现OPTION-CODE是PATH的扩展字段，则读取OPTION-CODE是QPATH的扩展字段，若其OPTION-DATA值为Overlay，则说明是Overlay网络的路径类型，PATH中的OPTION-DATA则是表示与Overlay网络路径对应的路径列表，在这种情况下，源端设备将待发送的目标数据包进行封装，封装的头域中包括转发节点的先后转发顺序(如，PoP的路径列表PoP-list)、源端设备的源地址、第一跳PoP的IP地址，并将该封装了头域的数据包发送给第一跳PoP。
步骤⑥，该路径列表中所涉及到的各个PoP按照先后转发顺序接收到数据包后，并解开外层封装的头域，读取PoP-list，并将下一个PoP的IP地址放入新的外层网络包头，送至Underlay网络，若该PoP是PoP-list中的最后一跳，则该PoP删除数据包的头域，将初始的目标数据包送至Underlay网络发送至目的端设备。具体地，步骤⑥的过程可参阅图15所示，详细封装、解封装的过程可参阅图13对应的实施例所述，此处不予赘述，需注意的是，图15是为了展示各个PoP如何对目标数据包进行解封、再封装以及转发过程，因此在图15中，省略了DNS服务器。
需要说明的是，在图14对应的实施例中，是以扩展DNS请求中包括的路径类型为 Overlay网络路径为例进行阐述的，也就是在扩展DNS请求的QPATH扩展字段的OPTION-DATA中填写的是Overlay网络路径。在本申请的其他的一些实施方式中，也可支持源端设备发起SRv6传输，在这种情况下，在扩展DNS请求的QPATH扩展字段的OPTION-DATA中填写的是SRv6，并且在步骤③和步骤④中，控制器根据该扩展DNS请求，匹配计算最优的SRv6路径的路径列表SRv6-list，并将该路径列表SRv6-list放入PATH扩展字段的OPTION-DATA中由DNS控制器进行返回。在步骤⑤和步骤⑥中，源端设备以及转发节点根据获取的SRv6路径的路径列表SRv6-list进行封装和转发，该封装和转发过程与SRv6转发标准类似，此处不予赘述。需要注意的是，路径类型为SRv6路径的重要应用场景是企业网环境，且包含于同一SR域，源端设备可以是企业网中的手机、PC等终端设备，本申请实施例中的路径类型(即SRv6路径)也可替换为SR MPLS，即路径类型可变为MPLS标签栈，路由方法与SRv6路径类似，此处不予赘述。
还需要说明的是，本申请实施例中扩展DNS请求中包括的路径类型除了可以是Overlay网络路径、SRv6路径之外，还可以是SFC路径，即本申请所述的路由方式可支持SFC路径，具体地，当在QPATH的OPTION-DATA中的路径类型为SFC，则在步骤③和步骤④中，控制器返回的扩展DNS响应中的路径信息是SFC的路径列表，源端设备和各转发节点基于该SFC的路径列表对数据包进行封装以及转发，该过程与上述类似，此处不予赘述，不同的地方在于：相关的转发节点需要支持步骤⑥中的转发功能。
下面对本申请实施例提供的路由方法的兼容性进行分析，具体请参阅图16，图16为本申请实施例提供的兼容性示意图，其中，传统源端设备是指没有部署SDK的源端设备，新源端设备是指部署SDK的源端设备，传统DNS服务器是指没有对应部署控制器的DNS服务器，新DNS服务器是指对应部署了控制器的DNS服务器。下面针对不同情况进行分析：
a、若是传统源端设备向传统DNS服务器发送DNS报文，则是常规的DNS报文解析流程。
b、若是传统源端设备向新DNS服务器发送DNS报文，新DNS服务器根据QUESTION字段正常返回目的端设备的目的地址。
c、若是新源端设备向传统DNS服务器发送DNS报文，传统DNS服务器根据QUESTION字段正常返回目的端设备的目的地址，这是因为传统DNS服务器在ADDITIONAL字段中无法解析OPTION-CODE：QPATH，因此不做特殊处理。
d、若是新源端设备向新DNS服务器发送DNS报文，新DNS服务器可以解析OPTION-CODE：QPATH，具体过程则为本申请实施例所述的路由过程。
由上述分析可知，本申请实施例遵循后向兼容性原则，即新源端设备可配合传统DNS服务器(无控制器)或新DNS服务器(对应部署有控制器)，且新DNS服务器可回应传统DNS请求或扩展DNS请求。
需要说明的是，在本申请上述所有实施例中，阐述的都是将对路径的请求以及对路径请求的响应(即控制器规划的路径信息)携带在扩展DNS报文中，从而实现为源端设备上的应用提供访问目的端设备的路径的控制能力。在本申请的另一些实施方式中，还可以是 以其他信息为媒介，实现在终端为互联网传输配置端到端传输路径的功能。例如，可以使用HTTP协议进行域名解析，代替现有基于UDP的DNS协议，域名解析请求直接发送到可灵活配置的HTTPDNS服务器，从而绕过运营商的本地DNS服务器，能够避免本地DNS服务器造成的域名劫持问题和调度不精准问题。具体地，请参阅图17，图17为本申请实施例提供的路由方法的另一流程示意图，该方法可以包括如下步骤：
1701、源端设备向Http DNS服务器发送第一Http请求，第一Http请求中包括第一路径请求。
首先，源端设备向Http DNS服务器发送第一Http请求，该第一Http请求中包括第一路径请求，该第一路径请求就用于指示后续源端设备向目的端设备发送数据包的时候通过的是什么路径(即指示源端设备向目的端设备发送数据包的方式)。
同样地，在本申请实施例中，第一路径请求中包括对决定路由路径的相关信息，第一路径请求所包括的信息不同，那么控制器基于该第一路径请求规划的路径信息也不同。例如，该第一路径请求中至少包括如下信息中的任意一种：待发送数据所要去向的目的端设备的地址(即上述所述的目的端地址)、待发送数据的应用类型、待发送数据的应用ID、待发送数据的业务类型、待发送数据的QoS要求、待发送数据要求使用的第一路径类型。具体介绍请参阅上述步骤801中的描述，此处不予赘述。
这里需要注意的是，在图8对应的实施例中，不同的路径请求是事先定义在扩展DNS请求的资源记录的字段内的，例如，可以是对扩展DNS协议标准的扩展(即增加新的扩展字段)，也可以是兼容现有的标准协议。在本申请实施例中，不同的路径请求预先定义在Http请求内，定义过程不涉及标准，因此无需向机构(如，IANA)申请。
需要说明的是，在本申请实施例中，该第一Http请求的生成可以有多种触发形式，作为一个示例，该第一Http请求可以通过安装于该源端设备的SDK生成，具体地，可以是源端设备上安装的应用发起会话请求，例如，浏览器应用访问www.huawei.com的会话请求，该会话请求触发源端设备调用SDK生成第一Http请求；作为另一示例，该第一Http请求也可以是在应用中事先写好的软件模块，当源端设备上安装的应用发起会话请求，该会话请求就会触发源端设备调用该应用中的软件模块生成第一Http请求；作为另一示例，该第一Http请求还可以通过写协议栈的方式触发生成。具体地，本申请对如何触发生成第一Http请求的具体实现方式不做限定，此处不再举例示意。
1702、Http DNS服务器根据第一Http请求，得到与该第一路径请求对应的路径信息。
Http DNS服务器接收到由源端设备发送的第一Http请求之后，可以根据该第一Http请求中的信息做匹配查询，得到与该第一路径请求对应的路径信息。
需要说明的是，在本申请实施例中，默认Http DNS服务器可基于第一Http请求中的信息实现路径规划的功能，至于该Http DNS服务器如何基于得到的信息得到规划好的路径信息，可基于自研算法得到，此处不做限定。
1703、Http DNS服务器向源端设备发送第一Http响应，该路径信息包含在该第一Http响应中，其中，在该路径信息的取值不为空的情况下，该路径信息包括源端设备到目的端设备之间的转发节点以及转发节点的先后转发顺序。
Http DNS服务器基于该第一Http请求得到路径信息后，会向源端设备发送该第一Http响应，该路径信息就包含在该第一Http响应中。
类似地，在本申请实施例中，路径信息的规划与源端设备的应用类型、应用需求(如，是否大带宽、是否时延小等需求)等相关，Http DNS服务器规划的路径一般是指从源端设备至目的端设备之间符合当前要求的最优路径，当该路径信息的取值不同，那么路径信息所包含的信息也不同，具体地，可被划分为如下几种类型：
1)在路径信息的取值不为空的情况下，路径信息包括源端设备到目的端设备之间的转发节点以及转发节点的先后转发顺序，需要注意的是，当转发节点为1个时，则默认先后转发顺序就是由这1个转发节点进行转发，当转发节点为n个(n≥2)，则是正常的先后转发顺序。
2)在路径信息的取值为空的情况下，说明该路径信息不包括任何转发节点。
需要说明的是，在本申请的一些实施方式中，当路径请求为路径类型，那么路径类型不同，所涉及的转发节点的类型也不同，例如，当第一路径类型是Overlay网络路径时，转发节点就为PoP；当第一路径类型是SRv6路径，转发节点就为SRv6路由器；当第一路径类型为SFC路径，转发节点就为支持服务链的硬件设备。在本申请实施例中，转发节点的类型与路径类型相关，此处不予赘述。
1704、源端设备经由该转发节点按照该先后转发顺序将待发送的目标数据包向目的端设备发送。
在申请实施例中，步骤1704与上述步骤804类似，具体请参阅上述步骤804，此处不予赘述。
由图17对应的实施例可知，该实施例与图8对应实施例不同之处在于：1)在图17对应实施例中，对路径的请求和响应是由Http请求和Http响应承载，而图8对应实施例则是由扩展DNS报文承载；2)图17对应实施例中，将图8对应实施例中控制器规划路径的功能集成在Http DNS服务器上。除了这两点不同，其他过程与图8对应实施例的过程类似。
需要说明的是，在本申请实施例中，是将图8对应实施例中控制器规划路径的功能集成在Http DNS服务器上，在本申请的另一些实施方式中，还可以是将图8对应实施例中控制器规划路径的功能独立部署为一个模块或多个模块，该模块可以不部署在Http DNS服务器上，而是部署在其他设备上，在这种情况下，图17对应实施例中由Http DNS服务器执行的操作就由部署有该模块的其他设备执行。
同样地，在本申请实施例中，每个转发节点在头域中封装的先后转发顺序可以是全量的，也可以是增量的，本申请对此不做限定。具体可参阅上述步骤804相关的描述，此处不予赘述。
在介绍完本申请实施例提供的路由方法的具体实现方式之后，下面对本申请实施例提供的路由方法所带来的有益效果进行阐述：
一、为源端设备的应用提供控制用户访问路径的能力
当前互联网传输的DNS解析方案，应用仅能控制目的端(即应用仅能决定自身需访问的目的地址是哪个)，而路由的路径由互联网(internet)决定，无法控制。如图18所示， 图18为本申请实施例提供的路由方法与传统互联网传输的DNS解析方案的对比示意图，由图18中的(a)子示意图可知，百度可通过GSLB(即图18中(a)子示意图中的Baidu GSLB)为用户分配最优的服务器进行访问，但用户到服务器的路径完全由互联网所决定。若应用还想对用户的路径进行控制，例如，需要通过overlay网络加速、路径避让策略(如，数据包不能离开中国大陆)或需要通过SFC(如，数据包必须先进入防火墙)路径传输等需求，那么采用本申请实施例提供的路由方法是直接、简单且高效的方法。如图18中的(b)子示意图所示，百度通过部署的控制器(即图18中(b)子示意图中的Baidu E2E)为用户规划路径，规划策略可以是差异化用户体验，例如，为会员用户分配更优的加速路径，而为常规用户分配默认互联网路径。
二、实现端到端联合优化
本申请实施例提供的路由方法为端到端的联合优化提供了实现手段，端到端联合优化可以为用户带来更好的性能提升，为证明该结论，本申请对联合优化的优势进行简单的仿真。具体的实验配置如下：
a、拓扑生成：如图19所示，在二维平面模拟地球尺度，固定源点，目的点在x轴水平移动，调整源-目的距离；随机撒点，部署PoP(如图19中的点)，PoP点数目100，200，500。
b、时延分布：根据测量数据分析，任意两点间的时延服从Gamma分布，如图20所示，时延均值随距离呈线性增长。
c、对比方法：1.默认直连，源点-目的点直接相连；2.距离最近PoP点接入，源点选择距离最近的PoP点作为入口，目的点选择最近的PoP点作为出口，出入口之间根据Overlay网络全连接拓扑，计算最短路径；3.时延最短PoP点接入，与2类似，仅在选择出入口PoP点时，选择时延最短接入点，而非距离最近；4.端到端联合优化(即本申请方法)，本申请实施例提供的路由方法在全连接网络拓扑中，直接在源点-目的点间计算最短路径。
基于上述的实验配置，图21展示了在不同PoP点数目的场景下，四种方法时延随距离的变化曲线。由图21中可看出：现有就近接入路由方法在近距离通信场景会带来负增益，由于上Overlay网络绕路，时延高于默认直连路径。而本申请实施例提供的方法根据实际网络情况确定Overlay网络路径(或直连通信)，性能优于其他现有方法和默认直连路径。
三、极大简化转发节点的设计，降低维护成本
在传统方法中，例如Overlay智能路由，PoP要依靠中心控制器进行管理，根据链路质量更新路由表和目的IP-出口PoP映射表。而在本申请实施例提供的路由方法中，PoP无需维护任何表项，避免了与控制器的交互与更新，所有转发状态均在数据包内部。
四、延伸SR域至终端设备
SR技术可以消除网络中过渡节点的网络状态信息，将路径状态信息数据包头中，使网络管理和运维更加容易。然而现有SR域大多在网络内部，例如，同一自治域的路由器交换机等。本申请实施例提供的路由方法进一步将SR域延伸至用户终端，从真正的数据源头发起SR，端边云协同配合，实现极简网络。
需要说明的是，本申请实施例提供的路由方法还可以扩展应用到用于与服务器的回源 请求。下面具体介绍该扩展应用。
在云网络发展的大趋势下，用户与服务器的回源请求往往需要借助边缘代理服务器做中转，而非用户直接与服务器建立连接，该具体流程可如图22所示，用户至服务器的路径包括：用户-边缘代理服务器-云骨干网-DC。各设备的功能分别为：边缘代理服务器/PoP点用于终结用户的TCP或Http请求，并对内容缓存；DC用于承载应用的逻辑和状态；云骨干网用于连接DC和边缘代理服务器。可以看到，边缘代理服务器作为DC服务器网络的出入口，一方面将内容缓存至离用户更近的位置，另一方面作为用户与DC间的管理者，保证安全性和负载均衡。
现有的用户与与服务器的回源请求的方法包括三个子系统：1)边缘代理服务器选择系统：用户根据DNS协议，获得就近边缘代理服务器/PoP点；2)DC选择系统：根据各DC负载状况及网络状况，选择DC节点服务用户请求；3)云骨干网路由系统：生成各边缘代理服务器至各DC的最优路径。
现有方法存在两个突出问题：1)端到端的路径联合优化，是当前云网络最大的诉求之一。例如，用户若就近接入Proxy1，但由于Proxy1-DC链路拥塞，骨干网自身无法解决，只能通过用户重新连接Proxy2恢复通信。2)三个子系统决策在不同实体(分为位于DNS服务器、负载均衡器、骨干控制器)，因此难以协调，无法实现一致性更新配置。例如，若用户新会话通过DNS服务器连接Proxy2，但骨干网Proxy-DC的路由还未建立，在Proxy2处会发生黑洞、丢包。
而利用本申请实施例提供的路由方法的思路，可解决用户回源流程中不同子系统独立配置的不一致性问题。具体而言，用户发起回源请求，做DNS报文解析，DNS服务器联合控制器根据用户地址、DC负载及网络情况、边缘代理服务器负载及网络状况和云骨干网状况，联合计算回源路径，并将回源路径承载在扩展DNS报文中进行下发，该回源路径包括选择的代理服务器、选择的骨干网路由、选择的DC节点等。该回源路径封装于用户传输的数据包头内，用户端设备根据路径信息，先与选择的边缘代理服务器建立连接，之后边缘代理服务器根据路径信息与相应DC建立连接(复用长连接)，并根据该回源路径中的骨干线路规划路径。
在图8所对应的实施例的基础上，为了更好的实施本申请实施例的上述方案，下面还提供用于实施上述方案的相关设备。具体参阅图23，图23为本申请实施例提供的一种终端设备的示意图，该终端设备作为源端设备，具体可以包括：第一发送模块2301、获取模块2302以及第二发送模块2303，其中，第一发送模块2301，用于向控制器发送第一扩展DNS请求，该第一扩展DNS请求中包括第一路径请求，第一路径请求用于指示所述源端设备向目的端设备发送数据包的方式；获取模块2302，用于接收由该控制器发送的第一扩展DNS响应，该第一扩展DNS响应中包括与该第一路径请求对应的路径信息，该路径信息由该控制器根据该第一扩展DNS请求得到，在该路径信息的取值不为空的情况下，该路径信息包括该源端设备到目的端设备之间的转发节点以及转发节点的先后转发顺序；第二发送模块2303，用于经由该转发节点按照该先后转发顺序将待发送的目标数据包向该目的端设备发送。
在本申请上述实施方式中，将对路径的请求以及对路径请求的响应(即控制器规划的路径信息)携带在扩展DNS报文中，从而实现为源端设备上的应用提供访问目的端设备的路径的控制能力。首先，第一发送模块2301将路径请求携带在扩展DNS请求中向控制器发送，控制器基于接收到的扩展DNS请求规划路径，规划好的路径信息携带于扩展DNS响应中，该获取模块2302将会接收到由该控制器发送的扩展DNS响应，再由该第二发送模块2303根据该路径信息的具体内容(如，包括几个转发节点、转发节点之间的先后转发顺序等)将目标数据包向目标的端设备发送。本申请实施例以扩展DNS报文为媒介，将路径信息配置在扩展DNS报文中的响应报文中从真正的数据源头发起SR，在终端为互联网传输配置端到端传输路径，提高了路由效率，并提升了互联网业务端到端表现。
在一种可能的设计中，该第二发送模块2303，具体用于：首先，根据该路径信息对该目标数据包进行封装，得到封装了第一头域的第一数据包，该第一头域内包括该先后转发顺序、源端设备的源地址以及第一跳转发节点的地址(如，IP地址，或，IP地址的标识，或，其他可以对第一跳转发节点进行寻址的标识等)；之后，将该第一数据包发送至该第一跳转发节点，且在该第一跳转发节点不是最后一跳转发节点的情况下，由该第一跳转发节点对该第一数据包的第一头域解封装后对该目标数据包进行再封装，得到封装了第二头域的第二数据包，并由该第一跳转发节点将该第二数据包向第二跳转发节点发送，该第二头域包括该先后转发顺序、该第一跳转发节点的地址以及第二跳转发节点的地址，且在该第二跳转发节点是最后一跳转发节点的情况下，由该第二跳转发节点删除该第二头域，并由该第二跳转发节点将删除了该第二头域的该目标数据包向该目的端设备发送。
在本申请上述实施方式中，阐述了当路径信息中包括至少两个转发节点时，第二发送模块2303以及各个转发节点基于头域中封装入的转发节点之间的先后转发顺序实现将目标数据包发送至目的端设备的目的，在本申请实施例提供的路由方法中，转发节点无需维护任何表项，避免了与控制器的交互与更新，所有转发状态均在数据包内部，降低了维护成本。
在一种可能的设计中，该第二发送模块2303，还用于：在该路径信息的取值为空的情况下，直接将待发送的该目标数据包向该目的端设备发送。
在本申请上述实施方式中，阐述了当路径信息中只包括一个转发节点时目标数据包如何经由该转发节点发送到目的端设备，也就是不管路径信息中包括几个转发节点，都可实现基于头域中封装入的转发节点之间的先后转发顺序实现将目标数据包发送至目的端设备的目的，具备广泛适用性。
在一种可能的设计中，该终端设备2300还包括生成模块2304，该生成模块2304，用于在该第一发送模2301向控制器发送第一扩展DNS请求之前，通过安装于该源端设备上的SDK生成该第一扩展DNS请求，该第一扩展DNS请求的生成由该源端设备上安装的应用发起的会话请求触发。
在本申请上述实施方式中，阐述了生成模块2304如何触发生成第一扩展DNS请求的应用场景，具备可实现性。
在一种可能的设计中，该第一发送模块2301，具体用于：向与该源端设备对应的DNS 服务器发送该第一扩展DNS请求，并由该DNS服务器向该控制器发送该第一扩展DNS请求；
该获取模块2302，具体用于接收该控制器通过该DNS服务器转发的第一扩展DNS响应。
在本申请上述实施方式中，具体阐述了第一发送模块2301以及获取模块2302与控制器之间的数据交互是经由与该源端设备对应的DNS服务器进行的，具备可实现性。
需要说明的是，图23对应实施例所述的终端设备2300中各模块/单元之间的信息交互、执行过程等内容，与本申请中图8对应的方法实施例基于同一构思，具体内容可参见本申请前述所示的方法实施例中源端设备所执行的操作过程以及叙述，此处不再赘述。
接下来介绍本申请实施例提供的另一种终端设备，请参阅图24，图24为本申请实施例提供的终端设备的一种结构示意图，该终端设备作为源端设备，具体可以包括：第一发送模块2401、获取模块2402以及第二发送模块2403，其中，第一发送模块2401，用于向Http DNS服务器发送第一Http请求，该第一Http请求中包括第一路径请求，第一路径请求用于指示源端设备向目的端设备发送数据包的方式；获取模块2402，用于获取由Http DNS服务器发送的第一Http响应，该第一Http响应中包括与该第一路径请求对应的路径信息，该路径信息由该Http DNS服务器根据该第一Http请求得到，在该路径信息的取值不为空的情况下，该路径信息包括该源端设备到目的端设备之间的转发节点以及转发节点的先后转发顺序；第二发送模块2403，用于经由该转发节点按照该先后转发顺序将待发送的目标数据包向该目的端设备发送。
在本申请上述实施方式中，将对路径的请求以及对路径请求的响应(即Http DNS服务器规划的路径信息)分别携带在Http请求和Http响应中，从而实现为源端设备上的应用提供访问目的端设备的路径的控制能力。首先，第一发送模块2401将路径请求携带在Http请求中向Http DNS服务器发送，Http DNS服务器基于接收到的Http请求规划路径，并将规划的路径信息携带在Http响应中，该获取模块2402将会接收到由该Http DNS服务器发送的Http响应，再由该第二发送模块2403根据该路径信息的具体内容(如，包括几个转发节点、转发节点之间的先后转发顺序等)将目标数据包向目标的端设备发送。本申请实施例以Http请求和Http响应为媒介，将路径信息定义在Http响应中从真正的数据源头发起SR，在终端为互联网传输定义端到端传输路径，提高了路由效率，并提升了互联网业务端到端表现。
在一种可能的设计中，该第二发送模块2403，具体用于：首先，根据该路径信息对该目标数据包进行封装，得到封装了第一头域的第一数据包，该第一头域内包括该先后转发顺序、源端设备的源地址以及第一跳转发节点的地址；之后，将该第一数据包发送至该第一跳转发节点，且在该第一跳转发节点不是最后一跳转发节点的情况下，由该第一跳转发节点对该第一数据包的第一头域解封装后对该目标数据包进行再封装，得到封装了第二头域的第二数据包，并由该第一跳转发节点将该第二数据包向第二跳转发节点发送，该第二头域包括该先后转发顺序、该第一跳转发节点的地址以及第二跳转发节点的地址，且在该第二跳转发节点是最后一跳转发节点的情况下，由该第二跳转发节点删除该第二头域，并 由该第二跳转发节点将删除了该第二头域的该目标数据包向该目的端设备发送。
在本申请上述实施方式中，阐述了当路径信息中包括至少两个转发节点时，第二发送模块2403以及各个转发节点基于头域中封装入的转发节点之间的先后转发顺序实现将目标数据包发送至目的端设备的目的，在本申请实施例提供的路由方法中，转发节点无需维护任何表项，避免了与控制器的交互与更新，所有转发状态均在数据包内部，降低了维护成本。
在一种可能的设计中，该第二发送模块2403，还用于：在该路径信息的取值为空的情况下，直接将待发送的该目标数据包向该目的端设备发送。
在本申请上述实施方式中，阐述了当路径信息中只包括一个转发节点时目标数据包如何经由该转发节点发送到目的端设备，也就是不管路径信息中包括几个转发节点，都可实现基于头域中封装入的转发节点之间的先后转发顺序实现将目标数据包发送至目的端设备的目的，具备广泛适用性。
在一种可能的设计中，该终端设备2400还包括生成模块2404，该生成模块2404，用于在该第一发送模2401向Http DNS服务器发送第一Http请求之前，通过安装于该源端设备上的SDK生成该第一Http请求，该第一Http请求的生成由该源端设备上安装的应用发起的会话请求触发。
在本申请上述实施方式中，阐述了生成模块2404如何触发生成第一Http请求的应用场景，具备可实现性。
需要说明的是，图24对应实施例所述的终端设备2400中各模块/单元之间的信息交互、执行过程等内容，与本申请中图17对应的方法实施例基于同一构思，具体内容可参见本申请前述所示的方法实施例中源端设备所执行的操作过程以及叙述，此处不再赘述。
本申请实施例还提供一种控制器，请参阅图25，图25为本申请实施例提供的控制器的一种结构示意图，该控制器2500具体可以包括：获取模块2501、路径规划模块2502以及发送模块2503，其中，获取模块2501，用于获取由源端设备发送的第一扩展DNS请求，该第一扩展DNS请求中包括第一路径请求，第一路径请求用于指示源端设备向目的端设备发送数据包的方式；路径规划模块2502，用于根据该第一扩展DNS请求得到与该第一路径请求对应的路径信息；发送模块2503，用于向该源端设备发送第一扩展DNS响应，该路径信息包含在该第一扩展DNS响应中，其中，在该路径信息的取值不为空的情况下，该路径信息包括该源端设备到目的端设备之间的转发节点以及转发节点的先后转发顺序，以使得该源端设备经由该转发节点按照该先后转发顺序将待发送的目标数据包向该目的端设备发送。
在本申请上述实施方式中，将对路径的请求以及对路径请求的响应(即控制器规划的路径信息)携带在扩展DNS报文中，从而实现为源端设备上的应用提供访问目的端设备的路径的控制能力。首先，获取模块2501获取由源端设备发送的扩展DNS请求，该扩展DNS请求中包含有对路径的请求(即第一路径请求)，路径规划模块2502再基于接收到的扩展DNS请求规划路径，再由发送模块2503将规划的路径信息携带在扩展DNS响应中向源端设备发送，由该源端设备根据该路径信息的具体内容(如，包括几个转发节点、转发节点 之间的先后转发顺序等)将目标数据包向目标的端设备发送。该本申请实施例以扩展DNS报文为媒介，将路径信息配置在扩展DNS报文中的响应报文中从真正的数据源头发起SR，在终端为互联网传输配置端到端传输路径，提高了路由效率，并提升了互联网业务端到端表现。
在一种可能的设计中，该获取模块2501，具体用于：获取由该源端设备通过DNS服务器转发的第一扩展DNS请求，该DNS发服务器与该源端设备对应；
发送模块2503，具体用于向该DNS服务器发送第一扩展DNS响应，并由该DNS服务器向该源端设备发送该第一扩展DNS响应。
在本申请上述实施方式中，具体阐述了获取模块2501、发送模块2503与源端设备之间的数据交互是经由与该源端设备对应的DNS服务器进行的，具备可实现性。
需要说明的是，图25对应实施例所述的控制器2500中各模块/单元之间的信息交互、执行过程等内容，与本申请中图8对应的方法实施例基于同一构思，具体内容可参见本申请前述所示的方法实施例中控制器所执行的操作过程以及叙述，此处不再赘述。
本申请实施例还提供一种Http DNS服务器，请参阅图26，图26为本申请实施例提供的Http DNS服务器的一种结构示意图，该Http DNS服务器2600具体可以包括：获取模块2601、路径规划模块2602以及发送模块2603，其中，获取模块，用于获取由源端设备发送的第一Http请求，该第一Http请求中包括第一路径请求，第一路径请求用于指示源端设备向目的端设备发送数据包的方式；路径规划模块2602，用于根据该第一Http请求得到与该第一路径请求对应的路径信息；发送模块2603，用于向该源端设备发送第一Http响应，该路径信息包含在该第一Http响应中，其中，在该路径信息的取值不为空的情况下，该路径信息包括该源端设备到目的端设备之间的转发节点以及转发节点的先后转发顺序，以使得该源端设备经由该转发节点按照该先后转发顺序将待发送的目标数据包向该目的端设备发送。
在本申请上述实施方式中，将对路径的请求以及对路径请求的响应(即Http DNS服务器规划的路径信息)分别携带在Http请求和Http响应中，从而实现为源端设备上的应用提供访问目的端设备的路径的控制能力。首先，获取模块2601获取由源端设备发送的Http请求，该Http请求中包含有对路径的请求(即第一路径请求)，路径规划模块2602再基于接收到的Http请求规划路径，再由发送模块2603将规划的路径信息携带在Http响应中向源端设备发送，由该源端设备根据该路径信息的具体内容(如，包括几个转发节点、转发节点之间的先后转发顺序等)将目标数据包向目标的端设备发送。本申请实施例以Http请求和Http响应为媒介，将路径信息配置在Http响应中从真正的数据源头发起SR，在终端为互联网传输配置端到端传输路径，提高了路由效率，并提升了互联网业务端到端表现。
需要说明的是，图26对应实施例所述的Http DNS服务器2600中各模块/单元之间的信息交互、执行过程等内容，与本申请中图17对应的方法实施例基于同一构思，具体内容可参见本申请前述所示的方法实施例中Http DNS服务器所执行的操作过程以及叙述，此处不再赘述。
接下来介绍本申请实施例提供的一种计算机设备，请参阅图27，图27为本申请实施 例提供的计算机设备的一种结构示意图，该计算机设备2700可以是本申请所述的终端设备，也可以是本申请所述的控制器，还可以是本申请所述的Http DNS服务器。当该计算机设备2700为终端设备时，那么该计算机设备2700上可以部署有图23或图24对应实施例中所描述的模块，用于实现图23或图24对应实施例中终端设备的功能；当该计算机设备2700为控制器时，那么该计算机设备2700上可以部署有图25对应实施例中所描述的模块，用于实现图25对应实施例中控制器的功能；当该计算机设备2700为Http DNS服务器时，那么该计算机设备2700上可以部署有图26对应实施例中所描述的模块，用于实现图26对应实施例中Http DNS服务器的功能。计算机设备2700由一个或多个服务器实现，计算机设备2700可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上中央处理器(central processing units，CPU)2722(例如，一个或一个以上中央处理器)和存储器2732，一个或一个以上存储应用程序2742或数据2744的存储介质2730(例如一个或一个以上海量存储设备)。其中，存储器2732和存储介质2730可以是短暂存储或持久存储。存储在存储介质2730的程序可以包括一个或一个以上模块(图示没标出)，每个模块可以包括对计算机设备2700中的一系列指令操作。更进一步地，中央处理器2722可以设置为与存储介质2730通信，在计算机设备2700上执行存储介质2730中的一系列指令操作。
计算机设备2700还可以包括一个或一个以上电源2726，一个或一个以上有线或无线网络接口2750，一个或一个以上输入输出接口2758，和/或，一个或一个以上操作系统2741，例如Windows ServerTM，Mac OS XTM，UnixTM，LinuxTM，FreeBSDTM等等。
本申请实施例中，当计算机设备2700为终端设备，那么该计算机设备2700作为源端设备，可用于执行图8或图17对应实施例中由源端设备执行的步骤，例如，中央处理器2722可以用于：向控制器发送第一扩展DNS请求，该第一扩展DNS请求中包括第一路径请求，该第一路径请求用于指示后续源端设备向目的端设备发送数据包的时候通过的是什么路径(即指示源端设备向目的端设备发送数据包的方式)，在本申请实施例中，不同的路径请求是事先定义在扩展DNS请求的资源记录的字段内的，具体可以有多种实现方式，例如，可以是对扩展DNS协议标准的扩展(即增加新的扩展字段)，也可以是兼容现有的标准协议。在向控制器发送了第一扩展DNS请求后，之后将获取由控制器发送的第一扩展DNS响应，该第一扩展DNS响应由控制器生成，该第一扩展DNS响应中包括与第一路径请求对应的路径信息，该路径信息由控制器根据该第一扩展DNS请求中的信息做匹配查询得到。需要注意的是，在本申请实施例中，在该路径信息的取值不为空的情况下，该路径信息包括源端设备到目的端设备之间的转发节点以及转发节点的先后转发顺序。最后，经由转发节点(即路径信息中包括的转发节点)按照所述先后转发顺序将待发送的目标数据包向该目的端设备发送。需要注意的是，当转发节点为1个时，则默认先后转发顺序就是由这1个转发节点进行转发，当转发节点为n个(n≥2)，则是正常的先后转发顺序。
中央处理器2722，用于执行图8或图17对应实施例中由源端设备执行的任意一个步骤。具体内容可参见本申请前述所示的方法实施例中的叙述，此处不再赘述。
本申请另一些实施例中，当计算机设备2700为控制器，可用于执行图8对应实施例中由控制器执行的步骤，例如，中央处理器2722可以用于：获取由源端设备发送的第一扩展 DNS请求，该第一扩展DNS请求中包括第一路径请求，该第一路径请求用于指示后续源端设备向目的端设备发送数据包的时候通过的是什么路径(即指示源端设备向目的端设备发送数据包的方式)，在本申请实施例中，不同的路径请求是事先定义在扩展DNS请求的资源记录的字段内的，具体可以有多种实现方式，例如，可以是对扩展DNS协议标准的扩展(即增加新的扩展字段)，也可以是兼容现有的标准协议。接收到该第一扩展DNS请求后，可以根据该第一扩展DNS请求中的信息做匹配查询，得到与该第一路径请求对应的路径信息。基于该第一扩展DNS请求得到路径信息后，会向源端设备发送该第一扩展DNS响应，该路径信息就包含在该第一扩展DNS响应中。需要注意的是，在本申请实施例中，在该路径信息的取值不为空的情况下，该路径信息包括源端设备到目的端设备之间的转发节点以及转发节点的先后转发顺序，以使得源端设备经由转发节点(即路径信息中包括的转发节点)按照所述先后转发顺序将待发送的目标数据包向该目的端设备发送。需要注意的是，当转发节点为1个时，则默认先后转发顺序就是由这1个转发节点进行转发，当转发节点为n个(n≥2)，则是正常的先后转发顺序。
中央处理器2722，用于执行图8对应实施例中由控制器执行的任意一个步骤。具体内容可参见本申请前述所示的方法实施例中的叙述，此处不再赘述。
本申请另一些实施例中，当计算机设备2700为Http DNS服务器，可用于执行图17对应实施例中由Http DNS服务器执行的步骤，例如，中央处理器2722可以用于：获取由源端设备发送的第一Http请求，该第一Http请求中包括第一路径请求，该第一路径请求用于指示后续源端设备向目的端设备发送数据包的时候通过的是什么路径(即指示源端设备向目的端设备发送数据包的方式)，在本申请实施例中，不同的路径请求是事先定义在Http请求内，定义过程不涉及标准，因此无需向机构申请。接收到该第一Http请求后，可以根据该第一Http请求中的信息做匹配查询，得到与该第一路径请求对应的路径信息。基于该第一Http请求得到路径信息后，会向源端设备发送该第一Http响应，该路径信息就包含在该第一Http响应中。需要注意的是，在本申请实施例中，在该路径信息的取值不为空的情况下，该路径信息包括源端设备到目的端设备之间的转发节点以及转发节点的先后转发顺序，以使得源端设备经由转发节点(即路径信息中包括的转发节点)按照所述先后转发顺序将待发送的目标数据包向该目的端设备发送。需要注意的是，当转发节点为1个时，则默认先后转发顺序就是由这1个转发节点进行转发，当转发节点为n个(n≥2)，则是正常的先后转发顺序。
中央处理器2722，用于执行图17对应实施例中由Http DNS服务器执行的任意一个步骤。具体内容可参见本申请前述所示的方法实施例中的叙述，此处不再赘述。
本申请实施例中还提供一种计算机可读存储介质，该计算机可读存储介质中存储有用于进行信号处理的程序，当其在计算机上运行时，使得计算机执行如前述所示实施例描述中计算机设备所执行的步骤。
另外需说明的是，以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际 的需要选择其中的部分或者全部模块来实现本实施例方案的目的。另外，本申请提供的装置实施例附图中，模块之间的连接关系表示它们之间具有通信连接，具体可以实现为一条或多条通信总线或信号线。
通过以上的实施方式的描述，所属领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件的方式来实现，当然也可以通过专用硬件包括专用集成电路、专用CPU、专用存储器、专用元器件等来实现。一般情况下，凡由计算机程序完成的功能都可以很容易地用相应的硬件来实现，而且，用来实现同一功能的具体硬件结构也可以是多种多样的，例如模拟电路、数字电路或专用电路等。但是，对本申请而言更多情况下软件程序实现是更佳的实施方式。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在可读取的存储介质中，如计算机的软盘、U盘、移动硬盘、只读存储器(read only memory，ROM)、随机存取存储器(random access memory，RAM)、磁碟或者光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，训练设备，或者网络设备等)执行本申请各个实施例所述的方法。
在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。
所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、训练设备或数据中心通过有线(例如同轴电缆、光纤、数字用户线)或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、训练设备或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存储的任何可用介质或者是包含一个或多个可用介质集成的训练设备、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，高密度数字视频光盘(digital video disc，DVD))、或者半导体介质(例如，固态硬盘(solid state disk，SSD))等。

Claims (39)

  1. 一种路由方法，其特征在于，包括：
    源端设备向控制器发送第一扩展DNS请求，所述第一扩展DNS请求中包括第一路径请求，所述第一路径请求用于指示所述源端设备向目的端设备发送数据包的方式；
    所述源端设备接收由所述控制器发送的第一扩展DNS响应，所述第一扩展DNS响应中包括与所述第一路径请求对应的路径信息，所述路径信息由所述控制器根据所述第一扩展DNS请求得到，在所述路径信息的取值不为空的情况下，所述路径信息包括所述源端设备到所述目的端设备之间的转发节点以及转发节点的先后转发顺序；
    所述源端设备经由所述转发节点按照所述先后转发顺序将待发送的目标数据包向所述目的端设备发送。
  2. 根据权利要求1所述的方法，其特征在于，所述源端设备经由所述转发节点按照所述先后转发顺序将待发送的目标数据包向所述目的端设备发送包括：
    所述源端设备根据所述路径信息对所述目标数据包进行封装，得到封装了第一头域的第一数据包，所述第一头域内包括所述先后转发顺序、源端设备的源地址以及第一跳转发节点的地址；
    所述源端设备将所述第一数据包发送至所述第一跳转发节点，且在所述第一跳转发节点不是最后一跳转发节点的情况下，由所述第一跳转发节点对所述第一数据包的第一头域解封装后对所述目标数据包进行再封装，得到封装了第二头域的第二数据包，并由所述第一跳转发节点将所述第二数据包向第二跳转发节点发送，所述第二头域包括所述先后转发顺序、所述第一跳转发节点的地址以及第二跳转发节点的地址；
    在所述第二跳转发节点是最后一跳转发节点的情况下，由所述第二跳转发节点删除所述第二头域，并由所述第二跳转发节点将删除了所述第二头域的所述目标数据包向所述目的端设备发送。
  3. 根据权利要求2所述的方法，其特征在于，
    在所述第一跳转发节点是最后一跳转发节点的情况下，由所述第一跳转发节点删除所述第一头域，并由所述第一跳转发节点将删除了所述第一头域的所述目标数据包向所述目的端设备发送。
  4. 根据权利要求1-3中任一项所述的方法，其特征在于，所述方法还包括：
    在所述路径信息的取值为空的情况下，所述源端设备直接将待发送的所述目标数据包向所述目的端设备发送。
  5. 根据权利要求1-4中任一项所述的方法，其特征在于，在所述源端设备向控制器发送第一扩展DNS请求之前，所述方法还包括：
    所述源端设备通过安装于所述源端设备上的软件开发工具包(SDK)生成所述第一扩展DNS请求，所述第一扩展DNS请求的生成由所述源端设备上安装的应用发起的会话请求触发。
  6. 根据权利要求1-5中任一项所述的方法，其特征在于，所述源端设备向控制器发送第一扩展DNS请求包括：
    所述源端设备向与所述源端设备对应的DNS服务器发送所述第一扩展DNS请求，并由所述DNS服务器向所述控制器发送所述第一扩展DNS请求；
    所述源端设备接收由所述控制器发送的第一扩展DNS响应包括：
    所述源端设备接收所述控制器通过所述DNS服务器转发的第一扩展DNS响应。
  7. 根据权利要求1-6中任一项所述的方法，其特征在于，所述第一路径请求至少包括如下信息中的任意一种：
    所述目的端地址、待发送数据的应用类型、待发送数据的应用ID、待发送数据的业务类型、待发送数据的QoS要求、待发送数据要求使用的第一路径类型。
  8. 根据权利要求7所述的方法，其特征在于，所述第一路径类型至少包括如下类型中的任意一种：
    Overlay网络路径、SRv6路径、服务链(SFC)路径。
  9. 根据权利要求8所述的方法，其特征在于，
    当所述第一路径类型为所述Overlay网络路径，所述转发节点为PoP；
    当所述第一路径类型为所述SRv6路径，所述转发节点为SRv6路由器；
    当所第一路径类型为所述服务链路径，所述转发节点为支持服务链的硬件设备。
  10. 根据权利要求1-9中任一项所述的方法，其特征在于，
    所述第一路径请求在扩展DNS请求的伪资源记录的新增字段内定义；
    或，
    所述第一路径请求在扩展DNS请求的标准资源记录的已有字段内定义。
  11. 一种路由方法，其特征在于，包括：
    源端设备向Http DNS服务器发送第一Http请求，所述第一Http请求中包括第一路径请求，所述第一路径请求用于指示所述源端设备向目的端设备发送数据包的方式；
    所述源端设备接收由Http DNS服务器发送的第一Http响应，所述第一Http响应中包括与所述第一路径请求对应的路径信息，所述路径信息由所述Http DNS服务器根据所述第一Http请求得到，在所述路径信息的取值不为空的情况下，所述路径信息包括所述源端设备到所述目的端设备之间的转发节点以及转发节点的先后转发顺序；
    所述源端设备经由所述转发节点按照所述先后转发顺序将待发送的目标数据包向所述目的端设备发送。
  12. 根据权利要求11所述的方法，其特征在于，所述源端设备经由所述转发节点按照所述先后转发顺序将待发送的目标数据包向所述目的端设备发送包括：
    所述源端设备根据所述路径信息对所述目标数据包进行封装，得到封装了第一头域的第一数据包，所述第一头域内包括所述先后转发顺序、源端设备的源地址以及第一跳转发节点的地址；
    所述源端设备将所述第一数据包发送至所述第一跳转发节点，且在所述第一跳转发节点不是最后一跳转发节点的情况下，由所述第一跳转发节点对所述第一数据包的第一头域解封装后对所述目标数据包进行再封装，得到封装了第二头域的第二数据包，并由所述第一跳转发节点将所述第二数据包向第二跳转发节点发送，所述第二头域包括所述先后转发 顺序、所述第一跳转发节点的地址以及第二跳转发节点的地址；
    在所述第二跳转发节点是最后一跳转发节点的情况下，由所述第二跳转发节点删除所述第二头域，并由所述第二跳转发节点将删除了所述第二头域的所述目标数据包向所述目的端设备发送。
  13. 根据权利要求12所述的方法，其特征在于，
    在所述第一跳转发节点是最后一跳转发节点的情况下，由所述第一跳转发节点删除所述第一头域，并由所述第一跳转发节点将删除了所述第一头域的所述目标数据包向所述目的端设备发送。
  14. 根据权利要求11-13中任一项所述的方法，其特征在于，所述方法还包括：
    在所述路径信息的取值为空的情况下，所述源端设备直接将待发送的所述目标数据包向所述目的端设备发送。
  15. 根据权利要求11-14中任一项所述的方法，其特征在于，在所述源端设备向Http DNS服务器发送第一Http请求之前，所述方法还包括：
    所述源端设备通过安装于所述源端设备上的软件开发工具包(SDK)生成所述第一Http请求，所述第一Http请求的生成由所述源端设备上安装的应用发起的会话请求触发。
  16. 根据权利要求11-15中任一项所述的方法，其特征在于，所述第一路径请求至少包括如下信息中的任意一种：
    所述目的端地址、待发送数据的应用类型、待发送数据的应用ID、待发送数据的业务类型、待发送数据的QoS要求、待发送数据要求使用的第一路径类型。
  17. 根据权利要求16所述的方法，其特征在于，所述第一路径类型至少包括如下类型中的任意一种：
    Overlay网络路径、SRv6路径、服务链(SFC)路径。
  18. 根据权利要求17所述的方法，其特征在于，
    当所述第一路径类型为所述Overlay网络路径，所述转发节点为PoP；
    当所述第一路径类型为所述SRv6路径，所述转发节点为SRv6路由器；
    当所第一路径类型为所述服务链路径，所述转发节点为支持服务链的硬件设备。
  19. 一种路由方法，其特征在于，包括：
    控制器接收由源端设备发送的第一扩展DNS请求，所述第一扩展DNS请求中包括第一路径请求，所述第一路径请求用于指示所述源端设备向目的端设备发送数据包的方式；
    所述控制器根据所述第一扩展DNS请求得到与所述第一路径请求对应的路径信息；
    所述控制器向所述源端设备发送第一扩展DNS响应，所述路径信息包含在所述第一扩展DNS响应中，其中，在所述路径信息的取值不为空的情况下，所述路径信息包括所述源端设备到所述目的端设备之间的转发节点以及转发节点的先后转发顺序，以使得所述源端设备经由所述转发节点按照所述先后转发顺序将待发送的目标数据包向所述目的端设备发送。
  20. 根据权利要求19所述的方法，其特征在于，所述控制器接收由源端设备发送的第一扩展DNS请求包括：
    所述控制器接收由所述源端设备通过DNS服务器转发的第一扩展DNS请求，所述DNS发服务器与所述源端设备对应；
    所述控制器向所述源端设备发送第一扩展DNS响应包括：
    所述控制器向所述DNS服务器发送第一扩展DNS响应，并由所述DNS服务器向所述源端设备发送所述第一扩展DNS响应。
  21. 一种路由方法，其特征在于，包括：
    Http DNS服务器接收由源端设备发送的第一Http请求，所述第一Http请求中包括第一路径请求，所述第一路径请求用于指示所述源端设备向目的端设备发送数据包的方式；
    所述Http DNS服务器根据所述第一Http请求得到与所述第一路径请求对应的路径信息；
    所述Http DNS服务器向所述源端设备发送第一Http响应，所述路径信息包含在所述第一Http响应中，其中，在所述路径信息的取值不为空的情况下，所述路径信息包括所述源端设备到所述目的端设备之间的转发节点以及转发节点的先后转发顺序，以使得所述源端设备经由所述转发节点按照所述先后转发顺序将待发送的目标数据包向所述目的端设备发送。
  22. 一种终端设备，其特征在于，所述终端设备作为源端设备，包括：
    第一发送模块，用于向控制器发送第一扩展DNS请求，所述第一扩展DNS请求中包括第一路径请求，所述第一路径请求用于指示所述源端设备向目的端设备发送数据包的方式；
    获取模块，用于接收由所述控制器发送的第一扩展DNS响应，所述第一扩展DNS响应中包括与所述第一路径请求对应的路径信息，所述路径信息由所述控制器根据所述第一扩展DNS请求得到，在所述路径信息的取值不为空的情况下，所述路径信息包括所述源端设备到所述目的端设备之间的转发节点以及转发节点的先后转发顺序；
    第二发送模块，用于经由所述转发节点按照所述先后转发顺序将待发送的目标数据包向所述目的端设备发送。
  23. 根据权利要求22所述的设备，其特征在于，所述第二发送模块，具体用于：
    根据所述路径信息对所述目标数据包进行封装，得到封装了第一头域的第一数据包，所述第一头域内包括所述先后转发顺序、源端设备的源地址以及第一跳转发节点的地址；
    将所述第一数据包发送至所述第一跳转发节点，且在所述第一跳转发节点不是最后一跳转发节点的情况下，由所述第一跳转发节点对所述第一数据包的第一头域解封装后对所述目标数据包进行再封装，得到封装了第二头域的第二数据包，并由所述第一跳转发节点将所述第二数据包向第二跳转发节点发送，所述第二头域包括所述先后转发顺序、所述第一跳转发节点的地址以及第二跳转发节点的地址，且在所述第二跳转发节点是最后一跳转发节点的情况下，由所述第二跳转发节点删除所述第二头域，并由所述第二跳转发节点将删除了所述第二头域的所述目标数据包向所述目的端设备发送。
  24. 根据权利要求22-23中任一项所述的设备，其特征在于，所述第二发送模块，还用于：
    在所述路径信息的取值为空的情况下，直接将待发送的所述目标数据包向所述目的端设备发送。
  25. 根据权利要求22-24中任一项所述的设备，其特征在于，所述设备还包括：
    生成模块，用于在所述第一发送模块向控制器发送第一扩展DNS请求之前，通过安装于所述源端设备上的软件开发工具包(SDK)生成所述第一扩展DNS请求，所述第一扩展DNS请求的生成由所述源端设备上安装的应用发起的会话请求触发。
  26. 根据权利要求22-25中任一项所述的设备，其特征在于，所述第一发送模块，具体用于：
    向与所述源端设备对应的DNS服务器发送所述第一扩展DNS请求，并由所述DNS服务器向所述控制器发送所述第一扩展DNS请求；
    所述获取模块，具体用于接收所述控制器通过所述DNS服务器转发的第一扩展DNS响应。
  27. 一种终端设备，其特征在于，所述终端设备作为源端设备，包括：
    第一发送模块，用于向Http DNS服务器发送第一Http请求，所述第一Http请求中包括第一路径请求，所述第一路径请求用于指示所述源端设备向目的端设备发送数据包的方式；
    获取模块，用于接收由Http DNS服务器发送的第一Http响应，所述第一Http响应中包括与所述第一路径请求对应的路径信息，所述路径信息由所述Http DNS服务器根据所述第一Http请求得到，在所述路径信息的取值不为空的情况下，所述路径信息包括所述源端设备到所述目的端设备之间的转发节点以及转发节点的先后转发顺序；
    第二发送模块，用于经由所述转发节点按照所述先后转发顺序将待发送的目标数据包向所述目的端设备发送。
  28. 根据权利要求27所述的设备，其特征在于，所述第二发送模块，具体用于：
    根据所述路径信息对所述目标数据包进行封装，得到封装了第一头域的第一数据包，所述第一头域内包括所述先后转发顺序、源端设备的源地址以及第一跳转发节点的地址；
    将所述第一数据包发送至所述第一跳转发节点，且在所述第一跳转发节点不是最后一跳转发节点的情况下，由所述第一跳转发节点对所述第一数据包的第一头域解封装后对所述目标数据包进行再封装，得到封装了第二头域的第二数据包，并由所述第一跳转发节点将所述第二数据包向第二跳转发节点发送，所述第二头域包括所述先后转发顺序、所述第一跳转发节点的地址以及第二跳转发节点的地址，且在所述第二跳转发节点是最后一跳转发节点的情况下，由所述第二跳转发节点删除所述第二头域，并由所述第二跳转发节点将删除了所述第二头域的所述目标数据包向所述目的端设备发送。
  29. 根据权利要求27-28中任一项所述的设备，其特征在于，所述第二发送模块，还用于：
    在所述路径信息的取值为空的情况下，直接将待发送的所述目标数据包向所述目的端设备发送。
  30. 根据权利要求27-29中任一项所述的设备，其特征在于，所述设备还包括：
    生成模块，用于在所述第一发送模块向Http DNS服务器发送第一Http请求之前，通过安装于所述源端设备上的软件开发工具包(SDK)生成所述第一Http请求，所述第一Http请求的生成由所述源端设备上安装的应用发起的会话请求触发。
  31. 一种控制器，其特征在于，包括：
    获取模块，用于接收由源端设备发送的第一扩展DNS请求，所述第一扩展DNS请求中包括第一路径请求，所述第一路径请求用于指示所述源端设备向目的端设备发送数据包的方式；
    路径规划模块，用于根据所述第一扩展DNS请求得到与所述第一路径请求对应的路径信息；
    发送模块，用于向所述源端设备发送第一扩展DNS响应，所述路径信息包含在所述第一扩展DNS响应中，其中，在所述路径信息的取值不为空的情况下，所述路径信息包括所述源端设备到所述目的端设备之间的转发节点以及转发节点的先后转发顺序，以使得所述源端设备经由所述转发节点按照所述先后转发顺序将待发送的目标数据包向所述目的端设备发送。
  32. 根据权利要求31所述的控制器，其特征在于，所述获取模块，具体用于：
    接收由所述源端设备通过DNS服务器转发的第一扩展DNS请求，所述DNS发服务器与所述源端设备对应；
    所述发送模块，具体用于向所述DNS服务器发送第一扩展DNS响应，并由所述DNS服务器向所述源端设备发送所述第一扩展DNS响应。
  33. 一种Http DNS服务器，其特征在于，包括：
    获取模块，用于接收由源端设备发送的第一Http请求，所述第一Http请求中包括第一路径请求，所述第一路径请求用于指示所述源端设备向目的端设备发送数据包的方式；
    路径规划模块，用于根据所述第一Http请求得到与所述第一路径请求对应的路径信息；
    发送模块，用于向所述源端设备发送第一Http响应，所述路径信息包含在所述第一Http响应中，其中，在所述路径信息的取值不为空的情况下，所述路径信息包括所述源端设备到所述目的端设备之间的转发节点以及转发节点的先后转发顺序，以使得所述源端设备经由所述转发节点按照所述先后转发顺序将待发送的目标数据包向所述目的端设备发送。
  34. 一种终端设备，包括存储器和一个或多个处理器，所述一个和多个处理器与所述存储器耦合，所述终端设备作为源端设备，其特征在于，
    所述存储器，用于存储程序；
    所述一个或多个处理器，用于执行所述存储器中的程序，使得所述终端设备执行如权利要求1-18中任一项所述的方法。
  35. 一种控制器，包括存储器和一个或多个处理器，所述一个和多个处理器与所述存储器耦合，其特征在于，
    所述存储器，用于存储程序；
    所述一个或多个处理器，用于执行所述存储器中的程序，使得所述控制器执行如权利 要求19-20中任一项所述的方法。
  36. 一种Http DNS服务器，包括存储器和一个或多个处理器，所述一个和多个处理器与所述存储器耦合，其特征在于，
    所述存储器，用于存储程序；
    所述一个或多个处理器，用于执行所述存储器中的程序，使得所述Http DNS服务器执行如权利要求21所述的方法。
  37. 一种计算机可读存储介质，包括计算机可读指令，其特征在于，当所述计算机可读指令在计算机上运行时，使得计算机执行如权利要求1-21中任一项所述的方法。
  38. 一种计算机程序产品，包括计算机可读指令，其特征在于，当所述计算机可读指令在计算机上运行时，使得计算机执行如权利要求1-21中任一项所述的方法。
  39. 一种芯片，其特征在于，所述芯片包括存储器和一个或多个处理器，所述芯片用于读取存储器中存储的计算机程序，使得所述一个或多个处理器执行如权利要求1-21任一项所述的方法。
PCT/CN2022/083327 2021-03-31 2022-03-28 一种路由方法及设备 WO2022206667A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202110350574.1A CN115150312B (zh) 2021-03-31 2021-03-31 一种路由方法及设备
CN202110350574.1 2021-03-31

Publications (1)

Publication Number Publication Date
WO2022206667A1 true WO2022206667A1 (zh) 2022-10-06

Family

ID=83403507

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2022/083327 WO2022206667A1 (zh) 2021-03-31 2022-03-28 一种路由方法及设备

Country Status (2)

Country Link
CN (1) CN115150312B (zh)
WO (1) WO2022206667A1 (zh)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117240772B (zh) * 2023-11-08 2024-03-01 苏州元脑智能科技有限公司 一种路由路径确定方法、装置、电子设备及存储介质

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103326945A (zh) * 2013-04-28 2013-09-25 北京智谷睿拓技术服务有限公司 传输控制方法、传输方法及其设备
CN104917677A (zh) * 2014-03-10 2015-09-16 中兴通讯股份有限公司 数据流转发的控制方法及系统
CN107707469A (zh) * 2016-08-09 2018-02-16 百度在线网络技术（北京）有限公司 用于检测访问路径的方法和装置

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3729051B2 (ja) * 2000-10-18 2005-12-21 日本電気株式会社 インタードメインルーティング装置、システムおよび方法
CN103023778B (zh) * 2012-12-05 2016-02-03 华为技术有限公司 路由选路方法及装置
US10454780B2 (en) * 2017-12-07 2019-10-22 Cisco Technology, Inc. Optimizing source routing using machine learning
KR102585874B1 (ko) * 2018-07-11 2023-10-06 삼성전자주식회사 Sdn네트워크에서 라우팅 제어 장치 및 방법
CN111385209B (zh) * 2018-12-28 2021-06-22 华为技术有限公司 一种报文处理方法、报文转发方法、装置及设备
CN109729190B (zh) * 2019-03-15 2024-02-09 深圳前海微众银行股份有限公司 网络访问方法、系统、设备及计算机可读存储介质
CN112242949A (zh) * 2019-07-18 2021-01-19 厦门网宿有限公司 路由分发方法及控制器、信息路由方法及网络节点设备
CN110932968B (zh) * 2019-11-18 2021-05-14 华南理工大学 一种流量转发方法及装置

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103326945A (zh) * 2013-04-28 2013-09-25 北京智谷睿拓技术服务有限公司 传输控制方法、传输方法及其设备
CN104917677A (zh) * 2014-03-10 2015-09-16 中兴通讯股份有限公司 数据流转发的控制方法及系统
CN107707469A (zh) * 2016-08-09 2018-02-16 百度在线网络技术（北京）有限公司 用于检测访问路径的方法和装置

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
QUALCOMM INCORPORATED: "KI#1: Usage of existing DNS and IP routing procedures for Edge Computing discovery", 3GPP DRAFT; S2-2000878, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, vol. SA WG6, no. Incheon, South Korea; 20200113 - 20200117, 7 January 2020 (2020-01-07), Mobile Competence Centre ; 650, route des Lucioles ; F-06921 Sophia-Antipolis Cedex ; France , XP051842932 *

Also Published As

Publication number Publication date
CN115150312B (zh) 2024-05-17
CN115150312A (zh) 2022-10-04

Similar Documents

Publication Publication Date Title
US11909586B2 (en) Managing communications in a virtual network of virtual machines using telecommunications infrastructure systems
US10645056B2 (en) Source-dependent address resolution
US20240163165A1 (en) Configuration system for configuring telecomunications infrastructure networks
CN112470436B (zh) 用于提供多云连通性的系统、方法、以及计算机可读介质
US12003380B2 (en) Providing virtual networking device functionality for managed computer networks
US10819678B2 (en) Data network address sharing between multiple elements associated with a shared network interface unit
Nordström et al. Serval: An {End-Host} stack for {Service-Centric} networking
US8526467B2 (en) Facilitating transition of network operations from IP version 4 to IP version 6
US10530657B2 (en) Providing virtual networking functionality for managed computer networks
US9736016B2 (en) Managing failure behavior for computing nodes of provided computer networks
US9385887B2 (en) Virtualization mapping
US9183028B1 (en) Managing virtual computing nodes
JP4977689B2 (ja) ローカル・ネットワークとリモート・ネットワークとの間のマルチリンク・アクセスを確立する方法および対応するアプライアンス
US8458303B2 (en) Utilizing a gateway for the assignment of internet protocol addresses to client devices in a shared subset
WO2021043314A1 (zh) 混合云环境中的通信方法及网关、管理方法及装置
WO2024067338A1 (zh) 云组网系统、安全访问方法、设备及存储介质
WO2022206667A1 (zh) 一种路由方法及设备
Shah et al. An examination of next generation IP migration techniques: Constraints and evaluation
Rayes et al. The internet in IoT
JP5580766B2 (ja) サーバ装置、パケット伝送システム、パケット伝送方法及びプログラム
Cisco IPv6: Providing IPv6 Services over an IPv4 Backbone Using Tunnels
JP2023546775A (ja) インライン・トランスペアレント・コンピュータ・ネットワーキングデバイスの仮想化のための方法およびシステム
KR101124635B1 (ko) ＩＰｖ４／ＩＰｖ６ 연동 게이트웨이
JP2008206081A (ja) マルチホーミング通信システムに用いられるデータ中継装置およびデータ中継方法
Novo Enabling CoAP-Based Communication across Network Boundaries: Challenges and Solutions

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22778849

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 22778849

Country of ref document: EP

Kind code of ref document: A1