EP2915315B1 - Mise à l'échelle otv au moyen d'adresses mac virtuelles de site - Google Patents

Mise à l'échelle otv au moyen d'adresses mac virtuelles de site Download PDF

Info

Publication number
EP2915315B1
EP2915315B1 EP13789116.4A EP13789116A EP2915315B1 EP 2915315 B1 EP2915315 B1 EP 2915315B1 EP 13789116 A EP13789116 A EP 13789116A EP 2915315 B1 EP2915315 B1 EP 2915315B1
Authority
EP
European Patent Office
Prior art keywords
network
address
layer
mac address
vmac
Prior art date
Legal status (The legal status 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 status listed.)
Active
Application number
EP13789116.4A
Other languages
German (de)
English (en)
Other versions
EP2915315A1 (fr
Inventor
Jaimin Pankajkumar PATEL
Tejas Kokje
Ankur Goyal
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Cisco Technology Inc
Original Assignee
Cisco Technology Inc
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 Cisco Technology Inc filed Critical Cisco Technology Inc
Publication of EP2915315A1 publication Critical patent/EP2915315A1/fr
Application granted granted Critical
Publication of EP2915315B1 publication Critical patent/EP2915315B1/fr
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46—Interconnection of networks
    • H04L12/4641—Virtual LANs, VLANs, e.g. virtual private networks [VPN]
    • 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/64—Routing or path finding of packets in data switching networks using an overlay routing layer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/35—Switches specially adapted for specific applications
    • H04L49/354—Switches specially adapted for specific applications for supporting virtual local area networks [VLAN]
    • 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/09—Mapping addresses
    • H04L61/10—Mapping addresses of different types
    • H04L61/103—Mapping addresses of different types across network layers, e.g. resolution of network layer into physical layer addresses or address resolution protocol [ARP]

Definitions

  • Embodiments presented in this disclosure generally relate to extending layer 2 connectivity across multiple sites, and more specifically, to techniques for using a site virtual MAC address for routing layer 2 traffic to hosts located at remote sites.
  • the traffic flowing into a network device - e.g., a router, switch, bridge, server, and the like - is generally made up of multiple abstraction layers (e.g. , the Open Systems Interconnection (OSI) model). Each of these logical layers generally relates to communications functions of a similar nature.
  • layer 2 of the OSI model is known as the data link layer and uses physical addressing (e.g. , Media Access Control (MAC) addresses) for switching traffic.
  • Layer 2 encapsulation generally provides the mechanism for transferring data between network entities, and can also be used for error correction for layer 1.
  • layer 3 traffic is known as network layer traffic and uses logical addressing (e.g ., Internet Protocol (IP) addresses) for routing traffic.
  • IP Internet Protocol
  • routers can be configured to forward packets from one network to another. For instance, a router may receive a packet, inspect the IP address in the packet's header, and compare the IP address to route information stored in the router's internal routing table to determine what to do with the packet. For example, the router could determine a destination for the packet based on information in the router's internal routing table and could forward the packet on towards the destination. As the packet is switched from router to router, its IP address may remain the same, but its MAC address may be updated to the next router interface along the path.
  • Overlay Transport Virtualization provides a solution to extend layer 2 connectivity across different sites using an existing layer 3 network.
  • layer 2 extensions across multiple data centers is achieved by configuring one or more OTV edge devices at each of the data centers to extend a set of virtual local area networks (VLANs) across the multiple data centers.
  • VLANs virtual local area networks
  • remote-site MAC addresses can be installed on the edge devices, such that hosts within a first one of the data centers can access hosts within the other data centers using layer 2 communications.
  • these techniques can extend layer 2 connectivity across multiple different sites.
  • US2011/0317703 A1 discloses such an extension technique wherein a MAC address of a gateway is used as proxy for all hosts residing in the corresponding site.
  • the invention provides for a method of providing an extended layer 2 network per claim 1, a corresponding system per claim 5 and a computer readable medium per claim 6.
  • Dependent claims set out preferred embodiments of the invention.
  • One challenge for layer 2 networks extended across multiple data centers using OTV is controlling the size of MAC address tables on the various edge devices. That is, in a traditional network extended using OTV, an edge device at a first one of the data centers may need to be configured with the MAC addresses for each of the hosts at each of the other data centers. These MAC address tables may quickly grow to be prohibitively large as the layer 2 extended network grows. As a result, the total size of the extended network may be limited by the maximum size of the edge devices' MAC address tables. These limitations may be more pronounced in system on chip (SOC) network devices, where resources such as system memory are more limited.
  • SOC system on chip
  • Figure 1 illustrates a layer 2 extended network, according to one embodiment described herein.
  • the system 100 includes a first data center 110 and a second data center 120, interconnected via an overlay network 130.
  • each of the data centers 110, 120 may maintain a separate layer 2 network, and these layer 2 networks can be logically combined into an extended layer 2 network through the use of OTV.
  • host 1 140 within the first data center's 110 layer 2 network may send layer 2 network traffic to host 2 150 within the second data center's 120 layer 2 network.
  • an edge device within the first data center's 110 network could be configured with a MAC address table that specifies the MAC address of host 1 as well as the MAC address of host 2.
  • the edge device Upon receiving a data packet destined for the MAC address of host 2, the edge device could transmit the data packet over the overlay network 130 to an edge device for the second data center 120, which could then route the data packet on to host 2. While such a solution may be adequate for small scale extended networks containing a relatively small number of remote hosts, the MAC address tables on the edge devices can grow prohibitively large when dealing with a larger number of remote hosts.
  • embodiments include techniques for providing an extended layer 2 network.
  • Such an extended network could span, for instance, multiple data centers connected via a layer 2 data center interconnect.
  • a first network edge device in a first layer 2 network may receive a data packet specifying a destination Media Access Control (MAC) address.
  • MAC Media Access Control
  • Logic on the first network edge device may then determine whether the destination MAC address is a site virtual MAC (S-VMAC) address.
  • S-VMAC address is a logical identifier assigned to each layer 2 network in a given OTV site or to an entire OTV site within the extended layer 2 network.
  • a first data center could be assigned an S-VMAC address of "S1-VMAC" and a second data center could be assigned an S-VMAC address of "S2-VMAC".
  • a MAC address table on each of the network edge devices within the extended layer 2 network could be preconfigured with information characterizing these S-VMAC addresses and logic configured to handle data packets directed to these S-VMAC addresses. For instance, returning to the present example, logic on the first network edge device could access a MAC address table on the first network edge device and could determine that the destination MAC address specified by the data packet is an S-VMAC address associated with a second network device in a second layer 2 network within the extended layer 2 network. Based on this determination, the logic within the first network edge device could forward the data packet to the second network device associated with the S-VMAC address.
  • the second network device Upon receiving the data packet from the first network device, the second network device could determine a destination media access control (MAC) address associated with the destination IP address. For instance, logic on the second network device could access an IP address to MAC address binding table (e.g., an adjacency table) on the second network device to determine a destination MAC address associated with the destination IP address. Once the destination MAC address is determined, the logic on the second network device could forward the data packet to a destination device within the second layer 2 network associated with the destination MAC address.
  • MAC media access control
  • edge devices within the extended layer 2 network to maintain a single S-VMAC address for each of the remote edge devices within the extended layer 2 network. That is, as discussed above, edge devices in traditional OTV-enabled networks maintain a separate MAC address in their respective MAC address table for each individual host within each remote layer 2 network. This, in turn, can cause these MAC address tables to grow prohibitively large and may effectively limit the total size of the extended layer 2 network.
  • embodiments make more efficient use of the MAC address tables on the edge devices and thus may provide a much larger extended layer 2 network than traditional solutions.
  • FIG. 2 An example of a system configured to use S-VMAC addresses is shown in Figure 2 , which illustrates a layer 2 extended network configured with an OTV component, according to one embodiment described herein.
  • the system 200 includes a first data center network 210 and a second data center network 220 interconnected via a data center interconnect (DCI) layer 2 extension network 230.
  • the first data center network 210 contains an edge network device 240 1 configured with an OTV component 245 1
  • the second data center network 220 contains an edge network device 240 2 configured with an OTV component 245 2
  • the first data center network 210 includes hosts 250 1-2
  • the second data center network 220 includes hosts 250 3-4 .
  • the DCI layer 2 extension network 230 could be, for instance, an existing service provider layer 3 network. More generally, however, it is contemplated that any type of network connecting the data centers 210, 220 could be used, consistent with the embodiments described herein.
  • each of the hosts 250 1-4 and the edge devices 240 1-2 are configured with a respective MAC address 270 1-6 .
  • the hosts 250 1-2 and the edge device 240 1 may communicate with one another using the MAC addresses 270 1-3 (and other devices within the first data center network 210 using their respective MAC addresses).
  • the host 250 1 could transmit an ARP request requesting the MAC address associated with a first IP address.
  • the host 250 2 could return the MAC address 270 3 in response to the ARP request.
  • the host 250 1 could then transmit layer 2 traffic to the host 250 2 by addressing the traffic to the MAC address 270 3 .
  • Layer 2 communications within the second data center network 220 may be handled in a similar fashion.
  • the OTV components 245 1-2 may be configured to handle layer 2 communications over the extended layer 2 network using the S-VMAC addresses 260 1-2 . That is, the OTV component 245 1 could be configured to manage layer 2 communications going to and coming from the second data center network 220 over the DCI layer 2 extension network 230, and the OTV components 245 2 could be configured to manage layer 2 communications going to and coming from the first data center network 210 over the DCI layer 2 extension network 230.
  • the OTV components 245 1-2 are preconfigured with data assigning the S-VMAC addresses 260 1-2 to the edge devices 240 1-2 .
  • one of more of the OTV components 245 1-2 is configured to dynamically assign the S-VMAC addresses 260 1-2 to the edge devices 240 1-2 .
  • each of the OTV components 245 1-2 is configured to forward layer 2 traffic to its respective remote network 210, 220 over the DCI layer 2 extension network 230 based on the assigned S-VMAC addresses 260 1-2 .
  • the host 250 1 could transmit an ARP request to the edge device 240 1 , requesting the MAC address associated with a particular IP address.
  • the OTV component 245 1 on the edge device 240 1 could determine that the particular IP address is associated with a host located within the second data center network 220. In making this determination, the OTV component 245 1 could reference an IP-to-MAC address binding table stored on the edge device 240 1 . An example of such a table is shown below in Table 1.
  • the OTV component 245 1 could determine that the second IP address (e.g., HOST3-IP, which represents an IP address corresponding to the host 250 3 ) corresponds to the destination MAC address "S2-VMAC". Upon determining that the second IP address is associated with a remote host, the OTV component 245 1 could return the address "S2-VMAC” (i.e., the S-VMAC address 260 2 associated with the second data center network 220) to the host 250 1 in response to the ARP request. Logic on the host 250 1 could then update its local ARP cache with the returned S-VMAC address 260 2 corresponding to the particular IP address.
  • the second IP address e.g., HOST3-IP, which represents an IP address corresponding to the host 250 3
  • the OTV component 245 1 could return the address "S2-VMAC” (i.e., the S-VMAC address 260 2 associated with the second data center network 220) to the host 250 1 in response to the ARP request.
  • the host 250 1 could generate layer 2 traffic directed to the address "S2-VMAC", based on the host's 250 1 local ARP cache.
  • the OTV component 245 1 could reference a MAC address table to determine how to properly switch the traffic.
  • An example of such a table is shown below in Table 2.
  • Table 2 - Data Center 1 Hardware MAC Address Table VLAN Destination MAC Address Destination Interface 10 HOST1-MAC Eth1/5 11 HOST2-MAC Eth1/5 10 S2-VMAC Overlay 11 S2-VMAC Overlay
  • the OTV component 245 1 upon receiving network frames from the host 250 1 addressed to the address "S2-VMAC" (i.e., S-VMAC address 260 2 ), the OTV component 245 1 could reference the MAC address table to determine that frames to this S-VMAC address for both VLANs "10" and "11" are sent over the "Overlay” network (i.e., the DCI layer 2 extension network 230). The OTV component 245 1 could then forward these network frames to the OTV component 245 2 on the edge device 240 2 , over the DCI layer 2 extension network 230.
  • S2-VMAC i.e., S-VMAC address 260 2
  • the OTV component 245 1 could reference the MAC address table to determine that frames to this S-VMAC address for both VLANs "10" and "11” are sent over the "Overlay” network (i.e., the DCI layer 2 extension network 230).
  • the OTV component 245 1 could then forward these network frames to the OTV component 245 2 on the
  • the OTV component 245 2 Upon receiving the network frames from the OTV component 245 1 , the OTV component 245 2 could access an IP-to-MAC address binding table (e.g., an adjacency table) on the edge device 240 2 to determine a MAC address to forward the network frames to.
  • IP-to-MAC address binding table e.g., an adjacency table
  • An example of such a table is shown below in Table 3.
  • the OTV component 245 2 could analyze the forwarded data packets and could determine that the destination IP address specified in the forwarded data packets is "HOST3-IP", and that the IP-to-MAC address binding table indicates that this IP address corresponds to host 250 3 having MAC address 270 5 ( i.e. , "HOST3-MAC") on the second data center network 220.
  • the OTV component 245 2 could then alter the destination MAC address specified in the forwarded data packets by replacing the S-VMAC address 260 2 with the MAC address 270 5 for the host 250 3 .
  • the OTV component 245 2 could access a MAC address table on the edge device 240 2 to determine how to switch the incoming traffic to the MAC address "HOST3-MAC".
  • a MAC address table is shown below in Table 4.
  • Table 4 - Data Center 2 MAC Address Table VLAN Destination MAC Address Destination Interface 10 HOST3-MAC Eth2/10 11 HOST4-MAC Eth2/10 10 S1-VMAC Overlay 11 S1-VMAC Overlay
  • the OTV component 245 2 could access the MAC address table shown in Table 3 and could determine that traffic to the MAC address "HOST3-MAC" should be sent on VLAN 10 and using the interface "Eth2/10". The OTV component 245 2 could then forward the altered data packets on to the host 250 3 .
  • the aforementioned techniques provide the extended layer 2 network in a more efficient fashion than conventional OTV techniques. That is, as the edge devices 240 1-2 in the depicted example maintain an S-VMAC address for each of the data centers within the extended layer 2 network, as opposed to a separate MAC address for each and every remote host within the extended layer 2 network, the size of these MAC address tables are not directly based on the total number of hosts within the extended layer 2 network.
  • the extended layer 2 network can become much larger than conventional extended layer 2 networks before the MAC address tables on the edge devices 240 1-2 become prohibitively large.
  • SOC system on a chip
  • FIG. 2 shows two data center networks 210, 220 interconnected via the DCI layer 2 extension network 230, it is broadly contemplated that any number of different networks can be connected together under an extended layer 2 network using the techniques described above.
  • FIG. 3 is a flow diagram illustrating a method for returning a MAC address for a host, according to one embodiment described herein.
  • the method 300 begins at block 310, where an OTV component 245 on an edge device 240 receives an ARP request from a first host and specifying an IP address associated with a second host.
  • the OTV component 245 determines whether the second host associated with the IP address is located at a remote site (block 315). That is, the OTV component 245 determines if the second host is located within a different physical layer 2 network than the edge device 245.
  • the OTV component 245 could determine that the second host is located at a remote site.
  • the OTV component 245 determines an S-VMAC address associated with the remote site and returns the determined S-VMAC address in response to the ARP request (block 325).
  • the OTV component 245 determines an S-VMAC address associated with the remote site and returns the determined S-VMAC address in response to the ARP request (block 325).
  • the second host is located at the local site, the method 300 ends. In such a scenario, the second host could return its MAC address in response to the ARP request. Once the OTV component 245 returns the S-VMAC address, the method 300 ends.
  • logic on the first host could then update an ARP cache on the first host with the received address. For example, if the OTV component 245 returns an S-VMAC address for the second host in response to the ARP request, logic on the first host could update its local ARP cache to create an association between the IP address and the returned S-VMAC address. If, at some subsequent point in time, the first host wishes to transmit a network frame to the second host, the first host could then specify a destination MAC address within the network frame as the returned S-VMAC address.
  • Figure 4 is a flow diagram illustrating a method for routing a data packet, according to one embodiment described herein.
  • the method 400 begins at block 410, where the OTV component 245 receives a data packet from the first host. Upon receiving the data packet, the OTV component 245 analyzes the data packet and determines a destination MAC address for the data packet. Additionally, the OTV component 245 determines whether the destination MAC address is an S-VMAC address (block 415).
  • the OTV component 245 determines a remote device to route the data packet to and forward the data packet on to the remote device (block 425). For example, the OTV component 245 could access a MAC address table on the edge device 240 and could determine that network traffic for a particular VLAN and addressed to S-VMAC address "S2-VMAC" should be sent over the "Overlay" interface (e.g ., an existing service provider layer 3 network connecting two or more data centers, such as the DCI interconnect network 230 shown in Figure 2 ) to a remote network device having a particular IP address, and could forward the network traffic on accordingly.
  • the "Overlay" interface e.g ., an existing service provider layer 3 network connecting two or more data centers, such as the DCI interconnect network 230 shown in Figure 2
  • the OTV component 245 determines that the destination MAC address specified in the data packet is not an S-VMAC address, the OTV component 245 forward the data packet on to the local device associated with the destination MAC address (block 420). Once the OTV component 245 routes the packet to the remote edge device or the local device, the method 400 ends.
  • the OTV component 245 may determine a local MAC address associated with the data packet and forward the data packet on to the local MAC address.
  • Figure 5 is a flow diagram illustrating a method for routing a data packet received from a remote site, according to one embodiment described herein.
  • the method 500 begins at block 510, where the OTV component 245 on a first edge device receives a data packet from a remote edge device.
  • the received packet is addressed to an S-VMAC address associated with the first edge device.
  • the data packet could be forwarded using the method 400 described above.
  • the OTV component 245 Upon receiving the data packet, the OTV component 245 analyzes the data packet to determine a destination IP address for the data packet. Based on this destination IP address, the OTV component 245 determines a destination MAC address for the data packet (block 515). For example, the OTV component 245 could query an IP-to-MAC address binding table (e.g ., an adjacency table) on the first edge device to determine a destination MAC address that corresponds to the destination IP address for the data packet. Upon determining the destination MAC address, the OTV component 245 rewrites the MAC address in the network frame for the data packet to replace the S-VMAC destination address with the determined destination MAC address (block 520).
  • an IP-to-MAC address binding table e.g ., an adjacency table
  • the OTV component 245 could query a MAC address table on the first edge device to determine how to transmit network traffic to the determined destination MAC address (e.g., which interface to use, which VLAN to use, etc. ) .
  • the OTV component 245 then transmits the altered network frame to the destination MAC address (block 525), and the method 500 ends.
  • a MAC address table on the first edge device to determine how to transmit network traffic to the determined destination MAC address (e.g., which interface to use, which VLAN to use, etc. ) .
  • the OTV component 245 then transmits the altered network frame to the destination MAC address (block 525), and the method 500 ends.
  • Advantageously, doing so provides an extended layer 2 network while minimizing the size of the MAC address tables maintained by the various edge devices within the extended network.
  • FIG. 6 illustrates a communication network, according to one embodiment described herein.
  • Communication network 600 includes a plurality of computing devices 605 and edge network devices 630.
  • Each computing device (or end device or host) 605 1-3 includes a processor 610, memory 615, and network adapter 625.
  • the processor 610 may be any processing element capable of performing the functions described herein.
  • the processor 610 represents single processor, multiple processors, a processor with multiple cores, and combinations thereof.
  • the memory 615 may be either volatile or non-volatile memory and include, RAM, flash, cache, disk drives and the like. Although shown as a single entity, the memory 615 may be divided into different memory storage element such as RAM and one or more hard disk drives.
  • the network adapter 625 facilitates communication between the computing devices 605 and the edge network devices 630.
  • the network adapter may use either wired or wireless communication techniques to transmit data to, and receive data from, the edge network devices 630.
  • the applications 620 may use the network adapter to enable communication to other computer devices 605 2,3 .
  • the edge network devices 630 include a processor 635, communication ports 640, and memory 645.
  • the processor 635 may be any processing element capable of performing the functions described herein.
  • the processor 635 represents a single processor, multiple processors, a processor with multiple cores, and combinations thereof.
  • the memory 645 may be either volatile or non-volatile memory and include, RAM, flash, cache, disk drives and the like.
  • the memory 645 contains an OTV component 245.
  • the OTV components 245 within the edge network devices 630 1-3 are generally configured to provide an efficient extended layer 2 network through the use of S-VMAC addresses.
  • the memory 645 could also contain network logic- e.g., a content addressable memory - for forwarding data in the communication network 600.
  • the edge network devices 630 may also include a control plane for configuring and managing the forwarding logic.
  • An edge network device 630 may be coupled to one or more computing devices 605, other network devices, or a combination of both using the ports 640.
  • the network 655 represents one or more network devices that forward data plane traffic from one end device to another.
  • the network may be a WAN (e.g. , the Internet) or a LAN.
  • the network 655 may forward management plane or control plane traffic between the network devices 630 or between the network devices 630 and the computing devices 605.
  • each of the edge network devices 630 1-3 resides at a different site ( e.g ., a data center) and the network 655 represents a DCI interconnect network (e.g ., an existing service provider layer 3 network).
  • the OTV components 245 are generally configured to provide an extended layer 2 network, in which the connected computing devices (e.g ., computing device 605 1 for the edge network device 630 1 ) can transmit layer 2 network traffic to remote computing devices (e.g ., computing device 605 2 ) using an S-VMAC address.
  • the OTV component 245 within the edge network device 630 1 could receive a data packet specifying a first destination MAC address.
  • the OTV component 245 could forward the data packet to a second network device (e.g ., the edge network device 630 2 over the network 655).
  • the OTV component 245 could access a MAC address table on the edge network device 630 1 and could determine that data packets addressed to the particular S-VMAC address should be routed over the network 655 and to an IP address associated with the edge network device 630 2 .
  • the OTV component 245 on the edge network device 630 2 could determine a destination MAC address associated with a destination IP address specified in the data packet. For instance, the OTV component 245 could access an ARP table on the edge network device 630 2 to determine the destination MAC address associated with the specified destination IP address in the data packet. The OTV component 245 could then forwarding the data packet to a destination device associated with the destination MAC address. For example, assuming that the determined MAC address corresponds to the computing device 605 2 , the OTV component 245 could forward the data packet on to the computing device 605 2 .
  • the computing devices 605 1-3 can communicate with remote devices within the extended layer 2 network using layer 2 communications.
  • Cloud computing generally refers to the provision of scalable computing resources as a service over a network. More formally, cloud computing may be defined as a computing capability that provides an abstraction between the computing resource and its underlying technical architecture (e.g ., servers, storage, networks), enabling convenient, on-demand network access to a shared pool of configurable computing resources that can be rapidly provisioned and released with minimal management effort or service provider interaction.
  • cloud computing allows a user to access virtual computing resources (e.g ., storage, data, applications, and even complete virtualized computing systems) in "the cloud,” without regard for the underlying physical systems (or locations of those systems) used to provide the computing resources.
  • Cloud computing resources may be provided to a user on a pay-per-use basis, where users are charged only for the computing resources actually used (e.g., an amount of storage space consumed by a user or a number of virtualized systems instantiated by the user).
  • a user can access any of the resources that reside in the cloud at any time, and from anywhere across the Internet.
  • an OTV component 245 could execute on an edge network device in a first data center for the cloud and could associate an S-VMAC address with another data center for the cloud.
  • the OTV component 245 could return the S-VMAC address in response to ARP requests from hosts at the first data center that specify a destination IP address associated with a remote host located at the other data center for the cloud.
  • the OTV component 245 Upon receiving network traffic specifying the S-VMAC address as a destination address, the OTV component 245 could forward the network traffic to a remote edge device at the other data center.
  • An OTV component 245 on the remote edge device could determine a destination MAC address within the other data center based on the destination IP address specified in the data packet, and could forward the data packet on to the determined destination MAC address.
  • Advantageously, doing so provides an extended layer 2 network for two or more data centers for the cloud which users can access from any computing system attached to a network connected to the cloud (e.g ., the Internet).
  • aspects of the present disclosure may be implemented in hardware or software or in a combination of hardware and software.
  • One embodiment of the disclosure may be implemented as a program product for use with a computer system.
  • the program(s) of the program product define functions of the embodiments (including the methods described herein) and can be contained on a variety of computer-readable storage media.
  • Illustrative computer-readable storage media include, but are not limited to: (i) non-writable storage media (e.g ., read-only memory devices within a computer such as CD-ROM disks readable by a CD-ROM drive, flash memory, ROM chips or any type of solid-state non-volatile semiconductor memory) on which information is permanently stored; and (ii) writable storage media (e.g ., floppy disks within a diskette drive or hard-disk drive or any type of solid-state random-access semiconductor memory) on which alterable information is stored.
  • non-writable storage media e.g ., read-only memory devices within a computer such as CD-ROM disks readable by a CD-ROM drive, flash memory, ROM chips or any type of solid-state non-volatile semiconductor memory
  • writable storage media e.g ., floppy disks within a diskette drive or hard-disk drive or any type of solid-state random-access semiconductor memory
  • each block in the flowchart or block diagrams may represent a module, segment or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s).
  • the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved.

