US11190447B2 - Routing protocol and distributed router - Google Patents

Routing protocol and distributed router Download PDF

Info

Publication number
US11190447B2
US11190447B2 US16/875,886 US202016875886A US11190447B2 US 11190447 B2 US11190447 B2 US 11190447B2 US 202016875886 A US202016875886 A US 202016875886A US 11190447 B2 US11190447 B2 US 11190447B2
Authority
US
United States
Prior art keywords
address
destination
node
routing
packet
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
US16/875,886
Other versions
US20210006495A1 (en
Inventor
Chiang Yeh
Nathan Farrington
Cyriel Minkenberg
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.)
Rockley Photonics Ltd
Original Assignee
Rockley Photonics Ltd
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 Rockley Photonics Ltd filed Critical Rockley Photonics Ltd
Publication of US20210006495A1 publication Critical patent/US20210006495A1/en
Assigned to ROCKLEY PHOTONICS LIMITED reassignment ROCKLEY PHOTONICS LIMITED ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: YEH, CHIANG, FARRINGTON, NATHAN, MINKENBERG, CYRIEL JOHAN AGNES
Application granted granted Critical
Publication of US11190447B2 publication Critical patent/US11190447B2/en
Assigned to WILMINGTON SAVINGS FUND SOCIETY, FSB, AS COLLATERAL AGENT reassignment WILMINGTON SAVINGS FUND SOCIETY, FSB, AS COLLATERAL AGENT SECURITY INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: ROCKLEY PHOTONICS LIMITED
Assigned to WILMINGTON SAVINGS FUND SOCIETY, FSB, AS COLLATERAL AGENT reassignment WILMINGTON SAVINGS FUND SOCIETY, FSB, AS COLLATERAL AGENT SECURITY INTEREST - SUPER SENIOR INDENTURE Assignors: ROCKLEY PHOTONICS LIMITED
Assigned to WILMINGTON SAVINGS FUND SOCIETY, FSB, AS COLLATERAL AGENT reassignment WILMINGTON SAVINGS FUND SOCIETY, FSB, AS COLLATERAL AGENT SECURITY INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: ROCKLEY PHOTONICS LIMITED
Assigned to ROCKLEY PHOTONICS LIMITED reassignment ROCKLEY PHOTONICS LIMITED RELEASE OF PATENT SECURITY INTEREST - SUPER SENIOR INDENTURE - REEL/FRAME 061768/0082 Assignors: WILMINGTON SAVINGS FUND SOCIETY, FSB, AS COLLATERAL AGENT
Assigned to ROCKLEY PHOTONICS LIMITED reassignment ROCKLEY PHOTONICS LIMITED RELEASE OF SECURITY INTEREST - REEL/FRAME 060204/0749 Assignors: WILMINGTON SAVINGS FUND SOCIETY, FSB, AS COLLATERAL AGENT
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/02Topology update or discovery
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/12Shortest path evaluation
    • H04L45/127Shortest path evaluation based on intermediate node capabilities
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/44Distributed routing
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/74Address processing for routing
    • H04L45/745Address table lookup; Address filtering
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/74Address processing for routing
    • H04L45/745Address table lookup; Address filtering
    • H04L45/748Address table lookup; Address filtering using longest matching prefix
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements, protocols or services for addressing or naming
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements, protocols or services for addressing or naming
    • H04L61/09Mapping addresses
    • H04L61/25Mapping addresses of the same type
    • H04L61/2503Translation of Internet protocol [IP] addresses
    • H04L61/251Translation of Internet protocol [IP] addresses between different IP versions
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22Parsing or analysis of headers
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2101/00Indexing scheme associated with group H04L61/00
    • H04L2101/60Types of network addresses
    • H04L2101/618Details of network addresses
    • H04L2101/659Internet protocol version 6 [IPv6] addresses

