Abstract: Embodiments described herein use APIs on network devices in a SDN enabled network to monitor the network traffic flowing through the network devices and determine an identity of the client initiating the network traffic. Specifically, the APIs provide a user application with user credentials, IP addresses, MAC addresses, and other identifying information mined from the network flows. Once the identity is found, the application may identify the client's current geographic location. The network devices may continue to monitor the network devices to identify any movement events associated with the client. In response to a movement event, the application may reallocate resources proximate to the new geographic location of the client.

Abstract: System, method, and computer program product to orchestrate software defined networking (SDN) applications, by providing a plurality of network elements in a network, each network element comprising a plurality of ingress interfaces, a plurality of egress interfaces, and a routing information base (RIB), providing, to an SDN application, an application program interface (API) to abstract properties and events of: (i) the ingress interfaces, (ii) the egress interfaces, and (iii) the RIB of a specified network element, receiving a request from the SDN application apply a function to the specified network element, the function specifying to modify: (i) a preprocessing operation on a data packet, (ii) the RIB, (iii) a post processing operation on the data packet, and (iv) the properties of the ingress interfaces, egress interfaces, and RIBs of the specified network element, and applying the function to the specified network element through the API.

Abstract: In general, techniques are described for dynamically scheduling and establishing paths in a multi-layer, multi-topology network to provide dynamic network resource allocation and support packet flow steering along paths prescribed at any layer or combination of layers of the network. In one example, a multi-topology path computation element (PCE) accepts requests from client applications for dedicated paths. The PCE receives topology information from network devices and attempts to identify paths through a layer or combination of layers of the network that can be established at the requested time in view of the specifications requested for the dedicated paths and the anticipated bandwidth/capacity available in the network. The PCE schedules the identified paths through the one or more layers of the network to carry traffic for the requested paths. At the scheduled times, the PCE programs path forwarding information into network nodes to establish the scheduled paths.

Abstract: In general, techniques are described for using routing information obtained by operation of network routing protocols to dynamically generate network and cost maps for an application-layer traffic optimization (ALTO) service. For example, an ALTO server of an autonomous system (AS) receives routing information from routers of the AS by listening for routing protocol updates outputted by the routers and uses the received topology information to dynamically generate a network map of PIDs that reflects a current topology of the AS and/or of the broader network that includes the AS. Additionally, the ALTO server dynamically calculates inter-PID costs using received routing information that reflects current link metrics. The ALTO server then assembles the inter-PID costs into a cost map that the ALTO server may provide, along with the network map, to clients of the ALTO service.

Abstract: Using the ALTO Service, networking applications can request through the ALTO protocol information about the underlying network topology from the ISP or Content Provider. The ALTO Service provides information such as preferences of network resources with the goal of modifying network resource consumption patterns while maintaining or improving application performance. This document describes, in one example, an ALTO server that intersects network and cost maps for a first network with network and cost maps for a second network to generate a master cost map that includes one or more master cost entries that each represent a cost to traverse a network from an endpoint in the first network to an endpoint in the second network. Using the master cost map, a redirector may select a preferred node in the first network with which to service a content request received from a host in the second network.

Abstract: In general, techniques are described for dynamically scheduling and establishing paths in a multi-layer, multi-topology network to provide dynamic network resource allocation and support packet flow steering along paths prescribed at any layer or combination of layers of the network. In one example, a multi-topology path computation element (PCE) accepts requests from client applications for dedicated paths. The PCE receives topology information from network devices and attempts to identify paths through a layer or combination of layers of the network that can be established at the requested time in view of the specifications requested for the dedicated paths and the anticipated bandwidth/capacity available in the network. The PCE schedules the identified paths through the one or more layers of the network to carry traffic for the requested paths. At the scheduled times, the PCE programs path forwarding information into network nodes to establish the scheduled paths.

Abstract: In general, techniques are described for enhancing the Application-Layer Traffic Optimization (ALTO) service to supplement network topological grouping with location-based groupings to account for endpoint mobility. For example, as described herein, an ALTO server maintains physical location information for a network of one or more endpoints that provides a service. A PID generator of the ALTO server aggregates the endpoints into a set of one or more PIDs based at least on the physical location information for the endpoints, wherein each PID is associated with a subset of the endpoints. The ALTO server generates network and cost maps for the ALTO service that include PID entries to identify a respective subset of the endpoints associated with each of the set of PIDs and cost entries that incorporate cost that reflect physical distances among endpoints.

Abstract: Bandwidth usage for an existing communication tunnel between a first device and second device is monitored. A determination is made that additional bandwidth is required for communication between the first network device and the second network device. A determination is made that for the addition of the additional bandwidth would exceed available bandwidth for the existing tunnel. Additional bandwidth is established between the first network device and the second network device.

Abstract: In general, techniques are described for transmitting MPLS labels over a network. More specifically, a network device such a router receives a packet to be forwarded according to a label switching protocol, such as Multi-Protocol Label Switching (MPLS). The router may determine a service instance for the packet based on a client device from which the packet originated. The network device may determine one or more services to apply to the packet based on the service instance for the packet and generate a label which having a service instance portion and a service information portion. The network device may append the label to the packet to form an MPLS-encapsulated packet, and may forward the MPLS-encapsulated packet via an output interface according to the label switching protocol.