Landscapes

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

Claims (6)

  1. Procédé de fourniture d'un réseau de couche 2 étendu comprenant une pluralité de réseaux de couche 2 connectés selon la tecnnologie OTV (Overlay Transport Virtualization), à chacun des réseaux de couche 2 étant assigné un identifiant logique unique appelé adresse de commande d'accès au support, MAC, virtuelle de site, S-VMAC, le procédé comprenant :
    la réception (410), au niveau d'un premier dispositif périphérique de réseau dans un premier réseau de couche 2 au sein du réseau de couche 2 étendu, d'un paquet de données spécifiant une première adresse, MAC, destinataire ;
    l'accès, sur le premier dispositif périphérique de réseau, à une table d'adresses MAC, la table d'adresses MAC renfermant ladite adresse S-VMAC unique de chaque réseau de couche 2 distant, pour déterminer que la première adresse MAC destinataire est une adresse S-VMAC, ladite adresse S-VMAC étant associée à un deuxième dispositif périphérique de réseau dans un deuxième réseau de couche 2 au sein du réseau de couche 2 étendu et pour déterminer des informations de commutation comportant un identifiant d'interface servant à identifier une interface destinataire correspondant à l'adresse S-VMAC pour transférer le paquet de données au deuxième dispositif périphérique de réseau, dans lequel l'adresse S-VMAC est assignée dynamiquement au deuxième dispositif de réseau au sein du réseau de couche 2 étendu ; et
    le transfert (425) du paquet de données à l'aide de l'interface identifiée au deuxième dispositif périphérique de réseau, dans lequel le deuxième dispositif périphérique de réseau est configuré pour déterminer (515) une deuxième adresse MAC destinataire pour le paquet de données sur la base d'une adresse de protocole Internet, IP, destinataire spécifiée dans le paquet de données, et est configuré en outre pour remplacer la première adresse MAC destinataire dans le paquet de données par la deuxième adresse MAC destinataire déterminée et est configuré en outre pour transférer (525) le paquet de données à un dispositif destinataire associé à la deuxième adresse MAC destinataire déterminée.
  2. Procédé selon la revendication 1, comprenant en outre :
    à la détermination que la première adresse MAC destinataire n'est pas une adresse S-VMAC, le transfert du paquet de données à un dispositif destinataire associé à la première adresse MAC destinataire.
  3. Procédé selon la revendication 1, comprenant en outre :
    la réception d'une demande de protocole de résolution d'adresse, ARP, spécifiant l'adresse IP ;
    la détermination que l'adresse IP correspond à un hôte distant au sein du deuxième réseau de couche 2 ; et
    en réponse à la demande ARP, le renvoi de l'adresse S-VMAC associée au deuxième dispositif périphérique de réseau.
  4. Procédé selon la revendication 1, dans lequel les informations de commutation comportent au moins un d'un identifiant d'interface, et d'un identifiant de VLAN.
  5. Système comprenant un premier dispositif périphérique de réseau dans un premier réseau de couche 2 au sein d'un réseau de couche 2 étendu et un deuxième dispositif périphérique de réseau dans un deuxième réseau de couche 2 au sein du réseau de couche 2 étendu, chacun des premier et deuxième dispositifs périphériques de réseau comprenant :
    un processeur ; et
    une mémoire contenant un programme qui, à son exécution par le processeur, amène le système à mettre en œuvre toutes les étapes d'un procédé selon l'une quelconque des revendications précédentes.
  6. Support lisible par ordinateur comportant des instructions exécutables qui, à leur exécution dans un système de traitement, amènent le système de traitement à mettre en œuvre toutes les étapes d'un procédé selon l'une quelconque des revendications 1 à 4.