Definitions

  • Embodiments of the present invention are directed towards a routing protocol for routing packets in a network of network nodes, and a distributed router comprising a plurality of internal network nodes.
  • An IP/Ethernet network may include many network nodes (in the form of switches or routers) to interconnect network endpoints, e.g. server nodes.
  • network endpoints e.g. server nodes.
  • an IP lookup or Ethernet routing table lookup is required at each network node. These lookups require complex logic and data structure to parse the packet header and decide to which local output to send the packet based on the passed header fields. This is an inefficient process because it needs to be repeated at every hop, introducing penalties in latency, energy consumption, and resource requirements (e.g. logic and memory).
  • Some embodiments of the present invention aim to address this problem by considering a collection of network nodes as one large distributed router, rather than a collection of independent routers, and performing routing within that collection of network nodes based on addresses having local relevance only. These addresses can thus be chosen from an address space that is much smaller than the full IP or Ethernet address space, and may hence be amenable for efficient direct-index lookup. IP/Ethernet header parsing needs to occur only once, upon entry into the distributed router, as opposed to at each hop.
  • some embodiments of the present invention provide a routing protocol including the steps of: receiving a packet at an ingress internal node of a distributed router, the ingress node having an ingress node address, and the packet having a packet header containing a global destination address for that packet; converting the global destination address into a local destination address, the local destination address identifying a location on the distributed router; and routing the packet to the local destination address.
  • the term “global destination address” refers to an address identifying a location on a whole network, e.g. the entire IP or Ethernet network. This is contrast to “local destination address” which identifies a location on the distributed router.
  • the conversion from a global to a local address means that the routing step need only take place at a level which is local to the distributed router, rather than on a whole-network level.
  • the routing protocol of some embodiments of the present invention represents one step in the routing of a packet from a source network node to a destination node on a global network, the global network including a plurality of nodes.
  • the distributed router comprises a subset of these network nodes, referred to herein as “internal nodes”, or “internal network nodes” in order to clarify which nodes form part of the distributed router. Nodes which form part of the global network, but which are not part of the distributed router may be referred to herein as “external nodes”.
  • the distributed router could be considered to represent a single node in the global network, which itself is made up of many sub-nodes.
  • the term “global” refers to the whole network, whereas the term “local” refers to the distributed router only.
  • the router is “distributed” because the component which performs e.g. the routing lookup is not localized onto a single network node, but rather it is distributed across a plurality of network nodes.
  • the routing lookup at the level of a distributed router made up of a plurality of internal network nodes, the journey of a packet from an ingress port of the distributed router and an egress port of the distributed router, which may take the packet through a plurality of intermediate internal network nodes, is effectively a single hop. This is in contrast to the situation in which a complex routing lookup must be performed when the packet arrives at each successive network node.
  • the step of converting the global destination address into a local destination address is the most computationally demanding, and it is therefore in some embodiments this step is performed as little as possible.
  • the packet may make several intermediate hops, i.e. travel through several internal network nodes on its journey to the location on the distributed router designated by the local destination address.
  • a prime advantage of some embodiments of the invention is that the computationally demanding step of converting the global destination address to a local destination address need only be performed once, i.e. on entry into the distributed router. Thereafter, after each intermediate hop, the only input required is the already-determined local destination address.
  • routing protocol of some embodiments of the present invention may be performed by a routing engine.
  • routing engine may refer to computing logic, e.g. in the form of a computer program.
  • the routing engine may be a devoted component.
  • more than one, or all of the internal network nodes within the distributed router may have a routing engine localized thereon.
  • the routing protocol may be performed at the ingress node.
  • the local destination address which is derived from the global destination address may include two components: a destination node address, and destination port address.
  • the destination node address designates the internal network node of the distributed router to which the packet should be directed in order eventually to reach its global destination address.
  • the destination port address designates the egress port of the internal node designated by the destination node address from which the packet should exit the distributed router in order to reach its global destination address.
  • the routing protocol may include a step of deriving a destination node address and a destination port address from the local destination address.
  • the distributed router may include a local control CPU, having a local CPU address.
  • the distributed router may include a plurality of local control CPUs. For example, there may be one local control CPU per network node.
  • a local control CPU may be associated with a plurality of internal network nodes, e.g. a group of network nodes which are physically assembled on the same or physically proximate switch cards. It should be noted that the local control CPU is separate from the routing engine. Packets may be sent to the CPU if e.g. they are directed there, or if the routing engine is unable to identify how they should be processed.
  • the routing step includes determining whether the destination node address is the local control CPU address. If the destination node address is the local control CPU address, the routing step may further include a step of directing the packet to the local control CPU. Once the packet arrives at the local control CPU, additional processing may be performed on the packet. This further processing is outside the scope of this application.
  • the internal network node at which the packet arrives i.e. the internal network node on which the ingress port is located
  • the ingress node having an ingress node address.
  • the routing step may include determining whether the destination node address is the ingress node address, i.e. that the destination network node is the ingress node.
  • the local destination address may also include a destination port address.
  • the destination port address may be in the form of a logical address.
  • the destination port address may be in the form of an integer value, the value identifying a port on the destination network node.
  • the destination port address in addition to identifying a port on the destination network node, may also be able to include an integer value indicating that the packet should be forwarded to the local control CPU.
  • the destination port address may take more values than there are physical ports on the destination network node, because the port addresses are logical rather than physical addresses.
  • the method may further include examining the destination port address.
  • the method may further include the step of directing the packet to the local control CPU for further processing, as above.
  • the routing step may further comprise performing a first routing lookup.
  • the first routing lookup may be performed in a physical port table (PPT), using the destination port address as the input.
  • PPT physical port table
  • the output of the first routing lookup may identify a set of physical ports on the present network node, i.e. the node which is processing the packet at that time.
  • the identified set of ports may include all of those ports on the destination network node which may serve as egress ports from which the packet may be output in order to reach its local destination node, which ultimately leads to the global destination network node; these ports may be referred to as “eligible” ports.
  • the eligible ports are returned in the form of a bitmap, referred to herein as the eligible physical port bitmap.
  • the eligible physical port bitmap may include information about the current port status. However, in some embodiments, this status is not considered at this stage.
  • the EPPB is in the form of a vector, made up of the number of bits as there are ports on the destination network node. An eligible port may be denoted by a “1” and an ineligible port may be denoted with a “0”. If all of the ports are denoted “0”, this means that there are no ports available which can get the packet to its destination network node. In such cases, the method includes the step of dropping the packet.
  • the destination network node is the ingress node.
  • the packet may be routed to an intermediate internal node of the distributed router before it is able to be transmitted to the local destination address.
  • a prime advantage of some embodiments of the invention lies within the fact that when the packet reaches this intermediate internal node, there is no need to re-calculate the local destination address from the global destination address.
  • the routing protocol further includes a step of transmitting the packet to an intermediate internal node, and performing a second routing lookup, wherein: the input of the second routing lookup is the local destination address, and the output from the second routing lookup identifies a set of eligible ports, which are a set of physical ports on the intermediate internal node which are able to serve as egress ports from which the packet may be output in order to reach the local destination node.
  • the routing step may further include a step of mapping the destination node address to a smaller index.
  • the smaller index is an integer value.
  • the step of mapping the destination node address to a smaller index may include calculating an integer value, the calculation being based on the topology of either the global network or the distributed router. Example calculations which may be performed are given later on in this application. This index or integer is referred to as the fabric lookup routing table index, or FLRT index. After the destination node address has been mapped onto an FLRT index, i.e.
  • the routing step may further include a step of performing the second routing lookup in a fabric lookup routing table (FLRT), using the FLRT index as the input.
  • FLRT fabric lookup routing table
  • the output from the second routing lookup may be the same as the output from the first routing lookup, i.e. it may be in the form of an EPPB, or any of the other options set out in the previous paragraph, as in the case where the local destination address itself is used as the input to the second routing lookup.
  • first and second routing lookup are used as labels only, and should not be construed as meaning that both routing lookups necessarily take place, nor that one is more important than the other, or necessarily takes place before the other.
  • a set of eligible ports has been determined, by one means or another.
  • this may be in the form of an EPPB, though alternative expressions are envisaged.
  • the EPPB does not take into account the current status of the ports.
  • the routing step may further include a step of identifying, from the set of eligible physical ports, the subset of physical ports which are available for use. This subset is the set of ports which are e.g. operational, non-faulty etc. In other words, this is set of physical ports from which an egress port may be selected.
  • the set of physical ports which are available for use may be determined based on the status of the set of eligible ports.
  • the set of available ports may be determined based on a combination of the set of eligible ports, and a physical port status bitmap (PPSB).
  • the PPSB may be a vector having the same dimension as the EPPB, the PPSB representing the status of each physical port.
  • the component of the vector representing a given port is 1 for a properly-functioning port, and 0 for a non-functioning port.
  • the set of available ports may be represented in the form of a physical port bitmap (PPB). If all of the components of the PPB are equal to zero, none of the eligible ports are functioning properly, and accordingly the packet is dropped.
  • the PPB or equivalent feature represents the set of egress ports from which the packet may be output in order to approach its global destination address, and which are properly-functioning and available for use.
  • the routing step may further include a step of selecting a port from the set of egress ports.
  • the routing protocol may further include a step of outputting the packet from the selected egress port.
  • a packet which is being transferred from a source client device to a destination device may pass through a number of intermediate network nodes.
  • an important advantage of some embodiments of the present invention is that the computationally demanding initial lookup (i.e. to convert the global destination address to the local destination address) need only be performed once, when the packet arrives at the ingress node.
  • the routing protocol of some embodiments of the present invention does not only take place at the ingress node; when the packet has to travel through one or more intermediate nodes, the routing protocol may be performed at each intermediate node.
  • a second aspect of some embodiments of the present invention provides a routing protocol including the steps of: receiving a packet at an internal node of a distributed router, the internal node having an internal node address, and the packet having a packet header containing a local destination address, the local destination address identifying a location on the distributed router; and routing the packet to the local destination address.
  • a global destination address is converted to the local destination address at an ingress node of the distributed router.
  • the protocol according to the second aspect of some embodiments of the invention defines the steps that take place at an intermediate node, rather than an ingress node.
  • Embodiments of the second aspect of some embodiments of the invention may include the same optional features which have been presented above, with reference to the first aspect of some embodiments of the invention, where compatible. The skilled person is well-aware which optional features are compatible.
  • a third aspect of some embodiments of the invention sets out explicitly the operations taking place at both the ingress node and an intermediate node. Accordingly, it provides a routing protocol including the steps of:
  • the method may further include a step of determining whether the intermediate network node is the destination network node. If not, the intermediate network node may be referred to as a first intermediate network node, and the method may include a further step (f), of outputting the packet from one of the eligible ports to a second intermediate network node. Thereafter, the determining step and outputting step (i.e. to a third intermediate network node and so on) until it is determined that a given intermediate network node is the destination network node.
  • the process of determining whether a given intermediate network node is the destination network node, and if not, outputting the packet to a further intermediate network node repeats until the packet arrives at its ultimate destination network node, wherein in each case, the set of eligible ports is determined only from the local destination address and not the global destination address, in order to save computing time.
  • a fourth aspect of some embodiments of the present invention provides a distributed router including a plurality of internal network nodes, the plurality of internal network nodes including an ingress node configured to receive a packet, the packet having a packet header containing a global destination address for that packet, means for converting the global destination address into a local destination address, the local destination address identifying a location on the distributed router; and a routing engine configured to route the packet to the local destination address.
  • the means for converting the global destination address into a local destination address may be a longest prefix matching (LPM) component.
  • the global destination address may be converted into a local destination address using methods described in US 2017/0093717 A1, which is incorporated herein by reference.
  • the means for converting the global destination address into a local destination address may be located on the ingress node.
  • the internal network nodes may be implemented in the form of a chip such as an application specific integrated circuit (ASIC).
  • ASIC application specific integrated circuit
  • FIG. 1 shows a longest prefix matching process.
  • FIG. 2 shows a flowchart representing the routing protocol of an embodiment of the present invention.
  • FIG. 3 shows an example of a physical port table (PPT).
  • PPT physical port table
  • FIG. 4 shows an example of a fabric lookup routing table (FLRT).
  • An incoming packet generally has an IP/Ethernet packet header including information about the ultimate destination of the packet within the network.
  • a protocol header which includes a global port address is inserted into this packet.
  • the routing lookup is performed using longest prefix matching, a process by which an IPv4 of IPv6 destination address is received and a global port address is returned. More detail about longest prefix matching may be found in Lampson et al. (1999) 1 . This process is illustrated in FIG. 1 .
  • the routing engine i.e. the computing logic which is configured to perform the protocol of some embodiments of the present invention, takes as its input a destination local port address (“LPA”).
  • LPA local port address
  • this is a 24-bit address comprised of a local chip address (“LCA”) and a local logical port address (“LLPA”).
  • LPA local chip address
  • LLPA local logical port address
  • the output of the routing protocol is one of three options: either a packet is dropped (“DROP”), the packet is forwarded to the CPU (“FORWARD_TO_CPU”), or a physical port bitmap (“PPB”):
  • a destination LCA and LLPA are extracted from the LPA.
  • the LCA represents an address which is local to the distributed router.
  • the routing engine determines whether the LCA is a “well-known” LCA.
  • the “well-known LCA” is a mechanism for explicitly addressing a packet to the control CPU of a given network node.
  • the FORWARD_TO_CPU action is returned. In FIG. 1 , this may be done by encapsulating the packet with a generic routing encapsulation (“GRE”) header.
  • GRE generic routing encapsulation
  • a port which connects the network node to the control CPU is selected. This may be a gigabit Ethernet (“GBE”) port.
  • the routing engine determines whether the destination LCA matches the LCA of the routing engine itself. If it is, the routing engine then determines whether the LLPA is equal to a predetermined value not corresponding to any regular output port. In the present scheme, this is an LLPA which is used to express that the destination of the packet is the local control CPU, and accordingly, if so, the steps of encapsulating the packet with a GRE header, and selecting a control port, such as a GBE port take place as set out in the previous paragraph. If the LLPA does not indicate the local control CPU, then the LLPA is input into a physical port table (“PPT”) in order to determine an eligible physical port bitmap (“EPPB”).
  • PPT physical port table
  • the EPPB is a 12-bit vector resulting from the PPT (or FLRT index) which indicates the set of data ports that are eligible as next hop ports, without taking the current port status into account.
  • FIG. 3 An example of a PPT is shown in FIG. 3 , in which the input LLPA is interpreted as an integer index into the PPT.
  • Y is the value (comprising R bits) stored at table index x. Multiple bits may be set to 1 indicating that for routing purposes, these ports may be considered equivalent.
  • Y PPT(x). This may also be used for link bundles and aggregation groups.
  • the physical port bitmap (“PPB”) is determined.
  • the 12-bit PPB represents the set of physical 100 GbE ports from which the next hop may be selected.
  • the PPB is the result of a bitwise logical AND operation between the EPPB and a further bitmap, the physical port status bitmap (“PPSB”).
  • PPSB physical port status bitmap
  • This is a 12-bit vector which represents the physical status of each 100 GbE port. The status reflects whether or not the port is functioning properly, i.e. whether the link is up and is carrying traffic in both directions without errors.
  • the PPSB is updated in hardware: when the SERDES detects a loss of signal/lock, or the FEC error count exceeds a threshold, then the PPSB bit for this port is cleared to 0.
  • the destination LCA does not match the LCA of the routing engine, the destination LCA is mapped to a smaller integer called the fabric lookup routing table (“FLRT”).
  • FLRT is calculated differently for different topologies.
  • the global chip address may take the form: ( x L-1 , . . . ,x 1 ,x 0 )
  • m j is the downward branching factor at tier j. It should be noted that the tier index x L-1 does not appear in the computation because we only need to route to leaf switch modules.
  • the FLRT index may be calculated differently:
  • R i R for all values of i, then:
  • the FLRT index is mapped onto an EPPB using the fabric lookup routing table FLRT.
  • An example of an FLRT is shown in FIG. 4 , in which:
  • the PPB is determined using the PPSB as before.

