ENVIRONMENTAL-IMPACT EXTENSIONS FOR TRACEROUTE AND PING

The computer network diagnostic facilities traceroute and ping are arguably some of the most used networking troubleshooting tools. Augmenting those facilities to present environmental and sustainability data and metadata would contribute to gain visibility on “green metrics” on the Internet, an objective mentioned in the Internet Engineering Task Force (IETF) E-Impact initiative. Techniques are presented herein that support Environmental-Impact extensions (or “E-Impact” extensions for short) to both traceroute and ping. The presented extensions are backwards compatible and potentially provide per-hop (e.g., per networking topological node) power metrics, estimated greenhouse gas (GHG) emission numbers, and potentially other current or future sustainability metrics. Aspects of the presented techniques support a combination of in-packet (e.g., Internet Control Message Protocol (ICMP) extensions) plus out-of-band (e.g., out of band database lookup or application programming interface (API) calls from a host) methods that, together, yield the above-described new metrics. The presented techniques are useful not only in a transactional setting (e.g., a user desired to find some information so they issue a traceroute or a ping request) but they may also be run periodically in a mesh across the Internet or across an administrative domain to map out environmental-impact metrics, including energy usage, power and normalized power, and estimated GHG emissions

SELF-ADAPTIVE ANOMALY DETECTION WITH DEEP REINFORCEMENT LEARNING AND TOPOLOGY

In the networking field, network topology is one of the most important perspectives as it can bring additional insights to the modeling process. Existing anomaly detection approaches do not take topology information into consideration. To address such limitations techniques are presented herein that support deep Convolutional Neural Network (CNN) modeling with Reinforcement Learning (RL) employing, for example, an Advantage Actor Critic (A2C) algorithm. Additionally, aspects of the techniques presented herein support an innovative new way to model a customer profile that leverages topology information

SRV6/BITMASK DATAPLANE SIGNALED SEAMLESS FAAS/SERVERLESS FUNCTION DEPLOYMENT

Presented herein are techniques through which a list of functions (FUNC) that are to be invoked in a system may be carried as part of a Segment Routing for Internet Protocol version 6 (SRv6) micro-Segment Identifier (uSID) or a bitmask in an interesting packet. A first packet may be used to invoke the functions and, once invoked, a more specific entry for the address can be instantiated in a forwarding table so as to avoid attempting to invoke the same functions for subsequent packets

INTENT-AWARE FLOW REDIRECT USING SINGLE-HOP INTERNET CONTROL MESSAGE PROTOCOL (ICMP) EXTENSION

Techniques presented herein provide for a Control Agent that monitors flow distribution and Smart Network Interface Card (sNIC) capability and utilizes a simple Internet Control Message Protocol (ICMP) extension to instruct upstream node(s) to redirect traffic over other sNIC connected link(s). The techniques may be utilized for both Layer 2 (L2) and Layer 3 (L3) links and may provide a novel mechanism to leverage an sNIC for flow-based/intent-based/capability-aware load balancing and/or policy-balancing

SECURE AND FULLY TRANSPARENT ROAMING FOR LONG RANGE

Roaming with Long Range wide-area network (LoRaWAN) requires connections to home Network Servers (hNS), serving Network Servers (sNS) and forwarding Network Servers (fNS) across LoRa domains. Today, this entails a tedious manual process for generating the keys, certificates and configuration files to connect these servers on a peer-to-peer basis. This means that manual configurations grow quadratically with the number of LoRa networks involved. In addition, today there is no way to enable roaming across LoRa networks dynamically (i.e., not if these pre-configurations among the visited and the home/serving LoRa networks aren\u27t in place). Accordingly, presented herein are techniques to scale LoRaWAN roaming linearly, while not only automating the entire roaming process, but also allowing the acceptance of dynamic roaming requests. Opposite to conventional arrangements, such as roaming hubs, where roaming partners need to adhere to the hub\u27s rules for packet routing, service levels and trust, the techniques presented herein act transparently to the servers, keeping routing and data exchanges under the control of each peer

SRV6 SID/USID OAM FOR ADJ-SID VALIDATION

Techniques are presented for using a Loopback segment identifier (SID) that has the semantic of a Loopback address (terminate and process). Such a Loopback SID is assigned for both traditional SID and micro SID (uSID) that can be used in the segment-list of the probe packet to terminate the probe directly in the Nexthop of the adjacent SID (Adj-SID) which can be used to validate the forwarding semantic of the respective Adj-SID at the dataplane

INFORMATION CENTRIC NETWORKING INTEREST SIGNALED DYNAMIC DATA INTEGRITY VALIDATION OFFLOAD TO FOG NODE OR MOBILE EDGE COMPUTING NODE

Techniques are described herein for offloading the responsibility of validation to an edge node such as a fog router or Mobile Edge Computing (MEC) platform by signaling the same in an Interest packet or using another Out-of-Band (OOB) mechanism. Upon receiving the Interest packet, the edge node creates the local state entry in a Pending Interest Table (PIT) and marks the entry for local integrity validation. The edge node uses any mechanism to retrieve the public key and perform the validation on behalf of the sensors/end-users

IOT OAM CONNECTIVITY MODEL - END-TO-END APPLICATION LAYER RELAY PING FOR CONNECTIVITY CHECK

Methods are provided that allow for detecting the connectivity between an Internet-of-Things application (IoT-App) and a device at the application layer. In one method, an IoT gateway (IoT-GW) acts as a proxy that triggers a Request message to the device upon receiving a proxy request from the IoT-App with relevant details such as correlation identifier (ID) that can be used to correlate the response to the request. In another method, local statistics cached by the IoT-GW are leveraged for each device

SERVICE LAYER DEPENDENCY MAPPING BASED HEATMAP FOR FAULT ISOLATION

Techniques are described herein for a two-fold process where a first Machine Learning (ML) model is engaged in building a Dependency Mapping Table (DMT) based on the data from the network (network observations). An Interior Gateway Protocol (IGP) database, service graph information, and in-band Operations, Administration and Management (iOAM) data is leveraged to feed into the ML model to build the DMT. The DMT is built with a per physical element precision (fiber optical cable in each direction). In other words, the database is built in a way to enable identification of the list of (connected/non-connected) services and protocols that potentially relies on the fiber cable. In the second fold, the ML model uses the dependency mapping built in the previous phase to identify the potential cause for an issue and prioritize the relevant alarms. In addition, it may be tied together with existing failure prediction mechanisms for any layer that in turn will be used with the above database to prioritize the alarm/notification to an operator Operations Support System (OSS) and take any necessary pre-emptive action on the above layers

MULTIPART, MULTIPATH ENTROPY QUERY BASED ON EGRESS LINK COMBINATION

Dynamic entropy ranges are runtime operational state pre-use cached results of entropy calculations based on an actual state of links. These results may include proactive entropy calculations based on the up- and down-states of links. A non-binary state for links that describes their load can also be included. This information enables network optimization and traffic engineering by introducing the capability of querying additional details in the multipart-multipath entropy query. Querying can be accomplished using Label Switched Path (LSP) Ping or any other Operations, Administration, and Maintenance (OAM) extensions, such as Yet Another Next Generation (YANG). Upon receiving such a query, a transit node will reply back with entropy ranges for different combinations of link failure. The response is cached by the initiator and used accordingly based on failure detection