Use of UDP port numbers for service delimiting, such as for delimiting virtual routing and forwarding instances in layer 3 tunnels

Abstract

Embodiments of the present disclosure relate to using UDP port numbers for service delimiting, such as for delimiting virtual routing and forwarding instances in Layer 3 tunnels. When an IP-in-IP (also referred to as a UDP-based IP) is used as a tunneling mechanism (e.g., in a data center), different connection services (e.g., customers, VRFs) are identified using, for example, different UDP port numbers, without the need for a Multi-Protocol Label Switching (MPLS) tag or a Virtual Extensible Local Area Network (VXLAN) Network Identifier (VNI). Different services in a virtual routing and forwarding instance (VRF) are identified.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of U.S. Provisional Application No. 63 / 523,877, filed on June 28, 2023, entitled “USING UDP PORT NUMBERS FOR SERVICE DELIMITING, SUCH AS FOR DELIMITING VIRTUAL ROUTING AND FORWARDING INSTANCES IN LAYER 3 TUNNELS” and listing Wen lin, Kevin Wang, and Kireeti Kompella as inventors (referred to as the “'877 Provisional Application” and incorporated herein by reference). The scope of the invention is not limited to any claims of the specific embodiments in the '877 Provisional Application. Technical Field

[0003] The present application relates to network communications. In particular, the present application relates to tunneling in a network that only provides layer 3 (L3) services. Background Art

[0004] One of the most commonly used network topologies for data centers (DCs) is the leaf-spine topology, which provides high bandwidth and resiliency. Overlay tunnels are used in DCs to create virtual networks that run on top of the physical infrastructure. Overlay tunnels allow different customers or connection services (e.g., pseudowires) to share the same physical network while maintaining isolation and security. This is often referred to as "multi-tenancy." This is often implemented using virtual routing and forwarding (VRF) instances. In the forwarding plane at the egress, each VRF is typically identified using an identifier, such as, for example, a Multiprotocol Label Switching (MPLS) label for a Layer 3 service or a VXLAN identifier for a Layer 2 or Layer 3 Ethernet Virtual Private Network (EVPN) over an Internet Protocol (IP) structure.

[0005] For pure IP fabric networks, it is sometimes desirable to avoid using MPLS or "X"-based MPLS encapsulation in the overlay; that is, to continue using IP. For example, some commercial chipsets do not support MPLS well. For the next generation of IP fabric-based DCs that provide layer 3 services, it is necessary to identify different services through VRF without the need for MPLS labels or VXLAN network identifiers (VNIs).

[0006] Each of the following references is incorporated herein by reference.

[0007] -Postel,J.,et al.,"User Datagram Protocol", Request for Comments (RFC) 768 (Internet Engineering Task Force (IETF), STD 6, RFC 768, August 1980) (referred to as "RFC 768" and incorporated herein by reference).

[0008] -Postel,J.,et al.,"Assigned Numbers," Request for Comments (RFC) 790 (USC / Information Sciences Institute, September 1981) (referred to as "RFC 790" and incorporated herein by reference).

[0009] -Bradner,S.,et al.,"Key words for use in RFCs to IndicateRequirement Levels",BCP 14, Request for Comments (RFC) 2119 (Internet Engineering Task Force (IETF), March 1997) (referred to as "RFC 2119" and incorporated herein by reference).

[0010] -S. Deering, et al, "Internet Protocol, Version 6 (IPv6) Specification," Request for Comments (RFC): 2460 (Internet Engineering Task Force (IETF), December 1998) (referred to as "RFC 2460" and incorporated herein by reference).

[0011] -M. Eubanks, et al. "IPv6 and UDP Checksums for Tunneled Packet," Request for Comments (RFC): 6935 (Internet Engineering Task Force (IETF), April 2013) (referred to as "RFC 6935" and incorporated herein by reference).

[0012] -K.Patel,et al.,"The BGP Tunnel Encapsulation Attribute," Request for Comments (RFC) 9012 (Internet Engineering Task Force (IETF), April 2021) (referred to as "RFC 9012" and incorporated herein by reference). Summary of the invention

[0013] There are different tunnel mechanisms that can be used for next-generation DCs that only provide layer 3 services, such as IP-in-IP or SRv6. In contrast to SRv6, when (multiple) IP-in-IP tunnels are used for overlay, the underlying layer can be an IPv4 or IPv6 network. IP-in-IP tunnels are generally not limited to the feasibility of SRv6 support in hardware. For IP-in-IP tunnels, different IP loopback addresses are typically used as tunnel destination addresses for different services. However, this does not scale well in DCs (e.g., approximately 1000 VRFs) and adds a lot of provisioning overhead. In order to support IP-in-IP (also known as IP over UDP) tunnels in a well-scaling manner, the inventors propose that when IP-in-IP (also known as IP over UDP) is used as a tunneling mechanism (e.g., in a data center), different UDP port numbers are used in the overlay to identify different connection services (e.g., customers, VRFs).

[0014] When IP-in-IP (also known as IP over UDP) is used as the tunneling mechanism in a DC, different UDP port numbers are used in the overlay to identify different connection services, customers and / or VRFs.

[0015] An example embodiment consistent with the present description may provide a computer-implemented method for identifying different services through VRF without the need for MPLS labels or VXLAN network identifiers (VNIs), the computer-implemented method comprising: (a) assigning, by a network device at the egress of the UDP-based IP tunnel and belonging to a shared network, (1) a UDP destination port value for a UDP-based IP tunnel to (2) a unique instance of a private connection service; and (b) associating, by the network device at the egress of the UDP-based IP tunnel, a forwarding table for the unique instance of the private connection service and the UDP destination port value.

[0016] In some example implementations, the only instance of the private connection service is a virtual router and forwarder (VRF) instance.

[0017] In some example implementations, the allocation action is based on manual user input. In some alternative implementations, the allocation action is automatically performed using available and unallocated UDP destination port values. For example, the allocation action can be dynamically performed using (A) a UDP port allocation library on the network device, or (B) a software-based management entity external to the network device.

[0018] Some example implementations also include: (c) announcing, by a network device at the exit of the UDP-based IP tunnel, to a network device at the entrance of the UDP-based IP tunnel and belonging to the shared network: (1) information associating a UDP destination port value for the UDP-based IP tunnel with (2) a unique instance of a private connection service. In at least some such implementations, the information associating (1) a UDP destination port value for the UDP-based IP tunnel with (2) a unique instance of a private connection service is announced through at least one service route belonging to the unique instance of the private connection service. In some example implementations, the announcement is included in a BGP message. For example, the announcement can be included in a tunnel encapsulation attribute (TEA) type length value (TLV). As another example, the announcement is included in an address family identifier (AFI) and a subsequent address family identifier (SAFI).

[0019] Some example implementations may further include: (d) receiving, by a network device at the ingress of a UDP-based IP tunnel, an IP packet associated with a unique instance of a private connection service; (e) encapsulating, by a network device at the ingress of the UDP-based IP tunnel, the IP packet using an IP over UDP header to generate an IP-in-IP packet having (1) a UDP destination port field filled with a UDP destination port value, and (2) an IP destination field filled with an IP address of a network device at the egress of the UDP-based IP tunnel; and (f) transmitting, by the network device at the ingress of the UDP-based IP tunnel, the IP-in-IP packet. Some example implementations may further include (g) receiving an IP-in-IP packet by a network device at an egress of a UDP-based IP tunnel; (h) decapsulating the IP-in-IP packet by the network device at the egress of the UDP-based IP tunnel to expose the IP packet; (i) selecting, by the network device at the egress of the UDP-based IP tunnel, one of a plurality of forwarding tables using a UDP destination port value in the received IP-in-IP packet; and (j) forwarding the IP packet by the network device at the egress of the UDP-based IP tunnel using the selected one of the plurality of forwarding tables.

[0020] Some other example implementations may further include: (c) receiving an IP-in-IP packet by a network device at an exit of a UDP-based IP tunnel; (d) decapsulating the IP-in-IP packet by a network device at the exit of the UDP-based IP tunnel to expose the IP packet; (e) selecting one of multiple forwarding tables by a network device at the exit of the UDP-based IP tunnel using a UDP destination port value in the received IP-in-IP packet; and (f) forwarding the IP packet by a network device at the exit of the UDP-based IP tunnel using the selected one of the multiple forwarding tables.

[0021] Still other implementations may further include: (c) assigning, by a network device at an egress of the second UDP-based IP tunnel, (1) a second UDP destination port value for the UDP-based IP tunnel to (2) a second unique instance of the private connection service; and (d) associating, by a network device at the egress of the second UDP-based IP tunnel, a second forwarding table for the second unique instance of the private connection service with the second UDP destination port value. In some such implementations, the second unique instance of the private connection service may be a second virtual router and forwarder (VRF) instance.

[0022] Some example network devices consistent with the present description (e.g., at an ingress and / or at an egress) include: (a) at least one processor; and (b) a non-transitory computer-readable storage medium storing processor-executable instructions that, when executed by the at least one processor, cause the at least one processor to perform any of the described methods.

[0023] Some example implementations may also include a non-transitory computer-readable storage medium storing processor-executable instructions that, when executed by at least one processor, cause the at least one processor to perform any of the described methods. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] Figure 1A and Figure 1B It is an example method consistent with the present application, and the example method can be performed by devices at the egress and ingress of a UDP-based IP VRF-aware tunnel, respectively.