Landscapes

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

Abstract

A routing protocol, the routing protocol includes the steps of: receiving a packet at an ingress node of a distributed router, the ingress node having an ingress node address, and the packet having a packet header containing a global destination address; converting the global destination address into a local destination address, the local destination address identifying a location on the distributed router; and routing the packet to the local destination address. A distributed router includes a plurality of internal network nodes, the plurality of internal network nodes including an ingress node configured to receive a packet, the ingress node having an ingress node address, and the packet having a packet header containing a global destination address for that packet; means for converting the global destination address into a local destination address, the local destination address identifying a location on the distributed router; and a routing engine configured to route the packet to the local destination address.

Description

CROSS-REFERENCE TO RELATED APPLICATION
The present application claims priority to and the benefit of United Kingdom Application No. GB1906921.0, filed May 16, 2019, the entire content of which is incorporated herein by reference.
FIELD
Embodiments of the present invention are directed towards a routing protocol for routing packets in a network of network nodes, and a distributed router comprising a plurality of internal network nodes.
BACKGROUND
An IP/Ethernet network may include many network nodes (in the form of switches or routers) to interconnect network endpoints, e.g. server nodes. In order to route a packet from a source node to a destination node, an IP lookup or Ethernet routing table lookup is required at each network node. These lookups require complex logic and data structure to parse the packet header and decide to which local output to send the packet based on the passed header fields. This is an inefficient process because it needs to be repeated at every hop, introducing penalties in latency, energy consumption, and resource requirements (e.g. logic and memory).
Some embodiments of the present invention aim to address this problem by considering a collection of network nodes as one large distributed router, rather than a collection of independent routers, and performing routing within that collection of network nodes based on addresses having local relevance only. These addresses can thus be chosen from an address space that is much smaller than the full IP or Ethernet address space, and may hence be amenable for efficient direct-index lookup. IP/Ethernet header parsing needs to occur only once, upon entry into the distributed router, as opposed to at each hop.
SUMMARY
Accordingly, some embodiments of the present invention provide a routing protocol including the steps of: receiving a packet at an ingress internal node of a distributed router, the ingress node having an ingress node address, and the packet having a packet header containing a global destination address for that packet; converting the global destination address into a local destination address, the local destination address identifying a location on the distributed router; and routing the packet to the local destination address. Here, the term “global destination address” refers to an address identifying a location on a whole network, e.g. the entire IP or Ethernet network. This is contrast to “local destination address” which identifies a location on the distributed router. The conversion from a global to a local address means that the routing step need only take place at a level which is local to the distributed router, rather than on a whole-network level.
The routing protocol of some embodiments of the present invention represents one step in the routing of a packet from a source network node to a destination node on a global network, the global network including a plurality of nodes. The distributed router comprises a subset of these network nodes, referred to herein as “internal nodes”, or “internal network nodes” in order to clarify which nodes form part of the distributed router. Nodes which form part of the global network, but which are not part of the distributed router may be referred to herein as “external nodes”.
Alternatively, the distributed router could be considered to represent a single node in the global network, which itself is made up of many sub-nodes. The term “global” refers to the whole network, whereas the term “local” refers to the distributed router only. The router is “distributed” because the component which performs e.g. the routing lookup is not localized onto a single network node, but rather it is distributed across a plurality of network nodes. By performing the routing lookup at the level of a distributed router made up of a plurality of internal network nodes, the journey of a packet from an ingress port of the distributed router and an egress port of the distributed router, which may take the packet through a plurality of intermediate internal network nodes, is effectively a single hop. This is in contrast to the situation in which a complex routing lookup must be performed when the packet arrives at each successive network node.
In some embodiments of the present invention, the step of converting the global destination address into a local destination address is the most computationally demanding, and it is therefore in some embodiments this step is performed as little as possible. Along the journey of a given packet through the distributed router, the packet may make several intermediate hops, i.e. travel through several internal network nodes on its journey to the location on the distributed router designated by the local destination address. A prime advantage of some embodiments of the invention is that the computationally demanding step of converting the global destination address to a local destination address need only be performed once, i.e. on entry into the distributed router. Thereafter, after each intermediate hop, the only input required is the already-determined local destination address.
The routing protocol of some embodiments of the present invention may be performed by a routing engine. Herein, “routing engine” may refer to computing logic, e.g. in the form of a computer program. In alternative embodiments, the routing engine may be a devoted component. In other embodiments, more than one, or all of the internal network nodes within the distributed router may have a routing engine localized thereon. The routing protocol may be performed at the ingress node.
The local destination address which is derived from the global destination address may include two components: a destination node address, and destination port address. The destination node address designates the internal network node of the distributed router to which the packet should be directed in order eventually to reach its global destination address. The destination port address designates the egress port of the internal node designated by the destination node address from which the packet should exit the distributed router in order to reach its global destination address. Accordingly, the routing protocol may include a step of deriving a destination node address and a destination port address from the local destination address.
The distributed router may include a local control CPU, having a local CPU address. In some embodiments, the distributed router may include a plurality of local control CPUs. For example, there may be one local control CPU per network node. In some cases, a local control CPU may be associated with a plurality of internal network nodes, e.g. a group of network nodes which are physically assembled on the same or physically proximate switch cards. It should be noted that the local control CPU is separate from the routing engine. Packets may be sent to the CPU if e.g. they are directed there, or if the routing engine is unable to identify how they should be processed. In some embodiments, the routing step includes determining whether the destination node address is the local control CPU address. If the destination node address is the local control CPU address, the routing step may further include a step of directing the packet to the local control CPU. Once the packet arrives at the local control CPU, additional processing may be performed on the packet. This further processing is outside the scope of this application.
Throughout this application, the internal network node at which the packet arrives, i.e. the internal network node on which the ingress port is located, may be referred to as the ingress node, having an ingress node address. In embodiments in which the routing protocol is performed at the ingress node, e.g. when the routing engine is located on the ingress node, and optionally in cases where it is determined that the destination node address is not the local control CPU address, the routing step may include determining whether the destination node address is the ingress node address, i.e. that the destination network node is the ingress node.
As discussed, the local destination address may also include a destination port address. The destination port address may be in the form of a logical address. The destination port address may be in the form of an integer value, the value identifying a port on the destination network node. In some embodiments, in addition to identifying a port on the destination network node, the destination port address may also be able to include an integer value indicating that the packet should be forwarded to the local control CPU. In general, it will be appreciated that the destination port address may take more values than there are physical ports on the destination network node, because the port addresses are logical rather than physical addresses.
When it is determined that the destination node address is the ingress node address, the method may further include examining the destination port address. When the destination port address is equal to the value indicating the local control CPU, the method may further include the step of directing the packet to the local control CPU for further processing, as above.
When it is determined that the destination node address is the ingress node address, and that the destination port address does not correspond to the local control CPU, the routing step may further comprise performing a first routing lookup. The first routing lookup may be performed in a physical port table (PPT), using the destination port address as the input. The output of the first routing lookup may identify a set of physical ports on the present network node, i.e. the node which is processing the packet at that time. The identified set of ports may include all of those ports on the destination network node which may serve as egress ports from which the packet may be output in order to reach its local destination node, which ultimately leads to the global destination network node; these ports may be referred to as “eligible” ports. In some embodiments of the present invention, the eligible ports are returned in the form of a bitmap, referred to herein as the eligible physical port bitmap. In some embodiments, the eligible physical port bitmap may include information about the current port status. However, in some embodiments, this status is not considered at this stage. In some embodiments, the EPPB is in the form of a vector, made up of the number of bits as there are ports on the destination network node. An eligible port may be denoted by a “1” and an ineligible port may be denoted with a “0”. If all of the ports are denoted “0”, this means that there are no ports available which can get the packet to its destination network node. In such cases, the method includes the step of dropping the packet.
The above paragraphs concern the case where the destination network node is the ingress node. Alternatively, it may be determined that the destination network node is not the same as the ingress node. This means, effectively, that the packet may be routed to an intermediate internal node of the distributed router before it is able to be transmitted to the local destination address. As discussed earlier in this application, a prime advantage of some embodiments of the invention lies within the fact that when the packet reaches this intermediate internal node, there is no need to re-calculate the local destination address from the global destination address. So, when it is determined that the destination node is not the same as the ingress node, the routing protocol further includes a step of transmitting the packet to an intermediate internal node, and performing a second routing lookup, wherein: the input of the second routing lookup is the local destination address, and the output from the second routing lookup identifies a set of eligible ports, which are a set of physical ports on the intermediate internal node which are able to serve as egress ports from which the packet may be output in order to reach the local destination node.
In some embodiments in which it is determined that the destination network node is not the same as the ingress node, in order to simplify the second routing lookup, the routing step may further include a step of mapping the destination node address to a smaller index. In some embodiments, the smaller index is an integer value. The step of mapping the destination node address to a smaller index may include calculating an integer value, the calculation being based on the topology of either the global network or the distributed router. Example calculations which may be performed are given later on in this application. This index or integer is referred to as the fabric lookup routing table index, or FLRT index. After the destination node address has been mapped onto an FLRT index, i.e. after a step of calculating an FLRT index based on the destination node address, the routing step may further include a step of performing the second routing lookup in a fabric lookup routing table (FLRT), using the FLRT index as the input. The output from the second routing lookup may be the same as the output from the first routing lookup, i.e. it may be in the form of an EPPB, or any of the other options set out in the previous paragraph, as in the case where the local destination address itself is used as the input to the second routing lookup.
It should be noted that the terms “first” and “second” routing lookup are used as labels only, and should not be construed as meaning that both routing lookups necessarily take place, nor that one is more important than the other, or necessarily takes place before the other.
At this stage in the method, whether or not it is determined that the destination network node is the same as the ingress node, a set of eligible ports has been determined, by one means or another. In some embodiments, this may be in the form of an EPPB, though alternative expressions are envisaged. As discussed, in some embodiments, the EPPB does not take into account the current status of the ports. In those embodiments, the routing step may further include a step of identifying, from the set of eligible physical ports, the subset of physical ports which are available for use. This subset is the set of ports which are e.g. operational, non-faulty etc. In other words, this is set of physical ports from which an egress port may be selected. The set of physical ports which are available for use may be determined based on the status of the set of eligible ports. In some embodiments, the set of available ports may be determined based on a combination of the set of eligible ports, and a physical port status bitmap (PPSB). The PPSB may be a vector having the same dimension as the EPPB, the PPSB representing the status of each physical port. In some embodiments, the component of the vector representing a given port is 1 for a properly-functioning port, and 0 for a non-functioning port. The set of available ports may be represented in the form of a physical port bitmap (PPB). If all of the components of the PPB are equal to zero, none of the eligible ports are functioning properly, and accordingly the packet is dropped.
Otherwise, the PPB or equivalent feature represents the set of egress ports from which the packet may be output in order to approach its global destination address, and which are properly-functioning and available for use. The routing step may further include a step of selecting a port from the set of egress ports. The routing protocol may further include a step of outputting the packet from the selected egress port.
A packet which is being transferred from a source client device to a destination device may pass through a number of intermediate network nodes. As discussed, an important advantage of some embodiments of the present invention is that the computationally demanding initial lookup (i.e. to convert the global destination address to the local destination address) need only be performed once, when the packet arrives at the ingress node. However, the routing protocol of some embodiments of the present invention does not only take place at the ingress node; when the packet has to travel through one or more intermediate nodes, the routing protocol may be performed at each intermediate node.
Accordingly, a second aspect of some embodiments of the present invention provides a routing protocol including the steps of: receiving a packet at an internal node of a distributed router, the internal node having an internal node address, and the packet having a packet header containing a local destination address, the local destination address identifying a location on the distributed router; and routing the packet to the local destination address. In some embodiments, in line with the first aspect of some embodiments of the invention, a global destination address is converted to the local destination address at an ingress node of the distributed router. Effectively, the protocol according to the second aspect of some embodiments of the invention defines the steps that take place at an intermediate node, rather than an ingress node. Embodiments of the second aspect of some embodiments of the invention may include the same optional features which have been presented above, with reference to the first aspect of some embodiments of the invention, where compatible. The skilled person is well-aware which optional features are compatible.
A third aspect of some embodiments of the invention sets out explicitly the operations taking place at both the ingress node and an intermediate node. Accordingly, it provides a routing protocol including the steps of:
    • (a) receiving a packet at an ingress internal node of a distributed router, the ingress node having an ingress node address, and the packet having a packet header containing a global destination address;
    • (b) converting the global destination address to a local destination address, the local destination address identifying a location on the distributed router, the local destination address including a destination node address corresponding to a destination network node on the distributed router;
    • (c) determining a first set of eligible ports on the ingress node which are able to serve as egress ports from which the packet may be output in order to reach the destination network node;
    • (d) outputting the packet from one of the eligible ports to an intermediate network node of the distributed router;
    • (e) receiving the packet at the intermediate network node; and determining, based on the local destination address, a second set of eligible ports on the intermediate network node which are able to serve as egress ports from which the packet may be output in order to reach the destination network node.
