Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: Techniques are described for backup service function notification and synchronization. For example, a network system comprises: a plurality of service functions; a computing device comprising a service function classifier configured to: classify a packet to a service function chain including the plurality of service functions; determine backup service function(s) for an active service function of the service function chain; encapsulate the packet with a network service header, wherein the network service header includes backup service function information identifying one or more computing devices that host the backup service function(s); and send the packet encapsulated with the network service header to a computing device that hosts the active service function to enable the computing device that hosts the active service function to send, based at least on the backup service function information, state information for the active service function with the one or more backup service functions.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.