Cisco Technology, Inc.

Mohamed Khalid

Rajiv Asati

Aamer Saeed Akhter

Brian Eliot Weis

Kenneth Durazzo

Pratima Pramod Sethi

Haseeb Sarwar Niazi

Sunil Cherukuri

Ciprian Pompiliu Popoviciu

Warren Scott Wainner

Kavitha Kamarthy

Paul M Quinn

Sheela Dixit Rowles

Manikchand Roopchand Bafna

John T Chapman

Scott Roy Fluhrer

Muhammad Afaq Khan

Scott Thomas Fanning

John M Gavin

William J Wei

Brian Cinque

James Neil Guichard

Gregory J Shepherd

Alvaro E Retana

Shree N Murthy

Randall R Stewart

Robert E Gleichauf

Richard Mandfred Pruss

Donnie Van Savage

Yiqun Cai

Khalil A Jabr

W Scott Wainner

Richard Manfred Pruss

Vivek Datar

Patrick Grossetete

Jason Guy

Vijay Bollapragada

Shashidhar P Patil

Shashi Sastry

Ramakrishnan Rajamoni

Haseeb Naizi

In an embodiment, a method comprises obtaining a second network address at a computer node, which has been already associated with a first network address and provided first keying information; sending, to a key server computer, an update message that comprises both the first network address and the second network address; using the first keying information to encrypt messages that the computer node sends from the second network address to one or more other members of a group.

Changing group member reachability information

An example method includes receiving a request for a cloud capability set during an Internet Key Exchange negotiation associated with a virtual private network (VPN) tunnel between a subscriber and a cloud, wherein the cloud capability set comprises one or more cloud capabilities, mapping the request to one or more cryptographic modules that can support the cloud capability set, and offloading the VPN tunnel to the one or more cryptographic modules. The request can be an Internet Security Association and Key Management Protocol (ISAKMP) packet listing the one or more cloud capabilities in a private payload. The method may further include splitting the VPN tunnel between the cryptographic modules if no single cryptographic module can support substantially all the cloud capabilities in the cloud capability set. In some embodiments, the request is compared with a service catalog comprising authorized cloud capabilities.

System and method for secure cloud service delivery with prioritized services in a network environment

Systems, methods, and other embodiments associated with any-to-any multicasting in a tunnel based virtual private network (VPN) are described. One example method includes calculating a resolved address for an unknown reverse path forwarding (RPF) neighbor in an any-to-any multicasting route. The resolved address is calculated using next hop resolution protocol (NHRP) resolution. The address is to be resolved based on control plane traffic. The NHRP address resolution is not to affect unicast routing. The example method may also include establishing the any-to-any multicasting route. Since the multicasting route is any-to-any (e.g., spoke-to-spoke), the multicasting route is not required to include a hub in the logical hub-and-spoke network.

Any-to any multicasting in a tunnel based virtual private network

In one embodiment, a first network device receives a priority message from a second network device, wherein the priority message conforms to a connection establishment protocol and indicates a priority associated with the second network device. The first network device obtains the priority from the priority message and stores the priority. The first network device allocates resources for at least one of control or data plane processing to the second network device in accordance with the priority.

Providing differentiated network services and priorities to VPN routers/clients

In an example embodiment, a method for selecting a communication path is provided. The method may comprise receiving data encapsulated in a transport protocol. In addition, a classification type and exit path information associated with the classification type may be received. The data is associated with the classification type and then is encapsulated in Stream Control Transmission Protocol (SCTP) based on the exit path information. This exit path information is associated with the classification type that is associated with the data.

Communication path selection

In one example, an Edge Quadrature Amplitude Modulation (EQAM) communicates EQAM information to a Modular Cable Modem Termination System (M-CMTS) core using a routing protocol that is configured on a packet switched network coupling the EQAM to the M-CMTS core. The EQAM generates a routing message according to the routing protocol and inserts EQAM information, such as a description of a modulated channel extending from the EQAM, the service-group information, etc., into the routing message. The EQAM then floods the EQAM information over at least portions of a routing domain by transmitting the routing message to an adjacent intermediary device.

Dynamic EQAM discovery in M-CMTS architecture

In an embodiment, a care-of address associated with a first node coupled to a communications network via an access node is received. The care-of address may be contained in a notification message sent by a home agent associated with the first node or by a binding update message sent by the first agent. The access node is identified using the care-of address. A request to tap communications associated with the first node at the access node is generated and the request is forwarded to the access node to cause communications associated with the first node to be tapped at the access node.

Managing mobile nodes in a lawful intercept architecture

Apparatus, methods and computer programs enable carrying service insertion architecture data plane packets in IPv4 or IPv6 networks by packaging destination addresses using IPv6 mechanisms. For example, a data processing apparatus is configured for receiving, from a service broker, a service label and an Internet Protocol version 6 (IPv6) address of a first service node; receiving an IPv4 packet requesting a service associated with the first service node; creating an IPv6 packet comprising a service label in a Flow Label field of the IPv6 packet, the IPv6 address of the first service node in a destination address field of the IPv6 packet, and the IPv4 packet in a payload field of the IPv6 packet; forwarding the IPv6 packet to the first service node. Approaches allow service insertion architecture support for all-IPv6 traffic including tunneled and non-tunneled techniques for environments in which user applications place data in the flow label field.

Service insertion in a computer network using internet protocol version 6 techniques

In one embodiment, a network device joins a first multicast tree to receive post-ad-inserted video content. The network device also joins a second multicast tree to receive the pre-ad-inserted video content. The content from the first multicast tree is forwarded by the network device to the receiver(s). The network device determines if it does not receive the content on the first multicast tree due to any failure, in which case, it delivers the content from the second multicast tree to the receiver(s). This enables the receiver to receive the original (pre-ad-inserted) content during the failure in first multicast tree. When the failure is resolved, the network device can go back to sending the content from the first multicast tree to the receiver(s).

Network based switchover to original content after ad-insertion device failure

Apparatus, methods, and other embodiments associated with providing service insertion architecture (SIA) differentiated services in a virtual private network (VPN) environment are described. Embodiments may provision an authentication, authorization, and accounting (AAA) server with user-to-SIA service-context mapping information. With the AAA server provisioned, embodiments may acquire, in an IPSec VPN hub, during IPSec tunnel user authentication, from the AAA server, the user-to-SIA service-context mapping information. With the mapping information available, embodiments may dynamically map an SIA service to an IPSec VPN tunnel user based on the service information acquired from the Service Broker or Pseudo-Service Broker. The dynamic mapping facilitates providing differentiated services in the SIA by facilitating forwarding an IPSec packet received on the IPSec VPN tunnel from the user to a service node associated with the SIA service based, at least in part, on the IPSec SADB entry modified using the service information.

Integrating service insertion architecture and virtual private network

Growing community of inventors

Cary, NC, United States of America

Mohamed Khalid