In some embodiments, between steps (d) and (e), the method may further include a step of determining whether the intermediate network node is the destination network node. If not, the intermediate network node may be referred to as a first intermediate network node, and the method may include a further step (f), of outputting the packet from one of the eligible ports to a second intermediate network node. Thereafter, the determining step and outputting step (i.e. to a third intermediate network node and so on) until it is determined that a given intermediate network node is the destination network node. In other words, the process of determining whether a given intermediate network node is the destination network node, and if not, outputting the packet to a further intermediate network node, repeats until the packet arrives at its ultimate destination network node, wherein in each case, the set of eligible ports is determined only from the local destination address and not the global destination address, in order to save computing time.
A fourth aspect of some embodiments of the present invention provides a distributed router including a plurality of internal network nodes, the plurality of internal network nodes including an ingress node configured to receive a packet, the packet having a packet header containing a global destination address for that packet, means for converting the global destination address into a local destination address, the local destination address identifying a location on the distributed router; and a routing engine configured to route the packet to the local destination address. In an IP network, the means for converting the global destination address into a local destination address may be a longest prefix matching (LPM) component. In other embodiments, the global destination address may be converted into a local destination address using methods described in US 2017/0093717 A1, which is incorporated herein by reference. The means for converting the global destination address into a local destination address may be located on the ingress node.
In some embodiments of some embodiments of the present invention, the internal network nodes may be implemented in the form of a chip such as an application specific integrated circuit (ASIC).
The optional features set out above with reference to the first aspect of some embodiments of the invention apply equally well to the third aspect of the invention.
Further optional features of some embodiments of the invention are set out below.
BRIEF DESCRIPTION OF THE DRAWINGS
The present invention will now be described with reference to the accompanying drawings, in which:
FIG. 1 shows a longest prefix matching process.
FIG. 2 shows a flowchart representing the routing protocol of an embodiment of the present invention.
FIG. 3 shows an example of a physical port table (PPT).
FIG. 4 shows an example of a fabric lookup routing table (FLRT).
DETAILED DESCRIPTION OF THE DRAWINGS
Before the routing protocol of some embodiments of the present invention takes place, it is necessary to identify a network node on the distributed router to which a packet may be directed in order to continue its path to its ultimate destination on the IP/Ethernet network. An incoming packet generally has an IP/Ethernet packet header including information about the ultimate destination of the packet within the network. Before the routing protocol takes place, a protocol header which includes a global port address is inserted into this packet. In specific embodiments the routing lookup is performed using longest prefix matching, a process by which an IPv4 of IPv6 destination address is received and a global port address is returned. More detail about longest prefix matching may be found in Lampson et al. (1999)1. This process is illustrated in FIG. 1. An alternative means by which a LPA may be obtained is set out in US 2017/0093717 A1, which is incorporated herein by reference. In this document, the source routing approach is based on a stack of multiprotocol label switching (MPLS) headers. The LPA may be encoded directly in the label or by indexing a different table mapping MPLS labels to LPAs.
The routing protocol of some embodiments of the present invention is shown in FIG. 2, and will now be described in depth. In broad terms, the routing engine, i.e. the computing logic which is configured to perform the protocol of some embodiments of the present invention, takes as its input a destination local port address (“LPA”). In some embodiments, this is a 24-bit address comprised of a local chip address (“LCA”) and a local logical port address (“LLPA”). From this, the output of the routing protocol is one of three options: either a packet is dropped (“DROP”), the packet is forwarded to the CPU (“FORWARD_TO_CPU”), or a physical port bitmap (“PPB”):
    • DROP: This means that for some reason the packet cannot be directed to its destination address, e.g. because the port in question is inactive.
    • FORWARD_TO_CPU: This may mean that the packet is actually destined for the local control CPU, or that the routing engine is unable to determine how exactly the packet should be process, and therefore delegates responsibility.
    • PPB: This is the most common case. It means that the routing engine has successfully formed a routing lookup, which results in a set of eligible ports of the network node to which the packet may be routed.