EP13789116.4A 2012-10-31 2013-10-24 Mise à l'échelle otv au moyen d'adresses mac virtuelles de site Active EP2915315B1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US13/664,905 US8976792B2 (en) 2012-10-31 2012-10-31 OTV scaling: site virtual MAC address
PCT/US2013/066684 WO2014070590A1 (fr) 2012-10-31 2013-10-24 Mise à l'échelle otv au moyen d'adresses mac virtuelles de site

Publications (2)

Publication Number Publication Date
EP2915315A1 EP2915315A1 (fr) 2015-09-09
EP2915315B1 true EP2915315B1 (fr) 2020-06-10

Family

ID=49553859

Family Applications (1)

Application Number Title Priority Date Filing Date
EP13789116.4A Active EP2915315B1 (fr) 2012-10-31 2013-10-24 Mise à l'échelle otv au moyen d'adresses mac virtuelles de site

Country Status (4)

Country Link
US (1) US8976792B2 (fr)
EP (1) EP2915315B1 (fr)
CN (1) CN104782104B (fr)
WO (1) WO2014070590A1 (fr)

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103179228B (zh) * 2013-04-02 2015-08-19 杭州华三通信技术有限公司 因特网协议地址解析方法及边缘节点
JP6036506B2 (ja) * 2013-04-15 2016-11-30 富士通株式会社 障害影響範囲を特定するためのプログラム及び情報処理装置
JP2016103731A (ja) * 2014-11-28 2016-06-02 株式会社日立製作所 計算機システム、ゲートウェイ、および、転送制御方法
US10491476B2 (en) 2017-08-22 2019-11-26 Cisco Technology, Inc. Extending a virtual local area network across a layer 2 data center interconnect
CN108989220B (zh) * 2018-09-05 2021-04-02 中国联合网络通信集团有限公司 路由方法和路由系统
US11425147B2 (en) * 2019-03-01 2022-08-23 Oracle International Corporation In-service data plane encryption verification
US11057350B2 (en) 2019-05-30 2021-07-06 Cisco Technology, Inc. Layer 2 mobility for hybrid multi-cloud deployments without host-overlay
US11438237B1 (en) * 2020-01-21 2022-09-06 Vmware, Inc. Systems and methods for determining physical links between network devices

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4647825B2 (ja) * 2001-04-27 2011-03-09 富士通セミコンダクター株式会社 パケット送受信システム、ホスト、および、プログラム
US8166205B2 (en) 2007-07-31 2012-04-24 Cisco Technology, Inc. Overlay transport virtualization
EP3703345A1 (fr) * 2010-06-29 2020-09-02 Huawei Technologies Co., Ltd. Encapsulation d'adresse de réseau asymétrique
CN102457586B (zh) * 2010-10-18 2015-06-03 中兴通讯股份有限公司 一种实现二层网络的扩展方法及扩展的二层网络

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
None *