[0025] Figure 2 The diagram illustrates a payload (eg, an IP packet) encapsulated within an IP header over UDP in a manner consistent with the present description.

[0026] Figure 3A and Figure 3BThe diagram illustrates packet forwarding for different VRFs over a UDP-based IP tunnel.

[0027] Figure 4 Two data forwarding systems are illustrated that may be used as nodes coupled via a communication link in a communication network, such as a communication network supporting UDP-based IP VRF-aware tunnels.

[0028] Figure 5 is a block diagram of a router that may be used in a communications network, such as a communications network that supports (multiple) UDP-based IP VRF-aware tunnels.

[0029] Figure 6 is an example architecture in which ASICS may be distributed among packet forwarding components to divide the responsibility for packet forwarding.

[0030] Fig. 7A and Figure 7B yes Figure 6 An example of the operation of the sample schema.

[0031] Figure 8 is a flow chart of an example method for providing packet forwarding in an example router.

[0032] Fig. 9 is a block diagram of an exemplary machine that can perform one or more of the processes described and / or store information used and / or generated by such processes. DETAILED DESCRIPTION

[0033] The present disclosure may be directed to novel methods, apparatus, message formats, and / or data structures that, when IP-in-IP (also known as IP over UDP) is used as a tunneling mechanism (e.g., in a data center), use, for example, different UDP port numbers to identify different connection services (e.g., customers, VRFs) without the need for MPLS labels or VXLAN network identifiers (VNIs) to identify different services in a VRF. The following description is presented to enable a person skilled in the art to make and use the described embodiments, and is provided in the context of a specific application and its requirements. Therefore, the following description of the example embodiments provides illustrations and descriptions, but is not intended to be exhaustive or to limit the present disclosure to the precise form disclosed. Various modifications to the disclosed embodiments will be apparent to those skilled in the art, and the general principles set forth below may be applied to other embodiments and applications. For example, although a series of actions may be described with reference to a flowchart, the order of the actions may be different in other implementations when the execution of one action does not depend on the completion of another action. In addition, non-dependent actions may be performed in parallel. Unless explicitly described in this way, the elements, actions or instructions used in the specification should not be interpreted as being critical or essential to this specification. In addition, as used herein, the article "a" is intended to include one or more items. In the case of only one item, the term "a" or similar language is used. Therefore, the present disclosure is not intended to be limited to the embodiments shown, and the inventor regards his invention as any patentable subject matter described.

