Juniper Networks, Inc.

Rtbrick Inc.

Other

Hannes Gredler

David Delano Ward

Jan Medved

Shraddha Hegde

Pushpasis Sarkar

Pravin S Bhandarkar

Santosh Pallagatti Kotrabasappa

Hendrikus G P Bosch

Nischal Sheth

John E Drake

Colby Barth

Scott Ferguson

Deepak J Gowda

Satish Raghunath

Ina Minei

Harish Raghuveer

Kireeti Kompella

Yakov Rekhter

John Galen Scudder

Chandrasekar Ramachandran

Zhaohui Zhang

Nitin Bahadur

Harish Sitaraman

Joel Abraham Obstfeld

Sameer Seth

Balaji Rajagopalan

Avneesh Sachdev

Deepak J

Leonard Anthony Giuliano

Ambrose Kwong

A policy server may include a policy parser that is communicably coupled to a configuration database. The policy parser may identify a policy data model in the configuration database associated with a policy. The policy data model may include a policy object expressed in a human-readable format. The policy server may include a policy engine for constructing a dynamic acyclic graph (DAG) representing the policy data model. The policy engine may include a code generation engine for parsing the DAG to generate code in a high-level language. The policy engine may include a compiler for compiling the generated code to generate binaries for implementing the policy. The policy server may include a policy dispatcher for generating a notification to a policy client to dispatch the binaries to at least one subscriber of the policy following the code being compiled. The policy server may asynchronously update the policy for the subscribers.

Extensible plug-n-play policy decision framework for network devices using ahead of time compilation

Disclosed herein is a distributed, modular and highly available routing apparatus that is enabled to perform IP, MPLS VPN v4 and v6 services. The routing apparatus comprises a plurality of functional modules selected from the group consisting of a processor, a data storage module, an input/output module, a shared memory, and a network module. Each functional module is driven by a software architecture comprising a TCP/IP stack, a protocol serializer, a protocol de-serializer, an in-memory data store and one or more utility applications. The software architecture is stored partially or completely in the user space of the operating system of the routing apparatus.

Method to build a modular distributed network device using microservices architecture

Systems and methods of the present disclosure are directed to defining a data store format for storing state information related to border-gateway protocol (BGP) routing information base (RIB) entries, BGP Neighbor Tables, intermediate system-intermediate system (IS-IS) adjacencies, Link-State Databases, Interface information, Chassis information, etc in a binary format. A brick data store (BDS) system can define tables, table properties, objects and attributes for an application in the system using configuration files expressed in Java Script Object Notation (JSON). The data format can be uniform across inter-process communication, file and in-memory representation.

System and methods for defining object memory format in memory and store for object interactions, manipulation, and exchange in distributed network devices

In general, techniques are described for extending routing protocol advertisements to include respective attributes of constituent links of an aggregation group. In one example, a network device includes a management interface that receives configuration information that specifies first and second constituent links for a layer two (L2) aggregated interface. The first and second constituent links are physical links connected to respective physical interfaces of forwarding units of the network device. A routing protocol daemon of the control unit generates a link state message that specifies layer three (L3) routing information associated with the aggregated interface and further specifies an attribute of the first constituent link and an attribute of the second constituent link. The routing protocol daemon sends the link state message from the network device to another network device of the network in accordance with a routing protocol.

Advertising with a layer three routing protocol constituent link attributes of a layer two bundle

An example method includes selecting, by a network device, a remote LFA next hop as an alternate next hop for forwarding network traffic from the network device to a destination, wherein the selected remote LFA next hop provides node protection to a primary next hop node on the shortest path from the network device to the destination. The method includes, for each candidate remote LFA next hop, performing a forward shortest path first (SPF) computation having the respective candidate remote LFA next hop as a root to compute a path segment between the respective candidate remote LFA next hop and the destination, wherein each of the candidate remote LFA next hops is the egress of a respective potential repair tunnel between the network device and candidate remote LFA next hop, and selecting the remote LFA next hop based at least in part on the computed path segments.