In a first step, a destination LCA and LLPA are extracted from the LPA. The LCA represents an address which is local to the distributed router.
In a first step, the routing engine determines whether the LCA is a “well-known” LCA. In the present scheme, the “well-known LCA” is a mechanism for explicitly addressing a packet to the control CPU of a given network node. In the event that it is determined that the LCA is a well-known LCA, then the FORWARD_TO_CPU action is returned. In FIG. 1, this may be done by encapsulating the packet with a generic routing encapsulation (“GRE”) header. Then, a port which connects the network node to the control CPU is selected. This may be a gigabit Ethernet (“GBE”) port.
1 Butler Lampson, Venkatachary Srinivasan, and George Varghese, “IP lookups using multiway and multicolumn search,” IEEE/ACM Transactions on Networking (1999): 324-334, http://cseweb.ucsd.edu/˜varghese/PAPERS/ToN99.pdf
In a next step, the routing engine determines whether the destination LCA matches the LCA of the routing engine itself. If it is, the routing engine then determines whether the LLPA is equal to a predetermined value not corresponding to any regular output port. In the present scheme, this is an LLPA which is used to express that the destination of the packet is the local control CPU, and accordingly, if so, the steps of encapsulating the packet with a GRE header, and selecting a control port, such as a GBE port take place as set out in the previous paragraph. If the LLPA does not indicate the local control CPU, then the LLPA is input into a physical port table (“PPT”) in order to determine an eligible physical port bitmap (“EPPB”). In the present embodiment, the EPPB is a 12-bit vector resulting from the PPT (or FLRT index) which indicates the set of data ports that are eligible as next hop ports, without taking the current port status into account. The port is eligible if and only if EPPB(i)=1. If the EPPB is equal to zero, DROP is returned because it means that the destination network node is in a different network partition.
An example of a PPT is shown in FIG. 3, in which the input LLPA is interpreted as an integer index into the PPT. Y is the value (comprising R bits) stored at table index x. Multiple bits may be set to 1 indicating that for routing purposes, these ports may be considered equivalent. In FIG. 3, the following is true:
0≤x<R
Y=
Figure US11190447-20211130-P00001
Y R-1 , . . . ,Y 1 ,Y 0
Figure US11190447-20211130-P00002
    • Yi=1, if LLPA x is an alias for a physical port i.