[0034] There are different tunnel mechanisms that can be used for next-generation DCs that only provide layer 3 services, such as IP-in-IP or SRv6. Example embodiments consistent with the present description involve using a unique UDP port number for each VRF instance and mapping the UDP port number to its corresponding VRF at both ends of the UDP-based IP tunnel. In the control plane, the egress PE can be used to assign a locally unique UDP port value to each VRF from a non-standard UDP port range. Such a UDP port can be referred to as a "service UDP port". The egress PE can advertise a service route with its corresponding service UDP port based on the VRF to which it belongs.

[0035] §4.1 Example Method(s)

[0036] Figure 1A and Figure 1BThe exemplary methods 100 and 150 are respectively consistent with the present description, and the exemplary methods 100 and 150 can be performed by devices at the egress and ingress of a UDP-based IP VRF-aware tunnel, respectively. In each case, different branches of the method are performed in response to the occurrence of different events. Each of the exemplary methods 100 and 150 includes actions related to configuring or establishing a UDP-based IP tunnel, and actions related to forwarding data payloads entering and exiting the UDP-based IP tunnel.

[0037] First reference Figure 1A In the example method 100, in response to the tunnel establishment condition being met (the right branch of event 105), the network device at the egress of the UDP-based IP tunnel assigns (1) the UDP destination port value for the UDP-based IP tunnel to (2) the unique instance of the private connection service (box 110), and associates the forwarding table for the unique instance of the private connection service with the UDP destination port value (box 115). As will be described later, this can be used by the decapsulator and the forwarding table selector to decapsulate and forward packets received on the UDP-based IP tunnel. In addition, the egress device notifies (e.g., service routing) the network device at the ingress of the UDP-based IP tunnel of information associating the UDP destination port value of the UDP-based IP tunnel with the unique instance of the private connection service (box 120).

[0038] Next reference Figure 1B In the example method 150, in response to receiving the notification (left branch of event 155), the network device at the ingress of the UDP-based IP tunnel configures the encapsulator with information including: (1) the IP address of the egress device, (2) the UDP destination port value, and (3) the unique instance of the private connection service. (Block 160) At this point, the UDP-based IP tunnel is configured (or established) and can forward data payloads.

[0039] Still reference Figure 1B In the example method 150, in response to receiving an IP packet associated with a unique instance of a private connection service (right branch of event 155), the ingress device encapsulates the IP packet using IP and UDP headers to generate an IP-in-IP packet having (1) a UDP destination port field populated with a UDP destination port value and (2) an IP destination field populated with an IP address of a network device at an egress of the UDP-based IP tunnel (box 165), and transmits the IP-in-IP packet (box 170).

[0040] Finally, reference Figure 1AIn the example method 100, in response to a network device at an egress of a UDP-based IP tunnel receiving an IP-in-IP packet (left branch of event 105), the egress device decapsulates the IP-in-IP packet to expose the IP packet (box 125); uses a UDP destination port value in the received IP-in-IP packet to select one of a plurality of forwarding tables (box 130); and uses the selected one of the plurality of forwarding tables to forward the IP packet (box 135).

[0041] In some example implementations of example methods 110 and 150, the only instance of the private connection service is a virtual router and forwarder (VRF) instance.

[0042] Referring back to the right branch of event 105, in some example implementations, the tunnel establishment condition is receiving manual user input, and the allocation action (box 110) uses manual user input. In other implementations, the allocation action (box 110) is automatically performed using available and unallocated UDP destination port values. In other implementations, the allocation action (box 110) is dynamically performed using (A) a UDP port allocation library on the network device or (B) a software-based management entity external to the network device. In these cases, the tunnel establishment condition can be receiving a command from an external device, receiving a command via a user interface, and / or being triggered by a condition in a program running on the egress device.

