Traffic-stream-based mapped cache refresh for supporting device and dynamic policy updates.

Abstract

A flow-based mapping cache refresh can be provided. When a packet associated with a flow having a destination and a source is dropped before reaching its destination, the computing device can receive a dropped packet message. Next, in response to receiving the dropped packet message, a mapping request message can be sent to the mapping server (MS). In response to sending the mapping request message, a mapping response message indicating the updated destination of the flow can be received. Then, based on the updated destination from the received mapping response message, the mapping cache for the source of the flow can be refreshed.

Description

[0001] Cross-references to related applications

[0002] This application, filed as a PCT international patent application on November 12, 2021, claims the benefit and priority of U.S. Provisional Patent Application No. 16 / 590,315, filed on November 17, 2020, the entire disclosure of which is incorporated herein by reference. Technical Field

[0003] This disclosure generally relates to providing a mapping cache refresh based on traffic flow. Background Technology

[0004] A computer network, or data network, is a telecommunications network that allows computers to exchange data. In a computer network, networked computing devices exchange data with each other using data links. Connections between nodes are established using either cable or wireless media. The most well-known computer network is the Internet.

[0005] Networked computer devices that initiate, route, and terminate data are called network nodes. Nodes can include hosts such as personal computers, telephones, servers, and networking hardware. Two such devices are said to be networked when one device can exchange information with another, regardless of whether they are directly connected to each other. Computer networks differ in the transmission medium used to carry their signals, the communication protocols used to organize network traffic, the size of the network, its topology, and its organizational intent. Attached Figure Description

[0006] The accompanying drawings, which are incorporated in and constitute a part of this disclosure, illustrate various embodiments of the present disclosure. In the drawings:

[0007] Figure 1 It is a block diagram of the network;

[0008] Figure 2 This is a flowchart for providing a method for refreshing a mapping cache based on traffic flow;

[0009] Figure 3 This is a flowchart illustrating a method for providing traffic-stream-based mapped cache refresh; and

[0010] Figure 4 It is a block diagram of a computing device. Detailed Implementation

[0011] Overview

[0012] The invention is set forth in the independent claims, and preferred features are set forth in the dependent claims. A feature of one aspect may be applied individually to each aspect or in combination with other aspects to each aspect.

[0013] A flow-based mapping cache refresh can be provided. When a packet associated with a flow having a destination and a source is dropped before reaching its destination, the computing device can receive a dropped packet message. Next, in response to receiving the dropped packet message, a mapping request message can be sent to the mapping server (MS). In response to sending the mapping request message, a mapping response message indicating the updated destination of the flow can be received. The mapping cache can then be refreshed for the source of the flow based on the updated destination from the received mapping response message.

[0014] The foregoing overview and the following exemplary embodiments are both illustrative and explanatory only, and should not be considered as limiting the scope of the described and claimed disclosure. Furthermore, features and / or variations may be provided in addition to the described features and / or variations. For example, embodiments of the disclosure may be directed to various combinations and sub-combinations of features described in the exemplary embodiments.

[0015] Example Implementation

[0016] The following detailed description refers to the accompanying drawings. Where possible, the same reference numerals are used in the drawings and the following description to refer to the same or similar elements. While embodiments of the present disclosure can be described, modifications, adjustments, and other implementations are possible. For example, elements shown in the drawings may be replaced, added, or modified, and the methods described herein may be modified by replacing, reordering, or adding stages to the disclosed methods. Therefore, the following detailed description does not limit the present disclosure. Rather, the appropriate scope of the present disclosure is defined by the appended claims.

[0017] A structured network can include a network topology in which components exchange data with each other through interconnected network nodes (e.g., devices). A structured network can include an overlay layer and a bottom layer. The bottom layer handles connections between structured network devices, while the overlay layer handles user traffic traversing the structured network. The structured network overlay layer can include functional components such as structured edge devices (ED or FE), structured intermediate devices, structured boundary devices (FB or BD), mapping servers (MS), and structured control planes (CP).