In the example shown in FIG. 2, the required memory is 16 entries of R=12 bits, i.e. 192 bits in total. Mathematically, it may be written that Y=PPT(x). This may also be used for link bundles and aggregation groups. Once the EPPB has been determined using the PPT, its value is determined by the routing engine. If the EPPB is equal to zero, this means that no port is eligible, i.e. there is no known path to the destination LCA. When this is the case, the packet is dropped.
When the EPPB is not equal to zero, the physical port bitmap (“PPB”) is determined. In the present embodiment, the 12-bit PPB represents the set of physical 100 GbE ports from which the next hop may be selected. The PPB is the result of a bitwise logical AND operation between the EPPB and a further bitmap, the physical port status bitmap (“PPSB”). This is a 12-bit vector which represents the physical status of each 100 GbE port. The status reflects whether or not the port is functioning properly, i.e. whether the link is up and is carrying traffic in both directions without errors. A physical port is functioning if PPSB[i]=1. The PPSB is updated in hardware: when the SERDES detects a loss of signal/lock, or the FEC error count exceeds a threshold, then the PPSB bit for this port is cleared to 0.
If the destination LCA does not match the LCA of the routing engine, the destination LCA is mapped to a smaller integer called the fabric lookup routing table (“FLRT”). The FLRT is calculated differently for different topologies. For the well-known folded Clos topology, the global chip address may take the form:
(x L-1 , . . . ,x 1 ,x 0)
And the FLRT index:
I ( x ) = i L - 2 ( x i · W i )
Where:
W i = j = 0 i - 2 m j + 2
In which mj is the downward branching factor at tier j. It should be noted that the tier index xL-1 does not appear in the computation because we only need to route to leaf switch modules.
In the RPFabric topology, exemplified in US 2017/0041691 A1, US 2017/0245028 A1, and US 2017/0117966 A1, the FLRT index may be calculated differently:
I ( x ) = i = 0 L - 1 ( x i · W i )
Wi is calculated slightly differently:
W i = i = 0 L - 1 ( x i · R i )
In which Ri is the number of chips in dimension i. If Ri=R for all values of i, then:
I ( x ) = i = 0 L - 1 ( x i · R i )
Once the FLRT index has been determined, it is mapped onto an EPPB using the fabric lookup routing table FLRT. An example of an FLRT is shown in FIG. 4, in which:
    • 0≤x<N−1, where N represents the total number of FLRT entries (i.e. the size of the table in number of rows).
      Y=
      Figure US11190447-20211130-P00001
      Y R-1 , . . . ,Y 1 ,Y 0
      Figure US11190447-20211130-P00002
    • Yi=1, if physical port i is eligible for routing towards LCA x.
Once an EPPB is determined using an FLRT index and the FLRT, the PPB is determined using the PPSB as before.

Claims (22)

The invention claimed is:
1. A routing protocol, the routing protocol including the steps of:
receiving a packet at an ingress internal node of a distributed router, the ingress internal node having an ingress node address, and the packet having a packet header containing a global destination address;
converting the global destination address into a local destination address, the local destination address identifying a location on the distributed router; and
routing the packet to the local destination address,
wherein:
the local destination address includes a destination node address corresponding to a destination network node located on the distributed router, and a destination port address corresponding to a port located on the destination network node;
the distributed router includes a local control CPU having a local control CPU address;
the routing step includes determining whether the destination node address is the local control CPU address; and
when it is determined that the destination node address is the local control CPU address, the routing step includes a step of directing the packet to the local control CPU.
2. The routing protocol according to claim 1, wherein:
longest prefix matching is used to convert the global destination address to the local destination address.
3. The routing protocol according to claim 1, wherein:
the routing step includes determining whether the destination node address is the ingress node address.
4. The routing protocol according to claim 3, wherein:
when it is determined that the destination node address is the ingress node address, and that the destination node address is not the local control CPU address, the routing step includes performing a first routing lookup, wherein:
an input of the first routing lookup includes the destination port address; and
an output of the first routing lookup identifies a set of eligible ports, which are a set of physical ports on the ingress internal node which are able to serve as egress ports from which the packet may be output in order to reach a local destination node.
5. The routing protocol according to claim 4, wherein:
the eligible ports are returned in the form of an eligible port bitmap.
6. The routing protocol according to claim 5, wherein:
the routing step further includes a step of identifying, from the set of eligible ports, a subset of eligible physical ports which are available for use, based on a status of the set of eligible ports.
7. The routing protocol according to claim 3, wherein:
when it is determined that the destination node address is not the ingress node address, the routing step includes determining a set of eligible ports on the ingress internal node which are able to serve as egress ports from which the packet may be output in order to reach the destination network node.
8. The routing protocol according to claim 3, wherein:
when it is determined that the destination node address is not the same as the ingress internal node address, the routing step further includes a step of transmitting the packet to an intermediate internal node, and performing a second routing lookup, wherein:
an input of the second routing lookup is the local destination address, and
an output from the second routing lookup identifies a set of eligible ports, which are a set of physical ports on the intermediate internal node which are able to serve as egress ports from which the packet may be output in order to reach a local destination node.
9. The routing protocol according to claim 3, wherein:
when it is determined that the destination node address is not the ingress node address, the routing step includes mapping the destination node address to a smaller index;
the routing step further includes performing a second routing lookup in a fabric lookup routing table, wherein:
an input of the second routing lookup is the smaller index; and
an output from the second routing lookup identifies a set of eligible ports, which are a set of physical ports on the ingress internal node which are able to serve as egress ports from which the packet may be output in order to reach a local destination node.
10. The routing protocol according to claim 1, further including the steps of:
determining a first set of eligible ports on the ingress internal node which are able to serve as egress ports from which the packet may be output in order to reach the destination network node;
outputting the packet from one of the eligible ports from the first set of eligible ports to an intermediate network node of the distributed router;
receiving the packet at the intermediate network node; and
determining, based on the local destination address, a second set of eligible ports on the intermediate network node which are able to serve as egress ports from which the packet may be output in order to reach the destination network node.
11. The routing protocol according to claim 10, wherein:
the routing protocol further includes a step of determining whether the intermediate network node is the destination network node.
12. The routing protocol according to claim 11, wherein:
if the intermediate network node is not the destination network node, the intermediate network node is a first intermediate network node, and the routing protocol further includes a step of outputting the packet from one of the second set of eligible ports on the first intermediate network node to a second intermediate network node.
13. A distributed router including:
a plurality of internal network nodes, the plurality of internal network nodes including an ingress node configured to receive a packet, the ingress node having an ingress node address, and the packet having a packet header containing a global destination address for that packet;
means for converting the global destination address into a local destination address, the local destination address identifying a location on the distributed router; and
a routing engine configured to route the packet to the local destination address,
wherein:
the local destination address includes a destination node address corresponding to a destination network node located on the distributed router, and a destination port address corresponding to a port located on the destination network node;
the distributed router includes a local control CPU, having a local control CPU address;
the routing engine is configured to determine whether the destination node address is the local control CPU address; and
when it is determined that the destination node address is the local control CPU address, the routing engine is configured to direct the packet to the local control CPU.
14. The distributed router according to claim 13, wherein:
the means for converting the global destination address into the local destination address is configured to use longest prefix matching to do so.
15. The distributed router according to claim 13, wherein:
when it is determined that the destination node address is the ingress node address, and that the destination node address is not the local control CPU address, the routing engine is configured to perform a first routing lookup, wherein:
an input of the first routing lookup includes the destination port address, and
an output of the first routing lookup identifies a set of eligible ports, which are a set of physical ports on the ingress node which are able to serve as egress ports from which the packet may be output in order to reach a local destination node.
16. A distributed router including:
a plurality of internal network nodes, the plurality of internal network nodes including an ingress node configured to receive a packet, the ingress node having an ingress node address, and the packet having a packet header containing a global destination address for that packet;
means for converting the global destination address into a local destination address, the local destination address identifying a location on the distributed router; and
a routing engine configured to route the packet to the local destination address,
wherein:
the local destination address includes a destination node address corresponding to a destination network node located on the distributed router, and a destination port address corresponding to a port located on the destination network node; and
the routing engine is configured to determine whether the destination node address is the ingress node address.
17. The distributed router according to claim 16, wherein:
when it is determined that the destination node address is not in the ingress node address, the routing engine is configured to determine a set of eligible ports on the ingress node which are able to serve as egress ports from which the packet may be output in order to reach the destination network node.
18. The distributed router according to claim 16, wherein:
when it is determined that the destination node address is not the same as the ingress node address, the routing engine is configured to transmit the packet to an intermediate internal node, and to perform a second routing lookup, wherein:
an input of the second routing lookup is the local destination address, and
an output from the second routing lookup identifies a set of eligible ports, which are a set of physical ports on the intermediate internal node which are able to serve as egress ports from which the packet may be output in order to reach a local destination node.
19. The distributed router according to claim 16, wherein:
when it is determined that the destination node address is not the ingress node address, the routing engine is configured to map the destination node address to a smaller index; and
the routing engine is further configured to perform a second routing lookup in a fabric lookup routing table, wherein:
an input of the second routing lookup is the smaller index, and
an output from the second routing lookup identifies a set of eligible ports, which are a set of physical ports on the ingress node which are able to serve as egress ports from which the packet may be output in order to reach a local destination node.
20. The distributed router according to claim 19, wherein:
the eligible ports are returned in the form of an eligible physical port bitmap.
21. The distributed router according to claim 20, wherein:
the routing engine is further configured to identify, from the set of eligible ports, a subset of eligible physical ports which are available for use, based on a status of the set of eligible ports.
22. The distributed router according to claim 16, wherein:
the means for converting the global destination address into the local destination address is configured to use longest prefix matching to do so.
US16/875,886 2019-05-16 2020-05-15 Routing protocol and distributed router Active US11190447B2 (en)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
GB1906921.0 2019-05-16
GB1906921 2019-05-16
GB1906921.0A GB2583962B (en) 2019-05-16 2019-05-16 Routing protocol and distributed router