Also Published As

Publication number Publication date
US20140119372A1 (en) 2014-05-01
US8976792B2 (en) 2015-03-10
WO2014070590A1 (fr) 2014-05-08
CN104782104A (zh) 2015-07-15
EP2915315A1 (fr) 2015-09-09
CN104782104B (zh) 2018-03-20

Similar Documents

Publication Publication Date Title
EP2915315B1 (fr) Mise à l'échelle otv au moyen d'adresses mac virtuelles de site
US11736394B2 (en) Address resolution using multiple designated instances of a logical router
US11411770B2 (en) Virtual port channel bounce in overlay network
US8358661B2 (en) Remote adapter configuration
KR102054338B1 (ko) 개별 관리들을 이용하는 vlan 태깅된 패킷들의 가상 포워딩 인스턴스들의 원단 주소들로의 라우팅
US9215175B2 (en) Computer system including controller and plurality of switches and communication method in computer system
WO2014136864A1 (fr) Appareil de réécriture de paquet, appareil de commande, système de communication, procédé de transmission de paquet et programme
CN112910750B (zh) 使用逻辑路由器进行地址解析的方法、设备、系统及介质
US10798048B2 (en) Address resolution protocol suppression using a flow-based forwarding element
US8489763B2 (en) Distributed virtual bridge management
US10742697B2 (en) Packet forwarding apparatus for handling multicast packet
US10079694B2 (en) Scalable virtual networks in SDN-based ethernet networks using VLANs
US20140280822A1 (en) Service directory for quick and simplified application identification
CN107113241B (zh) 路由确定方法、网络配置方法以及相关装置
US20110261687A1 (en) Priority Based Flow Control Within a Virtual Distributed Bridge Environment
WO2016003490A1 (fr) Codage d'informations de plan de commande dans un champ de port source de protocole de transport, et ses applications en virtualisation de réseau
US20110243134A1 (en) Data Frame Forwarding Using a Distributed Virtual Bridge
US20110222538A1 (en) Method and System for L3 Bridging Using L3-To-L2 Mapping Database
US9306856B2 (en) Optimal tree root selection for trees spanning multiple sites
US11991246B2 (en) Cloud scale multi-tenancy for RDMA over converged ethernet (RoCE)
US12010173B2 (en) Class-based queueing for scalable multi-tenant RDMA traffic
US20230336480A1 (en) Efficient Handling of Fragmented Packets in Multi-Node All-Active Clusters
WO2023204984A1 (fr) Gestion efficace de paquets fragmentés dans des grappes entièrement actives à nœuds multiples

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20150430

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