[0018] In the structured network overlay layer, FE devices may include, for example, Locator / ID Separation Protocol (LISP) xTR (Ingress / Egress Tunnel Router) / PxTR (Proxy xTR) nodes, and FB devices may include, for example, LISP PxTR (Proxy xTR) nodes. Endpoints (e.g., client devices or hosts) may be attached to FE devices. Endpoints may reside in an endpoint identifier space, where each endpoint may have an endpoint identifier (EID). Each device in the structured network (e.g., FE devices and FB devices) may be configured with an address (e.g., a locator address). FE devices may register discovered EIDs (from endpoints) with a structured host tracking database running on the MS, which associates the discovered EIDs with, for example, the configured locator address of the FE device that discovered it.

[0019] When a local FE device receives a packet from its local endpoint destined for a remote endpoint whose location is unknown (i.e., on a remote FE device) (e.g., an endpoint connected via the Internet), the local FE device can send a mapping request message to the MS. The MS may have a border device registered as an Internet Service Provider. In this case, the MS can respond to the mapping request using a remote locator address that serves as an Internet Service Provider boundary address. Once the local FE device receives a response message from the MS that associates an unknown EID with the remote locator address, all subsequent traffic from the local endpoint can be encapsulated (e.g., LISP encapsulation) and forwarded to the remote locator address (i.e., the remote xTR device). Once the encapsulated packet is received on the remote xTR device, the remote xTR device can decapsulate the packet and forward it locally (e.g., to the remote endpoint).

[0020] When a local FE device receives a packet from its local endpoint destined for a remote endpoint whose location is unknown at the local FE (i.e., on the remote FE device), the local FE device can send a mapping request message to the MS. The MS may have a remote endpoint registered with a Routing Locator (RLOC) of another remote FE. In this case, the MS can respond to the mapping request using the remote locator address, which is the address of the remote FE. Once the local FE device receives a response message from the MS that associates the remote EID with the remote locator address, subsequent traffic from the local endpoint can be encapsulated (e.g., LISP encapsulation) and forwarded to the remote locator address (i.e., the remote xTR device). Once the encapsulated packet is received on the remote xTR device, the remote xTR device can decapsulate the packet and forward it locally (e.g., to the remote endpoint).

[0021] FB devices can connect a fabricated network to a local routing domain. FB devices can be configured, for example, as LISP PxTR nodes and can provide default gateway services to FE nodes. Communication can occur through an FB device configured, for example, as a LISP PxTR node. When an FE device receives a packet from its local endpoint destined for a host outside the fabricated network within its local routing domain, the FE device can encapsulate the packet and send it to the FB device. FB devices can provide, for example, LISP PxTR functionality and advertise themselves as the next-hop address for all fabric-managed EID prefixes in the local routing domain so that they can route traffic.

[0022] The infrastructure overlay layer can provide the following services. For example, the infrastructure overlay layer can use Layer 3 overlay to provide extended Layer 2 services, which can provide the flexibility to extend subnets to any part of the infrastructure network. For example, a subnet can exist on multiple FE devices with the same anycast gateway Internet Protocol (IP) address to allow roaming by allowing endpoints to continue using the same gateway IP address. The services provided may also include Layer 3 overlay services and built-in mobility.

[0023] Traditional mapping caches (e.g., traditional LISP mapping caches) can be destination-based, so when they are flushed or removed, traffic destined for those destinations can be affected regardless of the source. However, for structured networks that support communication with cloud servers using policies based on security identities / groups for example, different IoT devices (e.g., using Software-Defined Access (SDA)), it may be necessary to dynamically update mapping caches specific to certain flows (i.e., flows between specific source and destination subnets / groups). This can be useful when, for example, certain users / devices (e.g., electronic badges, personal IoT devices, cloud-based IoT devices, etc.) are granted or deprived of access to certain privileged services provided by the cloud server. This may require flushing existing mapping caches without waiting for, for example, a 24-hour aging timeout. It is also desirable not to affect other flows that may be using the same time-critical services (e.g., same destination but different source), such as campus security / surveillance, emergency response voice / video calls, etc. These time-critical services should not be affected (i.e., mapping caches for those flows should not be removed and relearned if dynamic / policy changes do not affect them).

