Juniper Networks, Inc.

Peyush Gupta

Rajneesh Kumar

Srivathsa Sarangapani

Amit Agarwal

Sanjay Kumar Gupta

Bharat Dhaker

Dipankar Barman

Shreelan Savyasachi Panikkassery

Amit Kumar Agarwal

In some implementations, a network device may determine throughput rate metrics for a plurality of processing units of the network device that are processing network traffic of a network. The network device may maintain the throughput rate metrics in a status table associated with the plurality of processing units. The network device may receive tunnel traffic associated with a particular tunnel of the network. The network device may determine, based on a characteristic of the tunnel traffic, a potential throughput rate associated with processing the tunnel traffic. The network device may direct the tunnel traffic to a particular processing unit, of the plurality of processing units, based on the potential throughput rate and the throughput rate metrics indicated in the status table.

Tunnel processing distribution based on traffic type and learned traffic processing metrics

A first device may provide, periodically throughout a test session and to neighboring devices that are in a network with the first device, a message request for measuring network performance. The neighboring devices, upon receiving the request message, are to use a relay mechanism to determine network performance indicator (NPI) values. The first device may receive, from the neighboring devices and periodically throughout the test session, a response message that includes the NPI values. The first device may determine additional NPI values that measure the network performance between the first device and the neighboring devices. The first device may determine overall NPI values based on the NPI values and the additional NPI values. The first device may identify a preferred next-hop to one of the neighboring devices based on the overall NPI values, where the preferred next-hop is part of a preferred path through the network.

Network performance monitoring using an active measurement protocol and relay mechanism

In general, the disclosure describes techniques for adaptively determining one or more parameters of a service level agreement of an application. For instance, a network device may monitor round-trip times of a plurality of packets of a data flow of an application being transmitted over a link between an application server and a client device. The network device may determine an amount of retransmission of packets occurring during transmission of the plurality of packets of the data flow. The network device may predict, based at least in part on the round-trip times of the plurality of packets of the data flow and the amount of retransmission of packets occurring during transmission of the plurality of packets of the data flow, a round-trip time parameter for a service level agreement associated with the application.

Dynamic prediction and management of application service level agreements

This disclosure describes techniques that include adding information to a network service header in packets being processed by a set of compute nodes in a service chain. The information added to the network service header can be used during selection of the next hop in a service chain, and may be used to help ensure that service level agreements (SLA) are met with respect to one or more metrics. In one example, this disclosure describes a method that includes receiving, by a service complex having a plurality of service nodes, a packet associated with a service chain representing a series of services to be performed on the packet by one or more of the plurality of service nodes; identifying, by the service complex, one or more service chain constraints associated with the service chain; and modifying the packet, by the service complex, to include information about the service chain constraints.

SLA packet steering in network service function chaining

This disclosure is related to devices, systems, and techniques for using a Domain Name System (DNS) server to identify one or more network devices capable of operating according to a protocol. For example, a DNS system device includes a memory and one or more processors implemented in circuitry. The one or more processors are configured to receive, from a client device, a DNS query including a specification of a hostname and a request for an MP-TCP capability, determine, using the memory, at least one IP address corresponding to the hostname and corresponding to one of the devices that is MP-TCP capable, and send, to the client device, a DNS response including an indication of the at least one of the IP addresses.

Using DNS to communicate MC-TCP capability of server devices

In general, the disclosure describes techniques for programming a forwarding plane of a network device to cause the forwarding plane to load balance or otherwise direct packet flows to particular central processing unit (CPU) cores among a plurality of CPU cores. For example, a network device includes a control unit comprising processing circuitry in communication with a memory, wherein the processing circuitry is configured to execute one or more processes. Additionally, the network device includes a forwarding unit comprising an interface card, a packet processor, and a forwarding unit memory. The one or more processes of the control unit are configured for execution by the processing circuitry to configure the forwarding unit memory of the forwarding unit with one or more forwarding path elements, where the one or more forwarding path elements map a packet flow to a CPU core of the plurality of CPU cores for processing.

Network traffic steering among CPU cores using forwarding path elements

Techniques are described for extending a two-way active measurement protocol (TWAMP) to enable measurement of service key performance indicators (KPIs) in a software defined network (SDN) and network function virtualization (NFV) architecture. The TWAMP extensions enable control messaging to be handled by a TWAMP control client executed on a centralized controller, and data messaging to be handled by a TWAMP session initiator executed on a separate network device. Techniques are also described for extending TWAMP to enable measurement of any of a plurality of service KPIs for a given service supported at a TWAMP server. The service KPIs may include one or more of keepalive measurements, round trip time measurements, path delay measurements, service latency measurements, or service load measurements. The TWAMP extensions for the service KPIs may be used in both conventional network architectures and in SDN and NFV architectures.

Monitoring services key performance indicators using TWAMP for SDN and NFV architectures

Techniques are described for performing subscriber aware two-way active measurement protocol (TWAMP) data session provisioning between two endpoints in a computer network. For example, the disclosed techniques include extending TWAMP control messaging to include a communication mode for negotiating subscriber-aware TWAMP data monitoring. If the communication mode is supported by both endpoints, a subscriber identifier is specified when a TWAMP data session is provisioned (negotiated) over the control session. The disclosed techniques further include extending TWAMP data messaging to include the subscriber identifier in each test packet for the data session. In this way, each of the endpoints may identify a subscriber corresponding to one or more received TWAMP test packets based on the subscriber identifier included in the received TWAMP test packets.

Subscriber-aware TWAMP data monitoring in computer networks

Selecting and monitoring a plurality of services key performance indicators using TWAMP

A device may establish a communication session, with a client device, for monitoring a latency of a service. The device may receive, from the client device, a request for a monitored service list. The monitored service list may identify one or more services for which service latency monitoring is supported. The device may provide, to the client device, the monitored service list. The device may receive, from the client device, a service latency monitoring session request that may identify the service to be monitored. The device may establish, with the client device, the service latency monitoring session based on the service latency monitoring session request. The device may cause the service to be performed. The device may generate information for determining the latency of the service. The device may transmit, to the client device and via the service latency monitoring session, the information for determining the latency of the service.

Growing community of inventors

Bengaluru, India

Peyush Gupta