AU2017304281A1 - Extending an MPLS network using commodity network devices - Google Patents

Abstract

A provider network can expand an IP/MPLS core using commodity network devices at the edge of the provider network to connect customer networks. Upon receiving a request to establish a connection between a first customer network and a second customer network, the provider network can update a mapping of local VLAN IDs to provider edge port VLAN IDs and program the commodity network devices using push, pop, or swap VLAN operations to correctly transport traffic from the edge of the network into the core of the network where higher order functionality exists. Resiliency for the expansion network can be provided using primary/secondary network uplinks.

Description

EXTENDING AN MPLS NETWORK USING COMMODITY NETWORK DEVICES

TECHNICAL FIELD

[0001] The present technology pertains to computer networking, and more specifically to extending a Multiprotocol Label Switching (MPLS) network using commodity network devices.

BACKGROUND

[0002] Conventional Internet Protocol (IP) networks operate in a connectionless mode in which datagrams or packets are routed on a hop-by-hop basis and each network device (e.g., switch, router, gateway, etc.) along the network path makes an independent routing or forwarding decision. The next hop for a packet may be determined based on a destination address in the packet header and forwarding information that may be updated via routing protocols. At each hop, forwarding tables (e.g., forwarding information base (FIB), routing information base (RIB), routing tables, content addressable memory (CAM) tables, etc.) are accessed to determine an address prefix that is the longest match for the packet’s destination address.

[0003] There are several limitations with conventional techniques for connectionless communication. For example, forwarding may be determined based only on packet header information, and the network device at each hop may not take into account other network conditions. Further, connectionless communication can require more processing than other approaches. For instance, the packet header may include numerous fields that are not used for determining the next hop, and this data can represent unnecessary overhead flowing through the network. In addition, processing the packet header includes several operations, such as performing a lookup for the destination address in the forwarding table, updating the Time To Live (TTL) field, and calculating a new header checksum at each hop.

[0004] Connectionless communication may also be subject to uneven traffic distribution. For example, packets in such networks are usually forwarded along paths determined to have the fewest number of hops to the destination. With heavy traffic, the shortest routes may become congested while longer routes may be under-utilized.

[0005] In conventional connection-oriented networks, a connection is established between source and destination before actual data (e.g., user data, data plane traffic, etc. and not control data, control plane traffic, etc.) is exchanged. For instance, virtual circuits (e.g., tunnels, virtual links, virtual connections, virtual channels, etc.) can be established via signaling protocols, and packets flowing through the virtual circuits may be forwarded along fixed paths defined during set up. The virtual circuits may be identified by tags or labels in the packet header.

[0006] Conventional connection-oriented networking suffers from certain disadvantages relative to other networking techniques. For example, connection set up and termination can cause delay, and the signaling procedures for establishing and terminating a connection expend processing resources not incurred by connectionless communication protocols. Further, traditional connection-oriented communication networks can be especially vulnerable to failures of nodes along virtual circuits; a failure at any node results in connection failure. Conventional connection-oriented communication may also require reservation of resources that tie up those resources for the duration of the connection.

[0007] Multiprotocol Label Switching (MPLS) is a networking architecture that attempts to overcome the limitations of conventional networking techniques by combining traditional IP routing with connection-oriented communication. MPLS utilizes separate control and data planes for forwarding traffic. Routing information and labels are exchanged in the control plane and packets are forwarded based on labels in the data plane. The control plane may support various complex protocols for distributing routing information (e.g., Open Shortest Path First (OSPF), Interior Gateway Routing Protocol (IGRP), Enhanced Interior Gateway Routing Protocol (EIGRP), Intermediate System to Intermediate System (IS-IS), Routing Information Protocol (RIP), Border Gateway Protocol (BGP), etc.) and labels (e.g., Tag Distribution Protocol (TDP), Label Distribution Protocol (LDP), BGP, Resource Reservation Protocol (RSVP), Constraint-based Routing Label Distribution Protocol (CR-LDP), etc.). The data plane, on the other hand, can use a simple label-based forwarding engine, that is independent of any specific routing or labeling protocol implemented in the control plane, to forward packets. The forwarding engine may access a Label Forwarding Information Base (LFIB) to determine forwarding decisions.

[0008] MPLS can be used to support services such as quality-of-service (QoS), virtual private networks (VPNs), traffic engineering, unicast routing, multicast routing, and pseudowires, among other services. Networks that provide MPLS services are typically made up of robust and expensive network devices that support several layers of protocols and include numerous resiliency features. Each network device in such a network may have autonomous control over maintaining the state of the network and forwarding data in the collective right direction. However, such networks may be difficult to scale because as these networks grow, the cost of expanding these networks can increase exponentially.

[0009] In this specification where reference has been made to patent specifications, other external documents, or other sources of information, this is generally for the purpose of providing a context for discussing the features of the invention. Unless specifically stated otherwise, reference to such external documents or such sources of information is not to be construed as an admission that such documents or such sources of information, in any jurisdiction, are prior art or form part of the common general knowledge in the art.

BRIEF SUMMARY

[0010] It is an object of at least one or more embodiments of the present invention to overcome one or more draw backs in the prior art, or at least provide the public with a useful alternative.

[0011] In a first aspect there is provided a computer-implemented method, comprising: receiving a frame to a first edge network device of a provider network from a first customer network, the first edge network device being a commodity network device, the provider network including a Multiprotocol Label Switching (MPLS) core network; determining, by the first edge network device, an ingress interface of the first edge network device to which the frame is received and an ingress virtual local area network (VLAN) identifier (ID) of the frame; performing, by the first edge network device, a lookup in a forwarding table using the ingress interface and the ingress VLAN ID; determining, by the first edge network device, an egress interface and an egress VLAN ID for the frame based on the lookup; and transmitting, by the first edge network device, the frame, with the egress VLAN ID, to the egress interface.

[0012] The computer-implemented method further comprising the steps of: receiving, by the provider network, a request to establish a connection between the first network and a second customer network; determining, by the provider network, a first interface of a first customer edge network device of the first customer network that is connected to the provider network and a second interface of a second customer edge network device of the second customer network that is connected to the provider network; and determining, by the provider network, one or more forwarding rules for one or more edge network devices of the provider network for establishing the connection based at least in part on the first interface, a first VLAN ID corresponding to the first customer network, the second interface, and a second VLAN ID corresponding to the second customer network.

[0013] At least one of the first VLAN ID is selected by the first customer or the second VLAN ID is selected by the second customer.

[0014] The connection is a point-to-point connection or a point-to-multipoint connection.

[0015] The egress interface is located on the first edge network device, and the method further comprises: popping, by the first edge network device, the ingress VLAN ID from the frame; and pushing, by the first edge network device, the egress VLAN ID onto the frame.

[0016] The egress interface is located on the first edge network device and the ingress VLAN ID has a same value as the egress VLAN ID.

[0017] The egress interface is located on a first core network device of the MPLS core network, and the method further comprises: popping, by the first edge network device, the ingress VLAN ID from the frame; and pushing, by the first edge network device, the egress VLAN ID onto the frame; receiving the frame to the first core network device; transmitting the frame to one or more second core network devices; receiving the frame to a second edge network device of the provider network from a last core network device of the one or more second core network devices; popping, by the second edge network device, the egress VLAN ID from the frame; pushing, by the second edge network device, a second customer VLAN ID corresponding to a second customer network; and transmitting, by the second edge network device, the frame, with the second customer VLAN ID, to a customer edge network device of the second customer network.

[0018] The computer-implemented method further comprising the step of: configuring, by the provider network, a virtual leased line (VLL) or a virtual private local area network service (VPLS) for frames received to the egress interface of the first core network device and including the egress VLAN ID to the second edge network device.