[0024] Traditional mapping caching mechanisms (e.g., Solicit Map Requests (SMRs) / Leave Tables, etc.) can be destination-based. This can make it difficult for a group of users to change their access to public / critical services in an enterprise infrastructure network without affecting other users. This problem can become even more difficult if the infrastructure network is used for mission-critical applications using various sensors and IoT devices (e.g., hospitals, defense, aviation, space exploration, autonomous driving, etc.). Furthermore, traditional LISP data path SMRs can be based on User Datagram Protocol (UDP), and they can derive their destination from the source of the data packet (i.e., where the SMR is sent), which can negatively impact its reliability. If the SMR UDP packet is lost or the source of the data packet is incorrect or cannot be reached directly, the SMR may fail to reach its correct destination xTR (e.g., network device) to refresh the mapping cache. This can lead to continued traffic leakage or create a "black hole" due to dynamic changes or software / network errors.

[0025] Therefore, embodiments of this disclosure can dynamically refresh the mapping cache for a specific flow without affecting other flows of time-critical applications or maintainability, thereby enabling faster recovery from software or network problems. Some embodiments of this disclosure can install "flow-based" leave entries in the Forwarding Information Base (FIB) and forwarding hardware to drop packets and generate SMRs for the "flow". If the number of packets hitting the leave entry continues to increase and the number of generated SMRs increases to exceed a threshold (i.e., a predetermined value), other embodiments can refresh the mapping cache by sending "reliable SMRs" from the receiver xTR (e.g., FB) to the source xTR (e.g., FE) via a mapping server using, for example, a Transmission Control Protocol (TCP) session between the mapping server and the xTR. Embodiments of this disclosure can ensure that dynamic policy changes can be reliably refreshed in the mapping cache in the network without causing latency or scaling issues.

[0026] Figure 1 A system 100 for providing services with policy control, according to an embodiment of this disclosure, is shown. For example... Figure 1As shown, system 100 may include a first network 102, multiple client devices 104, a second network 106, a mapping server 108, a first server 110, and a second server 112. The first network 102 may include multiple network devices, including but not limited to router 114, a first edge device 116, a second edge device 118, intermediate network devices (not shown), and a border device 120. The multiple client devices 104 may include a first client device 122 and a second client device 124. The second network 106 may include networks outside of the first network 102, such as networks to the cloud (e.g., the Internet). Servers 110 and 112 may each provide any service (e.g., cloud-based services), including but not limited to Dynamic Host Configuration Protocol (DHCP), Domain Name System (DNS), Authentication, Authorization, and Accounting (AAA), and other shared services. The mapping server 108 may include, but is not limited to, a LISP mapping server.

[0027] The network devices in the first network 102 may include, but are not limited to, switches and routers. The first network 102 may include any number of network devices. The multiple client devices 104 may include any number of client devices, and are not limited to two. Each of the multiple client devices 104 may include any type of device wishing to communicate through the first network 102. For example, each of the multiple client devices 104 may include, but is not limited to, Wi-Fi access points, cellular base stations, tablet devices, Internet of Things (IoT) devices, mobile devices, smartphones, telephones, remote control devices, set-top boxes, digital video recorders, cable modems, personal computers, laptops, network computers, mainframes, routers, or other similar microcomputer-based devices.

[0028] The first network 102 may include a structured network. The structured network may include a lower layer and an overlay layer. The lower layer may handle connections between structured elements (e.g., network devices), and the overlay layer may handle user traffic entering the structure. Traffic may enter the structured network (i.e., the first network 102) through FE devices (e.g., first edge device 116 and second edge device 118). Traffic may be routed through the first network 102 via multiple intermediate network devices within the multiple network devices. FE devices may be responsible for encapsulating packets using a structure header containing the address of the egress FE device. When a packet (e.g., a frame) arrives at the egress FE device, the structure header may be stripped, and the local packet may be forwarded based on its internal address. The structured network may be able to provide Layer 2 and Layer 3 services above the lower layer. The structured network may have endpoints (e.g., multiple client devices 104) connected to it.

