Abstract: A verifier peer system transmits a request to an application of another peer system to obtain integrity data of the application. In response to the request, the verifier peer system obtains a response that includes kernel secure boot metrics of the other peer system and integrity data of the application and of any application dependencies. If the verifier peer system determines that the response is valid, the verifier peer system evaluates the integrity data and the kernel secure boot metrics against a set of Known Good Values to determine whether the integrity data and the kernel secure boot metrics are valid. If the integrity data and the kernel secure boot metrics are valid, the verifier peer system determines that the other peer system is trustworthy.

Abstract: A server that includes a graphics processing unit (GPU) may receive, from a first application that is remote from the server, a first request to reserve a first number of cores of the GPU for a first amount of time. The server may also receive, from a second application that is also remote from the server, a second request to reserve a second number of cores of the GPU for a second amount of time that at least partly overlaps the first amount of time. The server may determine that the first request is associated with a higher priority than the second request and, in response, may reserve the first number of cores for the first amount of time for the first application. The server may send, to the first application, an indication that the first number of cores have been reserved as requested by the first application.

Abstract: Techniques and mechanisms for automatically identifying counters/features of a network component that are related to a state change (or event) for the network component or for the network itself. For example, using data obtained from the network component around a time of the state change, delta averages for the features around the time of the state change may be determined. The delta averages may be utilized to determine which counters/features are most descriptive for a particular state change. The counter/features that are the most descriptive for a particular state change is as important as the change detection itself. This is especially true since in a case of an event/state change occurring, a large amount of counters/features may react to the state change or event. Thus, the techniques described herein provide for an approach to distill which counters/features contribute the most to a particular state change from a data driven perspective.

Abstract: This disclosure describes various methods, systems, and devices related to identifying path changes of data flows in a network. An example method includes receiving, at a node, a packet including a first path signature. The method further includes generating a second path signature by inputting the first path signature and one or more node details into a hash function. The method includes replacing the first path signature with the second path signature in the packet. The packet including the second path signature is forwarded by the node.

Abstract: In one embodiment, network operations are improved by performing updating operations data in an operations data field associated with the header of a particular protocol during the processing of a different protocol. A particular multiple-protocol (MP) packet is received by a particular network node in a network. The particular MP packet includes multiple protocol headers, including a first protocol header associated with a first protocol and a second protocol header associated with a second protocol. Further, the second protocol header associated with a second operations data field. During protocol processing of the first protocol on the particular MP packet, the second operations data field updated with particular operations data. The particular MP packet is sent from the particular network node, with said sent particular MP packet including said updated second operations data field with particular operations data.

Abstract: This disclosure describes various methods, systems, and devices related to identifying an issue in a network using a probe packet. An example method includes identifying an expired data packet transmitted in a network and addressed to a destination; generating a probe packet addressed to the destination; and forwarding the probe packet. When the probe packet is received, a report indicating a routing loop in the network can be transmitted to an administrator.

Abstract: Embodiments of the disclosure pertain to activating in-band OAM based on a triggering event. Aspects of the embodiments are directed to receiving a first notification indicating a problem in a network; triggering a data-collection feature on one or more nodes in the network for subsequent packets that traverse the one or more nodes; evaluating a subsequent packet that includes data augmented by the data collection feature; and determining the problem in the network based on the data augmented to the subsequent packet.

Abstract: Disclosed is a method of establishing secure communications. The method includes receiving an attestation parameter associated with a first peer in a potential peer-to-peer communication, adding the attestation parameter to an MACsec Key Agreement (MKA) protocol key exchange, transmitting the key exchange from the first peer to a second peer in the potential peer-to-peer communication and upon a validation of the attestation parameter by the second peer, enabling secure communication between the first peer and the second peer.

Abstract: In one embodiment, nodes use in-band operations data (e.g., carried in iOAM data field(s)) to signal departures in the processing of a packet in a network. A “departure” refers to a divergence or deviation, as from an established rule, plan, or procedure. Departures include, but are not limited to, sending a packet over a backup path (thus, a departure/deviation from sending over a primary path); offload processing of a packet (thus, a departure/deviation from processing of a packet by an application processing apparatus); and exception or punting/slow/software path processing of a packet (thus, a departure/deviation from normal or fast/hardware path processing of a packet). In one embodiment, a proof of transit validation apparatus uses departure information to select among multiple possible verification secrets, with the selected verification secret used in validation processing with a cumulative secret value obtained from the packet.

Abstract: In one embodiment, in-band operations data included in packets being processed is used to signal among entities of a virtualized packet processing apparatus. Using in-band operations data provides insight on actual entities used in processing of the packet within the virtualized packet processing apparatus. The operations data in the packet is modified to signal a detected overload condition of an entity that participates in communicating the packet within the virtualized packet processing apparatus and/or applying a network service to the packet. An In-Situ Operations, Administration, and Maintenance (IOAM) header is used in one embodiment, with the IOAM header typically including a new Overload Flag to signal the detection of the overload condition. In response to the signaled overload condition, a load balancer is adjusted such that future packets are not distributed to the virtualized entity associated with the detected overload condition.

Abstract: This disclosure describes various methods, systems, and devices related to identifying path changes of data flows in a network. An example method includes receiving, at a node, a packet including a first path signature. The method further includes generating a second path signature by inputting the first path signature and one or more node details into a hash function. The method includes replacing the first path signature with the second path signature in the packet. The packet including the second path signature is forwarded by the node.