[0019] The computer-implemented method further comprising the step of: configuring, by the provider network, the first edge network device to have a plurality of uplinks using fast failover group tables that are populated via a link detection protocol.

[0020] The edge network device is compliant with OpenFlow Switch Specification version 1.30, a later version thereof, or a derivation thereof.

[0021] In a second aspect there is provided a network comprising: a network controller; a Multiprotocol Label Switching (MPLS) core network; and a plurality of commodity network devices located at edges of the network, including a first edge network device having a processor and memory including instmctions that, upon being executed by the processor, cause the first edge network device to: receive a frame from a first customer network; determine an ingress interface of to which the frame is received and an ingress virtual local area network (VLAN) identifier (ID) of the frame; perform a lookup in a forwarding table using the ingress interface and the ingress VLAN ID; determine an egress interface and an egress VLAN ID for the frame based on the lookup;and transmit the frame, with the egress VLAN ID, to the egress interface.

[0022] The network controller includes a second processor and second instmctions that, upon being executed by the second processor, cause the network to: receive a request to establish a connection between the first customer network and a second customer network; determine a first interface of a first customer edge network device of the first customer network that is connected to the network and a second interface of a second customer edge network device of the second customer network that is connected to the network; and determine one or more forwarding rules for one or more edge network devices of the network for establishing the connection based at least in part on the first interface, a first VLAN ID corresponding to the first customer network, the second interface, and a second VLAN ID corresponding to the second customer network.

[0023] At least one of the first VLAN ID or the second VLAN ID is selected by the network.

[0024] The egress interface is located on the first edge network device, and the instmctions further cause the first edge network device to: pop the ingress VLAN ID from the frame; and push the egress VLAN ID onto the frame.

[0025] The egress interface is located on the first edge network device and the ingress VLAN ID has a same value as the egress VLAN ID.

[0026] In a third aspect there is provided a non-transitory computer-readable medium having computer readable instructions that, upon being executed by one or more processors, cause a network to: receive a frame to a first edge network device of the network from a first customer network, the first edge network device being a commodity network device, the network including a Multiprotocol Label Switching (MPLS) core network; determine, by the first edge network device, an ingress interface of the first edge network device to which the frame is received and an ingress virtual local area network (VLAN) identifier (ID) of the frame; perform, by the first edge network device, a lookup in a forwarding table using the ingress interface and the ingress VLAN ID; determine, by the first edge network device, an egress interface and an egress VLAN ID for the frame based on the lookup; and transmit, by the first edge network device, the frame, with the egress VLAN ID, to the egress interface.

[0027] The egress interface is located on a first core network device of the MPLS core network, and wherein the instructions upon being executed further cause the network to: pop, by the first edge network device, the ingress VLAN ID from the frame; and push, by the first edge network device, the egress VLAN ID onto the frame; receive the frame to the first core network device; transmit the frame to one or more second core network devices; receive the frame to a second edge network device of the network from a last core network device of the one or more second core network devices; pop, by the second edge network device, the egress VLAN ID from the frame; push, by the second edge network device, a second customer VLAN ID corresponding to a second customer network; and transmit, by the second edge network device, the frame, with the second customer VLAN ID, to a customer edge network device of the second customer network.

[0028] The instructions upon being executed further cause the processor to: configure, by the network, a virtual leased line (VLL) or a virtual private local area network service (VPLS) for frames received to the egress interface of the first core network device and including the egress VLAN ID to the second edge network device.

[0029] The instructions upon being executed further cause the processor to: configure, by the network, the first edge network device to have a plurality of uplinks using fast failover group tables that are populated via a link detection protocol. The non-transitory computer-readable medium of claim 16, wherein the edge network device is compliant with OpenFlow Switch Specification version 1.30, a later version thereof, or a derivation thereof.

[0030] The term ‘comprising’ as used in this specification and claims means ‘consisting at least in part of. When interpreting statements in this specification and claims which include the term ‘comprising’, other features besides the features prefaced by this term in each statement can also be present. Related terms such as ‘comprise’ and ‘comprised’ are to be interpreted in a similar manner.

[0031] As used herein the term ‘(s)’ following a noun means the plural and/or singular form of that noun.

[0032] As used herein the term ‘and/or’ means ‘and’ or ‘or’, or where the context allows both.

[0033] To those skilled in the art to which the invention relates, many changes in construction and widely differing embodiments and applications of the invention will suggest themselves without departing from the scope of the invention as defined in the appended claims. The disclosures and the descriptions herein are purely illustrative and are not intended to be in any sense limiting. Where specific integers are mentioned herein which have known equivalents in the art to which this invention relates, such known equivalents are deemed to be incorporated herein as if individually set forth.

BRIEF DESCRIPTION OF THE DRAWINGS

[0034] In order to describe the manner in which the above-recited features and other advantages of the disclosure can be obtained, a more particular description of the principles briefly described above will be rendered by reference to specific embodiments thereof which are illustrated in the appended drawings. Understanding that these drawings depict only exemplary embodiments of the disclosure and are not therefore to be considered to be limiting its scope, the principles herein are described and explained with additional specificity and detail through the use of the accompanying drawings in which: [0035] FIG. 1 illustrates an example of a conventional network environment; [0036] FIG. 2 illustrates a conventional packet header including an encapsulated MPLS header; [0037] FIG. 3 illustrates an example of a network environment in accordance with an embodiment; [0038] FIG. 4 illustrates an example of a process for programming a control plane of a commodity network device in accordance with an embodiment; [0039] FIG. 5 illustrates an example process for forwarding traffic from an commodity network device in accordance with an embodiment; and [0040] FIG. 6 illustrates an example of a network controller in accordance with an embodiment; and [0041] FIG. 7A and FIG. 7B illustrate examples of systems in accordance with some embodiments.

DETAILED DESCRIPTION

[0042] Systems and methods in accordance with various embodiments of the present disclosure overcome one or more of the above-referenced and other deficiencies in conventional approaches for expanding a Multiprotocol Label Switching (MPLS) network. In particular, various embodiments utilize a software-defined network (SDN) controller to populate forwarding tables of commodity network devices e.g., network devices built from merchant silicon and using open-source software) located at the edges of a core of more expensive and resilient network devices. The SDN controller can program the commodity network devices’ forwarding tables, which can represent a mapping of local virtual local area network (VLAN) identifiers (IDs) to provider edge port VLAN-IDs, to transport traffic from the edges of the network into the core of the network where higher order functionality exists. In some embodiments, network uplinks can be configured in a primary-secondary model to ensure resiliency, with a first network device functioning in a primary role and a second network device functioning in a secondary role. If the first network device fails, the second network device can be used as the uplink.

[0043] In various embodiments, a provider network can expand an IP/MPLS core using commodity network devices at the edge of the provider network to connect customer networks. Upon receiving a request to establish a connection between a first customer network and a second customer network, the provider network can update a mapping of local VLAN IDs to provider edge port VLAN IDs and program the commodity network devices using push, pop, or swap VLAN operations to correctly transport traffic from the edge of the network into the core of the network where higher order functionality exists. Resiliency for the expansion network can be provided using primary/secondary network uplinks.

[0044] Referring now to the drawings, FIG. 1 illustrates an example of a conventional network environment 100. The conventional network environment 100 can include a first IP network 102a associated with a first customer that connects to a second IP network 102b associated with a second customer (collectively, “102”) via an MPLS network 104 associated with a provider. The first customer network 102a can include one or more edge network devices (e.g., switches, routers, gateways, etc.) 106a for connecting the first customer network 102a to the provider network 104, and the second customer network 102b can include one or more edge network devices 106b for connecting the second customer network 102b to the provider network 104. The edge network devices 106a and 106b (collectively, “106”) are sometimes referred to as customer edge (CE) devices. The CE devices 106 can be hosts or Layer 2 switches but, as shown in FIG. 1, are typically IP routers that establish adjacency with network devices of the provider network 104. After establishing adjacency, the CE devices 106 may distribute Layer 3 routing information to each other via network devices of the provider network 104.