[0029] The first client device 122 and the second client device 124 can be wirelessly connected to the first edge device 116 and the second edge device 118 via wireless systems (including but not limited to WiFi, 4G or 5G). The first client device 122 and the second client device 124 can be, but are not limited to, IoT devices that can obtain services from the first server 110 or the second server 112.

[0030] The aforementioned components of system 100 (e.g., mapping server 108, server 110, server 112, router 114, first edge device 116, second edge device 118, border device 120, first client device 122, or second client device 124) can be implemented in hardware and / or software (including firmware, resident software, microcode, etc.) or any other circuit or system. The components of system 100 can be implemented in circuits (including discrete electronic components, packaged or integrated electronic chips containing logic gates, circuits utilizing microprocessors), or on a single chip containing electronic components or a microprocessor. Furthermore, the components of system 100 can also be implemented using other technologies capable of performing logical operations (e.g., AND, OR, NOT), including but not limited to mechanical, optical, fluid, and quantum technologies. See the following references... Figure 4 In more detail, the components of system 100 can be implemented in computing device 400.

[0031] Figure 2 This is a flowchart illustrating the overall stages involved in a method 200 for providing a traffic flow-based mapped cache refresh according to an embodiment of the present invention. Method 200 can be described using the methods referenced above. Figure 1 The first edge device 116 is implemented in more detail. For example, Figure 2 The embodiment shown can install "flow-based" departure entries in the FIB and forwarding hardware to drop packets and generate SMRs for the "flow". The manner in which each stage of implementing method 200 is carried out will be described in more detail below.

[0032] Method 200 may begin at start block 205 and proceed to stage 210, where the first edge device 116 may receive a message about a dropped packet when a packet associated with a flow having a destination and a source is dropped before reaching its destination. For example, when a dynamic policy associated with a destination and source prefix pair (e.g., associated with certain hosts / IoT devices and cloud servers in the same or different Virtual Routing and Forwarding (VRF) / instances) is changed, a leave table entry may be installed in the fast forwarding / FIB and forwarding hardware (e.g., in border device 120) to drop packets specific to that source and destination prefix pair. In other words, the dynamic policy may be changed to deny the first client device 122 access to the first server 110. In response, a leave table entry may be installed on border device 120 that causes border device 120 to drop packets in a flow having the first server 110 as the destination and the first client device 122 as the source. Nevertheless, the leave table entry may cover multiple sources, not just one. Whenever any data packet hits an exit table entry in border device 120, the data packet associated with that "flow" can be dropped by border device 120 without being sent to its destination (e.g., first server 110). Furthermore, border device 120 can generate a drop packet message and send it to first edge device 116. The drop packet message can include, but is not limited to, a User Datagram Protocol (UDP) Solicitation Mapping Request (SMR) generated to the source RLOC address of the data packet (e.g., the RLOC address of first edge device 116).

[0033] In phase 210, when a packet associated with traffic having a destination and a source is dropped before reaching its destination, the first edge device 116 receives a dropped packet message. Method 200 can then proceed from phase 210 to phase 220, in which the first edge device 116 may, in response to receiving the dropped packet message, send a mapping request message to the mapping server 108. For example, when a dropped packet message (e.g., SMR) arrives at the source xTR (e.g., the first edge device 116), the source xTR (e.g., the first edge device 116) may map the request to the mapping server 108 to obtain a new mapping for the destination endpoint identifier (EID) (i.e., an updated destination mapping).

[0034] Once the first edge device 116 sends a mapping request message to the mapping server 108 in response to receiving a dropped packet message in phase 220, method 200 can continue to phase 230, in which the first edge device 116 can receive a mapping response message indicating the updated destination of the flow in response to sending the mapping request message. For example, during the aforementioned dynamic policy change, for a source including the first client device 122, the destination EID may have already been updated on the mapping server 108 from the EID of the first server 110 to the EID of the second server 112. Therefore, the updated destination of the flow in the mapping response message may include the EID of the second server 112 instead of the EID of the first server 110. Therefore, the mapping server 108 responds with a mapping according to the new policy change.