DAX Request for extension of the european patent (deleted)
RIN1 Information on inventor provided before grant (corrected)

Inventor name: KOKJE, TEJAS

Inventor name: GOYAL, ANKUR

Inventor name: PATEL, JAIMIN PANKAJKUMAR

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20170403

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: GRANT OF PATENT IS INTENDED

INTG Intention to grant announced

Effective date: 20200107

GRAS Grant fee paid

Free format text: ORIGINAL CODE: EPIDOSNIGR3

GRAA (expected) grant

Free format text: ORIGINAL CODE: 0009210

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE PATENT HAS BEEN GRANTED

AK Designated contracting states

Kind code of ref document: B1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

REG Reference to a national code

Ref country code: GB

Ref legal event code: FG4D

REG Reference to a national code

Ref country code: CH

Ref legal event code: EP

Ref country code: AT

Ref legal event code: REF

Ref document number: 1280085

Country of ref document: AT

Kind code of ref document: T

Effective date: 20200615

REG Reference to a national code

Ref country code: DE

Ref legal event code: R096

Ref document number: 602013069794

Country of ref document: DE

REG Reference to a national code

Ref country code: IE

Ref legal event code: FG4D

REG Reference to a national code

Ref country code: LT

Ref legal event code: MG4D

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: SE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20200610

