Juniper Networks, Inc.

Zhaohui Zhang

Ronald P Bonica

Kireeti Kompella

Shraddha Hegde

Lili Wang

Wen Lin

Nischal Sheth

John E Drake

Alex Baban

Yimin Shen

Arda Akman

Princy T Elizabeth

Srihari Ramachandra Sangli

WeeSan Lee

Constantine Dimitrios-Polychronopoulos

Alexander Arseniev

Ross W Callon

Vikram Nagarajan

SelvaKumar Sivaraj

Hannes Gredler

Kaliraj Vairavakkalai

Ina Minei

Ravi I Singh

Tapraj Singh

Jeffrey M Haas

Abhishek Deshmukh

Jonathan T Looney

Shijo Thomas

Ragupathi J

Kurt J Windisch

Krzysztof Grzegorz Szarkowicz

Ronald Bonica

M Ganesh Prasad

Pavana C V

Hongwen Zhang

Xiangrong Cai

Jaroslaw Adam Gralak

In some implementations, a network device may determine a route distinguisher (RD) that is associated with a bit index explicit replication (BIER) domain, wherein the network device participates in the BIER domain and one or more BIER sub-domains of the BIER domain. The network device may identify BIER sub-domain information associated with a BIER sub-domain of the one or more BIER sub-domains of the BIER domain. The network device may identify proxy information that is associated with the BIER sub-domain. The network device may send an advertisement that includes a BIER prefix of the network device, the BIER sub-domain information, the RD, and the proxy information. Sending the advertisement is to permit a receiving network device to store the proxy information in a bit index forwarding table (BIFT) of the receiving network device.

Bit index explicit replication (BIER) advertising with a route distinguisher

In an example, a method comprises executing, by an access network user plane function (ANUP) for a mobile network, an access network protocol to implement a connection with a user equipment (UE); implementing, by the ANUP, based on session data received from a control plane function of a mobile core network for the mobile network, an interface with a data network; and routing or switching, by the ANUP, packets between the connection with the UE and the interface with the data network.

Mobile network user plane with access network user plane function

In some implementations, a first PE network device may receive, from a first CE network device, traffic that includes at least an IP header. The first PE network device may determine whether the first PE network device is to remove the IP header, or the IP header and a UDP header included in the traffic, from the traffic. The first PE network device may send, to one or more second PE network devices, the traffic, wherein the first PE network device, prior to sending the traffic, updates the traffic by removing the IP header, or the IP header and a UDP header, when the first PE network device makes a removal determination, and wherein the first PE network device, prior to sending the traffic, does not update the traffic when the first PE network device does not make a removal determination.

Transport of VPN traffic with reduced header information

A network node may receive a packet that originated from a root network node and may process the packet to determine segment identifier (SID) information associated with a point-to-multipoint transport chain. The network node may determine, based on the SID information, that the network node is a transit leaf node in the point-to-multipoint transport chain. The network node may generate, based on determining that the network node is a transit leaf node in the point-to-multipoint transport chain, a copy of the packet and may process the copy of the packet to perform one or more actions. The network node may update, based on determining that the network node is a transit leaf node in the point-to-multipoint transport chain, the SID information and may send, after updating the SID information, the packet, with the updated SID information, to another network node.

Point-to-multipoint transport chain

In an Ethernet Virtual Private Network (EVPN) with a multi-homed Ethernet Segment (MHES), potential problems of core isolation are avoided in a way that also avoids the potential 'split brain' problems.

Reducing convergence time and/or avoiding split-brain in multi-homed ethernet segment deployments, such as esi-lag deployments

A first network device may receive a first advertisement of a network destination from a second network device and may detect multihoming with the second network device. The second network device may detect the multihoming with the first network device. The first network device and the second network may enable egress protection for the multihoming. The first network device may allocate, from a first pool, a protection group identifier for a group of multihomed network devices and may allocate, from a second pool, a network destination identifier for the network destination. The first network device may provide, to a network and the second network device, a second advertisement that includes the protection group identifier and the network destination identifier. The protection group identifier and the network destination identifier may cause the network to direct traffic for the network destination, via the group of multihomed network devices.

