Cisco Technology, Inc.

Rishi Chhibber

Roshan Lal

Padmanab Pathikonda

Francesco Meo

Stig Ingvar Venaas

Mankamana Prasad Mishra

Anand Kumar Singh

Lakshmi Priya Sarma

Ramakrishnan Chokkanathapuram Sundaram

Rahul Savarapu Parameswaran

Varun Manchanda

Vaibhav Dhage

Ravinder Vissapragada

Subhasri Dhesikan

Peter Psenak

Nataraj Batchu

Ann Roshini Paul

Vinay Narayana Rai

Akash Garg

Meo Francesco

Techniques are described for an adaptive CoPP that can adapt and change based on actual network control traffic rather than static CoPP rates. An aggressive CoPP can protect the CPU (route processor) of a network device, e.g., routers and switches, but may also penalize convergence and performance. An adaptive CoPP may protect CPU as well as boost convergence and performance parameters. In particular, traffic between two sites may be managed by proactively changing the thresholds of lower CoS traffic based on the CoPP utilization of various protocol/BPDU class traffic, thereby improving data plane convergence and application performance in scaled environments.

Adaptive control plane policing

In one embodiment, a method includes receiving a request to establish a path for a data stream from the first network apparatus to a second network apparatus, where the request is associated with a requested bandwidth for the data stream, and where the first network apparatus and the second network apparatus are connected by a link aggregation group including a number of physical Ethernet links, accessing bandwidth information representing a number of remaining bandwidths of the respective multiple of physical Ethernet links, determining that the requested bandwidth is not satisfied by any of the number of remaining bandwidths of the number of physical Ethernet links, and sending a response rejecting the request to establish the path.

Bandwidth awareness in a link aggregation group

This disclosure describes methods to process timing information of flows in a network. One or more processors determine a latency associated with each of one or more packets of a flow passing through a device. The one or more processors determine that the latency is greater than a baseline latency, and the one or more processors provide a message indicating at least the flow and that the latency is greater than the baseline latency.

Pinpointing sources of jitter in network flows

This disclosure describes techniques for improved multicast network telemetry implemented over multilayer switches in a PIM domain. The multilayer switches may be configured to collectively certify end-to-end flow provisioning, and to publish telemetry data certifying flow provisioning from a single notifier to an external controller host. Computational workload and network traffic for streaming data related to certifying path provisioning is kept to a minimum for each flow that needs to be certified, which also keeps compounding of network traffic for many different flows to a minimum. Moreover, since controller hosts are notified upon successful provisioning but not at other times, controller hosts can trust that the telemetric data is minimally latent, and may be relied upon to enact timely actions which produce desired outcomes.

Efficient multi-path routing flow provisioning telemetry in protocol independent multicast

In one embodiment, a method includes receiving a request to establish a path for a data stream from the first network apparatus to a second network apparatus, where the request is associated with a requested bandwidth for the data stream, and where the first network apparatus and the second network apparatus are connected by a link aggregation group including a number of physical links, accessing bandwidth information representing a number of remaining bandwidths of the respective multiple of physical links, determining that the requested bandwidth is not satisfied by any of the number of remaining bandwidths of the number of physical links, and sending a response rejecting the request to establish the path.

Techniques for utilizing Software-Defined Networking (SDN) controllers and network border leaf nodes of respective cloud computing networks to configure a data transmission route for a multicast group. Each border leaf node may maintain a respective external sources database, including a number of records indicating associations between a multicast data source, one or more respective border leaf nodes disposed in the same network as the multicast data source, and network capability information. A border leaf node, disposed in the same network as a multicast data source, may broadcast a local source discovery message to all border leaf nodes in remote networks to which it is communicatively coupled. A border leaf node may also communicate network capability information associated with one or more remote networks to a local SDN controller. The SDN controller may utilize the network capability information to configure a data transmission route to one or more destination nodes.

Automatic configuration and connection of heterogeneous bandwidth managed multicast fabrics

In one embodiment, resource availability reallocation is used in establishing one or more new designated multicast flow paths with guaranteed availability of resources currently allocated and/or used by one or more designated existing multicast flow path to allocate/use for the new designated flow path(s). These resources typically include allocated guaranteed bandwidth of a network path between two adjacent or non-adjacent nodes of the network, and possibly forwarding/processing/memory resources of a network node. One embodiment communicates multicast control messages between nodes identifying to establish a new multicast flow path with resource availability reallocation from a designated multicast flow path. In one embodiment, a Protocol Independent Multicast-Sparse Mode (PIM-SM) Join/Prune Message identifies Pruning of one or more multicast flow paths and Joining of one or more different multicast flow paths and designating resource availability reallocation from these Pruned multicast flow path(s) to these Joined multicast flow path(s).

