Cisco Technology, Inc.

Accenture Global Solutions Limited

Nagendra B Kumar

Carlos M Pignataro

Ijsbrand Wijnands

Rajiv Asati

Eric C Rosen

Madhura Shivaram

Prakash Ghatage

Syed Kamran Raza

Nirav Sampat

Suraj Govind Jadhav

Sumeet Sawarkar

Kaushal Mody

Samatha Kottha

Madhu Sudhan H V

Techniques are described for routing service requests in a computer-implemented service environment. A received service request may be initially analyzed to determine a priority of the request. In some implementations, one or more actions may be automatically performed to provide an initial response to the requester. The text of the request may be analyzed to automatically determine a category of the request. In some implementations, a classification engine may determine the category of the request through use of a classification model that has been trained using one or more machine learning (ML) techniques and/or that employs Natural Language Processing (NLP). Based on the category, the request may be routed to agent(s) for handling. Routing may include generating a ticket that includes the request, the category, the priority, and/or other information, and the ticket may be provided to the appropriate agent(s) through a ticketing service.

Learning based routing of service requests

The present disclosure provides for carrying reachability information in an echo request message and/or an echo reply message, which can be used to reach an initiator when the initiator's address is unknown. An echo request message includes an FEC (forwarding equivalence class) stack that identifies a label switched path (LSP). The echo request message is received by a label switching routing element (LSR) on the LSP, and the echo request is originated by an initiator. In response to a detection that the FEC stack changes at the LSR, a segment reachability (SR) sub-TLV (type-length-value) element can be generated, where the SR sub-TLV includes reachability information that can be used to reach the initiator, and the reachability information includes an incoming label allocated by the LSR to reach the initiator.

MPLS LSP connectivity test when the initiator address is unknown

In one embodiment, an ingress network virtualization edge (NVE) in a computer network generates an echo packet, and sets an indication in the echo packet that the echo packet is for overlay path validation. In addition, the ingress NVE sets a message type of the echo packet to a generic echo request, and includes virtualization network (VN) context information within the echo packet. Once setting a destination address of the echo packet as an egress NVE address and including an indication to the egress NVE that the echo packet is an operations, administration, and management (OAM) message, the ingress NVE may then send the echo packet toward the egress NVE (e.g., to validate the VN context information and/or to reveal multipath traces).

Path-ping and ECMP-traceroute for IPV6 overlay virtualized networks

A receiving node receives a virtual LDP initialization (vInit) message from a first node, where the vInit message comprises a request to establish a vLDP session between a requesting node and a target node. If the receiving node does not own a destination address of the vInit message, the receiving node is determined to be a relay node. The relay node inserts a relay label into the vInit message, where the relay label is an outgoing label that the relay node uses to reach the first node, and forwards the vInit message toward the destination address. If the receiving node owns the destination address, the receiving node is determined to be the target node, which extracts a stack of relay labels from the vInit message. The relay labels are used to define a return path to the requesting node for messages transmitted over the vLDP session.

Virtual LDP session

Path-ping and ECMP-traceroute for IPv6 overlay virtualized networks

The present disclosure provides for avoiding packet loss and delay that occurs during conventional link switchover by moving link switchover logic from a downstream PORT (Protocol Independent Multicast Over Reliable Transport) routing element to an upstream PORT routing element. An upstream PORT routing element detects the failure of a forwarding interface for a multicast datastream, where the forwarding interface is coupled to a downstream PORT routing element. In response to detecting the failure, the upstream PORT routing element determines a set of candidate interfaces that are also coupled to the downstream PORT routing element. The upstream PORT routing element selects a new interface from the set of candidate interfaces and installs the new interface as a replacement forwarding interface for the multicast datastream.

PORT based redundant link protection

A method is provided in one example and includes receiving first address information from a protected node over a first label switched path having a first label. The first address information is associated with a first network element. A second label switched path has been previously established with the first network element. The method further includes establishing a targeted session with the first network element, assigning a second label to the second label switched path, and sending the second label to the first network element over the targeted session.

Growing community of inventors

Bengaluru, India

Nagendra B Kumar