Dynamically detecting multihomed network devices and allocating protection group identifiers

Techniques are described by which a routing protocol, such as border gateway protocol (BGP), is extended to control propagation and importation of information using route targets (RTs) specified as bitmasks that encode link administrative group information. For example, a network control device (e.g., controller) is configured to allocate one or more subset of resources (e.g., nodes or links) of an underlay network to each of one or more virtual networks established over the underlay network. The controller generates a bitmask encoded with link administrative group information of the one or more links. The controller then outputs, to a plurality of provider edge (PE) routers that are participating in a respective virtual network, a routing protocol message to advertise the one or more subset of resources, wherein the routing protocol message includes a route target specified as the bitmask.

Bitmask route target in targeted distribution of information using a routing protocol

In some implementations, a network device may receive one or more packets via an incoming interface of the network device. The network device may forward, or refraining from forwarding, based on a destination address associated with the one or more packets and the incoming interface of the network device, the one or more packets. The network device may receive, prior to receiving the one or more packets, route information indicating the destination address, and at least one of a set of one or more authorized incoming interfaces of the network device or a set of one or more authorized identifiers that are associated with the destination address and may save the route information in an entry of a data structure. Forwarding, or refraining from forwarding, the one or more packets may further be based on the entry of the data structure.

Traffic filtering based on destination address and incoming interface of a network device

A network device may receive a non-Internet protocol (non-IP) frame with a particular size and may compare the particular size to a maximum transmission unit (MTU) associated with a path between the network device and another network device. The network device may divide the non-IP frame into fragments, based on the particular size being greater than the MTU and may prepend generic fragmentation headers to the fragments to generate fragments with headers, based on the particular size being greater than the MTU. The network device may add generic fragmentation header labels and transport labels to the fragments with the headers to generate fragments with headers and labels, based on the particular size being greater than the MTU. The network device may transmit the fragments with the headers and the labels to the other network device, via the path, based on the particular size being greater than the MTU.

Generic layer independent fragmentation of non-internet protocol frames

Techniques are described for using route target constraint to filter routes advertised to a node in a seamless Multiprotocol Label Switching (MPLS) network. For example, a first router of a first network may generate a first border gateway protocol (BGP) message to advertise routing information for a first node of the first network, the first BGP message indicating a transport class and specifying an address-specific route target, the transport class comprising one or more tunnels to the first node that share common characteristics. In response to receiving a second BGP message originated by second node of a second network, the second BGP message comprising the address-specific route target, the first router sends the first BGP message to a second router of the second network for sending to the second node to cause the second node to import the routing information.

Route target constraint to filter routes advertised to a node in a seamless MPLS or seamless SR network

A bit indexed explicit replication (BIER) network device may receive information indicating that a BIER proxy device is a BIER proxy for a first network device, and may transmit, to the BIER proxy device and based on receiving the information, a BIER-encapsulated multicast packet via a first tunnel between the BIER network device and the BIER proxy device. The BIER proxy device may be to transmit, via a second tunnel through the first network device, a first copy of the BIER-encapsulated multicast packet to a second network device.

Forwarding multicast data packets using bit index explicit replication (BIER) for BIER-incapable network devices

Techniques are described for signaling a resource reservation point-to-multipoint (P2MP) label switched path (LSP) in a ring network. For example, the techniques include sending a single resource reservation request message without the ingress needing to send multiple resource reservation request messages, one for each leaf network device of the P2MP ring LSP. The resource reservation request message includes a leaf identification object from which network devices of a P2MP ring LSP may explicitly or implicitly identify themselves as prospective leaf network devices of the P2MP ring LSP. A network device determined to be a leaf network device may send a resource reservation response message back to the ingress network device of the P2MP ring LSP and send a modified resource reservation request message (if explicit) and/or the same resource reservation request message (if implicit) to a next hop network device along the P2MP ring LSP.

Resource reservation techniques for point-to-multipoint tunnels on a ring network

Growing community of inventors

Westford, MA, United States of America

Zhaohui Zhang