[0035] After the first edge device 116 receives a mapping response message (indicating the updated destination of the stream) in response to sending a mapping request message at stage 230, method 200 can proceed to stage 240, in which the first edge device 116 can refresh the mapping cache of the stream's source based on the updated destination from the received mapping response message. For example, using the refreshed mapping cache, the first edge device 116 can now include the correct destination (e.g., the second server 112) on packets sent from the first client device 122. When these new packets arrive at the edge device 120, the leave table entries may no longer cause them to be discarded because they no longer have the source and destination prefix pairs for the first client device 122 and the first server 110, but now have the source and destination prefix pairs for the first client device 122 and the second server 112. Once the first edge device 116 refreshes the mapping cache of the stream's source based on the updated destination from the received mapping response message at stage 240, method 200 can end at stage 250.

[0036] Figure 3 This is a flowchart illustrating the overall stages involved in a method 300 for providing a traffic flow-based mapped cache refresh, according to embodiments of this disclosure. Method 300 can be described using the methods referenced above. Figure 1 A more detailed description of the mapping server 108 is provided for implementation. For example, if the number of packets hitting outgoing entries continues to increase, and the number of generated SMRs increases to exceed a threshold (i.e., a predetermined value), then... Figure 3The illustrated embodiment may use, for example, a Transmission Control Protocol (TCP) session between mapping server 108 and xTR to send a “reliable SMR” from the receiver xTR (e.g., border device 120) to the source xTR (e.g., first edge device 116) via mapping server 108 to refresh the mapping cache in the first edge device 116. The manner in which the various stages of implementing method 300 are carried out will be described in more detail below.

[0037] Method 300 can begin at start block 305 and proceed to stage 310, in which mapping server 108 can receive refresh messages associated with a stream having a destination and a source through a first session. For example, utilizing the above-mentioned... Figure 2 If a receiver xTR (e.g., border device 120) continues to receive traffic after generating a predetermined number of discard packet messages (e.g., exceeding a preset threshold SMR) (flow leave entry hit), the installed flow-based leave table entry can conclude that the discard packet message (e.g., SMR) was not delivered to the source xTR (e.g., first edge device 116) of the data traffic, or that the source RLOC address (e.g., first edge device 116) in the packet for which it is sending the discard packet message is incorrect or unreachable.

[0038] In other words, the leave table entries on the receiver xTR (e.g., border device 120) are kept quizzed because it can continue to receive packets with source and destination prefix pairs for the first client device 122 and the first server 110, respectively. With each quizz, the receiver xTR (e.g., border device 120) can send a dropped packet message (e.g., SMR) to the first edge device 116. After sending a predetermined number of dropped packet messages, the border device 120 can assume that the dropped packet messages (e.g., SMR) have not reached the first edge device 116. Software or network errors may cause incorrect source RLOC addresses in lost data packets, resulting in, for example, UDP SMR failure. Therefore, after a predetermined number of dropped packet messages have been sent, the border device 120 can send a refresh message associated with the flow having a destination and source to the mapping server 108 via a first session. The first session may include a first Secure Transmission Control Protocol (TCP) session. The refresh message may include a “reliable SMR” sent via the TCP session. In this example, the receiver xTR (e.g., border device 120) can generate a "reliable SMR" with the same parameters and content as the UDP SMR sent to the source xTR (e.g., first edge device 116). However, the "reliable SMR" can be sent to the mapping server 108 via a reliable TCP session between the receiver xTR (e.g., border device 120) and the mapping server 108.

[0039] In phase 310, mapping server 108 receives a refresh message associated with a flow having a destination and a source via a first session. Method 300 can then proceed from phase 310 to phase 320, where mapping server 108 can determine the updated destination of the flow. For example, during the aforementioned dynamic policy change, for a source including first client device 122, the destination EID may have been updated on mapping server 108 from the EID of first server 110 to the EID of second server 112. Therefore, the updated destination of the flow in the mapping response message may include the EID of second server 112 instead of the EID of first server 110. Thus, mapping server 108 responds with mapping according to the new policy change.