[0043] Return to reference Figure 1A In block 120, in some implementations, information associating (1) a UDP destination port value for a UDP-based IP tunnel with (2) a unique instance of a private connectivity service is advertised via at least one service route belonging to the unique instance of the private connectivity service. In some implementations, the advertisement is included in a BGP message. (See, e.g., E. Rosen, et al, “BGP / MPLS IP Virtual Private Networks (VPNs),” Request forComments(RFC):4364 (Internet Engineering Task Force (IETF), February 2006) (also referred to as "RFC 4364", which is incorporated herein by reference) BGP within a service provider network. For example, the announcement (or the information in the announcement) can be included in a tunnel encapsulation attribute (TEA) type-length value (TLV). (See, for example, K. Patel, et al., "The BGP Tunnel Encapsulation Attribute," Request for Comments (RFC) 9012(Internet Engineering Task Force (IETF), April 2021) (referred to as "RFC 9012" and incorporated herein by reference)). As another example, the announcement (or information in the announcement) may be included in an address family identifier (AFI) and a subsequent address family identifier (SAFI).

[0044] Note that example methods 100 and 150 may be performed multiple times for multiple different unique instances of a private connection service (eg, for multiple unique VRFs).

[0045] Return to reference Figure 1B Boxes 165 and 170, Figure 2 The diagram illustrates a payload (e.g., IP packet) 210 encapsulated in UDP-based IP headers 220 and 230. In this example data structure 200, the value in the destination port number field 225 of the UDP header 220 is assigned to and associated with a unique instance of a private connection service (recall that Figure 1A 110 of the example data structure 200). In addition, in this example data structure 200, the value in the destination address field 235 of the IP header 230 corresponds to the IP address of the device at the egress of the UDP-based IP tunnel. The IP destination address is used to forward the packet to the egress device. For the UDP datagram protocol, the protocol field 237 in the outer IP header 230 is set to 17. The value in the destination port number field 225 is used by the egress device to understand which client or connection service the lower layer payload (e.g., IP packet) is for.

[0046] Note that the UDP destination port number does not need to be globally unique; it only needs to be unique to the egress device (i.e., locally unique). However, if the UDP destination port number is not unique to a unique VRF, some coordination may be useful in the case of dual-homed or multi-homed devices.

[0047] Note also that an egress device may interpret the UDP destination port value in any way it deems appropriate.

[0048] As understood above, for an overlay UDP-based IP tunnel in the data plane, the destination UDP port value in the outer IP header will be set to the service UPD associated with the service route learned from its egress device. At the egress device, the outer UDP destination port will be used to identify its VRF.

[0049] §4.2 Example Operation(s) of Example Method(s)

[0050] Figure 3A and Figure 3BThe diagram illustrates the data planes for handling messages of different VRFs at the ingress and egress of (multiple) UDP-based IP tunnels. The UDP-based IP tunnel 310 includes a tunnel ingress device 320 and a tunnel egress device 330. Zero or more transmission devices (not shown) may exist on the IP over UPD tunnel 310 between the tunnel ingress device 320 and the tunnel egress device 330. The tunnel ingress device 320 includes, in particular, an encapsulator 322 and a storage device or memory 324, which stores the association of one or more VRF identifiers and UDP destination port numbers. The tunnel egress device 330 includes, in particular, a decapsulator and (e.g., per VRF) a forwarding table selector 332, a storage device or memory 334 storing the association of one or more UDP destination port numbers and VRFs, and one or more forwarding tables 336. It should be understood that this example assumes that the forwarding state has been programmed on the tunnel ingress device 320, and the decapsulator and forwarding table selector 336 have been programmed on the tunnel egress device 330. Note that in this example, in order to simplify the description, lowercase letters (q, r, s, ...) are used to describe the UDP destination port number. In practice, the destination port number value should be in the range of 49512 to 65535.

[0051] First reference Figure 3A , message 340 for VRFX arrives at tunnel entry device 320. Encapsulator 322 uses the VRF to look up the corresponding UDP destination port number. In this example, UDP destination port number "q" is associated with VRF "X". Message 350 output from tunnel entry device 320 corresponds to the original message 340 encapsulated using a UDP header and an IP header, in which the value in the UDP destination port number field 225 is set to "q", in the IP header, the protocol field 237 for the UDP datagram protocol is set to "17", and the value in the destination address field 235 is set to the IP address of the egress device 330. (Recall, for example, Figure 1B (Note that the UDP source port may be provided with an entropy value for load balancing (but this is not required), and other UDP header fields may be populated in a conventional or proprietary manner.) Message 350 may be forwarded through zero or more transport devices (not shown) over UDP-based IP tunnel 310. (Recall e.g. Figure 1B 170). When message 350 arrives at tunnel egress device 330, decapsulator and forwarding table selector 332 uses the value "q" in UDP destination port number field 225 to look up the VRF (in this case "X") and selects the appropriate forwarding table 336 for VRF "X". Decapsulated message body 360 is output from tunnel egress device 330. (Recall, e.g. Figure 1A 135 of the . )

[0052] Next reference Figure 3B , message 340' for VRFZ arrives at tunnel entry device 320. Encapsulator 322 uses VRF to look up the corresponding UDP destination port number. In this example, UDP destination port number "s" is associated with VRF "Z". Message 350' output from tunnel entry device 320 corresponds to original message 340' encapsulated using a UDP header and an IP header, in which the value of UDP destination port number field 225 is set to "s", in the IP header, the protocol field 237 for the UDP datagram protocol is set to "17", and the value in the destination address field 235 is set to the IP address of the egress device 330. (Recall, for example, Figure 1B (Note that the UDP source port may be provided with an entropy value (but this is not required) and other UDP header fields may be populated in a conventional or proprietary manner.) Message 350' may be forwarded through zero or more transport devices (not shown) over UDP-based IP tunnel 310. (Recall e.g. Figure 1B When message 350' arrives at tunnel egress device 330, decapsulator and forwarding table selector 332 uses the value "s" in UDP destination port number field 225 to look up the VRF (in this case "Z") and selects the appropriate forwarding table 336 for VRF "Z". Decapsulated message body 360' is output from tunnel egress device 330. (Recall, e.g. Figure 1A 135 of the . )

[0053] §4.3 Example Device

[0054] A data communication network node (eg, an ingress and / or egress node of a UDP-based IP tunnel) may be a forwarding device such as, for example, a router. Figure 4 Two data forwarding systems 410 and 420 coupled via a communication link 430 are illustrated. The link may be a physical link or a "wireless" link. The data forwarding systems 410, 420 may be, for example, routers. If the data forwarding systems 410, 420 are example routers, each may include a control component (e.g., a routing engine) 414, 424 and a forwarding component 412, 422. Each data forwarding system 410, 420 includes one or more interfaces 416, 426 that terminate one or more communication links 430.

[0055] As mentioned above and with reference to Figure 5 , some example routers 500 include a control component (eg, routing engine) 510 and a packet forwarding component (eg, packet forwarding engine) 590 .

[0056] The control component 510 may include an operating system (OS) kernel 520, (multiple) routing protocol processes 530, (multiple) label-based forwarding protocol processes 540, (multiple) interface processes 550, (multiple) user interface (e.g., command line interface) processes 560, and (multiple) chassis processes 570, and may store (multiple) routing tables 539, label forwarding information 545, and (multiple) forwarding (e.g., route-based and / or label-based) tables 580. As shown, routing protocol process(es) 530 may support routing protocols such as Routing Information Protocol ("RIP") 531, Intermediate System Protocol ("IS-IS") 532, Open Shortest Path First ("OSPF") 533, Enhanced Interior Gateway Routing Protocol ("EIGRP") 534, and Border Gateway Protocol ("BGP") 535, and label-based forwarding protocol process(es) 540 may support protocols such as BGP 535, Label Distribution Protocol ("LDP") 536, Resource Reservation Protocol ("RSVP") 537, EVPN 538, and L2VPN 539. Other protocols may be supported. One or more components (not shown) may allow a user 565 to interact with the user interface process(es) 560. Similarly, one or more components (not shown) may allow an external device (not shown) to interact with one or more of the router protocol process(es) 530, the label-based forwarding protocol process(es) 540, the interface process(es) 550, and the chassis process(es) 570 via SNMP 585, and such processes may send information to the external device via SNMP 585.

[0057] The packet forwarding component 590 may include a microkernel 592 on top of a hardware component (e.g., ASIC, switch fabric, optics, etc.) 591, interface process(es) 593, ASIC driver 594, chassis process(es) 595, and forwarding (e.g., route-based and / or label-based) table(s) 596.

[0058] exist Figure 5In the example router 500, the control component 510 handles tasks such as executing routing protocols, executing label-based forwarding protocols, controlling packet processing (such as notifications as described above), etc., which frees up the packet forwarding component 590 to quickly forward the received packets. That is, the received control packets (e.g., routing protocol packets and / or label-based forwarding protocol packets) are not fully processed on the packet forwarding component 590 itself, but are passed to the control component 510, thereby reducing the amount of work that the packet forwarding component 590 must do and freeing it to efficiently process the packets to be forwarded. Therefore, the control component 510 is primarily responsible for running routing protocols and / or label-based forwarding protocols, maintaining routing tables and / or label forwarding information, sending forwarding table updates to the packet forwarding component 590, and performing system management. The example control component 510 can process routing protocol packets, provide management interfaces, provide configuration management, perform accounting, and provide alarms. Processes 530, 540, 550, 560, and 570 can be modular and can interact with the OS kernel 520. That is, almost all processes communicate directly with the OS kernel 520. Using modular software that completely separates processes from each other isolates problems with a given process so that these problems do not affect other processes that may be running. Additionally, using modular software facilitates easier expansion.

[0059] Still reference Figure 5 , the example OS kernel 520 can incorporate an application programming interface ("API") system for external program calls and script processing capabilities. The control component 510 can be based on an Intel PCI platform running an OS from flash memory, with a backup copy stored on the router's hard disk. The OS kernel 520 is layered on the Intel PCI platform and establishes communication between the Intel PCI platform and the processes of the control component 510. The OS kernel 520 also ensures that the forwarding tables 596 used by the packet forwarding component 590 are synchronized with those forwarding tables 580 in the control component 510. Therefore, in addition to providing the underlying infrastructure to the control component 510 software process, the OS kernel 520 also provides a link between the control component 510 and the packet forwarding component 590.

[0060] refer to Figure 5(multiple) routing protocol processes 530, which provide routing and routing control functions within the platform. In this example, RIP 531, ISIS 532, OSPF 533 and EIGRP 534 (and BGP 535) protocols are provided. Of course, other routing protocols can be provided in addition or alternatively. Similarly, (multiple) label-based forwarding protocol processes 540 provide label forwarding and label control functions. In this example, LDP 536, RSVP 537, EVPN 538 and L2VPN 539 (and BGP 535) protocols are provided. Naturally, other label-based forwarding protocols (e.g., MPLS, SR, etc.) can be provided in addition or alternatively. In the example router 500, (multiple) routing tables 539 are generated by (multiple) routing protocol processes 530, and label forwarding information 545 is generated by (multiple) label-based forwarding protocol processes 540.

[0061] Still reference Figure 5 , interface process(es) 550 perform configuration of physical interfaces and encapsulation.

[0062] Example control component 510 can provide several ways to manage the router. For example, it 510 can provide (multiple) user interface processes 560 that allow system operators 565 to interact with the system through configuration, modification and monitoring. SNMP 585 allows systems that support SNMP to communicate with the router platform. This also allows the platform to provide necessary SNMP information to external agents. For example, SNMP 585 can allow the system to be managed from a network management station running software (such as Hewlett-Packard's Network Node Manager ("HP-NNM")) through a framework such as Hewlett-Packard OpenView. The accounting of packets (commonly referred to as traffic statistics) can be performed by the control component 510 to avoid slowing down the traffic forwarding of the packet forwarding component 590.

[0063] Although not shown, the example router 500 can provide out-of-band management, RS-232DB9 port for serial console and remote management access and the third storage device using a removable PC card. In addition, although not shown, the process interface located at the front of the rack provides an external view into the internal work of the router. It can be used as a troubleshooting tool, a monitoring tool or both. The process interface can include LED indicators, alarm indicators, control component ports and / or display screens. Finally, the process interface can provide interaction with a command line interface ("CLI") 560 via a console port, an auxiliary port and / or a management Ethernet port.

[0064] The packet forwarding component 590 is responsible for correctly outputting received packets as quickly as possible. If there is no entry in the forwarding table for a given destination or a given label and the packet forwarding component 590 cannot perform forwarding itself, it 590 can send packets destined for unknown destinations to the control component 510 for processing. The example packet forwarding component 590 is designed to perform layer 2 and layer 3 switching, route lookups, and fast packet forwarding.

[0065] like Figure 5 As shown, the example packet forwarding component 590 has an embedded microkernel 592, interface process(es) 593, ASIC driver 594, and chassis process(es) 595 on top of hardware component 591 and stores forwarding (e.g., route-based and / or label-based) table 596. (Recall e.g. Figure 3A and Figure 3B 336). The microkernel 592 interacts with (multiple) interface processes 593 and (multiple) rack processes 595 to monitor and control these functions. (Multiple) interface processes 592 communicate directly with the OS kernel 520 of the control component 510. The communication includes forwarding abnormal packets and control packets to the control component 510, receiving packets to be forwarded, receiving forwarding table updates, providing information related to the health of the packet forwarding component 590 to the control component 510, and allowing configuration of the interface of (multiple) user interface (e.g., CLI) process 560 from the control component 510. The stored (multiple) forwarding table 596 is static until a new forwarding table is received from the control component 510. (Multiple) interface processes 593 use (multiple) forwarding tables 596 to look up next hop information. (Multiple) interface processes 593 also have direct communication with distributed ASICs. Finally, (multiple) rack processes 595 can communicate directly with the microkernel 592 and ASIC drivers 594.

[0066] Figure 6 is an example of how ASICS can be distributed among packet forwarding components 590 to divide the responsibility for packet forwarding. Figure 6 As shown, the ASICs of the packet forwarding component 590 may be distributed across a physical interface card ("PIC") 610, a flexible PIC concentrator ("FPC") 620, a midplane or backplane 630, and (multiple) system control boards 640 (for switching and / or forwarding). The switching fabric is also shown as a system switch board ("SSB") or switching and forwarding module ("SFM") 650 (which may be, for example, Fig. 7A and Figure 7BEach of the PICs 610 includes one or more PIC I / O managers 615. Each of the FPCs 620 includes one or more I / O managers 622, each of which has an associated memory 624 (which may be, for example, Fig. 7A and Figure 7B The midplane / backplane 630 includes buffer managers 635a, 635b. Finally, the system control board 640 includes an instance of an Internet processor 642 and a forwarding table 644 (recall, for example, Figure 5 of 596).

[0067] Still reference Figure 6 , PIC 610 includes interface ports. Each PIC 610 can be inserted into FPC 620. Each individual PIC 610 can include an ASIC that handles media specific functions (such as framing or encapsulation). Some example PIC 610s provide SDH / SONET, ATM, Gigabit Ethernet, Fast Ethernet, and / or DS3 / E3 interface ports.

[0068] like Figure 6 As shown, FPC 620 may contain one or more PICs 610 and may transmit signals from PIC 610 to midplane / backplane 630 .

[0069] Midplane / backplane 630 houses line cards. When inserted into the rack of the example router from the front, the line card can be connected to midplane / backplane 630. Control components (e.g., routing engines) 510 can be inserted into the back of midplane / backplane 630 from the back of the rack. Midplane / backplane 630 can transmit electrical (or optical) signals and power to each line card and control component 510.

[0070] The system control board 640 can perform forwarding lookups. It 640 can also transmit errors to the routing engine. In addition, it 640 can also monitor the status of the router based on the information it receives from the sensor. If an abnormal condition is detected, the system control board 640 can immediately notify the control component 510.

[0071] refer to Figure 6 , Fig. 7A and Figure 7BIn some exemplary routers, each of the PICs 610, 610' contains at least one I / O manager ASIC 615, which is responsible for media specific tasks, such as encapsulation. Packets pass through these I / O ASICs on their way in and out of the router. The I / O manager ASIC 615 on the PIC 610, 610' is responsible for managing the connection with the I / O manager ASIC 622 on the FPC 620, 620', managing link layer framing and creating a bit stream, performing cyclic redundancy checks (CRCs), and detecting link layer errors and generating alarms when appropriate. The FPC 620 includes another I / O manager ASIC 622. This ASIC 622 (shown as layer 2 / layer 3 packet processing component 610' / 620') takes packets from the PIC 610 and breaks them into (e.g., 74 byte) memory blocks. The FPC I / O Manager ASIC 622 (shown as a layer 2 / layer 3 packet processing component 610' / 620') sends the block to the first distributed buffer manager (DBM) 635a (shown as a switch interface component 635a'), decodes the encapsulation and protocol specific information, counts the packets and bytes for each logical circuit, verifies packet integrity and applies class of service (CoS) rules to the packet. At this point, the packet is first written to memory. More specifically, the example DBM ASIC 635 / 635a' manages the packet and writes the packet to a shared memory 624 across all FPCs 620. In parallel, the first DBM ASIC 635 / 635a' also extracts information about the destination of the packet and passes the forwarding related information to the Internet processor 642 / 642'. The Internet processor 642 / 642' uses the forwarding table 644 to perform a route lookup and sends the information through the second DBM ASIC 635b'. The Internet Processor ASIC 642 / 642' also collects the exception packets (i.e., those packets that do not have a forwarding table entry) and sends them to the control component 510. The second DBM ASIC 625 (shown as a queuing and memory interface component 635b') then takes this information and the 74-byte blocks and forwards them to the I / O Manager ASIC 622 of the egress FPC 620 / 620' (or multiple egress FPCs in the case of multicast) for reassembly. (Thus, the DBM ASICs 635a / 635a' and 635b / 635b' are responsible for managing the packet memory 624 / 624' distributed across all FPCs 620 / 620', extracting forwarding related information from the packets and instructing the FPCs where to forward the packets.)

[0072] The I / O Manager ASIC 622 on the egress FPC 620 / 620' may perform certain value added services. In addition to increasing the Time To Live ("TTL") value and re-encapsulating the packet for processing by the PIC 610, it may also apply Class of Service (CoS) rules. To do this, it may queue a pointer to the packet in one of the available queues, each with a share of the link bandwidth, before applying the rules to the packet. The queuing may be based on various rules. Thus, the I / O Manager ASIC 622 on the egress FPC 620 / 620' may be responsible for receiving the block from the second DBM ASIC 635 / 635', increasing the TTL value, queuing a pointer to the packet before applying CoS rules if necessary, re-encapsulating the block and sending the encapsulated packet to the PIC I / O Manager ASIC 615.

[0073] Figure 8 800 is a flowchart of an example method for providing packet forwarding in an example router. When a packet is received on an inlet (entry) port or interface, the main action of method 800 is triggered (event 810). The checksum and frame check type required for the media type it serves are executed and the packet is output as a serial bit stream (frame 820). The packet is then decapsulated and parsed into (e.g., 64-byte) blocks (frame 830). The packet is written to a buffer memory and the forwarding information is transmitted on an Internet processor (frame 840). The transmitted forwarding information is then used to find a route in a forwarding table (frame 850). Note that the forwarding table can usually handle unicast packets that do not have set options (e.g., accounting), as well as multicast packets that already have cache entries. Therefore, if it is determined that these conditions are met (the "yes" branch of decision 860), the packet forwarding component finds the next hop and the egress interface, and the packet is forwarded (or queued to forward) to the next hop (frame 870) via the egress interface before leaving method 800 (node ​​890). Otherwise, if these conditions are not met ("No" branch of decision 860), the forwarding information is sent to control component 510 for high-level forwarding resolution (block 880) before leaving method 800 (node ​​890).

[0074] Referring back to block 870, the packets may be queued. Figure 6As described above, pointers to packets can be queued. The packets themselves can be retained in shared memory. Therefore, all queuing decisions and CoS rules can be applied without actual packets. When the pointer to the packet reaches the front of the queue, the I / O Manager ASIC 622 can send a request for the packet to the second DBM ASIC 635b. The DBM ASIC 635 reads the blocks from the shared memory and sends them to the I / O Manager ASIC 622 on the FPC 620, which then serializes the bits and sends them to the media-specific ASIC of the egress interface. The I / O Manager ASIC 615 on the egress PIC 610 can apply physical layer framing, perform CRC and send the bit stream out over the link.

[0075] Return to reference Figure 8 The frame 880 and Figure 6 Regarding the transmission of control and abnormal packets, the system control board 640 processes almost all abnormal packets. For example, the system control board 640 can transmit the abnormal packets to the control component 510.

[0076] Although it can be Figure 4 or Figure 5 Example embodiments consistent with the present description are implemented on an example router of , but embodiments consistent with the present description may be implemented on communication network nodes (e.g., routers, switches, etc.) having different architectures. More generally, embodiments consistent with the present description may be implemented on a network node such as Fig. 9 Embodiments consistent with the present description are implemented on the illustrated example system 900 .

[0077] Fig. 9 900 is a block diagram of an exemplary machine 900 that can perform one or more processes described and / or store information used and / or generated by these processes. The exemplary machine 900 includes one or more processors 910, one or more input / output interface units 930, one or more storage devices 920, and one or more system buses and / or networks 940 for facilitating information communication between coupled elements. One or more input devices 932 and one or more output devices 934 can be coupled using one or more input / output interfaces 930. One or more processors 910 can execute machine executable instructions (e.g., C or C++ running on a Linux operating system that is widely available from multiple vendors) to perform one or more aspects of the present description. At least a portion of the machine executable instructions can be stored (temporarily or more permanently) on one or more storage devices 920 and / or can be received from an external source via one or more input interface units 930. The machine executable instructions can be stored as various software modules, each module performing one or more operations. Functional software modules are examples of components of the present description.

[0078] In some embodiments consistent with the present description, processor 910 may be one or more microprocessors and / or ASICs. Bus 940 may include a system bus. Storage device 920 may include system memory, such as a read-only memory (ROM) and / or a random access memory (RAM). Storage device 920 may also include a hard disk drive for reading from and writing to a hard disk, a disk drive for reading from or writing to a (e.g., removable) disk, an optical disk drive for reading from or writing to a removable (magneto) optical disk such as an optical disk or other (magneto) optical medium, or a solid-state non-volatile storage device.

[0079] Some example embodiments consistent with this description may also be provided as a machine-readable medium for storing machine-executable instructions. The machine-readable medium may be non-transitory and may include, but is not limited to, flash memory, optical disks, CD-ROMs, DVD ROMs, RAMs, EPROMs, EEPROMs, magnetic or optical cards, or any other type of machine-readable medium suitable for storing electronic instructions. For example, example embodiments consistent with this description may be downloaded as a computer program that may be transmitted from a remote computer (e.g., a server) to a requesting computer (e.g., a client) via a communication link (e.g., a modem or a network connection) and stored on a non-transitory storage medium. The machine-readable medium may also be referred to as a processor-readable medium.

[0080] Example embodiments consistent with the present description (or components or modules thereof) may be implemented in hardware, such as one or more field programmable gate arrays ("FPGAs"), one or more integrated circuits (such as ASICs), one or more network processors, etc. Alternatively or additionally, embodiments consistent with the present description (or components or modules thereof) may be implemented as stored program instructions executed by a processor. Such hardware and / or software may be provided in an addressing data (e.g., packet, cell, etc.) forwarding device (e.g., switch, router, etc.), a laptop computer, a desktop computer, a tablet computer, a mobile phone, or any device having computing and networking capabilities.

[0081] §4.4 Conclusion

[0082] The above example embodiments use IP over UDP as a tunneling mechanism, using different UDP port numbers to identify different connection services, customers, and / or VRFs (e.g., in a DC environment). This innovative approach provides multi-tenancy without the need to use MPLS or "X"-based MPLS encapsulation in the overlay. It improves scalability and reduces the overhead associated with using different destination IP addresses to identify different VRFs at the egress, making it an ideal option for next-generation data centers that provide layer 3 services. This is more scalable than using different IP loopback addresses to distinguish different VRFs. It also avoids additional headers and therefore avoids additional work in the forwarding plane.

Claims

1. A computer-implemented method comprising: a) assigning, by a network device at an egress of the UDP-based IP tunnel and belonging to a shared network, (1) a UDP destination port value for the UDP-based IP tunnel to (2) a unique instance of a private connection service; as well as b) associating, by the network device at the egress of the UDP-based IP tunnel, a forwarding table for the unique instance of the private connection service with the UDP destination port value.

2. The computer-implemented method of claim 1, wherein the only instance of a private connection service is a virtual router and forwarder (VRF) instance. The computer-implemented method of claim 1 , wherein the assigning action is based on manual user input.

4. The computer-implemented method of claim 1, wherein the act of allocating is performed automatically using an available and unallocated UDP destination port value.

5. The computer-implemented method of claim 4, wherein the allocating action is performed dynamically using (A) a UDP port allocation library on the network device, or (B) a software-based management entity external to the network device.

6. The computer-implemented method of claim 1 , further comprising: c) by the network device at the exit of the UDP-based IP tunnel, announcing, to a network device at the entrance of the UDP-based IP tunnel and belonging to the shared network, information associating (1) the UDP destination port value for the UDP-based IP tunnel with (2) the unique instance of the private connection service.

7. A computer-implemented method according to claim 6, wherein the information associating (1) the UDP destination port value for the UDP-based IP tunnel with (2) the unique instance of the private connection service is announced via at least one service route belonging to the unique instance of the private connection service.

8. The computer-implemented method of claim 6, wherein the advertisement is included in a BGP message.

9. The computer-implemented method of claim 8, wherein the advertisement is included in a tunnel encapsulation attribute (TEA) type-length-value (TLV).

10. The computer-implemented method of claim 8, wherein the announcement is included in an address family identifier (AFI) and a subsequent address family identifier (SAFI).

11. The computer-implemented method of claim 6, further comprising: d) receiving, by the network device at the ingress of the UDP-based IP tunnel, an IP packet associated with the unique instance of the private connection service; e) encapsulating the IP packet with a UDP-based IP header by the network device at the ingress of the UDP-based IP tunnel to generate an IP-in-IP packet having (1) a UDP destination port field populated with the UDP destination port value and (2) an IP destination field populated with the IP address of the network device at the egress of the UDP-based IP tunnel; as well as f) transmitting the IP-in-IP packet through the network device at the ingress of the UDP-based IP tunnel.