[0045] The provider network 104 can include edge network devices 108a and 108b (collectively, “108”) and core network devices 110a, 110b, and 110c (collectively, “110”) that are not directly connected to any customer networks. The edge network devices 108 in the provider network 104 are sometimes referred to as provider edge (PE) devices or label edge routers (LERs), and are directly connected to the customer networks 102, such as via the CE devices 106. The PE devices 108 may exchange routing information with the CE devices 106, and store routing information for those customer networks 102 to which they are directly connected. After learning routing information from the CE devices 106, the PE devices 108 may exchange the routing information with each other.

[0046] The core network devices 110 are devices in the provider network 104 that are not directly connected to the CE devices, and are sometimes referred to as provider (P) devices or label switch routers (LSRs). The P devices 110 may function as transit devices when forwarding Layer 3 traffic between the PE devices 108. The P devices 110 may store routing information to the PE devices 108.

[0047] IP packets can be forwarded hop-by-hop in the customer IP network 102a using IP destination addresses included in IP packet headers. For example, when a network device in the customer IP network 102a receives a packet, the network device can extract a destination address from a header of the packet and search for the next hop for the destination address in a forwarding table, where longest prefix matching may be performed and the packet may be forwarded to the next hop. In FIG. 1, the CE device 106a may receive an IP packet 112a with a destination address, “11.22.33.44,” after one or more hops, determine from a routing table that the next hop for the IP packet 112a is the PE device 108a, and forward the IP packet 112b to the PE device 108a.

[0048] The PE device 108a is the point of ingress into the MPLS network 104 for the IP packet 112b. The PE device 108a determines a label 114a for the packet 112b based on a Forwarding Equivalence Class (FEC) to which the packet 112b belongs. An FEC represents a group of IP packets that are forwarded in the same manner or have similar transport requirements, i.e., forwarded over the same label-switched path (LSP) and/or receiving the same forwarding treatment.

[0049] The assignment of the packet 112b to an FEC may be performed once upon ingress into the MPLS network 104. The assignment is equivalent to configuring a tunnel or LSP. Various criteria can be used to determine the FEC of a particular packet, such as destination address prefix, class of service, application flow (requiring both source and destination addresses as well as other Network or Transport layer information), IP multicast group, VPN, etc. The label may be encapsulated in the packet header or may be carried on a Layer 2 (L2) header designed for labels, such as in Asynchronous Transfer Mode (ATM) or Frame Relay networks.

[0050] FIG. 2 illustrates a conventional packet header 200 including an encapsulated MPLS header 204. The MPLS header 204 is sometimes referred to as a shim header as it is typically encapsulated between an L2 header 202 and a Layer 3 (L3) header 206 of a packet including payload data or user data 208. The MPLS header 204 includes a 20-bit label 210, a 3 experimental (EXP) bits 212,1 bottom of stack (S) bit 214, and an 8-bit time-to-live (TTL) 216. Since the label 210 is 20 bits, each link in an MPLS network can support at most 220 LSPs. The EXP 212 bits can be used to classify traffic according to seven levels of priority and may have a similar function as the IP TOS class of service bits. The S bit 214 can be used to indicate if the MPLS label is the last label as labels can be stacked on top of other labels. The TTL 216 determines how many MPLS network devices a packet can traverse before it is discarded.

[0051] Returning to FIG. 1, after the ingress PE device 108a determines the FEC and the corresponding label 114a, the PE device inserts the label 114a into the packet 112c and forwards the packet 112c to a next hop in the MPLS network 104. The label operation performed at the ingress PE device 108a is sometimes referred to as a push.

[0052] In the MPLS network 104, the next hop is the P device 110b, which receives the packet 112c, switches the incoming label 114a with the outgoing label 114b, and forwards the packet 112d to the next hop. The label operation in the P device 110b is sometimes referred to as a swap.

[0053] The packet 112d is received by the PE device 108b, which is the point of egress from the MPLS network 104. The egress PE device 108b takes the label 114b out, and forwards the packet 112e to the customer IP network 102b. The label operation in the egress PE device 108b is sometimes referred to as a pop. The packet 112e is ultimately routed to its destination, host 116 at IP address 11.22.33.44.

[0054] Conventionally, both the PE devices 108 and the P devices 110 must support a multitude of routing protocols, such as Open Shortest Path First (OSPF), Interior Gateway Routing Protocol (IGRP), Enhanced Interior Gateway Routing Protocol (EIGRP), Intermediate System to Intermediate System (IS-IS), Routing Information Protocol version (RIPv2), BGP, Routing Information Protocol version 2 (RIPv2), and many other routing protocols. In addition, the PE devices 108 and the P devices 110 must support various label protocols, such as Tag Distribution Protocol (TDP), Label Distribution Protocol (LDP), BGP, Resource Reservation Protocol (RSVP), Constraint-based Routing Label Distribution Protocol (CR-LDP), and many other label protocols. As discussed, it may be cost prohibitive to scale up the MPLS network 104 because the number of new network devices needed for expansion of the network can increase exponentially.

[0055] In various embodiments, instead of utilizing robust and expensive network devices for expanding the MPLS network 104, commodity network devices, which are relatively inexpensive, widely available, and generally interchangeable or compatible between manufacturers, can operate as customer-facing network interfaces of an expansion network for the MPLS network 104. FIG. 3 illustrates an example of a network environment 300 in accordance with an embodiment. It should be understood that, for the network environment 300 and any environment discussed herein, there can be additional or fewer nodes, devices, links, networks, or components in similar or alternative configurations. Other embodiments with different numbers and/or types of clients, networks, nodes, cloud components, servers, software components, devices, virtual or physical resources, configurations, topologies, services, appliances, deployments, or network devices are also contemplated herein. Further, the network environment 300 can include any number or type of resources, which can be accessed and utilized by customers, clients, or tenants. The illustrations and examples provided herein are for clarity and simplicity.

[0056] The network environment 300 includes customer networks 302a, 302b, 302c, 302d, and 302e (collectively, “302”) and a provider network 318. Although each of the networks of the network environment 300 are shown to be logically separated in FIG. 3, it will be appreciated that two or more of the networks can each include nodes located in the same physical location, such as a data center, carrier hotel, colocation center, meet-me room, or other facility enabling interconnectivity between networks. For example, the enterprise associated with the customer network 302a can lease or sublease space in a colocation center that also houses hardware of the provider network 318 to physically link the enterprise’s equipment with the provider’s infrastructure. In some embodiments, a particular customer network 302n can be a separate enterprise from other customer networks 302. In other embodiments, the customer network 302n may be a separate location (e.g., campus network, data center, remote branch office network, etc.) of the same enterprise associated with one or more other customer networks 302. Further, it should be understood that the customer networks 302 can be a carrier network, a cloud service provider network, a WAN such as the Internet, or other enterprise network.

[0057] In some embodiments, a customer network 302 that is a carrier network can include proprietary network infrastructure of an Internet service provider (ISP), such as a tier 1 network (e.g., a network that can reach every other network on the Internet without having to purchase IP transit or pay settlements); a tier 2 network (e.g., a network that can peer with some networks but may purchase IP transit or pay settlements to reach at least some portion of the Internet); or a tier 3 network (e.g., a network that only purchases IP transit from other networks to participate in the Internet).