Ref country code: GR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20200911

Ref country code: NO

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20200910

Ref country code: FI

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20200610

Ref country code: LT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20200610

REG Reference to a national code

Ref country code: NL

Ref legal event code: MP

Effective date: 20200610

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: LV

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20200610

Ref country code: RS

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20200610

Ref country code: HR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20200610

Ref country code: BG

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20200910

REG Reference to a national code

Ref country code: AT

Ref legal event code: MK05

Ref document number: 1280085

Country of ref document: AT

Kind code of ref document: T

Effective date: 20200610

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: AL

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20200610

Ref country code: NL

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20200610

REG Reference to a national code

Ref country code: DE

Ref legal event code: R082

Ref document number: 602013069794

Country of ref document: DE

Representative=s name: MATHYS & SQUIRE GBR, DE

Ref country code: DE

Ref legal event code: R082

Ref document number: 602013069794

Country of ref document: DE

Representative=s name: MATHYS & SQUIRE EUROPE PATENTANWAELTE PARTNERS, DE

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: SM

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20200610

Ref country code: EE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20200610

Ref country code: PT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20201012

Ref country code: ES

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20200610

Ref country code: RO

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20200610

Ref country code: IT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20200610

Ref country code: AT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20200610

Ref country code: CZ

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20200610

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: GB