12. The computer-implemented method of claim 11 , further comprising: g) receiving the IP-in-IP packet by the network device at the egress of the UDP-based IP tunnel; h) decapsulating the IP-in-IP packet by the network device at the egress of the UDP-based IP tunnel to expose the IP packet; i) selecting, by the network device at the egress of the UDP-based IP tunnel, one of a plurality of forwarding tables using a UDP destination port value in the received IP-in-IP packet; as well as j) forwarding the IP packet using a selected one of the plurality of forwarding tables through the network device at the egress of the UDP-based IP tunnel.

13. The computer-implemented method of claim 1 , further comprising: c) receiving an IP-in-IP packet by the network device at the egress of the UDP-based IP tunnel; d) decapsulating the IP-in-IP packet by the network device at the egress of the UDP-based IP tunnel to expose an IP packet; e) selecting, by the network device at the egress of the UDP-based IP tunnel, one of a plurality of forwarding tables using a UDP destination port value in the received IP-in-IP packet; as well as f) forwarding the IP packet using a selected one of the plurality of forwarding tables through the network device at the egress of the UDP-based IP tunnel.

14. The computer-implemented method of claim 1 , further comprising: c) assigning, by the network device at the egress of the second UDP-based IP tunnel, (1) a second UDP destination port value for the UDP-based IP tunnel to (2) a second unique instance of the private connection service; as well as d) associating, by the network device at the egress of the second UDP-based IP tunnel, a second forwarding table for the second unique instance of the private connection service with the second UDP destination port value.