[0058] In some embodiments, a customer network 302 that is a cloud service provider network can be a computer network for providing Internet-based computing in which computing resources may be dynamically provisioned and allocated to users on-demand, from a collection of resources available via the network. The computing resources can include any type of infrastructure resource, such as a computing, storage, and/or networking instance. For example, infrastructure resources may include compute/processing devices (e.g., servers, CPUs, GPUs, random access memory, caches, etc.), storage devices (e.g., network attached storages, storage area network devices, hard disk drives, solid-state devices, etc.), or network devices (e.g., firewalls, deep packet inspectors, traffic monitors, load balancers, etc.). The cloud computing resources can also include a combination of infrastructure resources that provide users higher-level services or applications, such as a database service, software development platform, content delivery network, enterprise email system, collaboration tool, customer relationship management (CRM) software, etc.

[0059] In some embodiments, a customer network 302 can be a WAN such as the Internet. The Internet connects disparate networks throughout the world, providing global communication between nodes on various networks. The nodes typically communicate over the network by exchanging discrete frames or packets of data according to predefined protocols, such as the Transmission Control Protocol/Intemet Protocol (TCP/IP). In this context, a protocol can refer to a set of rules defining how the nodes interact with each other.

[0060] Although not shown, each of the customer networks 302 includes one or more network devices or CE devices that connect to the provider network 318. In the example of FIG. 3, each of the customer networks 302 are IP networks. In other embodiments, the customer networks may be L2 networks based on Ethernet, Token Ring, Fiber Distributed Data Interface (FDDI), ATM, Frame Relay, and Point-to-Point Protocol (PPP) or L3 networks based on Internetwork Packet Exchange (IPX) or AppleTalk.

[0061] The provider network 318 includes an MPLS core network 304, that comprises core network devices 308a, 308b, and 308c (collectively, “308”); a set of edge network device 320a, 320b, 320c, 320d, and 320e (collectively, “320”); and a network controller 322. The core network devices 308 are high-performance network devices having multiple slots, supporting multiple rack units (RU) with forwarding performance greater than 1 Gbps. Although shown in FIG. 3 as three core network devices 308, in other embodiments, the MPLS core network 304 can include one or more interconnecting switches and/or routers that may be organized according to any network topology, such as a core-aggregation-access, spine-leaf, mesh, or other suitable architecture.

[0062] The core network devices 308 are capable of supporting OSPF, MPLS, RSVP, Fast ReRoute (FRR), Virtual Private LAN Service/Virtual Leased Line (VPLS/VLL), and other protocols and services. In an embodiment, the MLX® Series of routers, from Brocade® Communications Systems, Inc. of San Jose, California, are used as the core network devices 308. The edge network devices 320 are off-the shelf commodity network devices (e.g., standard 1-rack unit (RU), 48-port switches with forwarding performance less than 1 Bpps) that have limited to no support for MPLS. In an embodiment, the VDX® Series of routers from Brocade® are used as the edge network devices 320.

[0063] The network controller 322 manages the various resources of the provider network 318. For example, the network controller 322 can provision network resources based on customer requests, schedules, triggers, events, signals, messages, alerts, agreements, subscriptions, purchases, or other factors. In addition, the network controller 322 can handle traffic and manage configuration of the network resources, including managing network routing/re-routing, network data backup, security policies, etc. In some embodiments, the network controller 322 can collect data from a customer or other interconnection fabric participant and generate configuration information for specific network deployments. For example, the network controller 322 can generate security policies, subnetting and routing schemes, forwarding schemes, network address translation (NAT) settings, virtual private network (VPN) settings, etc. The network controller 322 can push or transmit these data and settings to components of the provider network 318 to implement a particular network deployment. For example, the network controller 322 can generate VPN settings, such as IP mappings, port number, and security information, and send the VPN settings to the components of the provider network 318. A component of the provider network 318 can use the VPN settings to establish a VPN tunnel according to the settings. As another example, the network controller 322 may generate and manage network diagnostic tools or graphical user interfaces, or automate the interconnection between multiple networks and resources.

[0064] In some embodiments, the network controller 322 can deploy a network, configure links or devices, or provide other services for customers, such as network administration services, network monitoring services, content filtering services, application control, WAN optimization, firewall services, gateway services, storage services, protocol configuration services, wireless deployment services, interconnection services, network services, etc.

[0065] Moreover, as far as communications, packets (e.g., network traffic and/or messages) can be exchanged among the various nodes and networks in the network environment 300 using various network protocols. In particular, packets can be exchanged using wired protocols, wireless protocols, security protocols, Open Systems Interconnection (OSI)-Layer specific protocols, labels, or other protocols. Some non-limiting examples of protocols can include Session Initiation Protocol (SIP), protocols from the Internet Protocol Suite, such as TCP/IP; OSI (Open Systems Interconnection) protocols, such as L1-L7 protocols; routing protocols, such as RIP, IGP, BGP, STP, ARP, OSPF, EIGRP, NAT; or any other protocols or standards, such as HTTP, SSH, SSL, RTP, FTP, SMTP, POP, PPP, NNTP, IMAP, Telnet, SSL, SFTP, WIFI, Bluetooth, VTP, ISL, IEEE 802 standards, L2TP, IPSec, etc. In addition, various hardware and software components or devices can be implemented to facilitate communications both within a network and between networks. The various hardware and software components or devices can also be referred to as nodes and some examples are switches, hubs, routers, access points (APs), antennas, network interface cards (NICs), modules, cables, firewalls, servers, repeaters, sensors, and the like.

[0066] In some embodiments, the network controller 322 is an SDN controller for managing forwarding decisions of packets entering the provider network 318. In the example of FIG. 3, the network controller 322 is deployed on a centralized server or cluster of servers. In other embodiments, the network controller 322 can be deployed on a single network device and operate similar to conventional IP routing but with a common interface between the aggregate control plane and data plane of the edge network devices 320. In an embodiment, the network controller 322 may be implemented using the OpenFlow® Switch Specification version 1.3.0 (June 25, 2012) from the Open Networking Foundation of Palo Alto, California, or a later version or derivation thereof. The network controller 322 may communicate over a secure channel with the edge network devices 320 through the OpenFlow® protocol to program flow rules that control the routes of packets through the provider network 318. The flow rules comprise flow descriptions and actions. The flow descriptions are a 12-tuple of L2-L4 header fields, any of which can be wildcards. Incoming packets are matched against the flow descriptions, and if there is a match, the action (e.g., push, pop, or swap) corresponding to the matching flow description is performed on the packet. If a packet matches multiple flow descriptions, the flow rule with the highest priority is applied.

[0067] The provider network 318 provides the customer networks 302 with various network services, such as L2 point-to-point connections 324 using VLLs between two customer facing ports and L2 point-to-multipoint connections 326 using VPLS for direct peering or exchanging routing information and traffic via provider managed route servers. In the example of FIG. 3, the point-to-point connections, which may also be called virtual cross connects or VXCs, include VXC 324a between the customer networks 302a and 302b, VXC 324b between the customer networks 302c and 302e, VXC 324c between customer networks 302c and 302e. It will be appreciated that VXCs may be established between any of the customer networks 302. The point-to-multipoint connections, which may also be called Internet Exchanges or IXs, include IXs 326a, 326b, 326c, 326d, and 326e.