Node-protection and path attribute collection with remote loop free alternates

In general, techniques are described for reducing or otherwise preventing micro-loops in network using Source Packet Routing in Networking (SPRING). In some examples, a method includes detecting a failure of a communication by a network device that implements a Source Packet Routing in Networking (SPRING) protocol to forward network packets using node labels according to an initial network topology. Responsive to detecting the failure of the communication link, the network device may apply, for a defined time duration, one or more adjacency labels to network packets to define a set of one-hop tunnels corresponding to a backup sub-path that circumvents the failed communication link. Upon expiration of the defined time duration, the network device may forward, according to a new network topology that is not based on applying the one or more adjacency labels that define the set of one-hop tunnels, network packets destined for the destination network device.

Micro-loop prevention using source packet routing

In general, techniques are generally described for reducing or preventing transient black-holing of network traffic in an overlay network. A method includes executing, by a network device included in a link state domain, an Interior Gateway Protocol (IGP) to exchange link-state messages with at least one remote network device in the link-state domain; generating, by the network device, an IGP link-state message that includes link overload information to overload a link in the link-state domain that couples the network device to the remote network device; and sending, by the network device and to the at least one other network device, the IGP link-state message that includes the link overload information to direct the remote network device to stop sending network traffic to the network device using the overloaded link.

Overload functionality in overlay networks

Techniques are described for providing node protection in a Source Packet Routing in Networking (SPRING) network. In some examples, a first network device, responsive to detecting a configuration request to provide node protection to a second network device that is adjacent to the first network device: generate at least one context table; configure at least one forwarding entry that indicates: a primary path between the first network device and a third network device, and a backup path, based at least in part on the at least one context table, between the first network device and the third network device that bypasses the second network device; while the second network device has not failed, forward network packets to the third network device using the primary path; and responsive to determining that the second network device has failed, forward network packets to the third network device using the backup path.

Node protection for stacked labels

In general, techniques are described for managing content request referrals by keying content requests to a composite key data structure that maps end-user address prefixes and content identifiers to content delivery network servers of downstream CDNs. In one example, a CDN exchange includes a communication module to receive first network prefixes and first content identifiers from a first secondary content delivery network and to receive second network prefixes and second content identifiers from a second secondary content delivery network. A request router of the CDN exchange redirects the content request to the first secondary content delivery network or to the second secondary content delivery network according to a network address of the end user device and a content identifier for the content request.

Content delivery network referral

In general, techniques are generally described for reducing or preventing transient black-holing of network traffic in an overlay network. A first customer edge (CE) network device positioned in a first customer network may be configured to perform the techniques. The first CE network device may comprise a control unit configured to execute an instance of a network protocol to detect faults between the first CE network device and a second CE network device positioned in a second customer network. The first CE network device may also comprise an interface configured to transmit a message to the second CE network device via the instance of the network protocol signaling that a provider edge (PE) network device is going to become nonoperational. The PE network device may be positioned in an intermediate network providing interconnectivity between the first customer network and the second customer network.

Overload functionality in overlay networks using fault detection protocols

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.

Advertising traffic engineering information with the border gateway protocol for traffic engineered path computation

Mechanisms are described by which link state 'path' information can be collected from networks and shared with external components, such as routers or centralized controllers or path computation elements, using an exterior gateway protocol, such as the Border Gateway Protocol. That is, the link state information for multiple interior gateway protocol (IGP) routing domains is shared between external components using the exterior gateway protocol, such as BGP. As such, the techniques described herein allow link state information to be shared across different routing domains, such as routing and reachability information shared between different autonomous systems. The extensions described herein allow an exterior gateway protocol to be used to signal explicit path segments within IPG routing domains so as to set up an overall path that spans the multiple IPG routing domains.

BGP link-state extensions for segment routing

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.

Growing community of inventors

Pillberg, Austria

Hannes Gredler