15. The computer implemented method of claim 14, wherein the second unique instance of a private connection service is a second virtual router and forwarder (VRF) instance.

16. A system comprising: - a first network device at the exit of the UDP-based IP tunnel and belonging to a shared network, the network device at the exit of the UDP-based IP tunnel comprising: a) at least one processor; and b) a non-transitory computer-readable storage medium storing processor-executable instructions that, when executed by the at least one processor, cause the at least one processor to perform a method comprising: 1) assigning, by the first network device, (i) a UDP destination port value for the UDP-based IP tunnel to (ii) a unique instance of a private connection service; and 2) Associating, by the first network device, a forwarding table for the unique instance of the private connection service with the UDP destination port value.

17. The system of claim 16, wherein the only instance of a private connection service is a virtual router and forwarder (VRF) instance.

18. The system of claim 16, further comprising: - a second network device at the entrance of said UDP-based IP tunnel and belonging to said shared network, The method performed by the first network device further includes: 3) Notifying, by the first network device, to the second network device, information associating (i) the UDP destination port value for the UDP-based IP tunnel with (ii) the unique instance of a private connection service.

19. The system according to claim 18, wherein the second network device comprises: a) at least one processor; as well as b) a non-transitory computer-readable storage medium storing processor-executable instructions that, when executed by the at least one processor of the second network device, cause the at least one processor of the second network device to perform a method comprising: 1) receiving, by the second network device, an IP packet associated with the unique instance of the private connection service; 2) encapsulating, by the second network device, the IP packet with an IP header over UDP to generate an IP-in-IP packet having (i) a UDP destination port field populated with the UDP destination port value, and (ii) an IP destination field populated with an IP address of the network device at the egress of the IP tunnel over UDP; and 3) Transmitting the IP-in-IP packet through the second network device.

20. A non-transitory computer-readable storage medium storing processor-executable instructions that, when executed by at least one processor, cause the at least one processor to perform a method comprising: a) assigning, by a network device at the egress of the UDP-based IP tunnel and belonging to the shared network, a UDP destination port value for the UDP-based IP tunnel to a unique instance of (2) the private connection service; as well as b) associating, by the network device at the egress of the UDP-based IP tunnel, a forwarding table for the unique instance of the private connection service with the UDP destination port value.

Images