[0068] The provider network 318 may provide a platform or application programming interface (API) for customer networks to make requests to connect to other customer networks via VXCs 324 or IXs 326. In an example embodiment, the platform is provided by Megaport® (Services) Pty Limited of Fortitude Valley, Queensland, Australia. The Megaport® platform utilizes a representational state transfer (REST) architecture that exposes various RESTful endpoints or web services that can be accessed via uniform resource identifiers (URIs). These web services can include authentication, obtaining information about available network resources, obtaining information about other customer networks, obtaining pricing information, ordering VXCs 324 or IXs 326, and obtaining invoices, among other possibilities. Megaport® offers various graphical user interfaces (GUIs) that are built on top of the Megaport® API, such as a web portal that can be accessed by desktop and mobile web browsers, mobile applications or “apps” (e.g., Google® Android®, Apple® iOS®, Microsoft® Windows Phone®, Blackberry® OS, etc ), and desktop applications (e g., Microsoft® Windows®, Apple® Mac OS X®, Linux®, UNIX®, etc.).

[0069] Upon the network controller 322 receiving a request for establishing a VXC or IX, the network controller 322 programs the edge network devices 320 to set up forwarding for the VXC(s) or IX(s). FIG. 4 illustrates an example of a process 400 for programming the edge network devices 320 in accordance with an embodiment. It should be understood that, for any process discussed herein, there can be additional, fewer, or alternative steps performed in similar or alternative orders, or in parallel, within the scope of the various example embodiments unless otherwise stated. The process 400 may be performed by the provider network 318, and particularly, the network controller 322 or other suitable component for programming the control plane of the edge network devices 320.

[0070] The process 400 may begin with step 402 in which a first customer network requests to establish a connection with a second customer network. In some embodiments, the request may specify an interface and a VLAN ID which the first customer will use to send traffic to the second customer network. In other embodiments, the interface may be predetermined if there is only one physical connection between a port of the first customer network’s CE device and a customer facing port of an edge network device 320 of the provider network 318 and/or the network controller 322 may select a unique VLAN ID on behalf of the first customer network, which may be passed to the first customer network upon provisioning of the requested connection.

[0071] The process 400 may continue to step 404 in which the network controller 322 provides information to the second customer network regarding the first customer’s requested connection. In some embodiments, the network controller 322 or one or more components between the network controller and the client interface to the provider network 318 may send a notification to the second customer network requesting approval for the first customer network’s connection request. In other embodiments, the connection request may be provided to the second customer network by the second customer network invoking a web service or RESTful end point for viewing pending connection requests.

[0072] Upon receiving approval of the first customer’s connection request at step 406, the network controller 322 performs steps 408 and 410 to program a first control plane of a first edge network device directly connected to the first customer network’s CE device, and to program a second control plane of a second edge network device directly connected to the second customer network’s CE device, respectively. Programming the control plane may depend on how the first customer network and the second customer network are connected to the provider network 318. Table 1 is an example of a forwarding table maintained by the network controller 322 for a configuration of the provider network 318 in which a pair of customer networks connects to the provider network on the same edge network device 320. This can be seen in FIG. 3 with customer networks 302a and 302b, which connect to the provider network 318 via the edge network device 320a.

[0074] In Table 1, the ingress interface refers to the interface to which a frame is received by an edge network device 320, the ingress VLAN ID refers to the VLAN ID of the frame on arrival to the ingress interface, the egress interface refers to the interface to which the frame is forwarded or the incoming interface after the frame is forwarded, and the egress VLAN ID refers to the VLAN ID of the frame after being forwarded or the VLAN ID of the frame upon arrival to the egress interface. In the scenario of Table 1, the customer network 302a requests to send traffic to the customer network 302b via interface 0/45 of the edge network device 320a and VLAN ID 123. The customer network 302b approves the request, and specifies that the traffic of the customer network 302a should be forwarded to interface 0/47 and VLAN ID 789. As discussed, the customer networks 302a and 302b happen to be connected to the provider network 318 on the same edge network device 320a. The network controller 322 programs the edge network device 320a to accept frames tagged with VLAN ID 123 from port 0/45, which has been assigned to the customer network 302a, pop the VLAN ID 123 from the frames, push the VLAN ID 789 onto the frames, and forward the frames to port 0/47, which has been assigned to customer network 302b. For traffic from the customer network 302b to customer network 302a, the network controller 322 programs the edge network device 320a to accept frames tagged with VLAN ID 789 received to port 0/47, pop the VLAN ID 789 from the frames, push the VLAN ID 123 onto the frames, and forward the frames to port 0/45.

[0075] Table 2 is an example of a forwarding table maintained by the network controller 322 for a configuration of the provider network 318 in which a pair of customer networks connects to the provider network on different edge network devices 320. For instance, this situation may occur if the customer network 302a requests to connect to the customer network 302d. The network controller 322 may program a first portion of this forwarding table to a forwarding table of a first edge network device 320 and a second portion of the network controller’s forwarding table to a forwarding table of a second edge network device 320. In Table 2, the ingress interface refers to the interface to which a frame is received by an edge network device 320 or a core network device 308 (as indicated in parentheses), the ingress VLAN ID to the VLAN ID on arrival to the ingress interface, the egress interface refers to the interface to which the frame is forwarded or the incoming interface after the frame is forwarded (as indicated in parentheses), and the egress VLAN ID refers to the VLAN ID of the frame after being forwarded or the VLAN ID of the frame upon arrival to the egress interface.

[0076] Traffic between customer networks connected to edge network devices 320 across the MPLS core network 304 requires an additional step to differentiate customer traffic arriving on the same core network device 308. In this situation, the network controller 322 can assign an arbitrary VLAN ID to tie each customer network to a specific VLL or VPLS configuration.

[0077] Table 2: Forwarding Table for Customer Networks on Different Edge Devices

[0078] To enable traffic to flow from the customer network 302a to the customer network 302d, the network controller 322 can program the edge network device 320a to match frames from port 0/45 having VLAN ID 123 to pop the VLAN ID 123 from the frames, push the VLAN ID 2000 onto the frames, and forward the frames to port 1/4 on core network device 308c. The core network device 308c can have a VLL or VPLS configured to forward traffic arriving at port 1/4 and having VLAN ID 2000 to port 2/1 of the core network device 308a, where VLAN ID 2000 is added back onto the traffic before forwarding to the edge network device 320b. The network controller 322 can program the edge network device 320b to match frames coming into port 0/10 having VLAN ID 2000 to pop the VLAN ID 2000 from the frames, push the VLAN ID 841 onto the frames, and forward the frames to the CE device (not shown) of the customer network 302d.

[0079] For traffic from the customer network 308d to the customer network 308a, the network controller can program the edge network device 320b to match frames sent from port 0/10 having VLAN ID 841 to pop the VLAN ID 841, push the VLAN ID 2000 (or some other arbitrary VLAN ID), and forward to port 2/1 on the core network device 308a. The core network device 308a can have a VLL or VPLS defined that forwards frames coming into port 2/1 and having VLAN ID 2000 to port 1/4 on the core network device 308c, whereupon the VLAN ID 2000 is added back onto the frames before sending them out to the edge network device 320a. The network controller 322 can program the edge network device 320a to match frames coming from the core network device 308c to pop the VLAN ID 2000, push the VLAN ID 123, and forward to the CE device (not shown) of the customer network 302a.

[0080] In some situations, a first customer network and a second customer network may select the same VLAN ID for exchanging traffic between themselves. In the case where the two customer networks are connected to the provider network 318 on the same edge network device 320, the network controller 322 does not need to program that device to perform any pop and push operations. Instead, the network controller may only need to program the edge network device 320 to forward between the customer networks’ respective interfaces on the edge network device 320. In the case where the two customer networks are on separate edge network devices 320 and their traffic must traverse the MPLS core network 304, the network controller 322 may program the respective edge network devices 320 in a similar manner as discussed above with respect to FIG. 2.