Establishing a multicast flow path through a network using multicast resources currently associated with a different multicast flow path

In one embodiment, a first networking device associated with a switched network comprises one or more processors and one or more computer-readable media storing computer-executable instructions that, when executed, cause the one or more processors to perform acts comprising configuring, on the first networking device, a network-address-translation (NAT) rule indicating that a first multicast group is to be translated to a second multicast group. The acts further include, at least partly in response to the configuring of the NAT rule, storing the NAT rule at the first networking device, generating a message indicating the NAT rule, and sending the message to at least a second networking device associated with the switched network.

Conveying network-address-translation (NAT) rules in a network

In one illustrative example, a multicast traceroute facility for a plurality of interconnected router nodes which are configured to communicate IP multicast traffic amongst hosts is described. The multicast traceroute facility may be for use in processing a multicast traceroute batch query packet which indicates a batch of multicast traceroute queries of a batch query, for identifying a plurality of traced paths for a batch of IP multicast traffic flows. Each identified traced path may be associated with one or more links, each of which has a link metric that satisfies a requested link metric (e.g. a link bandwidth). Resources for satisfying the requested link metric may be reserved for a predetermined or specified time period. The batch of IP multicast traffic flows may be established via at least some of the interconnected router nodes according to the plurality of traced paths identified from the query packet processing.

Multicast traceroute facility with batch query processing for multiple flows and reservation of resources for requested link metrics

In service flow capability updating in a guaranteed bandwidth multicast network may be provided. First, a node may determine that a bandwidth requirement of a flow has changed to a new bandwidth value. Then, in response to determining that the bandwidth requirement of the flow has changed to the new bandwidth value, an ingress capacity value may be updated in an interface usage table for a Reverse Path Forwarding (RPF) interface corresponding to the flow. The RPF interface may be disposed on a network device. Next, in response to determining that the bandwidth requirement of the flow has changed to the new bandwidth value, an egress capacity value may be updated in the interface usage table for an Outgoing Interface (OIF) corresponding to the flow. The OIF may be disposed on the network device.

In service flow capability update in guaranteed bandwidth multicast network

In one illustrative example, a switch for use in a network fabric which includes a plurality on interconnected switches configured to facilitate communication of IP multicast traffic amongst host devices may be provided. The switch may receive, from a controller, a global set of host policies associated with the plurality of switches of the network fabric. The switch may select, from the global set of host policies, a local subset of host policies applicable to the switch. The switch may grant or deny admission of host devices to receive or send IP multicast traffic flows in the network fabric according to the selected, local subset of host policies.

Host policy management in a network fabric of interconnected switches for IP multicast traffic delivery

Multicast error detection and recovery may be provided. A join request for a multicast stream may be sent from a first network node to a second network node. The join request may be sent over a first link of a plurality of links between the first network node and the second network node. A redirect message indicating that the second network node cannot accommodate the join request may be received by the first network node from the second network node. In response to receiving the redirect message, the join request for the multicast stream may not be sent on a second link of the plurality of links by the first network node to the second network node. And in response to receiving the redirect message, an alternate upstream network node may be determined by the first network node to send the join request for the multicast stream to.

Multicast error detection and recovery

In one example embodiment, a network node of a plurality of network nodes in a multicast path is configured to provide a multicast flow from a source of the multicast flow to a receiver of the multicast flow. The network node obtains, from the receiver in a reverse direction of the multicast path, configuration instructions specifying a configuration of the multicast flow. The network node implements the configuration of the multicast flow in accordance with the configuration instructions, and provides the configuration instructions toward the source in the reverse direction of the multicast path.

Efficient configuration of multicast flows

In one illustrative example, an IP network media data router includes a spine and leaf switch architecture operative to provide IP multicast delivery of media data from source devices to receiver devices without the overhead communication with a controller. The architecture can include K spine switches, K sets of L leaf switches, M data links between each leaf switch, and a plurality of bidirectional data ports connected to each leaf switch for a guaranteed non-blocking IP multicast delivery of data. A deterministic hash function a used on both the first hop router and the last hop router to ensure the same spine node is selected for flow stitching. Accordingly, without the extra communication with a centralized controller, the right spine for establishing a multicast flow can be chosen using the deterministic hash function and the distributed resource information stored on each node.

Growing community of inventors

Dublin, CA, United States of America

Rishi Chhibber