[0040] Once mapping server 108 determines the updated destination of the flow in phase 320, method 300 can proceed to phase 330, where mapping server 108 can send a mapping response message indicating the updated destination of the flow to the edge device (ED) associated with the source of the flow (e.g., first edge device 116) via a second session. The second session may include a second secure TCP session. For example, mapping server 108 can notify the source xTR (e.g., first edge device 116) that it has registered the source EID in the SMR via another reliable TCP session between mapping server 108 and the source xTR (e.g., first edge device 116). Mapping server 108 can find the source xTR (e.g., first edge device 116) from the source EID registration in the SMR (rather than from the source RLOC of the data packet). This can also be helpful for serviceability and guarantees, even if any software or network error causes an incorrect source RLOC address in the data packet (leading to UDP SMR refresh mapping cache failure).

[0041] In phase 330, after mapping server 108 sends a mapping response message indicating the updated destination of the flow to the ED associated with the source of the flow (e.g., first edge device 116) via a second session, method 300 may proceed to phase 340, in which the ED (e.g., first edge device 116) may refresh the mapping cache of the source of the flow based on the updated destination from the received mapping response message. For example, using the refreshed mapping cache, first edge device 116 can now include the correct destination (e.g., second server 112) on packets sent from first client device 122. When these new packets arrive at edge device 120, leave table entries may no longer cause them to be discarded because they no longer have the source and destination prefix pairs for first client device 122 and first server 110, but now have the source and destination prefix pairs for first client device 122 and second server 112. Once the ED (e.g., the first edge device 116) refreshes the source mapping cache of the stream based on the updated destination from the received mapping response message in stage 340, method 300 can end at stage 350.

[0042] Therefore, embodiments of the present invention can allow SDA-structured networks to dynamically update policies for IoT devices and other hosts that may require immediate (i.e., without waiting for a 24-hour timeout) mapping cache refresh. This can work on a "source / destination" basis (source / destination prefix and VRF / IID) without affecting endpoints with the same destination but different sources. Embodiments of this disclosure can work in the presence of network congestion or software and network errors (e.g., that may result in incorrect or unreachable source addresses for data packets), where existing data plane UDP SMR cannot update the mapping cache.

[0043] Figure 4 A computing device 400 is shown. (For example...) Figure 4 As shown, computing device 400 may include a processing unit 410 and a memory unit 415. Memory unit 415 may include software module 420 and database 425. Software module 420, when executed on processing unit 410, may perform (for example) as described above. Figure 2 and Figure 3 The described process is for providing a traffic-flow-based mapping cache refresh. For example, computing device 400 can provide an operating environment for mapping server 108, server 110, server 112, router 114, first edge device 116, second edge device 118, border device 120, first client device 122, or second client device 124. Mapping server 108, server 110, server 112, router 114, first edge device 116, second edge device 118, border device 120, first client device 122, or second client device 124 can operate in other environments, not limited to computing device 400.

[0044] Computing device 400 can be implemented using Wi-Fi access points, cellular base stations, tablet devices, mobile devices, smartphones, telephones, remote control devices, set-top boxes, digital video recorders, cable modems, personal computers, network computers, mainframes, routers, switches, server clusters, smart TV devices, network storage devices, network relay devices, or other similar microcomputer-based devices. Computing device 400 can include any computer operating environment, such as handheld devices, multiprocessor systems, microprocessor-based or programmable transmitter electronics, minicomputers, mainframes, etc. Computing device 400 can also be implemented in a distributed computing environment, where tasks are performed by remote processing devices. The systems and devices described above are examples, and computing device 400 can include other systems or devices.