[0081] To implement failover for an expansion network comprising commodity network devices, such as the provider network 318 and the edge network devices 320, Unidirectional Link Detection (UDLD) or another suitable link failure detection protocol (e.g., Device Link Detection Protocol (DLDP), Extreme Link Status Monitoring (ELSM), Link-state Tracking, Ethernet operations, administration, and maintenance (OAM), DULD, etc.) can be integrated with OpenFlow® group fast-failover tables to detect and rapidly switch flow table mappings to an alternate uplink. The network controller 322 can program the edge network devices 320 with diverse uplinks with fast failover group tables to transparently handle failover locally on each edge network device 320 without the need for the controller to detect and push new flow rules down to the edge network device.

[0082] In the MPLS core network 304, because each edge network device 320 may uplink to two core network devices 308 in different locations, the core network devices 308 each need to have identical VLL/VPLS configurations on the respective interfaces facing the downstream edge network device 320. It may be critical for the edge network device 320 to select to forward traffic toward one core network device 308 or the other to avoid creating L2 loops within the bridging domain. In some embodiments, the network controller can configure forwarding down one L2 path for some VLANs and the alternate L2 path for others. When any one path fails, only the VLANs on the failed path will be diverted to the remaining path. This can limit impact of a failed link and may also provide for an optical path where customer endpoints are known and can be pre-calculated to use the lowest latency link.

[0083] While the network controller 322 may be used to program the control plane of the edge network devices 320, data plane operations are performed by individual edge network devices. FIG. 5 illustrates an example of a process 500 for forwarding traffic from an edge network device 320 in accordance with an embodiment. The process 500 may be performed by a commodity network device, such as the edge network device 320 of FIG. 3, located at an edge of a network having an MPLS backbone network, such as the provider network 318 including the MPLS core network 304. The commodity network device may be directly connected to one or more customer networks, such as the customer networks 302, via customer edge devices. The commodity network device may be compatible with the OpenFlow® standard, and its control plane may be programmed by a SDN controller, such as the network controller 322. In particular, the SDN controller may program the commodity network devices’ forwarding tables to map the commodity network devices’ interfaces and VLAN IDs to other network devices, including MPLS core network devices, such as the core network devices 308, and other commodity network devices that are directly connected to other customer networks.

[0084] The forwarding process 500 may begin at step 502 in which a first commodity network device receives a frame from a CE device of a customer network. At step 504, the first commodity network device may process the frame and determine that the frame entered into a particular interface, i.e., an ingress interface, of the first commodity network device and that the frame includes a particular VLAN ID, i.e., an ingress VLAN ID. The process 500 may continue to conditional block 506 in which the first commodity network device performs a lookup in its forwarding table to attempt to match the ingress interface and ingress VLAN ID to a flow rule. If there is no match, the frame is dropped at step 508.

[0085] If there is a match, the process 500 proceeds to step 510 in which the first edge network device will determine whether any operations are to be performed on the frame based on the ingress interface and VLAN ID and the corresponding egress interface and VLAN ID. As discussed, in those cases in which a pair of customer networks attempting a connection are on a same edge network device, the first edge network device will pop the ingress VLAN ID from the frame and push the egress VLAN ID onto the frame unless the first customer network and the second customer network have selected the same VLAN ID. When the first customer network has selected the same VLAN ID as the second customer network, no pop and push operations are necessary because the frame already includes the egress VLAN ID. At step 512, the first edge network device forwards the frame to the egress interface with the frame tagged with the egress VLAN ID.

[0086] In those situations where the first customer network and the second customer network are connected to the provider network on different edge network devices and their respective traffic must traverse the MPLS core network, the first edge network device will pop the ingress VLAN ID and push a first core VLAN ID mapped to a first core network device. At step 512, the first edge network device will forward the frame, with the first core VLAN ID, to the egress interface for the first core network device. The first core network device will have a VLL configured for frames arriving to a specified interface and having a specified core VLAN ID to forward the frames to one or more second core network devices. The penultimate network device of the provider network processing the frame will be a core network device that forwards the frame to a second edge network device. The second edge network device will pop the core VLAN ID(s) from the frame, push the egress VLAN ID onto the frame, and forward the frame to the egress interface of a second customer network’s CE device.

[0087] In some embodiments, UDLD, DLDP, ELSM, Link-state Tracking, Ethernet OAM, DULD, or other link detection protocol can be combined with OpenFlow® group fast-failover tables to detect and switch flow table mappings to an alternate uplink. A network controller can program the commodity network devices with diverse uplinks with fast failover group tables to transparently handle failover locally on each edge network device 320 with the need for the controller to detect and push new flow rules down to the edge network device.

[0088] FIG. 6 illustrates an example of a network controller 622 in accordance with an embodiment. The network controller 622 can serve as a centralized management system for a network, such as the provider network 318 of FIG. 3. For example, the network controller 622 can perform authentication, manage network configuration, provision network resources, and monitor network traffic, among other tasks. For example, the network controller 622 can manage cloud service provisioning or deployment, such as cloud storage, media, streaming, security, or administration services. The network controller 622 can also manage VMs, containers, or virtual partitions; networks; service provisioning; virtual circuits between networks or clouds; interfaces; network ports; and so forth.

[0089] The network controller 622 can include several subcomponents, including a communication interface 628, a scheduling module 630, a networking module 632, a management layer 634, a monitoring module 636, one or more processors 638, and memory 640. The various subcomponents can be implemented as hardware and/or software components (e.g., processor, memory, modules, logic, virtual workload, data structures, etc.). Moreover, although FIG. 6 illustrates one example configuration of the various components of the network controller 622, those of skill in the art will understand that the components can be configured in a number of different ways and can include any other type and number of components. For example, the networking module 632 and the management layer 634 can belong to one software module or multiple separate modules. Other modules can be combined or further divided up into more subcomponents.

[0090] The communications interface 628 allows the network controller 622 to communicate with other devices or networks, such as customer networks 302 of FIG. 3 or other networks. The communications interface 628 can be a network interface card (NIC), and can include wired and/or wireless capabilities. The communications interface 628 allows the network controller 622 to send and receive data from other devices and networks. In some embodiments, the network controller 622 can include multiple communications interfaces for redundancy or failover. For example, the network controller 622 can include dual NICs for connection redundancy or for multiple lines or channels.

[0091] The scheduling module 630 can manage scheduling of procedures, events, services, or communications For example, the scheduling module 630 can schedule when resources should be allocated from a provider network. As another example, the scheduling module 630 can schedule when specific instructions or commands should be transmitted to network devices (e g., the network devices 308 or 320 of FIG. 3). The scheduling module 630 can provide scheduling for operations performed or executed by the various subcomponents of the network controller 622. The scheduling module 630 can also schedule resource slots, virtual machines, bandwidth, device activity, status changes, nodes, updates, policies, circuits, services, and the like.

[0092] The networking module 632 can be a module, application, appliance, logic, processor, or function capable of performing network operations. The networking module 632 can thus perform networking calculations, such as network addressing, or networking service or operations, such as auto virtual circuit configuration or traffic routing/re-routing. For example, the networking module 632 can perform filtering functions, switching functions, failover functions, high availability functions, network or device deployment functions, resource allocation functions, messaging functions, traffic analysis functions, port configuration functions, mapping functions, packet manipulation functions, path calculation functions, loop detection, cost calculation, error detection, or otherwise manipulate data or networking devices. The networking module 632 can handle networking requests from other networks or devices and establish links between devices. The networking module 632 can also perform queueing, messaging, or protocol operations.

[0093] The management layer 634 can include logic to perform management operations. For example, the management layer 634 can include the logic to allow the various components of the network controller 622 to interface and work together. The management layer 634 can also include the logic, functions, software, and procedure to allow the network controller 622 to perform monitoring, management, control, deployment, configuration, and administration operations of other devices, networks, clouds, providers, operations and/or applications, services provided to clients, or any other component or procedure. The management layer 634 can include the logic to operate the network controller 622 and perform particular services configured on the network controller 622.