Abstract: In one embodiment, in-band operations data (e.g., In-situ Operations, Administration, Maintenance and/or other operations data) is added to Seamless Bidirectional Forwarding (S-BFD) packets. In one embodiment, a S-BFD packet received by a node includes a BFD discriminator and operations data. Reactive processing is identified based on the BFD discriminator. The S-BFD packet and the operations data (e.g., in an operations data field in a header of the received S-BFD packet, in an IOAM Type-Length-Value (TLV), etc.) is processed according to the identified reactive function. Examples of these reactive actions include, but are not limited to, determining a result based on processing of said particular operations data by the local node or a remote analytics server, and sending a response packet including unprocessed and/or a result of the processed operations data (e.g., performance, loss, jitter, an indication of compliance with a service level agreement, and/or another data measurement or result).

Abstract: In one embodiment, network nodes coordinate recording of In-Situ Operations, Administration, and Maintenance (IOAM) data in packets traversing the network nodes, including a node adding IOAM data of another node to packets on behalf of the another node. After receiving a particular packet, a network node adds first IOAM data and second IOAM data to the particular packet, with the first IOAM data related to the first network node and the second IOAM data related to a second network node. The packet is then sent from the first network node. The coordinated offloading of the adding of IOAM data to packets allows a node to free up resources currently used for IOAM operations to be used for other packet processing operations, while still having IOAM data related to the node recorded in packets. The coordinated offloading may include control plane communication (e.g., via a routing or other protocol).

Abstract: Techniques and mechanisms for automatically identifying counters/features of a network component that are related to a state change (or event) for the network component or for the network itself. For example, using data obtained from the network component around a time of the state change, delta averages for the features around the time of the state change may be determined. The delta averages may be utilized to determine which counters/features are most descriptive for a particular state change. The counter/features that are the most descriptive for a particular state change is as important as the change detection itself. This is especially true since in a case of an event/state change occurring, a large amount of counters/features may react to the state change or event. Thus, the techniques described herein provide for an approach to distill which counters/features contribute the most to a particular state change from a data driven perspective.

Abstract: Techniques and mechanisms for automatically identifying counters/features of a network component that are related to a state change (or event) for the network component or for the network itself. For example, using data obtained from the network component around a time of the state change, delta-averages for the counters/features around the time of the state change may be determined. The delta-averages may be utilized to determine which counters/features are most descriptive for a particular state change. Determining which counters/features are most descriptive may also include determining which counters/features are most relevant, i.e., counters/features that contribute most to preserving the manifold structure of the original data or counters/features with the highest or lowest correlation with the other counters/features in the data set.

Abstract: In one embodiment, a service chain data packet is instrumented as it is communicated among network nodes in a network providing service-level and/or networking operations visibility. The service chain data packet includes a particular header identifying a service group defining one or more service functions, and is a data packet and not a probe packet. A network node adds networking and/or service-layer operations data to the particular service chain data packet, such as, but not limited to, in the particular header. Such networking operations data includes a performance metric or attribute related to the transport of the particular service chain packet in the network. Such service-layer operations data includes a performance metric or attribute related to the service-level processing of the particular service chain data packet in the network.

Abstract: A method is provided that is performed by a network element in a network. The network element receives a packet. The network element inserts into a header of the packet, packet replication information indicating whether and to which egress interface the network element performs a replication operation on the packet, wherein the header is an In-Situ Operations, Administration and Management (IOAM) header. The network element sends the packet, with the packet replication information included in the IOAM header, in the network.

Abstract: In one embodiment, improved operations processing of multiple-protocol packets is performed by a node connected to a network. Received is a multiple-protocol (MP) packet that has multiple protocol headers, each having an operations data field. The operations data field of a first protocol header includes first protocol ordered operations data. Operations data is cohered from the operations data field of each of multiple protocol headers into the operations data field of a second protocol header resulting in the operations data field of the second protocol header including ordered MP operations data evidencing operations data of each of the multiple network nodes in a node traversal order taken by the MP packet among multiple network nodes. The ordered MP operations data includes said first protocol ordered operations data cohered from the operations data field of the first protocol header.

Abstract: In one embodiment, in-band operations data (e.g., In-situ Operations, Administration, Maintenance and/or other operations data) is added to Seamless Bidirectional Forwarding (S-BFD) packets. In one embodiment, a S-BFD packet received by a node includes a BFD discriminator and operations data. Reactive processing is identified based on the BFD discriminator. The S-BFD packet and the operations data (e.g., in an operations data field in a header of the received S-BFD packet, in an IOAM Type-Length-Value (TLV), etc.) is processed according to the identified reactive function. Examples of these reactive actions include, but are not limited to, determining a result based on processing of said particular operations data by the local node or a remote analytics server, and sending a response packet including unprocessed and/or a result of the processed operations data (e.g., performance, loss, jitter, an indication of compliance with a service level agreement, and/or another data measurement or result).

Abstract: Embodiments of the disclosure pertain to activating in-band OAM based on a triggering event. Aspects of the embodiments are directed to receiving a first notification indicating a problem in a network; triggering a data-collection feature on one or more nodes in the network for subsequent packets that traverse the one or more nodes; evaluating a subsequent packet that includes data augmented by the data collection feature; and determining the problem in the network based on the data augmented to the subsequent packet.