[0045] For example, embodiments of this disclosure can be implemented as a computer process (method), computing system, or article of manufacture, such as a computer program product or a computer-readable medium. A computer program product can be a computer storage medium readable by a computer system and encodes a computer program containing instructions for performing the computer process. A computer program product can also be a propagated signal on a carrier wave readable by a computing system and encode a computer program containing instructions for performing the computer process. Therefore, this disclosure can be embodied in hardware and / or software (including firmware, resident software, microcode, etc.). In other words, embodiments of this disclosure can take the form of a computer program product on a computer-usable or computer-readable storage medium having computer-usable or computer-readable program code embodied therein for use by or in conjunction with an instruction execution system. A computer-usable or computer-readable medium can be any medium capable of containing, storing, communicating, propagating, or transmitting a program for use by or in connection with an instruction execution system, apparatus, or device.

[0046] Computer-usable or computer-readable media can be, for example, but not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, apparatuses, or propagation media. More specific examples of computer-readable media (a non-exhaustive list) may include the following: electrical connections having one or more wires, portable computer floppy disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), fiber optic cables, and portable optical disc read-only memory (CD-ROM). Note that computer-usable or computer-readable media can even be paper or other suitable media for printing programs, as programs can be electronically captured via optical scanning of, for example, paper or other media, then compiled, interpreted, or processed in a suitable manner as necessary, and then stored in computer memory.

[0047] While some embodiments of this disclosure have been described, other embodiments may exist. Furthermore, although embodiments of the invention have been described in association with data stored in memory and other storage media, data may also be stored on or read from other types of computer-readable media, such as secondary storage devices (e.g., hard disks, floppy disks, or CD-ROMs), carrier waves from the Internet, or other forms of RAM or ROM. Moreover, the stages of the disclosed method may be modified in any way without departing from this disclosure, including by reordering and / or inserting or deleting stages.

[0048] Furthermore, embodiments of this disclosure can be practiced in circuits (including discrete electronic components, packaged or integrated electronic chips containing logic gates, circuits utilizing microprocessors), or on a single chip containing electronic components or a microprocessor. Embodiments of this disclosure can also be practiced using other techniques capable of performing logical operations (e.g., AND, OR, NOT), including but not limited to mechanical, optical, fluid, and quantum technologies. Additionally, embodiments of the invention can be practiced within a general-purpose computer or in any other circuit or system.

[0049] Embodiments of this disclosure can be practiced via a system-on-a-chip (SOC), wherein Figure 1 Each or more of the elements shown can be integrated onto a single integrated circuit. Such a SOC device may include one or more processing units, graphics units, communication units, system virtualization units, and various application functions, all of which can be integrated (or “programmed”) onto a chip substrate as a single integrated circuit. When operating via the SOC, the functions described herein with respect to embodiments of this disclosure can be performed via dedicated logic integrated on a single integrated circuit (chip) along with other components of the computing device 400.

[0050] For example, embodiments of the present disclosure have been described above with reference to block diagrams and / or operational illustrations of methods, systems, and computer program products according to embodiments of the present disclosure. Functions / actions indicated in the blocks may occur in any order shown in any flowchart. For example, depending on the functions / actions involved, two blocks shown consecutively may actually be executed substantially simultaneously, or these blocks may sometimes be executed in reverse order.

[0051] Although the specification includes examples, the scope of this disclosure is indicated by the appended claims. Furthermore, although this specification has been described using language specific to structural features and / or methodological actions, the claims are not limited to the features or actions described above. Rather, the specific features and actions described above are disclosed as examples of embodiments of this disclosure.

Claims

1. A method for cache refresh, comprising: When a packet associated with a flow having a destination and a source is dropped before reaching the destination, the device receives a dropped packet message, wherein receiving the dropped packet message when a packet associated with a flow having a destination and a source is dropped before reaching the destination includes: receiving the dropped packet message in response to installing a leave table entry in a border device associated with the destination to drop packets specific to the destination and source prefix pair, and wherein the leave table entry is installed when a policy change associated with the destination and source prefix pair that denies the source access to the destination is implemented; In response to receiving the discard packet message, a mapping request message is sent to the mapping server (MS); In response to sending the mapping request message, receive a mapping response message indicating the updated destination of the stream; and Based on the updated destination from the received mapping response message, refresh the mapping cache for the source of the stream.