[0094] Moreover, the management layer 634 can initiate, enable, or launch other instances in the network controller 622 and/or a provider network. In some embodiments, the management layer 634 can also provide authentication and security services for a provider network, customer networks, the network controller 622, and/or any other device or component. Further, the management layer 634 can manage nodes, resources, VMs or other virtual partitions, settings, policies, protocols, communications, services, clouds, datacenters, networks, and the like.

[0095] The monitoring module 636 can provide an interface or front end where customers, administrators, and other users can access, consume, purchase, configure, remove, manage, and generally monitor cloud and network services. For example, the monitoring module 636 can provide a web-based frontend where customers can configure networks that are cloud-managed, provide customer preferences, configure policies, enter data, upload statistics, configure interactions or operations, etc. As another example, the monitoring module 636 can provide an interactive display where users can interconnect their network with other networks.

[0096] The monitoring module 636 can provide visibility information, such as views of networks or devices, and even provide diagnostic information, e.g., the monitoring module 636 can provide a view of the status or conditions of the provider network, the operations taking place, services, performance, a topology or layout, specific network devices, protocols implemented, running processes, errors, notifications, alerts, network structure, ongoing communications, data analysis, etc.

[0097] The memory 640 can include any data or information, such as management data, statistics, settings, preferences, profile data, account data, transactions, logs, notifications, attributes, configuration parameters, client information, network information, and the like. For example, the network controller 622 can collect network statistics from a network device (e.g., network devices 308 or 320) and store the statistics in the memory 640. The memory 640 can also include performance and/or configuration information. This way, the network controller 622 can use such data to perform management or service operations for the managed network. The memory 640 can be a physical storage or memory device, a database, a folder, a disk, or any storage medium on the network controller 622 or accessible to the network controller 622 (e.g., directly or indirectly).

[0098] FIG. 7A and FIG. 7B illustrate systems in accordance with various embodiments. The more appropriate system will be apparent to those of ordinary skill in the art when practicing the various embodiments. Persons of ordinary skill in the art will also readily appreciate that other systems are possible.

[0099] FIG. 7A illustrates an example architecture for a conventional bus computing system 700 wherein the components of the system are in electrical communication with each other using a bus 705. The computing system 700 can include a processing unit (CPU or processor) 710 and a system bus 705 that may couple various system components including the system memory 715, such as read only memory (ROM) in a storage device 770 and random access memory (RAM) 775, to the processor 710. The computing system 700 can include a cache 712 of high-speed memory connected directly with, in close proximity to, or integrated as part of the processor 710.

The computing system 700 can copy data from the memory 715 and/or the storage device 730 to the cache 712 for quick access by the processor 710. In this way, the cache 712 can provide a performance boost that avoids processor delays while waiting for data. These and other modules can control or be configured to control the processor 710 to perform various actions. Other system memory 715 may be available for use as well. The memory 715 can include multiple different types of memory with different performance characteristics. The processor 710 can include any general purpose processor and a hardware module or software module, such as module 1 732, module 2 734, and module 3 736 stored in storage device 730, configured to control the processor 710 as well as a special-purpose processor where software instructions are incorporated into the actual processor design. The processor 710 may essentially be a completely self-contained computing system, containing multiple cores or processors, a bus, memory controller, cache, etc. A multi-core processor may be symmetric or asymmetric.

[0100] To enable user interaction with the computing system 700, an input device 745 can represent any number of input mechanisms, such as a microphone for speech, a touch-protected screen for gesture or graphical input, keyboard, mouse, motion input, speech and so forth. An output device 735 can also be one or more of a number of output mechanisms known to those of skill in the art. In some instances, multimodal systems can enable a user to provide multiple types of input to communicate with the computing system 700. The communications interface 740 can govern and manage the user input and system output. There may be no restriction on operating on any particular hardware arrangement and therefore the basic features here may easily be substituted for improved hardware or firmware arrangements as they are developed.

[0101] Storage device 730 can be a non-volatile memory and can be a hard disk or other types of computer readable media which can store data that are accessible by a computer, such as magnetic cassettes, flash memory cards, solid state memory devices, digital versatile disks, cartridges, random access memories (RAMs) 725, read only memory (ROM) 720, and hybrids thereof.

[0102] The storage device 730 can include software modules 732, 734, 736 for controlling the processor 710. Other hardware or software modules are contemplated. The storage device 730 can be connected to the system bus 705. In one aspect, a hardware module that performs a particular function can include the software component stored in a computer-readable medium in connection with the necessary hardware components, such as the processor 710, bus 705, output device 735, and so forth, to carry out the function.

[0103] FIG. 7B illustrates an example architecture for a conventional chipset computing system 750 that can be used in accordance with an embodiment. The computing system 750 can include a processor 755, representative of any number of physically and/or logically distinct resources capable of executing software, firmware, and hardware configured to perform identified computations. The processor 755 can communicate with a chipset 760 that can control input to and output from the processor 755. In this example, the chipset 760 can output information to an output device 765, such as a display, and can read and write information to storage device 770, which can include magnetic media, and solid state media, for example. The chipset 760 can also read data from and write data to RAM 775. A bridge 780 for interfacing with a variety of user interface components 785 can be provided for interfacing with the chipset 760. The user interface components 785 can include a keyboard, a microphone, touch detection and processing circuitry, a pointing device, such as a mouse, and so on. Inputs to the computing system 750 can come from any of a variety of sources, machine generated and/or human generated.

[0104] The chipset 760 can also interface with one or more communication interfaces 790 that can have different physical interfaces. The communication interfaces 790 can include interfaces for wired and wireless LANs, for broadband wireless networks, as well as personal area networks. Some applications of the methods for generating, displaying, and using the GUI disclosed herein can include receiving ordered datasets over the physical interface or be generated by the machine itself by processor 755 analyzing data stored in the storage device 770 or the RAM 775. Further, the computing system 700 can receive inputs from a user via the user interface components 785 and execute appropriate functions, such as browsing functions by interpreting these inputs using the processor 755.

[0105] It will be appreciated that computing systems 700 and 750 can have more than one processor 710 and 755, respectively, or be part of a group or cluster of computing devices networked together to provide greater processing capability.

[0106] For clarity of explanation, in some instances the various embodiments may be presented as including individual functional blocks including functional blocks comprising devices, device components, steps or routines in a method embodied in software, or combinations of hardware and software.

[0107] In some embodiments the computer-readable storage devices, mediums, and memories can include a cable or wireless signal containing a bit stream and the like. However, when mentioned, non-transitory computer-readable storage media expressly exclude media such as energy, carrier signals, electromagnetic waves, and signals per se.

[0108] Methods according to the above-described examples can be implemented using computer-executable instructions that are stored or otherwise available from computer readable media. Such instructions can comprise, for example, instructions and data which cause or otherwise configure a general purpose computer, special purpose computer, or special purpose processing device to perform a certain function or group of functions. Portions of computer resources used can be accessible over a network. The computer executable instructions may be, for example, binaries, intermediate format instructions such as assembly language, firmware, or source code. Examples of computer-readable media that may be used to store instructions, information used, and/or information created during methods according to described examples include magnetic or optical disks, flash memory, USB devices provided with non-volatile memory, networked storage devices, and so on.

[0109] Devices implementing methods according to these disclosures can comprise hardware, firmware and/or software, and can take any of a variety of form factors. Typical examples of such form factors include laptops, smart phones, small form factor personal computers, personal digital assistants, rackmount devices, standalone devices, and so on. Functionality described herein also can be embodied in peripherals or add-in cards. Such functionality can also be implemented on a circuit board among different chips or different processes executing in a single device, by way of further example.