Payment date: 20201027

Year of fee payment: 8

Ref country code: FR

Payment date: 20201026

Year of fee payment: 8

Ref country code: DE

Payment date: 20201028

Year of fee payment: 8

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: PL

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20200610

Ref country code: SK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20200610

Ref country code: IS

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20201010

REG Reference to a national code

Ref country code: DE

Ref legal event code: R097

Ref document number: 602013069794

Country of ref document: DE

PLBE No opposition filed within time limit

Free format text: ORIGINAL CODE: 0009261

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: NO OPPOSITION FILED WITHIN TIME LIMIT

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: DK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20200610

26N No opposition filed

Effective date: 20210311

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: SI

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20200610

REG Reference to a national code

Ref country code: CH

Ref legal event code: PL

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: MC

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20200610

Ref country code: LU

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20201024

REG Reference to a national code

Ref country code: BE

Ref legal event code: MM

Effective date: 20201031

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: LI

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20201031

Ref country code: BE

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20201031

Ref country code: CH

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20201031

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: IE

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20201024

REG Reference to a national code

Ref country code: DE

Ref legal event code: R079

Ref document number: 602013069794

Country of ref document: DE

Free format text: PREVIOUS MAIN CLASS: H04L0029120000

Ipc: H04L0067286900

REG Reference to a national code

Ref country code: DE

Ref legal event code: R119

Ref document number: 602013069794

Country of ref document: DE

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: TR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20200610

Ref country code: MT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20200610

Ref country code: CY

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20200610

GBPC Gb: european patent ceased through non-payment of renewal fee

Effective date: 20211024

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: MK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20200610

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: GB

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20211024

Ref country code: DE

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20220503

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: FR

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20211031

P01 Opt-out of the competence of the unified patent court (upc) registered

Effective date: 20230525