2. The method according to claim 1, further comprising: Change the strategy associated with the flow.

3. The method according to claim 1, further comprising: Install the departure table entry on the network device associated with the destination to drop packets associated with the destination and the source, which are associated with the flow.

4. The method according to claim 3, further comprising: When the packet arrives at the network device, the packet is discarded according to the departure table entry.

5. The method according to claim 4, further comprising: In response to dropping the packet, the network device sends the dropped packet message.

6. The method according to any one of claims 1 to 5, wherein, The dropped packet message includes a request mapping request (SMR).

7. The method according to any one of claims 1 to 5, wherein, The source is associated with Internet of Things (IoT) devices.

8. The method according to any one of claims 1 to 5, wherein, The destination is associated with the first server.

9. The method according to any one of claims 1 to 5, wherein, The updated destination is associated with a second server.

10. A method for cache refresh, comprising: A computing device receives a refresh message associated with a flow having a destination and a source via a first session, wherein receiving the refresh message associated with a flow having a destination and a source includes: receiving a discard packet message in response to installing a leave table entry in a boundary device associated with the destination to discard packets specific to the destination and source prefix pair, and wherein the leave table entry is installed when a policy change associated with the destination and source prefix pair that denies the source access to the destination is implemented; Determine the updated destination of the flow; and A mapping response message indicating the updated destination of the stream is sent to the edge device (ED) associated with the source of the stream via a second session.

11. The method of claim 10, further comprising: Based on the updated destination from the received mapping response message, refresh the mapping cache for the source of the stream.

12. The method according to claim 10, wherein, Receiving the refresh message includes: receiving the refresh message in response to the network device sending a predetermined number of drop packet messages associated with a flow having the destination and the source.

13. The method according to claim 12, wherein, The predetermined number of dropped packet messages includes a predetermined number of Request Mapping Requests (SMRs).

14. The method according to any one of claims 10 to 13, wherein, The computing device includes a mapping server.

15. The method according to any one of claims 10 to 13, wherein, The first session includes a first secure transmission control protocol (TCP) session.

16. The method according to any one of claims 10 to 13, wherein, The second session includes a second Secure Transmission Control Protocol (TCP) session.

17. An apparatus for cache refresh, comprising: A module for receiving a discard packet message when a packet associated with a flow having a destination and a source is discarded before reaching the destination, wherein receiving the discard packet message when a packet associated with a flow having a destination and a source is discarded before reaching the destination includes: receiving the discard packet message in response to installing a leave table entry in a border device associated with the destination to discard packets specific to the destination and source prefix pair, and wherein the leave table entry is installed when a policy change associated with the destination and source prefix pair that denies the source access to the destination is implemented; A module for sending a mapping request message to the mapping server (MS) in response to receiving the discard packet message; A module for receiving a mapping response message indicating the updated destination of the stream in response to sending the mapping request message; and A module for refreshing the mapping cache for the source of the stream based on the updated destination from the received mapping response message.

18. The apparatus of claim 17, further comprising: Apparatus for implementing the method according to any one of claims 2 to 9.

19. An apparatus for cache refresh, comprising: A module for receiving, via a first session, a refresh message associated with a flow having a destination and a source by a computing device, wherein receiving the refresh message associated with a flow having a destination and a source includes: receiving a discard packet message in response to installing a leave table entry in a boundary device associated with the destination to discard packets specific to the destination and source prefix pair, and wherein the leave table entry is installed upon a policy change associated with the destination and source prefix pair that denies the source access to the destination; A module for determining the updated destination of the stream; and A module for sending, via a second session, a mapping response message indicating the updated destination of the stream to the edge device (ED) associated with the source of the stream.

20. The apparatus of claim 19, further comprising a module for implementing the method of any one of claims 11 to 16.

21. A computer program product comprising instructions that, when executed by a computer, cause the computer to perform the steps of the method according to any one of claims 1 to 16.

22. A computer-readable medium comprising instructions that, when executed by a computer, cause the computer to perform the steps of the method according to any one of claims 1 to 16.

Images