[0110] The instructions, media for conveying such instructions, computing resources for executing them, and other structures for supporting such computing resources are means for providing the functions described in these disclosures.

[0111] Although a variety of examples and other information was used to explain aspects within the scope of the appended claims, no limitation of the claims should be implied based on particular features or arrangements in such examples, as one of ordinary skill would be able to use these examples to derive a wide variety of implementations. Further and although some subject matter may have been described in language specific to examples of structural features and/or method steps, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to these described features or acts. For example, such functionality can be distributed differently or performed in components other than those identified herein. Rather, the described features and steps are disclosed as examples of components of systems and methods within the scope of the appended claims.

Claims (19)

1. A computer-implemented method, comprising: receiving a frame to a first edge network device of a provider network from a first customer network, the first edge network device being a commodity network device, the provider network including a Multiprotocol Label Switching (MPLS) core network; determining, by the first edge network device, an ingress interface of the first edge network device to which the frame is received and an ingress virtual local area network (VLAN) identifier (ID) of the frame; performing, by the first edge network device, a lookup in a forwarding table using the ingress interface and the ingress VLAN ID; determining, by the first edge network device, an egress interface and an egress VLAN ID for the frame based on the lookup; and transmitting, by the first edge network device, the frame, with the egress VLAN ID, to the egress interface.

2. The computer-implemented method of claim 1, further comprising: receiving, by the provider network, a request to establish a connection between the first network and a second customer network; determining, by the provider network, a first interface of a first customer edge network device of the first customer network that is connected to the provider network and a second interface of a second customer edge network device of the second customer network that is connected to the provider network; and determining, by the provider network, one or more forwarding rules for one or more edge network devices of the provider network for establishing the connection based at least in part on the first interface, a first VLAN ID corresponding to the first customer network, the second interface, and a second VLAN ID corresponding to the second customer network.

3. The computer-implemented method of claim 2, wherein at least one of the first VLAN ID is selected by the first customer or the second VLAN ID is selected by the second customer.

4. The computer-implemented method of claim 2 or 3, wherein the connection is a point-to-point connection or a point-to-multipoint connection.

5. The computer-implemented method of any one of claims 1 to 4, wherein the egress interface is located on the first edge network device, and the method further comprises: popping, by the first edge network device, the ingress VLAN ID from the frame; and pushing, by the first edge network device, the egress VLAN ID onto the frame.

6. The computer-implemented method of any one of claims 1 to 5, wherein the egress interface is located on the first edge network device and the ingress VLAN ID has a same value as the egress VLAN ID.

7. The computer-implemented method of any one of claims 1 to 6, wherein the egress interface is located on a first core network device of the MPLS core network, and the method further comprises: popping, by the first edge network device, the ingress VLAN ID from the frame; and pushing, by the first edge network device, the egress VLAN ID onto the frame; receiving the frame to the first core network device; transmitting the frame to one or more second core network devices; receiving the frame to a second edge network device of the provider network from a last core network device of the one or more second core network devices; popping, by the second edge network device, the egress VLAN ID from the frame; pushing, by the second edge network device, a second customer VLAN ID corresponding to a second customer network; and transmitting, by the second edge network device, the frame, with the second customer VLAN ID, to a customer edge network device of the second customer network.

8. The computer-implemented method of claim 7, further comprising: configuring, by the provider network, a virtual leased line (VLL) or a virtual private local area network service (VPLS) for frames received to the egress interface of the first core network device and including the egress VLAN ID to the second edge network device.

9. The computer-implemented method of any one of claims 1 to 8, further comprising: configuring, by the provider network, the first edge network device to have a plurality of uplinks using fast failover group tables that are populated via a link detection protocol.

10. The computer-implemented method of any one of claims 1 to 9, wherein the edge network device is compliant with OpenFlow Switch Specification version 1.30, a later version thereof, or a derivation thereof.

11. A network comprising: a network controller; a Multiprotocol Label Switching (MPLS) core network; and a plurality of commodity network devices located at edges of the network, including a first edge network device having a processor and memory including instructions that, upon being executed by the processor, cause the first edge network device to: receive a frame from a first customer network; determine an ingress interface of to which the frame is received and an ingress virtual local area network (VLAN) identifier (ID) of the frame; perform a lookup in a forwarding table using the ingress interface and the ingress VLAN ID; determine an egress interface and an egress VLAN ID for the frame based on the lookup; and transmit the frame, with the egress VLAN ID, to the egress interface.

12. The network of claim 11, wherein the network controller includes a second processor and second instructions that, upon being executed by the second processor, cause the network to: receive a request to establish a connection between the first customer network and a second customer network; determine a first interface of a first customer edge network device of the first customer network that is connected to the network and a second interface of a second customer edge network device of the second customer network that is connected to the network; and determine one or more forwarding rules for one or more edge network devices of the network for establishing the connection based at least in part on the first interface, a first VLAN ID corresponding to the first customer network, the second interface, and a second VLAN ID corresponding to the second customer network.

13. The network of claim 12, wherein at least one of the first VLAN ID or the second VLAN ID is selected by the network.

14. The network of any one of claims 11 to 13, wherein the egress interface is located on the first edge network device, and the instructions further cause the first edge network device to: pop the ingress VLAN ID from the frame; and push the egress VLAN ID onto the frame.

15. The network of any one of claims 11 to 14, wherein the egress interface is located on the first edge network device and the ingress VLAN ID has a same value as the egress VLAN ID.

16. A non-transitory computer-readable medium having computer readable instructions that, upon being executed by one or more processors, cause a network to: receive a frame to a first edge network device of the network from a first customer network, the first edge network device being a commodity network device, the network including a Multiprotocol Label Switching (MPLS) core network; determine, by the first edge network device, an ingress interface of the first edge network device to which the frame is received and an ingress virtual local area network (VLAN) identifier (ID) of the frame; perform, by the first edge network device, a lookup in a forwarding table using the ingress interface and the ingress VLAN ID; determine, by the first edge network device, an egress interface and an egress VLAN ID for the frame based on the lookup; and transmit, by the first edge network device, the frame, with the egress VLAN ID, to the egress interface.

17. The non-transitory computer-readable medium of claim 16, wherein the egress interface is located on a first core network device of the MPLS core network, and wherein the instructions upon being executed further cause the network to: pop, by the first edge network device, the ingress VLAN ID from the frame; and push, by the first edge network device, the egress VLAN ID onto the frame; receive the frame to the first core network device; transmit the frame to one or more second core network devices; receive the frame to a second edge network device of the network from a last core network device of the one or more second core network devices; pop, by the second edge network device, the egress VLAN ID from the frame; push, by the second edge network device, a second customer VLAN ID corresponding to a second customer network; and transmit, by the second edge network device, the frame, with the second customer VLAN ID, to a customer edge network device of the second customer network.

18. The non-transitory computer-readable medium of claim 17, wherein the instructions upon being executed further cause the processor to: configure, by the network, a virtual leased line (VLL) or a virtual private local area network service (VPLS) for frames received to the egress interface of the first core network device and including the egress VLAN ID to the second edge network device.

19. The non-transitory computer-readable medium of any one of claims 16 to 18, wherein the instructions upon being executed further cause the processor to: configure, by the network, the first edge network device to have a plurality of uplinks using fast failover group tables that are populated via a link detection protocol. The non-transitory computer-readable medium of claim 16, wherein the edge network device is compliant with OpenFlow Switch Specification version 1.30, a later version thereof, or a derivation thereof.