Publications (2)

Publication Number Publication Date
US20210006495A1 US20210006495A1 (en) 2021-01-07
US11190447B2 true US11190447B2 (en) 2021-11-30

Family

ID=67385094

Family Applications (1)

Application Number Title Priority Date Filing Date
US16/875,886 Active US11190447B2 (en) 2019-05-16 2020-05-15 Routing protocol and distributed router

Country Status (2)

Country Link
US (1) US11190447B2 (en)
GB (1) GB2583962B (en)

Citations (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020118682A1 (en) * 2000-12-22 2002-08-29 Myongsu Choe Apparatus and method for performing high-speed IP route lookup and managing routing/forwarding tables
US6868086B1 (en) 2000-03-29 2005-03-15 Intel Corporation Data packet routing
EP1569388A1 (en) 2004-02-24 2005-08-31 Valtion Teknillinen Tutkimuskeskus Distributed dynamic routing
US20090303882A1 (en) 2004-02-18 2009-12-10 Woven Systems, Inc. Mechanism for implementing load balancing in a network
US20110134924A1 (en) 2008-07-25 2011-06-09 Gnodal Limited Multi-path network
US20110149963A1 (en) 2009-12-17 2011-06-23 Hamilton James R Distributed routing architecture
US20110170553A1 (en) 2008-05-01 2011-07-14 Jon Beecroft Method of data delivery across a network fabric in a router or ethernet bridge
US20110243134A1 (en) 2010-03-31 2011-10-06 International Business Machines Corporation Data Frame Forwarding Using a Distributed Virtual Bridge
US20110243146A1 (en) 2010-03-31 2011-10-06 International Business Machines Corporation Data Frame Forwarding Using a Multitiered Distributed Virtual Bridge Hierarchy
US20150131664A1 (en) * 2013-11-14 2015-05-14 Verizon Patent And Licensing Inc. Distributing and virtualizing a network address translation (nat)
US20170041691A1 (en) 2015-11-05 2017-02-09 Rockley Photonics Limited Optoelectronic switch
US20170093717A1 (en) 2015-09-29 2017-03-30 Rockley Photonics Limited System and method for routing
US20170117966A1 (en) 2015-04-24 2017-04-27 Rockley Photonics Limited Optoelectronic switch
US20170245028A1 (en) 2015-04-24 2017-08-24 Rockley Photonics Limited Optoelectronic switch architectures

Patent Citations (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6868086B1 (en) 2000-03-29 2005-03-15 Intel Corporation Data packet routing
US20020118682A1 (en) * 2000-12-22 2002-08-29 Myongsu Choe Apparatus and method for performing high-speed IP route lookup and managing routing/forwarding tables
US20090303882A1 (en) 2004-02-18 2009-12-10 Woven Systems, Inc. Mechanism for implementing load balancing in a network
EP1569388A1 (en) 2004-02-24 2005-08-31 Valtion Teknillinen Tutkimuskeskus Distributed dynamic routing
US20110170553A1 (en) 2008-05-01 2011-07-14 Jon Beecroft Method of data delivery across a network fabric in a router or ethernet bridge
US20110134924A1 (en) 2008-07-25 2011-06-09 Gnodal Limited Multi-path network
US20110149963A1 (en) 2009-12-17 2011-06-23 Hamilton James R Distributed routing architecture
US20110243134A1 (en) 2010-03-31 2011-10-06 International Business Machines Corporation Data Frame Forwarding Using a Distributed Virtual Bridge
US20110243146A1 (en) 2010-03-31 2011-10-06 International Business Machines Corporation Data Frame Forwarding Using a Multitiered Distributed Virtual Bridge Hierarchy
US20150131664A1 (en) * 2013-11-14 2015-05-14 Verizon Patent And Licensing Inc. Distributing and virtualizing a network address translation (nat)
US20170117966A1 (en) 2015-04-24 2017-04-27 Rockley Photonics Limited Optoelectronic switch
US20170245028A1 (en) 2015-04-24 2017-08-24 Rockley Photonics Limited Optoelectronic switch architectures
US20170093717A1 (en) 2015-09-29 2017-03-30 Rockley Photonics Limited System and method for routing
US20170041691A1 (en) 2015-11-05 2017-02-09 Rockley Photonics Limited Optoelectronic switch

Non-Patent Citations (11)

* Cited by examiner, † Cited by third party
Title
Abts, D., "The Cray XT4 and Seastar 3-D Torus Interconnect", Apr. 6, 2010, 10 pages, ResearchGate.
Alverson, B. et al., "Cray® XC™ Series Network", 2012, pp. 1-28, Cray Inc.
Alverson, R. et al., "The Gemini System Interconnect", 18th IEEE Symposium on High Performance Interconnects, IEEE Computer Society, 2010, pp. 83-87, IEEE.
Arimilli, B. et al., "The PERCS High-Performance Interconnect", 18th IEEE Symposium on High Performance Interconnects, IEEE Computer Society, 2010, pp. 75-82, IEEE.
Chen, D. et al., "The IBM Blue Gene/Q Interconnection Network and Message Unit", 2011, pp. 1-10, ACM.
Lampson, Butler et al., "IP Lookups Using Multiway and Multicolumn Search", IEEE/ACM Transactions on Networking, Jun. 1999, pp. 324-334, vol. 7, No. 3, IEEE.
Minkenberg, C. et al, "Reimagining Datacenter Topologies With Integrated Silicon Photonics", J. Opt. Commun. Netw., Jul. 2018, pp. B126-B139, vol. 10, No. 7, Optical Society of America.
Morgan, T. P., "New Dune Chips Enable Heftier Switches", The Next Platform, Mar. 19, 2015, 10 pages, retrieved at URL: https://www.nextplatform.com/2015/03/19/new-dune-chips-enable-heftier-switches/ on Jan. 14, 2021.
StrataDNX™ Switch Solutions, Broadcom, 1 page, retrieved at URL: https://www.broadcom.com/products/ethernet-connectivity/switching/stratadnx on Nov. 5, 2020.
U.K. Intellectual Property Office Examination Report, dated Sep. 29, 2021, for Patent Application No. GB1906921.0, 4 pages.
U.K. Intellectual Property Office Search and Examination Report, dated Oct. 28, 2019, for patent application No. GB1906921.0, 8 pages.

Also Published As

Publication number Publication date
GB2583962B (en) 2022-08-31
GB201906921D0 (en) 2019-07-03
GB2583962A (en) 2020-11-18
US20210006495A1 (en) 2021-01-07

Similar Documents

Publication Publication Date Title
US6957272B2 (en) Stackable lookup engines
EP3738277B1 (en) Segment routing network processing of packets
US10225187B2 (en) System and method for providing a bit indexed service chain
US8792506B2 (en) Inter-domain routing in an n-ary-tree and source-routing based communication framework
US6650642B1 (en) Network relaying apparatus and network relaying method capable of high-speed routing and packet transfer
KR100624681B1 (en) Apparatus and method for combining forwarding tables in a distributed architecture router
EP3399700B1 (en) Method, apparatus and device for detecting forwarding table
WO2016107122A1 (en) Method and device for converting between rapidio packet and ethernet packet
US10212069B2 (en) Forwarding of multicast packets in a network
US20090135833A1 (en) Ingress node and egress node with improved packet transfer rate on multi-protocol label switching (MPLS) network, and method of improving packet transfer rate in MPLS network system
US20140185618A1 (en) Path splitting with a connection-oriented network
US7742471B2 (en) Methods and systems for routing packets with a hardware forwarding engine and a software forwarding engine
US9143448B1 (en) Methods for reassembling fragmented data units
US8929366B2 (en) Method and apparatus for transporting packets with specific traffic flows having strict packet ordering requirements over a network using multipath techniques
US7697532B2 (en) Frame concatenation with drop precedence assignment
US11190447B2 (en) Routing protocol and distributed router
US20120106555A1 (en) Low latency carrier class switch-router
CN114978986B (en) Data transmission method, device and storage medium
US11689464B2 (en) Optimizing entries in a content addressable memory of a network device
US9350648B2 (en) System and method for loop suppression in transit networks
TW200425685A (en) Packet forwarding method and system
US10432526B2 (en) Enhanced traffic distribution using VRF tables
WO2023088226A1 (en) Packet forwarding method and related device
CN110166357B (en) Device supporting transparent interconnection protocol of multiple links and communication method thereof
WO2024093778A1 (en) Packet processing method and related apparatus

Legal Events

Date Code Title Description
FEPP Fee payment procedure

Free format text: ENTITY STATUS SET TO UNDISCOUNTED (ORIGINAL EVENT CODE: BIG.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

STPP Information on status: patent application and granting procedure in general

Free format text: DOCKETED NEW CASE - READY FOR EXAMINATION

STPP Information on status: patent application and granting procedure in general

Free format text: NON FINAL ACTION MAILED

STPP Information on status: patent application and granting procedure in general

Free format text: RESPONSE TO NON-FINAL OFFICE ACTION ENTERED AND FORWARDED TO EXAMINER

STPP Information on status: patent application and granting procedure in general

Free format text: NOTICE OF ALLOWANCE MAILED -- APPLICATION RECEIVED IN OFFICE OF PUBLICATIONS

AS Assignment

Owner name: ROCKLEY PHOTONICS LIMITED, GREAT BRITAIN

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:YEH, CHIANG;FARRINGTON, NATHAN;MINKENBERG, CYRIEL JOHAN AGNES;SIGNING DATES FROM 20200813 TO 20211002;REEL/FRAME:057848/0215

STPP Information on status: patent application and granting procedure in general

Free format text: AWAITING TC RESP, ISSUE FEE PAYMENT VERIFIED

STPP Information on status: patent application and granting procedure in general

Free format text: PUBLICATIONS -- ISSUE FEE PAYMENT VERIFIED

STCF Information on status: patent grant

Free format text: PATENTED CASE

AS Assignment

Owner name: WILMINGTON SAVINGS FUND SOCIETY, FSB, AS COLLATERAL AGENT, DELAWARE

Free format text: SECURITY INTEREST;ASSIGNOR:ROCKLEY PHOTONICS LIMITED;REEL/FRAME:060204/0749

Effective date: 20220527

AS Assignment

Owner name: WILMINGTON SAVINGS FUND SOCIETY, FSB, AS COLLATERAL AGENT, DELAWARE

Free format text: SECURITY INTEREST - SUPER SENIOR INDENTURE;ASSIGNOR:ROCKLEY PHOTONICS LIMITED;REEL/FRAME:061768/0082

Effective date: 20221025

AS Assignment

Owner name: ROCKLEY PHOTONICS LIMITED, UNITED KINGDOM

Free format text: RELEASE OF PATENT SECURITY INTEREST - SUPER SENIOR INDENTURE - REEL/FRAME 061768/0082;ASSIGNOR:WILMINGTON SAVINGS FUND SOCIETY, FSB, AS COLLATERAL AGENT;REEL/FRAME:063264/0416

Effective date: 20230314

Owner name: ROCKLEY PHOTONICS LIMITED, UNITED KINGDOM

Free format text: RELEASE OF SECURITY INTEREST - REEL/FRAME 060204/0749;ASSIGNOR:WILMINGTON SAVINGS FUND SOCIETY, FSB, AS COLLATERAL AGENT;REEL/FRAME:063264/0333

Effective date: 20230314

Owner name: WILMINGTON SAVINGS FUND SOCIETY, FSB, AS COLLATERAL AGENT, DELAWARE

Free format text: SECURITY INTEREST;ASSIGNOR:ROCKLEY PHOTONICS LIMITED;REEL/FRAME:063287/0879

Effective date: 20230314