Abstract: In general, techniques are described for using routing information obtained by operation of network routing protocols to dynamically generate network and cost maps for an application-layer traffic optimization (ALTO) service. For example, an ALTO server of an autonomous system (AS) receives routing information from routers of the AS by listening for routing protocol updates outputted by the routers and uses the received topology information to dynamically generate a network map of PIDs that reflects a current topology of the AS and/or of the broader network that includes the AS. Additionally, the ALTO server dynamically calculates inter-PID costs using received routing information that reflects current link metrics. The ALTO server then assembles the inter-PID costs into a cost map that the ALTO server may provide, along with the network map, to clients of the ALTO service.

Abstract: Using the ALTO Service, networking applications can request through the ALTO protocol information about the underlying network topology from the ISP or Content Provider. The ALTO Service provides information such as preferences of network resources with the goal of modifying network resource consumption patterns while maintaining or improving application performance. This document describes, in one example, an ALTO server that implements enhancements to the ALTO service to enable initiating incremental updates of network and cost maps to ALTO clients upon receiving status information from a content delivery network (CDN) node.

Abstract: Using the ALTO Service, networking applications can request through the ALTO protocol information about the underlying network topology from the ISP or Content Provider. The ALTO Service provides information such as preferences of network resources with the goal of modifying network resource consumption patterns while maintaining or improving application performance. This document describes, in one example, an ALTO server that intersects network and cost maps for a first network with network and cost maps for a second network to generate a master cost map that includes one or more master cost entries that each represent a cost to traverse a network from an endpoint in the first network to an endpoint in the second network. Using the master cost map, a redirector may select a preferred node in the first network with which to service a content request received from a host in the second network.

Abstract: In one example, a system includes a first computing device configured to execute a virtual machine, wherein the virtual machine is communicatively coupled to a virtual private network (VPN) via a first attachment circuit using a first set of network parameters, stop execution of the virtual machine, and create checkpoint data for the virtual machine, and a second computing device configured to execute the virtual machine, using at least some of the checkpoint data, and to cause the virtual machine to become communicatively coupled to the VPN via a second attachment circuit using a second set of network parameters different from the first set of network parameters. The system may further include a first provider edge (PE) routing device communicatively coupled to the first computing device via the first attachment circuit, and a second PE routing device communicatively coupled to the second computing device via the second attachment circuit.

Abstract: In general, techniques are described for providing feedback loops for service engineered paths. A service node comprising an interface and a control unit may implement the techniques. The interface receives traffic via a path configured within a network to direct the traffic from an ingress network device of the path to the service node. The control unit applies one or more services to the traffic received via the path and generates service-specific information related to the application of the one or more services to the traffic. The interface then sends the service-specific information to at least one network device configured to forward the traffic via the path so that the at least one network device configured to forward the traffic via the path is able to adapt the path based on the service-specific information.

Abstract: In one embodiment, a particular device in a computer network maintains a locally owned tunnel-state table, and joins a distributed hash table (DHT) ring. In addition, the locally owned tunnel-state table is shared with other devices of the DHT ring to establish a DHT-owned tunnel-state table. The particular device (and other devices) determines ownership of link-state advertisements (LSAs) for a specific portion of a traffic engineering database (TED) according to the DHT ring. As such, when the particular device (or any device) computes a path for a tunnel using a local TED, the particular device may request permission to use resources along the computed path that were advertised in particular LSAs from owners of those particular LSAs when not owned by the particular device.

Abstract: In one example, a network device receives a packet to be forwarded according to a label switching protocol, determines a service to be performed on the packet by a service network device, sends a label request message to the service network device, wherein the label request message indicates support for labels having a particular length, wherein the particular length is larger than twenty bits (e.g., forty bits), and wherein the label request message specifies the service to be performed on the packet, receives, in response to the label request message, a label mapping message defining a label of the particular length, appends the label to the packet to form a Multi-Protocol Label Switching (MPLS)-encapsulated packet, and forwards the MPLS-encapsulated packet according to the label switching protocol.

Abstract: Using the ALTO Service, networking applications can request through the ALTO protocol information about the underlying network topology from the ISP or Content Provider. The ALTO Service provides information such as preferences of network resources with the goal of modifying network resource consumption patterns while maintaining or improving application performance. This document describes, in one example, an ALTO server that implements enhancements to the ALTO service to enable initiating incremental updates of network and cost maps to ALTO clients upon receiving status information from a content delivery network (CDN) node.

Abstract: A software reload is executed. The hardware associated with the network device continues to forward network traffic during the software reload. Also, a kernel of the network device operates unaffected in a protected address space throughout the software reload. Further, the kernel preserves local checkpointed and shared memory data. Application processes running on the network node are shut down gracefully. The reloaded software is brought up and the network device is resynchronized.

Abstract: In one embodiment, a method comprises receiving a request for a distributed service, the distributed service offered by a service provider via a data communications network having service delivery locations reachable via a prescribed physical topology; identifying the service delivery locations within a prescribed logical topology overlying the prescribed physical topology, the prescribed logical topology segregating the distributed service from other network traffic on the prescribed physical topology; and identifying one or moreof the service delivery locations optimized for providing the distributed service to at least one service consumption location in the prescribed logical topology according to a prescribed service level agreement with the service provider.

Abstract: In general, techniques are described for distributing traffic engineering (TE) link information across network routing protocol domain boundaries using a routing protocol. In one example, a network device logically located within a first routing protocol domain includes a routing protocol module executing on a control unit to execute an exterior gateway routing protocol. The routing protocol module of the network device receives an exterior gateway routing protocol advertisement from a router logically located within a second routing protocol domain and decodes traffic engineering information for a traffic engineering link from the exterior gateway routing protocol advertisement. A path computation module of the network device computes a traffic engineered path by selecting the traffic engineering link for inclusion in the traffic engineered path based on the traffic engineering information.